The short answer
Use MCP when the tool you are connecting will be reused across multiple agents, when an official or well-maintained server already exists, and when you want capability discovery and human-readable tool descriptions. Use custom integration when you need fine-grained control over auth, when latency matters more than reusability, or when the workflow is a one-off. Most production stacks end up running both — MCP for the standard surface area (Google, GitHub, Notion, Postgres) and custom integration for the proprietary or performance-critical pieces.
What MCP actually solves
Model Context Protocol standardizes how an LLM agent discovers, describes, and invokes tools. The win is reusability — the same MCP server can serve multiple agents, multiple model providers, and multiple frameworks. The win is also discoverability — the agent can introspect available capabilities rather than relying on hard-coded tool definitions.
When MCP is the right call
Tools used by more than one agent. Tools with well-maintained official servers (Google Workspace, GitHub, Postgres, Slack, Notion). Workflows where capability discovery matters — an agent that adapts to new tools without code changes. Environments where you want to centralize auth and audit per tool rather than per agent.
When custom integration wins
Latency-critical paths where the MCP indirection costs measurable wall-clock time. Tools with proprietary auth flows that no MCP server has implemented well. One-off integrations where the reuse value is zero. Cases where you need streaming responses, request batching, or specialized error handling that the generic MCP server does not expose.
The hybrid stack we actually deploy
In most production deployments, the standard surface area (Drive, GitHub, Slack, Postgres, Notion, calendars) runs via MCP servers — official where they exist, community-maintained where they do not. The proprietary CRM, the billing system, the warehouse, and any latency-critical tool runs via custom integration. The agent framework treats both as tool calls; the difference is invisible at the reasoning layer.
Security implications you should not skip
MCP servers run with the permissions you grant them — over-granting is the most common mistake. Scope each server to the minimum permission set, audit the tools it exposes, and treat third-party MCP servers with the same scrutiny as any third-party dependency. The 2025 mcp-remote incidents demonstrated that unvetted MCP servers are a real supply-chain risk.
Key takeaways
- MCP for reusable, well-maintained surfaces; custom for latency, auth, or one-offs.
- Capability discovery is MCP's underrated win — agents adapt without code changes.
- Hybrid stacks (MCP + custom) are the production norm, not an anti-pattern.
- Treat third-party MCP servers as third-party dependencies with full supply-chain scrutiny.
Frequently asked questions
Is MCP production-ready in 2026?+
Yes for the well-maintained surfaces (Google, GitHub, Postgres, Slack, Notion). The ecosystem is maturing fast and most enterprise tool vendors have either shipped or committed to MCP servers.
Can we build our own MCP server for an internal tool?+
Yes, and it is often the right call when more than one agent will use the tool. The MCP server becomes the internal API layer for agent consumption.
Do we lose observability with MCP?+
No — well-implemented MCP servers expose logging and tracing that integrates with your observability stack. The mistake is using off-the-shelf servers without confirming they log what you need to audit.