Model Context Protocol
Standardize how agents discover and call tools so any tool written once works with any conformant agent — no per-host glue code.
Intent & Description
🎯 Intent
Write tools once; use them everywhere.
📋 Context
You run an IDE plugin, desktop assistant, custom CLI, and a teammate’s editor agent — all wanting access to the same GitHub integration, Postgres query tool, and documentation search. Currently each host has its own integration. That’s four maintenance surfaces for three tools.
💡 Solution
Tools live behind a server speaking MCP. Hosts list available tools, call them with typed arguments, and receive typed results. The protocol covers discovery, invocation, errors, and (in some implementations) prompts and resources alongside tools. Bearer-wrapped per-user tokens handle auth at the protocol level.
Real-world Use Case
- Tool palettes need to be portable across multiple host applications.
- Multiple clients (IDEs, agents, CLIs) consume the same tool set.
- Tools are written in different languages and a transport-level protocol is needed.
Source
📌 TL;DR
MCP = write a tool once, use it in any conformant host. Standard protocol handles discovery, invocation, and auth. One process boundary added, many integration headaches removed.
Advantages
- Write a tool once, expose it to Claude Desktop, Claude Code, Cursor, and custom hosts.
- Protocol-level auth (bearer-wrapped per-user tokens) keeps multi-tenancy out of each tool.
Disadvantages
- Adds a process boundary — latency and operational surface increase.
- Schema versioning across servers and clients is a real concern as the protocol evolves.
- Long-lived SSE connections need server-side keep-alives; connection drops mid-call leave orphaned operations.