Why I Design MCP Servers Before Writing LangChain Chains

Every time I start a new agentic AI project, I face the same fork: reach for LangChain (or LlamaIndex, or LangGraph) and start building chains, or step back and think about the tool layer first.

I’ve shipped systems both ways. The MCP-first approach produces better architectures.

What “MCP-first” means in practice

Model Context Protocol is a specification for how AI models connect to external tools, data sources, and capabilities. An MCP server exposes a set of tools (each with a name, description, and input schema) that any compatible model can discover and call.

When I say “MCP-first,” I mean designing the tool layer as explicit, named MCP servers before deciding how to orchestrate them. The orchestration framework choice comes after.

Here’s why this matters:

It forces you to think in capabilities, not chains. A LangChain chain is a flow. An MCP server is a contract. Contracts are more durable than flows. When requirements change (they will), you update the orchestration, not the underlying capabilities.

It separates concerns cleanly. Your MCP server that queries BigQuery doesn’t care whether the caller is a Claude agent, a GPT-4o agent, or a custom orchestrator. It just exposes tools. This decoupling is worth a lot when you’re integrating with enterprise systems that evolve on their own schedule.

It makes the agent testable at the tool level. You can test your BigQuery MCP server independently before wiring it to any model. In enterprise contexts, this isolation is critical. Your data access patterns need sign-off before they touch a model.

The enterprise use case that convinced me

I was designing a procurement automation agent for a retail client. The initial instinct was to build a LangChain agent with tool calls inline. Common pattern, fast to prototype.

What we built instead: four MCP servers.

1. procurement-catalog: tools for querying vendor catalog and pricing data
2. approval-workflow: tools for reading and writing to the approval system
3. inventory-query: tools for real-time inventory status
4. policy-checker: tools for validating requests against procurement policy

The orchestrating agent (Claude, running via API) used these servers through Kong API Gateway. Each server had its own auth boundary, its own test suite, and its own deployment lifecycle.

When the client needed to swap out the approval workflow system six months later, it was a one-server change. Nothing in the agent’s orchestration layer changed.

When LangChain still makes sense

LangChain isn’t wrong. It’s just often applied too early. I reach for it when:

• I need RAG with complex retrieval logic (LangChain’s document loader + splitter ecosystem is genuinely useful here)
• The chain structure is the product and I need to serialize/inspect it
• I’m building a prototype and need to move fast

For production agents that need to connect to enterprise systems, the MCP layer is worth the extra setup time. The interfaces are more stable, the testing is cleaner, and the security boundaries are more explicit.

Starting point for a new MCP server

If you want to try this pattern, I’d start with the MCP TypeScript SDK. The scaffolding is lightweight and you can have a working tool server in under an hour.

Define your tools first as plain TypeScript interfaces. Then wrap them in the MCP server. You’ll find that the process of writing tool descriptions (which the model reads to decide when to use the tool) is itself a useful design exercise. If you can’t write a clear one-sentence description of what a tool does, the tool is probably doing too much.