Your teammate says they built an 'MCP server'. What did they actually build?

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.