MCP in production: wiring business systems to language models

A year ago, connecting a language model to a business system meant writing custom glue for every pairing. Model Context Protocol changed the economics: build the server once, and any MCP-capable client can use it.

What changed in practice

The interesting shift isn’t technical elegance — it’s who can be connected. Tools that would never have justified a custom integration now get one for the cost of an afternoon. The long tail of business software is suddenly reachable.

The three problems that remain

Authentication is still where projects stall. OAuth flows across multiple accounts, browser handoffs, and token refresh remain the most fragile part of any deployment — and the part users experience first.

Tool design matters more than tool count. A server exposing forty granular endpoints performs worse in practice than one exposing eight well-shaped tools that match how the model actually reasons about tasks. Design the interface for the model, not for API completeness.

Trust boundaries need explicit design. Content a model reads through a tool is data, not instructions. Systems that don’t enforce that distinction are one malicious document away from an incident.

Our default architecture

For client work we now default to: MCP servers for anything the business already uses, capped tool counts per workflow, human confirmation on any irreversible action, and logging that a non-engineer can audit. The protocol is standard; the judgment is the product.