MCP Servers: What They Are and How to Use Them

What an MCP Server Does

An MCP server wraps one or more external capabilities in the MCP protocol, making them discoverable and usable by any MCP-compatible AI application. The server listens for connections from MCP clients, negotiates capabilities during initialization, and then responds to requests for tool listings, tool invocations, resource reads, and prompt selections.

Each server is designed to be focused on a single domain. A filesystem server provides file reading, writing, and directory operations. A database server provides query execution and schema inspection. A GitHub server provides repository access, issue management, and pull request operations. This focused design keeps individual servers simple, easy to audit, and straightforward to maintain.

The server decides what operations to expose. A database server might expose read-only query tools for a development environment but add write tools for a staging environment. A filesystem server might restrict access to a specific directory tree. These decisions are made at the server level through configuration, giving server operators fine-grained control over what the AI model can do.

The Three Things Servers Expose

MCP servers can expose three types of primitives. Most servers expose at least tools, many also expose resources, and some include prompts.

Tools are the most common and most powerful primitive. A tool definition includes a unique name, a description that helps the AI model understand when and how to use it, and a JSON schema defining the expected input parameters. When the model decides to invoke a tool, the server receives the call with the model's chosen arguments, executes the operation, and returns the result. Tools can do anything from querying a database to sending an email to running a shell command.

Resources provide read-only data access. A filesystem server might expose file contents as resources identified by file:// URIs. A database server might expose table schemas or query templates. Resources are safer than tools because they cannot modify external systems, making them appropriate for contexts where you want the model to have information access without action capability.

Prompts are reusable templates that define how the model should approach specific tasks. A server for code review might include a prompt that sets up the review criteria, output format, and evaluation rubric. Prompts are the least commonly used primitive but can be valuable for organizations that want to standardize how AI agents handle specific workflows.

Official vs Community Servers

The MCP ecosystem includes both official servers maintained by Anthropic or major contributors and community-built servers published by individual developers and organizations.

Official servers cover the most common integration needs. The filesystem server provides secure access to local files and directories. The GitHub server supports repository operations, issues, pull requests, and file content access. The PostgreSQL and SQLite servers provide database query capabilities. The Slack server enables reading and posting messages. These official servers are well-maintained, security-reviewed, and serve as reference implementations for server developers.

Community servers cover virtually every other integration imaginable. As of mid-2026, over 10,000 community-built servers are published across npm, PyPI, and MCP-specific registries. These servers connect to cloud services (AWS, GCP, Azure), communication platforms (Discord, Teams, email), search engines (Brave, Tavily, Google), productivity tools (Jira, Notion, Linear), monitoring systems (Datadog, Grafana), and hundreds of other services.

When choosing a community server, evaluate its maintenance status, documentation quality, permission model, and whether it has been security audited. Some community servers contain vulnerabilities like command injection or excessive permission requests. Checking the source code, looking at issue trackers, and testing in a sandboxed environment before production deployment is strongly recommended.

How to Run an MCP Server

Running an MCP server depends on which host application you are using and whether the server uses stdio or HTTP transport.

For Claude Desktop and Claude Code, server configuration goes in a JSON configuration file. Each server entry specifies the command to run, any arguments, and optional environment variables. When the host starts, it launches each configured server as a child process and connects via stdio. The server runs for the duration of the host session and shuts down when the host disconnects.

TypeScript-based servers from npm are typically run with npx, which downloads and executes the server package. Python-based servers from PyPI are run with uvx or python -m, depending on the package. Some servers require additional configuration like API keys, database connection strings, or directory paths, which are passed through environment variables or command-line arguments.

Remote servers using Streamable HTTP transport run as persistent services. They expose an HTTP endpoint that clients connect to, and they handle authentication, session management, and multiple concurrent connections. These are more complex to deploy but enable shared access across teams and organizations.

Server Security Considerations

Each MCP server runs in its own process with its own permissions, creating natural security boundaries. A filesystem server with read access to one directory cannot access anything else. A database server with query-only permissions cannot modify data. This isolation is a core architectural feature of MCP.

Server operators should apply the principle of least privilege when configuring servers. Give a server only the permissions it needs for its intended use case. If the model only needs to read files, configure the filesystem server for read-only access. If it only needs to query a database, use a database user with SELECT-only permissions.

For remote servers, OAuth 2.1 authentication ensures that only authorized clients can connect. Token scoping allows fine-grained control over which operations each client can perform. Audit logging records all tool invocations for compliance and security monitoring.

Building vs Using Existing Servers

Before building a custom MCP server, search the existing ecosystem. Community registries, npm, and PyPI contain thousands of pre-built servers. For common integrations like databases, version control, communication tools, and cloud services, an existing server almost certainly exists and will save significant development time.

Build a custom server when your integration has unique requirements that existing servers do not satisfy, when you need to expose internal company systems that have no public MCP server, or when security requirements demand full control over the server implementation. The official TypeScript and Python SDKs make server development straightforward, with the SDK handling all protocol mechanics while you focus on implementing the actual tool logic.