Mcp Ecosystem

MCP Server Ecosystem

Why This is Copilot-Exclusive

Copilot CLI ships with a built-in GitHub MCP server providing 20+ tools for Issues, PRs, Actions, code search, and repository management — zero configuration required. Beyond that, it has a practical MCP management flow through copilot mcp add, copilot mcp list, copilot mcp get, user config at ~/.copilot/mcp-config.json, workspace config in .mcp.json, and plugin-provided MCP servers. Claude Code supports MCP but has no built-in GitHub server and a different configuration workflow.

When to Use

• Adding domain-specific tools that the built-in GitHub MCP does not cover, such as PostgreSQL, Redis, Jira, Slack, or an internal feature-flag API
• Creating MCP bridges to internal systems or external SaaS tools outside the default GitHub workflow
• Sharing custom MCP configurations across Copilot CLI and VS Code
• Building specialized AI workflows that need custom tools beyond the built-in GitHub MCP

When NOT to Use

| Instead of mcp-ecosystem | Use | |--------------------------|-----| | Reading GitHub issues, PRs, Actions, or repository metadata already covered by the built-in MCP | Use the built-in GitHub MCP tools directly | | Reviewing PRs, checking CI failures, or searching repository code | Use the built-in GitHub MCP and normal repo tools directly | | Pure code search, code review, or coding tasks with no external service dependency | Use the normal repo tools or the most relevant skill for that task | | Adding an untrusted third-party server without validating permissions and secret handling | Review the server first and prefer least-privilege configuration |

Common MCP Candidates

These are the kinds of services that usually justify this skill:

• PostgreSQL or MySQL databases
• Redis or other cache/data stores
• Internal REST or GraphQL APIs
• Jira, Slack, Notion, or other external SaaS tools

Workflow

1. Built-In GitHub MCP (Zero Config)

These tools work immediately — no setup required. Check this built-in coverage first before adding a custom MCP server:

Repository & Code:

• get_file_contents — Read files from any GitHub repo
• search_code — Search code across all of GitHub
• search_repositories — Find repos by topic, language, etc.
• list_branches, list_commits, get_commit — Git history

Issues:

• list_issues, search_issues — Find and filter issues
• issue_read — Get details, comments, sub-issues, labels

Pull Requests:

• list_pull_requests, search_pull_requests — Find PRs
• pull_request_read — Diffs, reviews, check runs, files

Actions:

• actions_list, actions_get — Workflow and run details
• get_job_logs — CI/CD log analysis

Users:

• search_users — Find GitHub users

2. Add Custom MCP Servers

Global Configuration

Use copilot mcp add for user-level installs, or edit ~/.copilot/mcp-config.json directly. Prefer environment variables for secrets rather than embedding tokens or connection strings in committed config:

copilot mcp add --transport http context7 https://mcp.context7.com/mcp
copilot mcp add --transport http notion https://mcp.notion.com/mcp

Equivalent JSON:

{
  "servers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/docs"]
    }
  }
}

Project-Level Configuration

Create .mcp.json in your repo:

{
  "servers": {
    "my-api": {
      "command": "node",
      "args": ["./tools/mcp-server.js"],
      "env": {
        "API_KEY": "${env:MY_API_KEY}"
      }
    }
  }
}

2-A. Review server dependencies before trusting them

Treat an MCP server like any other runtime dependency:

1. identify the package or image version actually deployed
2. check recent advisories before standardizing it
3. prefer pinned versions over floating latest

For Node-based MCP servers or companion dashboards that depend on transport libraries such as ws, verify the effective version is patched and confirm the reason in upstream release notes or your advisory feed before standardizing it.

npm ls ws
npm audit --omit=dev
pip show 

3. Inspect Configured Servers

Use the CLI to inspect what Copilot currently sees:

copilot mcp list
copilot mcp get my-api

4. Load Servers into a Session

Copilot loads MCP servers from three sources:

• user config: ~/.copilot/mcp-config.json
• workspace config: .mcp.json
• installed plugins that expose MCP servers

Inside a running session, use /env to inspect which MCP servers were loaded for that session.

5. Verify Available Tools

Once the session has loaded your config, new tools appear alongside the built-in ones. Copilot automatically discovers and can use all registered MCP tools.

If a configured server is missing, check copilot mcp list, then inspect the specific entry with copilot mcp get .

5-A. Transport-specific cautions

Not every transport should reuse sessions the same way:

| Transport | Default stance | What to watch | |-----------|----------------|---------------| | stdio | reuse cautiously | command path, env injection, process lifetime | | HTTP / SSE | isolation first | some backends intentionally skip session pooling for these transports; confirm auth, state, and retry behavior per request | | WebSocket | persistent but patched | heartbeat, timeout, reconnect behavior, and vulnerable ws versions |

If you standardize an HTTP or SSE server, document whether it is safe to pool sessions or whether each request should create fresh state.

5-B. Heavy-analysis MCP servers

Some MCP servers can shift from lightweight indexing to heavier background analysis as they evolve. If you use a codebase-memory or indexing server, verify whether LSP-backed analysis is opt-in or effectively always on in the version you deploy.

Verify:

