What is MCP and How Does it Work?

// Model Context Protocol — a standard way for AI agents to talk to external services

MCP = Model Context Protocol

Before MCP — Custom Tools

Each agent had its own one-off tool functions, hand-coded for each service.

After MCP — Standard Protocol

Any service can expose itself as an MCP server. Any agent can connect using the same standard.

// How the pieces connect
Your Agent
🤖 Claude
← MCP → JSON over HTTP/SSE
MCP Server
⚙ GitHub MCP
← API → GitHub REST API
Real Service
🐙 GitHub.com

⚙ MCP Server: github-mcp-server

3 tools exposed url: https://github.mcp.claude.com/mcp
When the agent connects to this server, it gets a list of tools it can use. Each tool talks to GitHub on the agent's behalf.
list_issues( )
What it does: Fetches open issues from any GitHub repository.

You give it: Owner name + repo name + optional filters.
It gives back: A list of issues with their titles, numbers, labels, and who opened them.

Like reading GitHub's Issues tab, but programmatically.
get_issue( )
What it does: Fetches the full details and comments on one specific issue.

You give it: Owner + repo + the issue number.
It gives back: Full description, all comments, current status, and labels.

Like clicking into a single GitHub issue and reading everything on it.
create_comment( )
What it does: Posts a new comment on an existing issue.

You give it: Owner + repo + issue number + the comment text.
It gives back: Confirmation that the comment was posted, with a link.

Like typing a reply in the GitHub comments box and hitting Submit.
The server sends this schema to the agent during the handshake. The agent reads it to know what tools exist and what parameters each needs.
list_issues( )
// MCP tool schema — sent by server // during tools/list handshake: { name: "list_issues", description: "List open GitHub issues", inputSchema: { // ← what to send owner: { type: "string" }, // required repo: { type: "string" }, // required state: { type: "string" }, // "open"|"closed" } }
get_issue( )
// The agent uses this schema to // know EXACTLY what params to pass. // No custom code needed — just read // the schema and fill it in. { name: "get_issue", description: "Get one issue + comments", inputSchema: { owner: { type: "string" }, repo: { type: "string" }, issue_number: { type: "number" }, } }
create_comment( )
// This tool WRITES to GitHub. // MCP handles auth — the agent // never touches API keys directly. { name: "create_comment", description: "Post a comment on an issue", inputSchema: { owner: { type: "string" }, repo: { type: "string" }, issue_number: { type: "number" }, body: { type: "string" }, // comment text } }
User Goal
MCP Connect
Tool Discovery
Agent Reasoning
MCP Tool Call
Server Response
Done
mcp_runtime.js ● LIVE
// MCP runtime — idle // Press "Run" to watch the full // connect → discover → call → respond // protocol play out live.
Connection State server_url: not connected connected: false tools_discovered: [] Agent Memory goal: null issues_list: null issue_detail: null comment_posted: false Execution Stats mcp_calls_made: 0 last_tool: none
💡 Key difference from regular tools: The agent doesn't have these functions baked in. It connects to the MCP server first, discovers what tools exist, then uses them — all via a standard protocol. Swap the server URL and you get a completely different set of capabilities.