MCP is becoming table stakes—treat it like an API program

The Model Context Protocol has moved from an interesting standard to an expected skill faster than most platform teams have adjusted. Agentic Ready's June 2026 Agentic AI Jobs Index found MCP in 454 of the 2,072 agentic roles it tracked, well ahead of multi-agent architecture (369) and evals (219). The protocol itself keeps maturing: its latest specification revision, dated 2026-07-28, shipped a week ago.

When something becomes table stakes, the risk shifts. The question is no longer whether your teams will connect agents to internal systems through MCP. They already are, often from a configuration file on a laptop. The question is whether those connections are managed like the APIs they effectively are.

What MCP actually standardizes

MCP defines how a host application (an IDE, a chat client, an agent runtime) talks to servers that expose tools, resources, and prompts, over local stdio or streamable HTTP. The value is that you write an integration once instead of once per framework. The risk scales identically: one well-written server gives every connected agent a new capability, and one careless server gives every connected agent a new way to cause damage.

Six things an MCP program needs

Treat each internal MCP server the way you would treat a new public API, with an owner, a review, and a lifecycle.

1. An inventory. Keep a registry of approved servers: which system each touches, who owns it, which version is approved, and which teams use it. Unknown servers in a developer's config are the agent-era version of shadow IT.

2. Identity and scopes. Servers that reach remote systems should authenticate with OAuth or scoped, short-lived credentials, never a shared admin token in an environment variable. Scope tokens to the minimum: a server that drafts tickets does not need permission to close them.

3. Strict schemas. Define every tool's input with an explicit JSON Schema, reject unknown fields, and validate types and ranges on the server. The model will occasionally send something creative. The server should refuse it rather than interpret it.

4. Side-effect discipline. Separate read tools from write tools. Make writes idempotent where possible, for example with a request ID so a retried "create ticket" does not create two. Put destructive or external-facing actions behind a confirmation step in the host.

5. Audit logging. Record every invocation: which agent and user, which tool, a hash or redacted copy of the arguments, the result class, and the latency. When something goes wrong, this is the record your security team will ask for first.

6. Rate limits. Agents retry with confidence. A loop that calls a search tool 400 times in a minute is not malicious, but it can still take down a fragile backend. Throttle per session and per user.

Mapping it to the threat model

The OWASP Top 10 for Agentic Applications, released in December 2025, gives security teams names for the risks MCP concentrates. Several of its categories land directly on tool servers:

• Tool misuse: an agent calling a legitimate tool for an illegitimate purpose. Narrow tools and confirmation on writes reduce it.
• Identity and privilege abuse: a server acting with more authority than the requesting user has. Per-user scopes reduce it.
• Agentic supply chain: installing a third-party server nobody reviewed. The inventory and version pinning reduce it.
• Unexpected code execution: servers that shell out or evaluate input. Sandboxing reduces it, and so does not building such tools unless they are the point.

The useful reframe is that MCP puts these risks in one reviewable place. A team that reviews its servers can manage them. A team that lets servers accumulate cannot.

A reference shape for your first server

Aim for something deliberately boring:

• Wrap one system of record, not five.
• Expose three to seven well-named tools. If you are writing tool number thirty, split the server or rethink the abstraction.
• Publish reference material, such as a policy document, as a resource the host can fetch, instead of pasting it into every system prompt.
• Register the server in project-level configuration so the whole team runs the same approved version.
• Exercise it with the protocol inspector and with deliberately hostile prompts before anyone depends on it.

Patterns to retire early

A few patterns appear in almost every early rollout and should go quickly: the "everything" server that bundles filesystem, shell, and production database access; tools that accept free-text commands instead of structured arguments; personal data passed in arguments without redaction; and servers that report vague success when a call actually failed, which invites the model to invent a result.

The payoff

A well-run MCP program makes agents faster to build, not slower. Once the identity, schema, and logging patterns exist, each new integration is a small, reviewable change rather than a security debate. That is the same bargain API programs offered a decade ago, and it is still a good one.

Sources cited

• Agentic Ready (Prefactor), Agentic AI Jobs Index — June 2026 report (snapshot June 23, 2026)
• Model Context Protocol specification, revision 2026-07-28 (released July 28, 2026)
• OWASP GenAI Security Project, Top 10 for Agentic Applications 2026 (released December 9, 2025)