• startup CPU and memory impact
• whether the repo actually benefits from live indexing
• whether the team wants that server enabled everywhere or only on demand
• whether the server still stays localhost-bound or now exposes a broader HTTP surface
• whether cross-repo graph or intelligence features widen the default data boundary more than the team wants

Treat upgrades in this class as scope changes, not only performance changes. When a codebase-memory server adds its own HTTP listener or cross-repo intelligence, re-check binding, authentication assumptions, and whether those features belong in the default deployment.

6. Use Context7 for Live Documentation

When you need current, version-aware framework or library docs, Context7 is one of the highest-value MCP servers to add.

Setup (recommended)

Run the guided setup to authenticate via OAuth and install the MCP server:

npx ctx7 setup

This generates an API key and registers the server automatically. To configure manually, add the HTTP MCP server and pass your key as a header:

copilot mcp add --transport http context7 https://mcp.context7.com/mcp

Then set CONTEXT7_API_KEY in your environment (or via ${env:CONTEXT7_API_KEY} in .mcp.json) so the server can authenticate.

MCP tools (called automatically by the agent)

| Tool | Purpose | |------|---------| | resolve-library-id | Map a library name to a Context7 ID (e.g. /vercel/next.js) | | query-docs | Fetch version-specific docs for a given library ID and question |

Prompt patterns

Single-prompt (agent resolves and fetches in one turn):

How do I configure middleware in Next.js 15 App Router? use context7

Targeting a specific version:

How do I set up Next.js 14 middleware? use context7

When you already know the library ID, skip resolution and load docs directly:

Implement basic authentication with Supabase.
use library /supabase/supabase for API and docs. use context7

CLI commands (no MCP required)

If you prefer not to run the MCP server, use the ctx7 CLI directly:

ctx7 library next.js "App Router middleware"
ctx7 docs /vercel/next.js "route handlers"

This pattern is especially useful when:

• the installed library version may differ from model training data
• a framework recently changed APIs
• you need official docs instead of secondary tutorials

Examples

Database-Aware Development

// .mcp.json
{
  "servers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${env:DATABASE_URL}" }
    }
  }
}

Now Copilot can query your database directly:

> "Show me the schema for the users table and write a migration to add > an email_verified column"

Multi-Service Architecture

{
  "servers": {
    "github": "built-in",
    "postgres": { "command": "npx", "args": ["-y", "@mcp/server-postgres"] },
    "redis": { "command": "npx", "args": ["-y", "@mcp/server-redis"] },
    "slack": { "command": "npx", "args": ["-y", "@mcp/server-slack"] }
  }
}

Copilot can now coordinate across GitHub, your database, cache, and communication channels — all through native tool calls.

Building a Custom MCP Server

Create a project-specific MCP server for your domain:

// tools/mcp-server.js
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({ name: "my-project-tools" });

server.tool("get_feature_flags", { env: z.string() }, async ({ env }) => {
  const flags = await fetchFeatureFlags(env);
  return { content: [{ type: "text", text: JSON.stringify(flags) }] };
});

server.run();

Register it in .mcp.json and Copilot can query feature flags natively.

Troubleshooting

Inspect the active configuration

copilot mcp list
copilot mcp get 
/env

| Symptom | Likely cause | What to check | |---------|--------------|---------------| | Server missing from copilot mcp list | Wrong config path or invalid JSON | Confirm the file is .mcp.json in the workspace root or ~/.copilot/mcp-config.json for user config | | Server is listed but tools are unavailable in-session | Session loaded a different config state | Use /env to inspect loaded MCP servers for the current session | | Remote server fails to respond | URL, auth header, or timeout issue | Re-check the remote endpoint and any --header values | | Local stdio server fails | Command path or dependencies are missing | Run the command manually and inspect its stderr outside Copilot | | HTTP or SSE server behaves inconsistently between requests | Unsafe session reuse assumption | Confirm whether the backend supports pooling for that transport or expects fresh state per request | | Server installs cleanly but acts unstable after upgrade | Dependency advisory or runtime-mode change | Re-check package versions, advisories, and whether heavy features such as always-on LSP changed defaults |

Tips

• Start with built-in GitHub MCP: It covers 90% of GitHub workflows. Only

add custom servers when you need tools beyond GitHub.

• Use .mcp.json for team tools: Project-level configs live at the workspace root

and can be committed to the repo for team use.

• Use ~/.copilot/mcp-config.json for personal tools: Global configs for

tools only you use (personal databases, API keys).

• Environment variables: Use ${env:VAR_NAME} syntax to keep secrets out

of config files.

• Inspect before you trust: copilot mcp list and copilot mcp get are the

fastest way to verify that Copilot is seeing the server definition you expect.

• Audit MCP dependencies explicitly: treat the server package, transport library,

and companion UI as part of the security surface before rollout.

• Treat HTTP/SSE as isolation-first: confirm whether the backend intentionally

avoids pooling before you optimize for reuse.

• Re-check fast-moving MCP tools: Context7 evolves quickly — run npx ctx7 setup to

get the latest version and confirm its MCP tool names (resolve-library-id, query-docs) match what your agent expects before standardizing new team workflows.

See Also

• [github-code-search](../github-code-search/SKILL.md) — use the built-in GitHub code index as grounded implementation context

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: drvoss
• Source: drvoss/everything-copilot-cli
• License: MIT

Install and usage instructions live in the source repository linked above.