An MCP server is a lightweight process that exposes capabilities, such as file access, database queries or API calls, to a language model using the Model Context Protocol. It lets a model request and use external resources in a structured, consistent way without custom integration code for every tool.
Background
Language models have no persistent access to systems outside their inference call. If a model needs to read a file, query a database or call an API, the application must handle that plumbing. Before any standard existed, every team solved this differently: custom function schemas, bespoke JSON formats, hand-rolled glue code.
Anthropic published the Model Context Protocol (MCP) in late 2024 to standardise how models and tools communicate. It defines a client-server architecture. The model-side application is the client; each external capability is wrapped in a server.
What an MCP server actually does
An MCP server declares three types of things:
- Tools. Functions the model can call, such as running a shell command, searching a codebase or submitting a form.
- Resources. Readable data sources, such as files, database rows or API responses, served on request.
- Prompts. Reusable prompt templates the server exposes so the client can invoke them by name.
The server runs as a separate process. It communicates with the client over a transport layer, typically standard input/output for local servers or HTTP with server-sent events for remote ones. The client discovers what the server offers by querying its manifest at startup.
Why a standard protocol helps
Without a shared protocol, connecting a model to ten different tools means writing ten different integration layers, and maintaining them as tool interfaces change. MCP makes tool connections composable. A client that speaks MCP can connect to any compliant server without bespoke code.
This matters for agentic coding and broader agentic workflows, where a model may need to call many tools in sequence, passing results from one into the next. A standard protocol reduces the surface area where things break.
It also makes capability boundaries explicit. The server declares exactly what it exposes. The model cannot reach beyond that declaration, which is relevant for security: a misconfigured or malicious server is a defined attack surface rather than an open socket.
How MCP servers fit into production systems
In practice, an engineering team might run several MCP servers alongside their application:
- One exposing their internal documentation as a resource
- One wrapping their database with read-only query tools
- One providing access to a code execution sandbox
The AI agent or coding tool connects to each at startup and uses whichever capabilities the task requires. The client, often an AI gateway or orchestration layer, handles routing.
MCP is relatively new. Adoption is growing in developer tooling and coding agents, but production deployments vary widely in maturity. Teams building on it should expect the specification to evolve.
Risks worth knowing
MCP servers expand what a model can do, which increases the consequence of errors. A tool that writes to a database or executes code can cause real damage if the model misuses it. Prompt injection is a particular concern: a malicious input could instruct the model to call a destructive tool.
Good practice treats MCP tool permissions the same way it treats API permissions: least privilege, explicit scopes, logging of calls made.
What we test for
Engineers working with agentic systems need to understand how tools are exposed to models and where the failure modes sit. Our vetting covers this directly: in the AI-native assessment, candidates are scored on tool orchestration and AI output verification, both of which surface quickly when someone is designing or debugging an MCP-backed workflow. Spec-driven development matters here too, since poor tool definitions produce the same poor results whether the boundary is a function call or an MCP interface. Full details at how we vet.
Short answers
Is MCP specific to Claude or Anthropic models?
No. Anthropic published the spec, but MCP is an open protocol. Any model client can implement it, and several coding tools and frameworks outside the Anthropic ecosystem have added MCP support.
What is the difference between an MCP server and a function-calling schema?
Function-calling schemas are defined per-model and per-integration. MCP is a transport-level standard: any compliant client connects to any compliant server without custom code. It wraps the concept of callable tools in a consistent protocol.
Can an MCP server expose read-write access to a database?
Yes, but this should be treated carefully. The server can expose write tools, but access should follow least-privilege principles. Logging every tool call the model makes is advisable before granting any destructive capability.