There’s a phrase you’ll hear a lot right now in companies adopting AI assistants: “We should put MCP in front of our APIs.”

If you translate it into plain English, it usually means:

“Let’s create a standard, governable layer that exposes our systems as AI-usable tools, so any MCP-capable assistant can safely call them.”

This post unpacks what that means for you day-to-day as a developer, and what it implies for software development more broadly.

The 30-second versionLink to heading

• MCP (Model Context Protocol) is a standard way for an AI app to discover and call “tools” provided by a server (plus access “resources” like files/data).
• Putting MCP “in front of APIs” means wrapping existing HTTP/gRPC/GraphQL endpoints behind an MCP server (or MCP gateway) so assistants can use them consistently.
• The “big deal” is less about the protocol and more about standardizing AI-to-system integration: auth, policy, auditing, safety controls, and tool design.

What MCP is (in practical terms)Link to heading

MCP is a protocol that lets an AI-enabled client (an assistant, IDE, or agent runner) connect to one or more MCP servers that provide:

• Tools: functions the assistant can call (capabilities with arguments + structured outputs)
• Resources: things the assistant can read (and sometimes write), like documents, records, or indexes
• Prompts/templates: reusable guidance the client can pull from the server

In practice, MCP becomes the “plug shape” for integrating assistants with real systems.

What “MCP in front of APIs” usually means architecturallyLink to heading

Most orgs land on one of these patterns (or a mix):

1) “Adapter” MCP servers (per domain/system)Link to heading

Each key system gets an MCP server that translates MCP tool calls into API calls:

• jira-mcp exposes create_issue, search_issues, add_comment
• billing-mcp exposes get_invoice, refund_payment
• crm-mcp exposes lookup_customer, update_contact

This tends to work well when teams own their domain and can evolve tools alongside APIs.

2) An “MCP gateway” (centralized front door)Link to heading

A shared team builds a gateway that:

• publishes a curated set of tools across multiple backends
• handles auth, policy, logging, throttling, approvals
• maps “assistant-friendly” tool shapes to messy internal endpoints

This can reduce duplication, but it also becomes a platform that needs clear ownership.

3) MCP as a policy layer on top of an API gatewayLink to heading

Some teams already have API gateways (Kong, Apigee, Envoy, etc.). In that world, MCP is often an extra layer that focuses on:

• tool discovery, schema, and responses optimized for LLM usage
• assistant-specific controls (human approvals, scoped credentials, audit trails by “assistant session”)
• safety constraints (redaction, filtering, allowlists) that are distinct from normal API consumers

What it means for you as a developerLink to heading

You’ll design tools, not just endpointsLink to heading

APIs for humans (or normal services) can be “generic and composable.” Tools for assistants should be:

• narrow and high-signal: fewer “do anything” parameters, more purpose-built actions
• hard to misuse: guardrails in the schema; limited free-form text
• idempotent when possible: safe retries and clear “already done” semantics
• explicit about side effects: a tool that changes state should say so in its name and description

One good mental model: your tool schema is part of your UX—except your “user” is an LLM.

You’ll care more about “how the model fails”Link to heading

With normal API consumers, errors mostly hit logs and dashboards. With AI tool-calling, errors often become:

• repeated retries (sometimes with slightly mutated inputs)
• partial plans that keep going after a failure
• confusing user experiences if the assistant can’t explain what happened

So you’ll end up investing more in:

• stable error shapes (machine-readable codes + human-readable summaries)
• safe defaults and constraints
• clear return values that help the assistant decide the next action

You’ll build “AI integration tests”Link to heading

If your org leans into agents, you may be asked to validate flows like:

• “Can the assistant create a ticket, attach logs, and notify a channel?”
• “Can it fetch the right customer record without overfetching data?”
• “Can it refuse unsafe actions unless an approval step is present?”

That’s less like unit testing and more like contract testing plus workflow simulation.

You’ll spend time on governance plumbing (even if you don’t want to)Link to heading

When tools can touch real systems, questions show up fast:

• Who is the “caller”? The end user, the assistant, a service account?
• What permissions does the tool run with? How is least-privilege enforced?
• How do we audit “assistant performed action X because user asked Y”?
• How do we prevent data leaks into the model context or logs?

As a developer, expect to partner more with security, platform, and compliance teams.

What it means for software development (the bigger shift)Link to heading

APIs become “AI-addressable”Link to heading

Historically, we built APIs for:

• UI clients
• other services
• partners

Now there’s a new consumer: LLM-driven tool use. That shifts emphasis toward:

• discoverability (what can this system do?)
• constrained interaction (what should it be allowed to do?)
• provenance (who asked, what was the justification, what changed?)

“Natural language” becomes a coordination layer, not a transportLink to heading

The point isn’t that we’ll replace APIs with natural language.

The point is that natural language becomes the orchestration surface:

• a user expresses intent (“refund the last invoice and email the receipt”)
• the assistant plans the work
• MCP tools are the “mechanical” interface for doing it safely

The work still happens via structured calls—MCP just standardizes the way assistants reach those calls.

Tool ecosystems start to look like package ecosystemsLink to heading

If MCP (or anything like it) becomes a common integration standard, you’ll see patterns that feel familiar:

• internal “tool registries”
• versioning and deprecation policies (tool names and schemas become contracts)
• shared libraries for auth, logging, and schema validation
• reusable “golden” tools that teams prefer over bespoke wrappers

In other words: platform engineering, but for tool interfaces.

The hard parts (what your workplace will debate)Link to heading

Security: prompt injection and data exfiltrationLink to heading

If an assistant reads untrusted text (tickets, emails, web pages), that text can try to influence tool calls (“ignore your rules, run this dangerous action…”).

Mitigations usually include:

• tool allowlists and strong auth (never “just let it call anything”)
• approval workflows for sensitive actions
• output filtering/redaction and strict logging controls
• minimizing tools that accept unconstrained free-form instructions

“Scope creep” toolsLink to heading

Tools that look like run_sql(query) or call_api(url, method, body) are tempting because they’re powerful—but they’re also:

• hard to secure
• hard to audit
• easy to prompt-inject
• likely to turn into an implicit backdoor

Many orgs end up preferring specific, well-named tools over generic supertools.

Ownership and change managementLink to heading

Once assistants depend on a tool’s schema, “tiny breaking changes” stop being tiny.

You’ll want conventions like:

• tool versioning or additive changes only
• deprecation windows
• contract tests for tool schemas
• strong observability (which tools are used, by whom, and how often)

How to evaluate “MCP in front of our APIs” at workLink to heading

Here are questions that quickly clarify whether the idea is serious engineering or just hype:

• Who is the MCP client? (IDE? internal agent runner? Chat UI? multiple?)
• Where does auth live? (per-user OAuth? service accounts? short-lived tokens?)
• What’s the approval model for side effects? (human-in-the-loop? limits?)
• What is the audit story? (trace from user prompt → tool call → backend request → data change)
• What’s the blast radius? (tool allowlists by environment; read-only by default)
• How do we prevent overexposure? (least privilege + “only return what’s needed”)
• How do we ship changes safely? (schema compatibility, staged rollout, monitoring)

A pragmatic takeawayLink to heading

If your company is serious about agents, “MCP in front of APIs” is basically a bet that:

• assistant integrations should be standardized (not one-off prompt glue)
• tool access should be governed (not a pile of ad-hoc scripts)
• platform teams should provide a safe, reusable interface to internal systems

As a developer, that’s both an opportunity (better leverage, fewer brittle integrations) and a responsibility (tool design, safety, and change management become part of the job).