What Nobody Tells You About Running MCP in Production

Example of production MCP governance controls: permissions, risk detection, secure credentials, and audit logging.

Over the last few weeks, I’ve spent a lot of time talking to developers, API teams, and engineers building with the Model Context Protocol (MCP).

Like many people entering the space, I initially assumed the hard part would be generating MCP tools from existing APIs.

I was wrong.

The more conversations I had, the more I realized that tool generation is rapidly becoming a solved problem.

The real challenges begin after the MCP server exists.

What Is an MCP Server?

For those new to MCP, the Model Context Protocol is a standard that allows AI applications such as Claude, Cursor, and other agent-based systems to interact with external tools and data sources.

An MCP server exposes tools that AI models can discover and use.

These tools often map directly to existing APIs, databases, file systems, internal services, or business applications.

A simple example:

• GET /customers → list customers
• POST /customers → create customer
• DELETE /customers/{id} → delete customer

In theory, exposing an API through MCP sounds straightforward.

In practice, that’s where the difficult questions start.

Tool Generation Is Getting Easier

Today, there are multiple ways to generate MCP tools from existing systems.

Teams can:

• Generate tools from OpenAPI specifications
• Convert Postman collections
• Use MCP frameworks
• Build custom servers manually

Creating the tool definitions is no longer the biggest obstacle.

Most teams already have APIs.

Most teams already have documentation.

Most teams already have authentication.

The challenge is deciding what should happen when AI agents gain access to those systems.

The First Problem: Permissions

One of the most common concerns I hear is surprisingly simple:

Should this tool even be available?

A typical business API contains dozens or hundreds of endpoints.

Some are relatively harmless:

• Get customer
• Search invoices
• List orders
• Retrieve product information

Others are much more sensitive:

• Delete customer
• Issue refund
• Revoke API key
• Modify permissions
• Change billing settings

Many early MCP implementations expose the entire API surface.

That might be fine for demos.

It becomes much more concerning in production.

The question quickly shifts from:

“Can we expose this API?”

to:

“Which parts of this API should an AI agent actually be allowed to use?”

The Second Problem: Credentials

Authentication is another area that looks simple until you deploy.

Many APIs require:

• Bearer tokens
• API keys
• OAuth credentials
• Custom authentication headers

A common mistake is exposing secrets too broadly.

Production systems usually need a dedicated layer that:

• Stores credentials securely
• Injects them server-side
• Prevents models from seeing secrets directly
• Rotates credentials when necessary

The challenge is no longer connecting to an API.

The challenge is doing it safely.

The Third Problem: Auditability

This is where conversations become particularly interesting.

When an AI agent performs an action, teams eventually ask:

What happened?

Questions start appearing:

• Which tool was called?
• Who triggered it?
• What arguments were used?
• Was the request successful?
• Was it blocked?
• Why was it blocked?

Without audit logs, answers are often difficult to obtain.

As MCP adoption grows, auditability is becoming a requirement rather than a nice-to-have feature.

The Fourth Problem: Human Approval

Not every action should be automated.

Imagine an agent attempting to:

• Delete a customer
• Issue a refund
• Modify permissions
• Revoke access

Many organizations are hesitant to allow these actions without human review.

This creates a growing need for approval workflows.

Instead of immediately executing a sensitive action, the system can:

1. Create an approval request
2. Notify a human
3. Require explicit approval
4. Execute only after approval

This approach keeps humans involved where the consequences matter most.

MCP Conversations Are Becoming Governance Conversations

One pattern surprised me more than anything else.

Most discussions start with tools.

They eventually become discussions about governance.

Teams ask questions such as:

• How do we classify risky tools?
• How do we separate read and write operations?
• How do we manage credentials?
• How do we approve sensitive actions?
• How do we monitor agent behavior?
• How do we audit decisions?

These questions rarely appear in tutorials.

Yet they are often the first questions raised by production teams.

The Future of MCP

The Model Context Protocol is growing rapidly because it solves a real problem.

AI agents need a standard way to interact with external systems.

That part is becoming increasingly clear.

What remains less discussed is everything surrounding those interactions.

Permissions.

Approvals.

Credentials.

Audit logs.

Governance.

Risk management.

In many ways, these topics may become more important than the generation of tools itself.

Generating a tool is easy.

Trusting an AI agent to use that tool in production is where the real work begins.

Author note: I’m currently building MCP infrastructure and spending a lot of time talking with teams deploying MCP in production. If you’re working with MCP, AI agents, API governance, or production deployments, I’d love to hear about your experiences.

https://www.mcpforge.tech