Skip to content

Claude Code Complete Guide

What is MCP: A Complete Overview and Quick Start Hub

February 2026 Update

An allowlist policy has been added for MCP server usage in GitHub Copilot / VS Code. Organization administrators can now specify which MCP servers are permitted.

Key Points

  • Why it's needed: Understand how the "Client + Server" approach compresses M×N connection problems to M+N.
  • How it works: Grasp the 3 primitives (Tools/Resources/Prompts) and JSON-RPC 2.0 request/response patterns.
  • How to try it: Create a minimal working loop with tools/list → tools/call while keeping security basics in place.

3 Key Points to Start

  • M×N → M+N: Instead of implementing tool integrations for each AI app, abstract connections through standardized "MCP Client" and "MCP Server" protocols.
  • 3 Primitives: Tools (verbs) / Resources (nouns) / Prompts (templates) - separate actions, data, and context handling.
  • JSON-RPC 2.0: Bidirectional standard messaging - discover capabilities with tools/list, execute with tools/call.

1. Why MCP is Needed (Problem Statement)

  • Fragmentation: Individual implementations required per AI/tool → maintenance explodes.
  • Scalability: Every new tool requires modifications to all AI integrations.
  • Lack of standardization: Security/permission models and resource representations vary widely.
  • Solution direction: Role separation with "AI side = MCP Client" and "Tool side = MCP Server" to standardize connection patterns.

The M×N Problem in One Picture

  • Traditional: M AIs × N Tools → M×N implementations.
  • MCP: M Clients + N Servers → Implement protocol once, reuse everywhere.

2. Understanding the Architecture Quickly

2-1. Architecture Flow

  1. User → Host App (e.g., Claude Desktop/IDE)
  2. Host App → MCP Client (protocol handling)
  3. MCP Client ⇄ MCP Server (tool implementation/data access)
  4. MCP Server → External Systems (DB/API/Files etc.)

2-2. The 3 Primitives

  • Tools (verbs): Actions AI can invoke. Discover with tools/list, execute with tools/call.
  • Resources (nouns): Referenceable data. resources/list → resources/read to retrieve.
  • Prompts (grammar): Reusable templates. prompts/list → prompts/get.

2-3. JSON-RPC 2.0 Request/Response Example

// tools/list (request)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "query_db",
        "description": "Execute SQL",
        "inputSchema": { "...": "..." }
      }
    ]
  }
}

2-4. Minimal Sequence Example (IDE → DB Schema Retrieval)

  1. Host gets available tools via tools/list
  2. Execute tools/call with describe_table("users")
  3. MCP Server queries DB and returns result
  4. Host presents schema information to user

3. When MCP Works Best (Applicability)

  • ✅ Operating across multiple tools (Slack/Drive/GitHub/DB etc.)
  • ✅ Sharing the same connections across different models (Claude/GPT/Gemini etc.)
  • ✅ Discovering capabilities at runtime (dynamic tools/list)
  • ❌ For simple single-tool testing, Function Calling may suffice
  • ❌ When minimal latency is the top priority (avoid MCP layer overhead)

4. Quick Start Guide (Minimal Configuration)

  1. Set up one MCP server (e.g., a simple server returning DB schema).
  2. Register the server in an MCP client environment (e.g., Claude Desktop / IDE plugin).
  3. Verify that tools/list → tools/call round-trip works.
  4. Once read operations work, add Human-in-the-loop (confirmation dialogs) for write operations.

💡 Tip: Start with 1 tool, 1 resource to get "it works". Expand later.

5. Implementation Checklist (Including Security)

  • Principle of least privilege: Limit Roots/tool permissions to the minimum necessary.
  • Authentication: Require authentication (e.g., OAuth) for remote servers.
  • Approval flow: Add Human-in-the-loop for writes and external calls.
  • Logging: Keep audit logs of tools/call and results.
  • Incident response: Prepare procedures for server shutdown/permission revocation.

7. Frequently Asked Questions (FAQ)

  • Q. How is this different from Function Calling? A. Function Calling requires model-specific function registration with individual implementations per tool/model. MCP standardizes the tool side as a "server", providing model-agnostic connections.
  • Q. What should I try first? A. Prepare one read-only tool (e.g., describe_table) and verify that tools/list → tools/call works.
  • Q. What security considerations are important? A. Avoid unauthenticated public access, add user approval for write operations, keep audit logs—these 3 points are the minimum baseline.