MCP is to LLM tooling what LSP was to IDEs: a common protocol so every server (database, filesystem, API) only needs one adapter, and every client (Claude Desktop, Claude Code, Cursor, VS Code, etc.) speaks one language.
An MCP server exposes three primitives: tools (callable functions), resources (readable data), and prompts (parameterizable templates the client can invoke). Transport is usually stdio or HTTP+SSE. The ecosystem grew fast in 2025 -- most major vendors now ship MCP servers for their platforms.
Example Prompt
# .mcp.json client config snippet
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/me/docs"]
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://..."]
}
}
}When to use it
- Building tools you want many LLM clients to use (don't couple to one vendor's function-calling API)
- Integrating with a client that already speaks MCP (Claude Code, Cursor, etc.)
- You need auditability and a clean capability boundary per tool server
When NOT to use it
- You control both client and server and don't need cross-vendor portability -- plain function calling is simpler
- Latency budgets that can't tolerate a separate server process