MCP (Model Context Protocol) Explained: How to Configure Data Sources for Your AI Agent

In one sentence: Your Agent can write code but cannot see your GitHub Issues, database schema, or internal docs—the problem is often not the model, but that nobody has explained where the data should come from. This article starts with MCP protocol fundamentals: architecture layers, the three capabilities (Tools / Resources / Prompts), stdio vs HTTP transport, then Cursor and Claude Code configuration patterns and a verification checklist. When you finish, you will be able to wire common data sources into your Agent without writing glue code for every SaaS.

Further reading: Claude Code MCP setup guide · 20 MCP Servers to install · Least-privilege permissions

What is MCP? What problem does it solve?

Model Context Protocol (MCP) is an open standard Anthropic open-sourced in late 2024. The goal is straightforward: let AI applications (Hosts) connect to the outside world—code repos, databases, doc sites, ticketing systems, browsers—in a uniform, auditable way, without a custom integration for every data source.

Before MCP, teams usually took one of two paths:

• Manual context hauling—paste Issue links, SQL results, and API responses into the chat. Accurate but slow, and impossible to scale.
• Roll your own Function Calling—write tool schemas and auth for GitHub, Postgres, Notion, and so on. Flexible but expensive to maintain; switching clients (Cursor → Claude Code) often means rewriting everything.

MCP is the third path: standardize the interface between data sources and Agents. Configure a GitHub MCP Server once and reuse it in Cursor, Claude Code, VS Code Copilot, OpenAI Codex; the community already ships thousands of Servers covering mainstream SaaS and dev tools.

Three-layer architecture: Host, Client, Server

To configure MCP correctly, first understand how the three roles work together:

A typical call chain: you ask Cursor "What files changed in PR #42?" → the Host sends the question to the LLM → the model decides to call mcp__github__get_pull_request → the Client sends the request to the GitHub MCP Server over stdio or HTTP → the Server calls the GitHub API and returns structured JSON → the model answers from real data.

Note: you configure how to connect to the Server (command, URL, env vars). The Host automatically discovers which tools it exposes. You do not hand-write API docs in the prompt—the Server pushes its capability list to the Client via tools/list at startup.

Three capability primitives: Tools, Resources, Prompts

An MCP Server exposes three kinds of capabilities to the Agent, each matching a different data-source integration pattern:

Tools — "let the Agent take action"

The most common. Each Tool has a name, description, and input schema (JSON Schema). The Agent invokes them on demand during reasoning. Examples: GitHub MCP's search_code, Playwright MCP's browser_click, database MCP's execute_query.

When configuring data sources, 90% of scenarios are Tool-based Servers: read repos, query tables, send HTTP, drive a browser.

Resources — "let the Agent read static context"

Resources are addressable data fragments, like read-only files with URIs. A Server declares file://docs/api.md or db://schema/users; the Host can fetch content before or during a conversation and inject it into context, without the Agent having to guess which Tool to call.

Good for: project READMEs, OpenAPI specs, database schema snapshots, config templates—knowledge that is relatively stable and enumerable.

Prompts — "pre-built workflow entry points"

A Server can expose named Prompt templates (with parameters). Users trigger fixed flows like "Code Review" or "Write migration script" from the Host in one click. Community adoption is lower than Tools, but teams can wrap SOPs into reusable entry points.

Data source types and common MCP Server mapping

Use this table to map "what I want to connect" to "which Server to install." For a fuller list of 20 options, see MCP Server recommendations.

Transport layer: stdio vs HTTP—which to choose?

MCP Client and Server communicate over JSON-RPC 2.0. In 2026, two transports dominate:

stdio (standard input/output)

The Host starts the Server as a subprocess, e.g. npx -y @modelcontextprotocol/server-github, and exchanges messages over stdin/stdout. Pros: simple config, no open ports, great for local dev. Cons: each Server uses a process; some full Docker builds expose so many tools they can hit Cursor's ~40-tool limit.

Streamable HTTP / SSE (remote)

The Server runs remotely (or is officially hosted); the Client connects over HTTPS, often with OAuth. GitHub, Supabase, Linear, Sentry, and others ship Remote versions. Pros: slimmer tool sets, no local Node/Docker, OAuth-managed tokens. Cons: network dependency; corporate networks must allow outbound access.

