MCP Server

Definition

An MCP server is a process that speaks the Model Context Protocol — an open standard introduced by Anthropic in November 2024 — to advertise a set of tools (callable operations), resources (readable data), and prompts (reusable templates) to any compliant LLM client. Once registered, the model can invoke those tools directly during a conversation: the user asks a question, the model decides an MCP tool will help, calls it, receives the structured result, and folds it into the answer.

Transports

The protocol defines three transports:

• stdio — the server is a local process spawned by the client over standard input/output. Used by Claude Desktop for filesystem and local-system servers.
• SSE (Server-Sent Events) — older HTTP-based transport, being deprecated in favor of Streamable HTTP.
• Streamable HTTP — the current preferred remote transport. Single POST endpoint accepting JSON-RPC 2.0 requests. Used by hosted SaaS MCP servers (Citare, Linear, Notion, Stripe).

How it differs from a REST API

An MCP server is not a replacement for a REST API — it's a conversation-facing wrapper on top of one. The protocol adds three things on top of REST:

1. Auto-discovery — the client calls tools/list once and gets the full operation catalog plus JSON Schema for every input. No OpenAPI doc to share separately.
2. Conversation context — the model picks which tool to call based on the user's question, with descriptions written for an LLM audience rather than a human developer.
3. Auth model designed for end-users — each user provides their own credentials per-server. The client (Claude Desktop) handles the connection lifecycle; the user doesn't see API keys in the chat.

For a hosted SaaS product, the typical pattern is: REST API for programmatic / integration use cases, MCP server as a thin dispatcher that maps each REST operation into a tool definition. Citare's MCP server does exactly this — 59 tools generated from the same OpenAPI OPERATIONS catalog the REST API uses.

What's worth exposing as MCP

The right operations to expose are the ones where the value of "answer my question conversationally" beats the value of "give me a structured API response":

• Read-heavy operations that summarize data the model can then narrate ("what's my top-cited URL across all 5 AI engines this week?")
• Definitional queries the model would otherwise hallucinate ("what's our domain rating for these 10 competitors?")
• Trigger-style writes the model can reasonably initiate with user approval ("schedule a Brand Radar dispatch for tomorrow")

Operations that don't translate well: anything requiring complex form input, bulk uploads, async multi-step workflows, or strict idempotency guarantees the model can't reason about.

Discovery — where MCP servers get listed

• Smithery (smithery.ai) — the largest hosted-MCP registry, ~10K MCP-shopping users
• Glama (glama.ai/mcp/servers) — auto-builds from the punkpeye awesome-mcp-servers list
• Anthropic's reference repo (github.com/modelcontextprotocol/servers) — reference implementations only; not a community submission point
• Awesome MCP Servers lists (punkpeye, appcypher, wong2) — community-curated; submission via PR

For Citare-style SaaS MCP servers, Smithery + the punkpeye list (which feeds Glama) deliver the bulk of inbound trial.

Common pitfalls

• Exposing every REST operation indiscriminately. Tool description quality matters more than count. Curated 20-tool servers convert better than 100-tool firehoses where the model can't pick the right call.
• Forgetting auth onboarding UX. End-users won't dig through your dashboard for an API key. Provide per-client install pages (/mcp/install/claude, /mcp/install/cursor) with one-click config snippets.
• Forgetting MCP-specific rate limits. Conversational use patterns are bursty in a different shape than REST integrations. A model retrying tool calls in a debug loop can blow through quota.
• Not handling resources/list + prompts/list. If your server only implements tools/*, return -32601 Method not found for the other two. Some clients call all three on connect.