MCP Servers: The Complete Guide to Extending AI Agents

What an MCP Server Actually Does

An MCP server exposes capabilities to an AI application through a standard protocol. Those capabilities come in three shapes: tools the model can call, resources it can read, and prompts the user can invoke. The host application, such as Claude Code or an IDE, runs an MCP client that connects to one or more servers.

Before MCP, every agent-tool integration was bespoke. MCP replaces that with a single interface, so the same GitHub server works in Claude Code, Codex, Antigravity, and any other compatible host.

Local vs Remote Servers

Local servers run as a child process and communicate over standard input and output. They are ideal for filesystem access, local databases, and developer tooling.

Remote servers run behind HTTP and communicate with streamable HTTP or server-sent events. They are ideal for SaaS products such as GitHub, Sentry, Stripe, and Notion, where the vendor hosts the server and handles authentication.

Adding a Server to Claude Code

Claude Code has first-class MCP commands. Add a remote server:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Add a local filesystem server scoped to one directory:

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/projects/my-app

List configured servers and check their health:

claude mcp list

Inside a session, /mcp shows connection status and available tools.

Adding a Server to Codex

Codex reads MCP configuration from ~/.codex/config.toml. A local server entry looks like this:

[mcp_servers.filesystem]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects/my-app"]

Restart Codex after editing the file. Remote servers use a url field instead of command and args.

Designing a Safe Server

Security is the hard part of MCP. A server is code running with your permissions, and its tool descriptions are text that the model will trust. Follow these rules:

1. Scope access narrowly. Point filesystem servers at a single project, not your home directory. Use read-only database credentials unless writes are required.
2. Audit before you connect. Read the server source or vendor documentation. Prefer official servers from the vendor that owns the API.
3. Treat tool output as untrusted. A webpage, issue comment, or database row can contain prompt injection. Never let tool output silently authorize destructive actions.
4. Require approval for writes. Keep human confirmation enabled for file writes, shell commands, payments, and anything that sends data externally.
5. Rotate credentials. Use short-lived tokens scoped to the minimum necessary permissions.

The Servers Worth Starting With

• Filesystem for scoped project access
• GitHub for issues, pull requests, and code search
• PostgreSQL for read-only schema inspection and queries
• Playwright for browser automation and testing
• Sentry for production error context
• Memory for persistent knowledge across sessions

Tecrese maintains a directory of vetted MCP servers with links to source and documentation. Start with one server, verify its behavior, and expand only when the workflow demands it.

The Bottom Line

MCP turns an agent from a text generator into a system that can act. That power is exactly why configuration deserves the same care as production credentials. Connect less, scope tighter, and review more.