Model Context Protocol Explained for Engineering Leaders

Why MCP Matters

The limiting factor for AI assistants at work is rarely the model. It's context. An assistant that can't see your tickets, your runbooks or your schema gives generic answers, and engineers compensate by copying and pasting, which is slow and leaks data in unmanaged ways.

Until recently, every connection between an assistant and a system was bespoke: a custom plugin for one tool, a function-calling integration for another, none of them reusable. The Model Context Protocol (MCP), which Anthropic released as an open protocol on 25 November 2024, tries to standardise that. The common analogy is USB for AI applications: build a connector once, use it with any compatible assistant.

In the two and a half months since launch, a lot of community servers have appeared and more developer tools have started adding client support. It's early, and the specification is still evolving, but it's moving quickly enough that engineering leaders should form a view now rather than discover it on engineers' laptops.

How It Works

MCP has three roles:

Host: the AI application the user interacts with, such as Claude Desktop or an AI-enabled editor.
Client: a component inside the host that maintains a connection to one server.
Server: a lightweight program that exposes a specific system (a ticket tracker, a documentation store, a database) through the protocol.

Messages use JSON-RPC 2.0. Servers expose three main primitives:

Primitive	Controlled by	What it is	Example
Tools	The model	Functions the model can decide to call, with a JSON Schema for inputs	`create_ticket`, `run_query`
Resources	The application	Data the host can read and include as context	A runbook, a table schema, a file
Prompts	The user	Reusable templates the user can pick	"Summarise this incident"

There are two transports in the current specification. stdio runs the server as a local subprocess of the host, which is simple and common for developer tools. HTTP with Server-Sent Events lets a server run remotely and be shared, which is what you'd want for centrally managed internal integrations.

Configuring a local server in Claude Desktop looks like this:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://readonly_user@localhost:5432/analytics"
      ]
    }
  }
}

The reference servers Anthropic published at launch cover systems such as GitHub, Slack, Google Drive, Git and PostgreSQL. Writing your own is a small job with the official TypeScript and Python SDKs.

What It Unlocks Internally

The use cases I find most compelling for an engineering organisation:

Tickets: "summarise the open bugs tagged checkout and draft a plan" without copying twenty tickets into a chat window.
Documentation and runbooks: answers grounded in your own architecture decision records and runbooks rather than general knowledge.
Read-only data access: exploring a schema or answering an ad hoc question against an analytics replica. For a data platform like our Redshift, Looker and dbt stack, a read-only connection with the dbt model documentation as a resource is an obvious candidate.
Operational context: recent deploys, feature flag states and error trends during an incident.

The Security Risks

The same property that makes MCP useful, letting a model take actions against real systems, is what makes it risky. Four concerns stand out.

Prompt injection

Any text a server returns becomes input to the model. A ticket description, a web page or a support email can contain instructions ("ignore previous instructions and ...") that the model may follow. If that model also has a tool that can write or send data, you have a path from untrusted content to action. This is not a solved problem in any assistant, with or without MCP.

Over-privileged tokens

A server acts with whatever credentials you give it. The easy route is an engineer's personal access token with full scopes, so the assistant can do everything that engineer can do, including deleting things. Least privilege matters more here than for a human, because the "user" can be manipulated by content it reads.

Untrusted servers

Community servers are code running on your machine or network with access to your credentials. Many are small projects with one maintainer. Installing one via npx is running unreviewed third-party code, and a server's tool descriptions can themselves carry malicious instructions to the model.

Data exfiltration

Combine a server that reads sensitive data with one that can send data outward (web requests, email, a public issue comment) and a single injected instruction could move data out of your organisation. The risk comes from the combination of tools, not any one server.

A Safe Rollout Approach

My approach, in order:

Inventory first. Ask who is already using MCP servers. Some engineers will be.
Approved server list. Prefer official servers from the vendor or the reference repository; review and pin versions of anything else. Build your own for internal systems.
Read-only by default. Start with resources and read-only tools. Add write tools one at a time, with human confirmation for each call.
Dedicated, scoped credentials. Service accounts or fine-grained tokens per server, never personal admin tokens. Point database servers at read replicas with restricted roles.
Separate sensitive and outbound tools. Avoid sessions that combine access to customer data with tools that can send data externally.
Log tool calls. For remote servers, log every call and its arguments so you can audit what happened.
Keep customer data out initially. Start with engineering metadata such as tickets, docs and schemas, not personal data.

Stage	Recommended posture
Startup	Allow reference and vendor servers locally, read-only, scoped tokens; a one-page policy
Scaleup	Approved list, internally built servers for core systems, central remote servers with logging
Enterprise	Formal review for each server, gateway-style central access control, integration with identity and data classification

What I'd Watch

The specification is young. Authentication for remote servers is an open area, and I'd expect it to change. Tooling for central management is thin. Client support across editors is still arriving. None of that is a reason to wait, but it is a reason to keep deployments reversible and not build anything critical on a specific version yet.

The Takeaway

MCP makes giving AI assistants real context straightforward, which is both its value and its risk. Treat MCP servers like any other integration with privileged access: approved sources, least-privilege credentials, read-only by default and logging. Engineering leaders who set that posture now will be able to say yes to the useful cases rather than cleaning up after the risky ones.