What is MCP?
The Model Context Protocol (MCP) is a standardized way to connect AI agents to external tools and data sources via dedicated server processes. Instead of defining tools inline in your agent code, MCP runs a separate server that exposes tools over a structured protocol.
MCP vs. Regular Tool Calls
A model tool call describes an intended action; the host executes it. That host can call a local function, a CLI, a remote API or an MCP server. MCP standardizes discovery and communication, not the model’s tool-call mechanism.
Regular Tool Calls
Host-defined tools may run locally or remotely. Integration and lifecycle behavior are specific to the application.
const tools = {
get_weather: (location) => {
return fetchWeather(location)
}
}
// Direct function call
result = tools.get_weather("Tokyo")MCP Servers
Servers expose a shared protocol over local stdio or Streamable HTTP. Serialization and process boundaries add overhead; a network connection is not required for stdio.
// Separate server process
const client = new MCPClient()
// Discover tools via protocol
tools = await client.listTools()
// Call over network
result = await client.invoke(
"get_weather", { location: "Tokyo" }
)When MCP Makes Sense
MCP shines in specific scenarios where its additional complexity pays off.
Multi-Language Teams
Your tools are written in Python but your agent is in TypeScript, or vice versa.
Shared Tool Ecosystem
Multiple agents across different projects need to access the same tools.
Enterprise Integration
You need to expose existing internal services as agent tools without modifying them.
Tool Marketplace
You want to use community-maintained tools without copying code into your project.
When MCP is Overkill
For many use cases, MCP adds unnecessary complexity.
Single-Language Projects
If your tools and agent are in the same language, inline functions are simpler and faster.
Simple Agents
A chatbot with a few tools doesn't need the overhead of running separate server processes.
Rapid Prototyping
When iterating quickly, the indirection of MCP slows down development.
Latency-Sensitive Apps
Remote transport adds network latency; local stdio adds process and serialization overhead. Measure the complete tool path before choosing an integration.
The Three Core Primitives
MCP servers can expose three types of capabilities to clients. Most documentation focuses on tools, but resources and prompts are equally important.
Tools
Functions the model can call to perform actions. Tools are invoked by the LLM to interact with external systems—search databases, call APIs, execute code.
query_database, send_email, create_fileResources
Data the server can provide for context. Resources are read-only content the client can fetch—files, database records, API responses—that inform the model's responses.
file://config.json, db://users/123, api://weather/todayPrompts
Pre-defined prompt templates the server offers. Prompts are reusable interaction patterns with parameters—like "summarize this document" or "review this code".
summarize_document, code_review, translate_textServer Lifecycle
MCP connections follow a structured lifecycle with capability negotiation at startup.
Initialize
Client sends initialize request with protocol version and client capabilities. This is always the first message.
Capabilities Exchange
Server responds with its supported capabilities (tools, resources, prompts) and protocol version agreement.
Initialized
Client sends initialized notification to confirm setup is complete. Normal operations can now begin.
Operation
Client and server exchange protocol methods such as tools/list, tools/call, resources/list, resources/read, prompts/list and prompts/get.
Shutdown
Either side can close the connection. Servers should clean up resources (database connections, file handles).
Real MCP Servers
The MCP ecosystem includes official reference servers and community-built integrations for popular platforms.
Filesystem
Secure file operations with configurable access controls. Read, write, and manage files within specified directories.
GitHub
Repository management, issues, pull requests, and code search. Requires a personal access token.
Slack
Channel management, messaging, and workspace interactions. Post messages, read history, manage threads.
PostgreSQL
Database queries with read-only or read-write access. Execute SQL and explore schema.
Memory
Knowledge graph-based persistent memory. Store and retrieve structured information across conversations.
Git
Read, search, and manipulate Git repositories. View commits, diffs, branches, and history.
Example host configuration. Replace the directory placeholder with a folder you intend to expose. The filesystem server can modify permitted files; review the package and host permissions before enabling it.
Configuration Example
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/approved-folder"
]
}
}
}How MCP Works
MCP defines a client-server architecture where the agent is the client and tools are exposed by servers.
Discovery
The agent connects to an MCP server and receives a list of available tools with their schemas.
Invocation
When the LLM decides to use a tool, the agent sends a request to the MCP server.
Execution
The MCP server runs the tool and returns results in a standardized format.
Integration
Results flow back to the agent and into the LLM context, just like regular tool results.
Practical Advice
Guidelines for deciding whether to use MCP in your project.
Start simple: use inline tool definitions until you hit a specific limitation.
Consider MCP when you find yourself copy-pasting tool code between projects.
A single useful integration can justify MCP; compare its maintenance and permission costs with alternatives.
Community MCP servers can accelerate development but add dependency risks.
MCP vs. CLI Tools
Many tasks that MCP servers handle can also be done by simply calling CLI tools (gh, git, curl, psql, etc.) from the agent's shell. Here's how they compare.
MCP Servers
// MCP: JSON-RPC: stdio / Streamable HTTP
{ "method": "tools/call",
"params": {
"name": "list_issues",
"arguments": { "repo": "org/app" }
} }- Structured protocol messages; tool output content still needs validation and parsing.
- Discoverable input schemas; the host must still validate arguments.
- Persistent connections — stateful sessions (e.g., DB connection pools)
CLI Tools (Shell Exec)
// CLI: shell exec
$ gh issue list --repo org/app
$ git log --oneline -10
$ curl -s api.example.com/data
$ psql -c "SELECT * FROM users"- Reuse installed command-line tools and their authentication setup.
- A broad ecosystem; availability depends on the execution environment.
- Composable — pipe, grep, jq, awk for complex transformations
The Pragmatic Take
Choose based on the integration contract, deployment, available clients and permission model. MCP standardizes discovery and transport; CLI tools expose their own interfaces. Both can be local or remote, restricted or broadly privileged, and both need validated inputs and outputs.
Key Takeaways
- 1MCP is a protocol for exposing tools via external servers, not a replacement for regular tool calls
- 2Local functions can be simpler for a small host, while an existing MCP integration may save implementation effort.
- 3MCP shines in polyglot environments and shared tool ecosystems
- 4Don't reach for MCP by default—it's a solution for specific scaling and interoperability challenges
Transports: stdio for local subprocesses and Streamable HTTP for remote connections. HTTP+SSE is a legacy transport. Permission scope and sandboxing come from the host and deployment, not MCP itself.