AI coding tools are powerful, but they are blind. They can read your code, but they cannot see your GitHub issues. They can write database queries, but they do not know your schema. They can suggest fixes, but they cannot check your CI pipeline.

MCP changes that. The Model Context Protocol connects your AI tools to external systems — databases, GitHub, file systems, APIs, and anything else you build a server for. Think of it as USB-C for AI. One standard protocol, many connections.

If you need the theory, start with MCP Explained. This article is about getting MCP working in your actual workflow.

What MCP Gives You in Practice

Without MCP, a typical debugging session looks like this:

  1. You see a bug report in GitHub
  2. You copy the issue description
  3. You paste it into Claude Code
  4. You describe your database schema from memory
  5. Claude Code suggests a fix
  6. You check CI manually to see if tests pass

With MCP, the same session looks like this:

  1. You tell Claude Code “Fix issue #42”
  2. Claude Code reads the issue from GitHub directly
  3. It checks the database schema through the PostgreSQL MCP server
  4. It writes the fix
  5. It verifies the CI status

No copying, no pasting, no context lost in translation. The AI works with your real tools, not your descriptions of them.

MCP Servers You Should Set Up First

MCP servers come in three types. Resources provide read-only data the AI can access. Tools give AI functions it can call. Prompts offer pre-written templates for common tasks.

Here are the most useful MCP servers to start with.

GitHub MCP Server

This is the single most impactful MCP server for most developers. It gives AI access to your issues, pull requests, code, and repository metadata.

What it enables:

  • “Read issue #42 and implement the fix”
  • “Check the CI status of my latest PR”
  • “Create a PR with this change and assign it to Sam”
  • “What open issues are assigned to me?”

Setup in Claude Code (.mcp.json):

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

Generate a personal access token with repo scope at github.com/settings/tokens. Store it securely — do not commit this file with the token.

Real workflow example:

> Read issue #42 in our repo. Understand the bug described,
  find the relevant code, write a fix, and create a PR.

Claude Code reads the issue, searches the codebase for the relevant files, implements the fix, runs the tests, creates a branch, commits, and opens a PR. One prompt, full workflow.

PostgreSQL MCP Server

If your project uses PostgreSQL, this server gives AI direct access to your database schema and data. No more describing your tables from memory.

What it enables:

  • “What columns does the users table have?”
  • “Write a query to find users who signed up in the last 7 days”
  • “Generate a migration to add a status column to the orders table”

Setup:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Important: Connect this to your development database, not production. MCP servers can read and potentially write data. Use a read-only connection string if your server supports it.

Filesystem MCP Server

This server gives AI access to files outside your project directory. Useful for reading documentation, configuration files, or shared resources.

Setup:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/docs",
        "/path/to/shared-config"
      ]
    }
  }
}

The paths you provide are the only directories the server can access. This is a security boundary — the AI cannot read files outside these paths.

Fetch MCP Server

This server lets AI make HTTP requests. Useful for checking API documentation, fetching status pages, or reading remote configuration.

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

With this server, you can say “Read the docs at https://api.example.com/docs and write a client for the /users endpoint.”

Configuring MCP for Your Project

MCP configuration lives in a .mcp.json file. There are two places to put it.

Project-level (.mcp.json in your project root): Shared with your team. Commit this file to version control, but use environment variables for secrets.

User-level (~/.claude/settings.json): Personal servers that apply to all projects. Good for GitHub, since you use the same token everywhere.

Here is a complete project-level configuration for a typical web project:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
      }
    },
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

The ${GITHUB_TOKEN} and ${DATABASE_URL} syntax references environment variables. Set them in your shell profile or .env file.

MCP in VS Code

VS Code has native MCP support since early 2026. You can configure MCP servers that work with GitHub Copilot and other AI extensions.

Add servers through the VS Code settings or a .vscode/mcp.json file:

{
  "servers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

The format is similar to Claude Code’s configuration. Once configured, Copilot can access the same tools and resources.

Finding MCP Servers

The MCP ecosystem has grown rapidly. Here is how to find servers for your tools.

Official registry: The MCP Registry lists published servers. Browse by category — databases, version control, cloud providers, monitoring, and more.

GitHub organization: The modelcontextprotocol GitHub organization maintains reference server implementations. These are well-tested and follow best practices.

npm search: Search npm for @modelcontextprotocol/server- to find official servers, or search for mcp-server- to find community servers.

Popular community servers:

  • Sentry — Access error reports and stack traces directly
  • Slack — Read and send messages in channels
  • Jira / Linear — Read tickets and update status
  • Docker — Manage containers and view logs
  • Kubernetes — Read pod status and logs
  • AWS — Access CloudWatch logs, S3 files, DynamoDB tables

Before installing a community server, check the repository. Look at the code, the permissions it requests, and the maintenance status. MCP servers run commands on your machine — treat them like any other dependency.

Building a Custom MCP Server

Sometimes you need an MCP server that does not exist yet. Maybe you have an internal API, a custom deployment tool, or a proprietary database.

Building one is simpler than you might think. Here is a minimal TypeScript MCP server that exposes a tool:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "deploy-status",
  version: "1.0.0",
});

