MCP in Production: A Field Guide to Model Context Protocol for Internal Tools

Model Context Protocol went from "interesting spec" to "standard we deploy" sometime in early 2025. We've now deployed MCP servers inside four different engineering orgs. Here's everything we've learned.

What MCP actually solves

Before MCP, every agent integration was bespoke. You had a different SDK for Notion, a different one for Linear, a different one for your internal Confluence. The model had no standardized way to understand what tools were available, what they did, or how to call them.

MCP gives you: a standard protocol for exposing tools, resources (files, documents, data), and prompts to any model. Once you've built an MCP server for your internal wiki, every agent that uses that server has access — without you needing to build the integration twice.

The production concerns nobody talks about

Auth is the first hard problem. MCP servers need to authenticate callers and authorize what tools they can use. The spec is minimal on this — you'll need to build it yourself. We use short-lived JWTs with tool-level scopes.

Rate limiting is the second. Your MCP server might be called by 10 agents simultaneously, all trying to read from the same database. Build rate limiting at the MCP server level, not just at the downstream resource.

Observability is the third. Log every tool call, every resource fetch, every error. This is where Langfuse earns its keep.

Deployment patterns we use

For internal tools: a small Node.js service running behind your internal auth proxy. For external-facing MCP (like a customer-facing support agent), we use Cloudflare Workers with JWT verification on every request.

Our current stack for MCP

`@modelcontextprotocol/sdk` (TypeScript) for the server, Claude's tool-use API for the client, Langfuse for tracing, short-lived JWTs from your existing auth system for auth.