What is MCP (Model Context Protocol)?

The problem MCP solves

Before MCP, every AI product integrated every external service its own way. Connecting your assistant to GitHub, your database, or your issue tracker meant a custom plugin for each combination of client and service — an N×M explosion of one-off integrations, each with its own auth story and each breaking independently.

The Model Context Protocol, introduced by Anthropic in late 2024 and since adopted across the industry — Cursor, VS Code/Copilot, Windsurf, Zed, OpenAI, Google — replaces that with one standard. A service implements one MCP server; every MCP-capable client can use it. Write it once, works everywhere.

The moving parts

• Server — a program that exposes capabilities. It can run locally (spawned by your editor over stdio) or remotely (a URL your client talks to over HTTP). Docs MD is a remote server at https://docs-md.com/api/mcp.
• Tools — typed functions the server offers, each with a JSON schema describing its inputs. The model reads the schemas and decides when to call which tool.
• Client — the AI application (Cursor, Claude Code, Claude.ai, …) that connects to servers, shows the model what tools exist, executes calls, and returns results into the conversation.
• Transports — stdio for local servers; streamable HTTP for remote ones. Remote servers need zero installation: you add a URL to your client's config and you're done.

What a session looks like

1. The client sends initialize and the server replies with its capabilities and version.
2. The client asks for tools/list — Docs MD, for example, returns share_markdown, update_share, and delete_share with their schemas.
3. When the conversation calls for it, the model issues tools/call with typed arguments, the server does the work, and returns structured output.

You can watch this happen with plain curl — MCP is just JSON-RPC:

curl -X POST https://docs-md.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Local vs. remote servers

Local (stdio) servers are right when the tool needs your machine: reading files, running builds, talking to a local database. Remote servers are right when the capability lives on the network anyway — publishing, search, SaaS APIs. Remote servers have two practical advantages: nothing to install or update, and they work identically from every device and client. The trade-off is trust: a remote server sees whatever arguments the model sends it, so prefer servers that need minimal data and no broad credentials.

Docs MD leans into that: no account, no API key, and the only thing it ever receives is the markdown you explicitly asked to publish. Each share returns a single-document edit token instead of any account-level credential.

Try a real MCP server in one minute

Add Docs MD to your client:

# Claude Code
claude mcp add --transport http md-share https://docs-md.com/api/mcp

# Cursor — ~/.cursor/mcp.json
{
  "mcpServers": {
    "md-share": { "url": "https://docs-md.com/api/mcp" }
  }
}

Then ask your assistant to "share this file as markdown" — it will discover the tool, call it, and hand you a public link. Full per-editor setup lives in the AI IDE guide; the same operations are also a plain REST API. For a deeper dive on the server side, read what an MCP server is and browse the curated MCP server list.