server.tool(
  "get_deploy_status",
  "Check the deployment status of a service",
  {
    service: z.string().describe("The service name to check"),
    environment: z.enum(["staging", "production"])
      .describe("The deployment environment"),
  },
  async ({ service, environment }) => {
    // Replace with your actual deployment API call
    const response = await fetch(
      `https://deploy.internal.com/api/status/${environment}/${service}`
    );
    const data = await response.json();

    return {
      content: [{
        type: "text",
        text: JSON.stringify(data, null, 2),
      }],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Key parts:

  1. Create a server with a name and version
  2. Define tools with a name, description, input schema, and handler
  3. Connect via stdio transport (standard for CLI-based MCP servers)

The description matters. AI reads it to decide when to use the tool. “Check the deployment status of a service” is clear. “Do stuff” is not.

Add it to your .mcp.json:

{
  "mcpServers": {
    "deploy": {
      "command": "npx",
      "args": ["tsx", "./tools/deploy-server.ts"]
    }
  }
}

Now you can say “Check the deployment status of the auth service in staging” and Claude Code will call your custom server.

MCP with Resources and Prompts

So far we have focused on MCP tools — functions that AI can call. But MCP servers expose two other primitives that are equally useful.

Resources are read-only data that AI can access on demand. Think of them as files or documents that the AI can reference without making an API call.

For example, a documentation MCP server might expose your API docs as a resource. When the AI needs to know the endpoint format, it reads the resource directly instead of making an HTTP request or relying on training data.

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": ["-y", "mcp-server-docs", "--path", "./docs/api"]
    }
  }
}

Now you can say “Read the API documentation and write a client for the users endpoint” and the AI reads your actual docs — not outdated training data.

Prompts are pre-written templates for common tasks. They are like saved prompts that the MCP server provides.

A database MCP server might offer a prompt template for “generate migration” that includes the current schema as context. Instead of you writing the full prompt every time, you reference the template and the MCP server fills in the current schema automatically.

Resources reduce hallucination because the AI reads real data instead of guessing. Prompts reduce repetition because common workflows are pre-built. Together with tools, they make MCP servers much more than simple API wrappers.

A Complete MCP Workflow

Let me walk through a real workflow that uses multiple MCP servers together.

The scenario: A bug report comes in. A user cannot reset their password.

Prompt:

Read issue #87 from our GitHub repo. It is about password reset
failing. Check the relevant code and the database schema for the
password_reset_tokens table. Find the bug and fix it.

What Claude Code does:

  1. GitHub MCP — Reads issue #87, gets the full description and any comments
  2. File system — Finds the password reset code in src/services/authService.ts
  3. PostgreSQL MCP — Checks the password_reset_tokens table schema, discovers the expires_at column
  4. Reads the code — Finds that the expiration check uses > instead of < (token expires when now > expires_at, but the code checks now < expires_at)
  5. Writes the fix — Corrects the comparison operator
  6. Runs tests — The existing test suite passes
  7. GitHub MCP — Creates a branch, commits, and opens a PR linked to issue #87

This entire flow takes about 60 seconds. Without MCP, you would spend that time copying issue text, looking up table schemas, and creating the PR manually.

Security Considerations

MCP servers have access to your systems. Treat them seriously.

Token scoping: Give MCP servers the minimum permissions they need. A GitHub token for code review does not need delete permissions. A database connection should be read-only unless you specifically need writes.

Environment isolation: Connect MCP servers to development and staging environments, not production. Even read-only access to production data can be a compliance issue.

Audit what runs: MCP servers execute commands on your machine. Review the server code before installing it, especially community servers. Check what shell commands it can run and what network requests it makes.

Team secrets management: Do not commit secrets in .mcp.json. Use environment variables and document which variables team members need to set up.

Sandboxing: Claude Code runs MCP servers as child processes. They inherit your shell environment. Be aware of what environment variables and credentials are available to them.

Troubleshooting Common Issues

Server fails to start: Check that the command is installed. Run npx -y @modelcontextprotocol/server-github manually to see if it works. Check Node.js version — MCP servers typically need Node 18 or later.

AI does not use the MCP tools: The AI decides when to use tools based on your prompt. Be explicit. Instead of “check the database,” say “use the PostgreSQL MCP server to check the users table schema.”

Slow responses: MCP calls add latency. Each tool call is a round trip. If the AI is making many MCP calls, consider whether the context could be provided upfront in your CLAUDE.md file instead.

Permission errors: Check your tokens and connection strings. The most common issue is an expired or incorrectly scoped token.

Key Takeaways

  • Start with GitHub MCP. It has the highest impact on daily workflow for most developers.
  • Connect your database. AI that knows your schema writes better queries and migrations.
  • Build custom servers for internal tools. A simple TypeScript server takes 30 minutes to build and saves hours every week.
  • Security matters. Scope tokens, use environment variables, and connect to dev — not production.
  • Be explicit in prompts. Tell AI which MCP tools to use when the task involves external data.

What’s Next?

In AI-Powered Testing — Let AI Write Your Tests, you will learn how to use AI to generate, review, and maintain your test suite. Combined with MCP, AI can run tests and verify its own work automatically.

Part 10 of the Vibe Coding series.