Mcp Server

What Is an MCP Server?

An MCP server is a capability provider in the Model Context Protocol that exposes capabilities to an MCP client. A server can publish tools, resources, and prompts through JSON-RPC, while the transport layer carries those messages over stdio or Streamable HTTP. The host—not the server—decides how capabilities enter the model context and when user approval is required.

An MCP server is the capability provider in the Model Context Protocol. While MCP clients (inside AI applications like Claude Desktop or Cursor) initiate connections, servers respond to those connections by exposing the tools, resources, and prompts available to connected clients.

MCP has a required base protocol and lifecycle, while individual features are negotiated during initialization. A server may support tools/list and tools/call, resources/list and resources/read, or prompts/list and prompts/get. Do not assume every server exposes all three primitives.

The ecosystem includes official SDKs, reference implementations, vendor-hosted remote servers, local community packages, and public registries. A listing or repository star count is discovery evidence—not a security certification. Start with the official MCP server concepts and architecture overview, then verify the exact server artifact you plan to execute.

Production safety is shared across participants. Servers must validate inputs, enforce access control, rate-limit calls, and sanitize outputs; clients should show sensitive inputs, request confirmation, apply timeouts, validate results, and retain audit evidence. See the official MCP tools security requirements and authorization specification.

MCP Server vs MCP Client: The Architecture

The MCP architecture separates concerns clearly: servers provide capabilities, clients consume them, and hosts run one or more clients. This stateless design is intentional — servers don't track which clients connect to them, enabling composability across any MCP-compatible application.

Key architectural property: Clients don't know which other clients are connected to the same server, and servers don't track which clients are using them. A client sends a tools/list request and receives a list of available tools. The server simply responds to requests — it doesn't maintain session state or client identity. This means Claude Desktop, Cursor, Cline, and any other MCP-compatible client can all connect to the same MCP server without the server needing special configuration.

For developers building AI systems, the practical implication: your choice of MCP server is independent of your choice of MCP client. All MCP-compatible applications can connect to the same servers, because the MCP specification standardizes the communication interface.

MCP Server Selection Matrix

Use this matrix to choose a server pattern by trust boundary and workload. Confirm every field against the exact release you deploy; names, schemas, transports, and permissions can change independently.

Validation rule: Measure initialization, discovery, authorization, execution, retries, and result validation separately. Never reuse a latency number from another region, provider, payload, account tier, or concurrency level.

Eight MCP Server Examples and What to Verify

These examples illustrate different capability and trust patterns. Treat every count, schema, transport, and permission as release-specific. Labels marked Verified indicate where the publisher offers an official implementation or documentation—not a blanket security approval.

1. GitHub MCP Verified

2. Figma MCP

3. Linear MCP

4. Sentry MCP Verified

5. Context7

6. Brave Search MCP Verified

7. Supabase MCP

8. Notion MCP

MCP Server Examples: How They Work in Practice

Understanding how an MCP server works under the hood helps you evaluate servers, debug connection issues, and build custom servers. Below is a minimal FastMCP server implementation and the JSON-RPC flow that powers tool discovery.

Building a Minimal MCP Server with the Python SDK

# Minimal MCP server with FastMCP
# Source: official MCP Python SDK documentation
# Pin and test the current SDK release before deployment

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def search_docs(query: str) -> str:
    """Search documentation for a query string."""
    return f"Results for: {query}"

@mcp.tool()
def get_doc_content(doc_id: str) -> str:
    """Retrieve the full content of a document by ID."""
    # Implementation would fetch from your doc store
    return f"Content of {doc_id}"

# Run: python my_server.py
# Or: fastmcp dev my_server.py (hot reload for development)
# Connect: Configure in claude_desktop_config.json as stdio

The FastMCP decorator-based approach keeps server code minimal. Each decorated function automatically becomes a tool with its name from the function name, description from the docstring, and input schema from type annotations.

JSON-RPC Request/Response Flow

Tool discovery and invocation use JSON-RPC 2.0 over stdio or Streamable HTTP:

// Step 1: Client discovers available tools
// Client → Server (via stdio stdin or HTTP POST)
{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}

// Step 2: Server returns tool definitions
// Server → Client (via stdio stdout or HTTP response)
{"jsonrpc": "2.0", "id": 1, "result": {
  "tools": [
    {"name": "search_docs", "description": "Search documentation for queries", "inputSchema": {"type": "object", "properties": {"query": {"type": "string"}}}}
  ]
}}

// Step 3: Client invokes a tool
{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {
  "name": "search_docs", "arguments": {"query": "authentication best practices"}
}}

// Step 4: Server returns results
{"jsonrpc": "2.0", "id": 2, "result": {
  "content": [{"type": "text", "text": "Results for: authentication best practices"}]
}}

Every request includes a jsonrpc version, an id for correlation, a method name, and params. Responses include the same id and a result or error. This simplicity makes MCP servers easy to implement and debug — no custom protocol parsing or state management required.

Production MCP Server Workflow and Trust Boundaries

A production flow should discover candidates, inspect provenance and schemas, authorize the narrowest action, call with validated arguments, and validate the result against its source. Keep the host, MCP server, authorization server, and downstream service boundaries explicit in logs and incident response.

Decision framework:

QVeris can serve as an optional capability discovery and routing layer in this workflow (QVeris CLI documentation). MCP still defines the protocol, the host controls context and approvals, each MCP server enforces authorization, and downstream providers remain responsible for their own data and operations.

Deployment Options for MCP Servers

MCP servers can be deployed in three patterns, each with different trade-offs for security, scalability, and operational overhead.

Local Process (stdio)

Simplest deployment: run the MCP server as a local process and connect via stdio. Works well for development, CLI tools, and single-user workflows. Claude Code and other CLI-based clients typically use stdio transport. Configuration is minimal — point your MCP client at the process command. The downside: the server is tied to the local machine, preventing team sharing and remote access.

Remote Service (Streamable HTTP)

For shared production workflows, deploy the MCP server as a remote HTTP service and verify its transport and authorization requirements. Follow MCP Security Best Practices to validate token audiences and limit permissions. Test endpoint availability, timeout handling, and failure recovery against the server and configuration you actually deploy.

Managed Platform

Managed MCP platforms like Apigene, Prefect, and AWS Bedrock handle authentication, monitoring, scaling, and security. CData MCP Server Best Practices for 2026 discusses production MCP governance, permissions, and operational best practices.

// Example: Claude Desktop config connecting a meta-server
// macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
// Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "qveris": {
      "command": "npx",
      "args": ["-y", "@qverisai/mcp"],
      "env": {
        "QVERIS_API_KEY": "your-api-key"
      }
    }
  }
}

// Alternative: connecting a single-purpose server directly
// See each server's repository for its specific config format

After configuring, restart your MCP client. The server's tools become available through the standard MCP tool discovery flow.