Configure data sources in Cursor

Cursor MCP config lives under Settings → MCP, or edit ~/.cursor/mcp.json directly. Structure is an mcpServers object with one entry per Server.

Example 1: local stdio — Fetch MCP

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

Example 2: local stdio — GitHub MCP (PAT)

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    }
  }
}

Prefer adding the official GitHub Remote MCP (OAuth) in the Cursor UI—fewer tools, no manual PAT. If you use a PAT, keep it fine-grained read-only and never commit it to git.

Example 3: Context7 (documentation data source)

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

After saving, restart Cursor and check Settings → MCP for a green Connected status. In Agent mode, ask "Look up Next.js 15 middleware syntax"—if configured correctly, the model calls Context7 instead of hallucinating APIs.

Configure data sources in Claude Code

Claude Code uses ~/.claude.json (user-level) or .mcp.json at the project root (project-level). Structure is similar to Cursor, with slightly different field names and paths.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    },
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

After editing config, fully quit Claude Code and relaunch. From the repo root run claude, then type /mcp in a session to list connected Servers and tools. Success looks like mcp__github__*, mcp__codegraph__*, and similar prefixed tools.

Step-by-step walkthrough: Claude Code MCP setup guide; triple-connect architecture: MCP overview.

Project-level vs user-level: where to put config

Best practice: keep credentials and personal preferences at user level (not in git); put repo-bound data sources (CodeGraph index paths, project doc Servers) at project level and commit .mcp.json so teammates clone and go. Reference sensitive tokens via env vars, e.g. "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }, injected by shell or CI.

Configuration verification: make sure the Agent actually uses your data

Configured does not mean working. Verify item by item:

1. Connectivity — Cursor: green light in Settings → MCP; Claude Code: /mcp lists Servers with no errors.
2. Tools visible — Confirm target tool names exist (e.g. mcp__github__search_code).
3. Smoke task — One explicit instruction that triggers a tool, e.g. "Use GitHub MCP to list open issues in this repo" or "Use Context7 to look up the latest Prisma migrate syntax."
4. Failures observable — If the Agent skips tools, check for too many tools, unclear descriptions, or vague tasks; add "please use GitHub MCP" to the prompt if needed.
5. Permission boundary — Deliberately ask for a forbidden action (e.g. delete a repo) and confirm the Server returns 403, not silent success.

Permissions and security boundaries

Every data source you connect opens a door from the Agent to an external system. Core principle: read-only by default, write only when explicit, isolate production.

• GitHub PAT — Fine-grained token scoped to target repos; read-only Issues/Contents covers most dev workflows.
• Database DSN — Read-only role on dev DBs; never put production write connections in project-level config.
• Filesystem MCP — Limit args to the project root; do not point at $HOME or /.
• Internal API — Use staging read-only endpoints; do not load production .env into the Claude Code workspace.

Full policy matrix and attack-chain analysis: MCP least-privilege permissions.

Common troubleshooting

FAQ

How is MCP different from Function Calling?

Function Calling is a tool declaration inside a single API request, usually tied to a specific model/vendor. MCP is a persistent Server connection and open protocol: configure once, reuse across clients, with a community-maintained ecosystem. Think of MCP as standardized, pluggable Function Calling runtime.

Can I write my own MCP Server?

Yes. Official SDKs exist for TypeScript (@modelcontextprotocol/sdk), Python, and more. Typical use: internal wiki, ticketing API, proprietary data lake. A minimal Server only needs tools/list and tools/call; stdio transport is enough to debug in Cursor.

Does MCP send data to the model vendor?

Tool call results enter the conversation context and go to whichever LLM API the Host uses—that is required for Agent work. MCP itself does not "upload" data separately; risk comes from what permissions you give the Server (which repos it can read, which SQL it can run). Configure least privilege to control exposure.

Which data sources should I connect first in 2026?

Most developers start with Context7 (docs) + GitHub (repo) + Playwright (browser verification). Add Supabase or DBHub for backend work; stack Linear/Notion only if your team uses them. See 20 MCP Servers to install.