How Model Context Protocol (MCP) works in practice
Before MCP, every pairing of an AI application and an external system required a custom connector, creating an N-by-M integration bottleneck across chat clients, IDEs, databases, and SaaS APIs. MCP replaces bespoke glue code with a client-host-server architecture built on JSON-RPC 2.0 messages sent over standard input/output (stdio) for local processes or Streamable HTTP for remote deployments.
An MCP server exposes three core primitives to any compliant host application: Resources (read-only data streams such as database schemas, log files, or CRM records), Tools (executable functions with JSON Schema inputs that allow the model to query APIs or mutate state), and Prompts (reusable interaction templates). When a session starts, the client and server negotiate capabilities so the model discovers available tools dynamically.
In practice, a Manchester SaaS engineering team runs internal MCP servers for Postgres, Sentry, and Linear. Whether a developer works inside Claude Code, Cursor, or an internal incident-triage agent, the assistant uses the exact same MCP server definitions to inspect a failing production trace, check read-replica schema constraints, and draft a linked bug ticket.
Why it matters and trade-offs
MCP has become the de facto USB-C port for enterprise AI tooling, backed by Anthropic, OpenAI, Google, Microsoft, and AWS under the Linux Foundation's Agentic AI Foundation. Writing one well-tested MCP server lets an organisation expose an internal platform to every approved coding agent and workflow orchestrator simultaneously, avoiding vendor lock-in when switching underlying models or developer tools.
However, MCP introduces security and context-window governance challenges. Loading dozens of verbose MCP tool definitions into a session consumes thousands of input tokens before the user types a word and degrades tool-selection accuracy. Furthermore, combining untrusted third-party MCP servers with internal write-capable tools creates severe indirect prompt-injection paths, requiring OAuth 2.1 scoping, container sandboxing, and human approval gates on destructive actions.