They built a process that wraps an external system (GitHub, a database, the filesystem, a SaaS API) and exposes it to AI hosts through the Model Context Protocol. The server declares capabilities during the initialize handshake and then responds to JSON-RPC requests: tools/list returns the tool catalog, tools/call executes a function, resources/read returns data, prompts/get returns templates. It can run locally as a host-launched subprocess over stdio or remotely as an HTTP service over streamable HTTP. The server owns the integration logic; the LLM lives in the host, not in the server.
When your teammate says they built an **MCP server**, they built a small process that wraps some external system and makes it available to AI applications through a standard protocol.
The server speaks the Model Context Protocol on the wire and translates incoming requests into real actions on whatever it wraps: the local filesystem, a database, the GitHub API, Slack, or any other system.
Every server declares up to three kinds of capabilities. Tools are functions the model can call (create_issue, search_files, run_query). Resources are read-only data identified by a URI that the host can pull on demand (a file, a database row set). Prompts are reusable templates the user can invoke (a code-review template that takes a PR number). A server can offer any combination of these; the initialize handshake tells the client what is available.
Deployment comes in two shapes. A local stdio server is a subprocess the host launches on demand and talks to over standard input and output. A remote HTTP server is a long-running service reached over the internet using the streamable HTTP transport. The protocol messages are identical in both cases; only the transport differs.
The important distinction: the server owns the integration with the external system. It does not see the LLM. The model lives in the host application, and the host's MCP client relays tool calls down to the server.
Your teammate built a process that implements the server side of the **Model Context Protocol** and exposes a vocabulary of capabilities to any MCP client that connects. The server is where integration logic for one external system actually lives.
On startup the server negotiates the protocol version and declares which capability families it offers. When the client calls tools/list, the server returns its tool catalog with names, descriptions, and JSON schemas. When the client calls tools/call, the server executes the requested function (a GitHub API call, a SQL query, a file write) and returns the result as typed content blocks. The same pattern applies to resources/list, resources/read, prompts/list, and prompts/get.
Two deployment shapes exist. A **stdio server** runs as a host-launched subprocess and exchanges newline-delimited JSON over standard input and output. This is the default for local tools (filesystem, sqlite, memory, fetch) because it requires zero network configuration and inherits the host's sandbox. A **remote HTTP server** runs as a long-lived service in a vendor's infrastructure and serves multiple users over streamable HTTP with OAuth 2.1 authentication. This is the right shape for SaaS integrations like GitHub, Slack, Linear, Notion, and Sentry.
The server is intentionally narrow. It wraps one system behind a standard interface. It does not run the model, orchestrate the agent loop, or render UI. Those are the host's jobs. Servers that stay narrow are small, easy to maintain, and easy to compose with other servers in a single host session.
Quick reference
TL;DR
An MCP server is a process that wraps an external system and exposes tools, resources, and prompts to MCP clients over stdio (local) or streamable HTTP (remote).
Think of the AI app on your laptop as someone sitting in an office. The office has special doors on the wall labeled GitHub, Filesystem, Postgres, Slack. Behind each door is a tiny helper whose only job is to carry requests from the office to that external system and bring results back. Each helper is an MCP server. Some helpers live in the same building (the host launches them as a program on your machine). Others live far away in a data center (you reach them over the internet). The helper does the real work on the other side and shields the office from the complexity.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Exposing a one-off internal endpoint that only one team uses from one IDE. A direct HTTP call from a custom plugin is simpler. MCP pays off when multiple hosts need to reach the same tool.
Wrapping a system that requires complex multi-step human approval flows. MCP servers handle stateless request-response. Complex consent UI belongs in the host or a higher layer, not inside a tool call.
Integrating a system whose authentication model cannot fit OAuth 2.1 or local sandboxing. If the underlying system needs exotic auth (mTLS with custom cert chains, SAML, hardware tokens), the MCP server shape may not be the cleanest fit.
Quick scan · 2–4 min
Everything important, quickly.
5 min: state the one-sentence definition framed as what your teammate built, name the three capability families, walk the two deployment shapes (stdio vs remote HTTP), name three official and three SaaS servers, and distinguish the server from the client and host.
Real-world examples
Real products, models, and research that use this idea.
1Official Anthropic servers (filesystem, fetch, memory, sqlite, sequential-thinking) ship at github.com/modelcontextprotocol/servers and are the default local servers for Claude Desktop.
2The GitHub MCP server was rewritten in Go in 2025 and is the canonical example of a remote server exposing issues, PRs, and code search through MCP.
3Slack, Notion, Linear, Sentry, and Stripe publish first-party MCP servers maintained by the vendors themselves, alongside their existing REST and GraphQL APIs.
4Postgres and SQLite servers expose read and parameterized query tools so the model can answer questions about a real database without the host needing database-specific code.
5Community catalogs at glama.ai, mcp.so, and smithery.ai index thousands of servers covering everything from Kubernetes to Spotify.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a stdio server differ operationally from a streamable HTTP server?
Sign in or go Pro to see the approach for this follow-up.
QCan a single server expose all three primitive types (tools, resources, and prompts)?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens when a server crashes mid-session?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Calling the server an AI service. The server is plumbing that wraps an existing system; the model lives in the host, not the server.