The Model Context Protocol ecosystem has grown rapidly since its introduction. Dozens of MCP servers now exist, each giving AI agents structured access to a different tool or data source. But with so many options, it is hard to know which servers matter, how they differ architecturally, and when to use one over another. This guide surveys the most important MCP server implementations in production today, with real configuration examples and guidance on building your own.
File System MCP Server
The file system MCP server is the simplest and most widely used. It exposes local file operations — read, write, list, search — as MCP tools. Agents use it to navigate codebases, read configuration files, and write generated code. It runs locally (no network calls), responds in milliseconds, and requires minimal configuration. Most MCP-compatible editors include a built-in file system server, so you may already be using one without explicit setup.
The architecture is straightforward: the server watches a configurable set of directories, exposes tools like read_file, write_file, list_directory, and search_files, and enforces path-based access controls to prevent agents from reading outside the project root. Some implementations add glob-based filtering (only expose .ts and .tsx files) and gitignore-aware directory listings.
GitHub MCP Server
GitHub's official MCP server exposes the GitHub API as MCP tools. Agents can read repository contents, search code across repos, create and manage issues, open and review pull requests, and read workflow run status. It is essential for any agent workflow that involves version control — which is nearly all of them.
The server authenticates via a GitHub personal access token or OAuth app. It translates MCP tool calls into GitHub REST API requests, handles pagination transparently, and returns structured JSON. For teams with multiple repos, agents can cross-reference code and issues across repositories in a single session. The setup guide at /blog/github-mcp-server-cursor-setup covers the full configuration for Cursor.
// MCP server examples — editor config (.cursor/mcp.json)
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "./src"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx" }
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": { "DATABASE_URL": "postgresql://reader:pass@localhost:5432/mydb" }
}
}
}PostgreSQL MCP Server
The PostgreSQL MCP server gives agents schema awareness and read-only query execution. It connects to your database using a read-only role and exposes tools for listing tables, describing columns and constraints, viewing foreign key relationships, and running SELECT queries. This is critical for any agent task that involves database interactions — building API endpoints, writing migrations, or debugging data issues.
The key architectural decision is read-only enforcement. Production PostgreSQL MCP servers use a database role that can only execute SELECT statements. This is enforced at the database level (GRANT SELECT ONLY), not just in the MCP server code, because agents can be creative with tool parameters. Our detailed guide at /blog/postgresql-mcp-server covers setup, security, and best practices.
Linear MCP Server
The Linear MCP server connects agents to your issue tracker. Agents can read issues with full metadata (status, labels, assignee, linked PRs), search across projects, create sub-issues, and update ticket status. It transforms agents from code-only assistants into project-aware collaborators that know what to build, not just how to build it.
Linear's GraphQL API maps cleanly to MCP tools. Each tool corresponds to a Linear query or mutation, with structured input parameters and typed JSON responses. The server handles authentication, pagination, and rate limiting. For a deep dive into Linear MCP workflows, see /blog/linear-mcp-server.
Slack MCP Server
The Slack MCP server gives agents access to team communication. Agents can read channel messages, search conversation history, post updates, and read thread replies. The primary use case is context gathering — an agent working on a feature can search Slack for discussions about requirements, design decisions, and known edge cases that never made it into the ticket.
The architecture uses Slack's Web API with bot tokens. The MCP server scopes access to specific channels (agents should not read #random) and enforces rate limits to avoid Slack API throttling. Message formatting is normalized from Slack's mrkdwn to plain text so agents process content without parsing markup. Write access (posting messages) is typically restricted to specific channels like #agent-updates.
AppHandoff MCP Server
AppHandoff's MCP server is purpose-built for AI agent coordination across the full development lifecycle. Unlike single-service servers that expose one tool or data source, AppHandoff aggregates context from multiple sources — API specs, database schemas, frontend contracts, mismatch reports, ticket history — into a unified tool surface. Agents get 30+ tools covering project context, ticket management, scanning, deployment, and agent session coordination.
The server uses Streamable HTTP transport with SSE for real-time events (ticket updates, scan completions). Authentication supports both OAuth (for interactive agents in editors) and API keys (for headless CI agents). Session management preserves context across tool calls, so an agent that resolves a project in one call automatically scopes subsequent calls to that project. The full tool reference is at /mcp-server.
// AppHandoff MCP server — production config
{
"mcpServers": {
"apphandoff": {
"url": "https://api.apphandoff.com/mcp",
"headers": {
"Authorization": "Bearer <your-api-key>"
}
}
}
}
// Available tool categories:
// - Project context: get_project_summary, get_api_spec, get_db_schema
// - Tickets: get_handoff_requests, report_handoff_request, close_handoff_request
// - Scanning: trigger_rescan, get_mismatches, get_scan_history
// - Agent sessions: start session, sync state, get workload
// - Deploy: deploy_check, trigger_fe_deployArchitecture Patterns Across MCP Servers
Despite their different data sources, production MCP servers share common patterns. Transport is overwhelmingly Streamable HTTP (replacing the earlier stdio-based approach for remote servers). Authentication uses bearer tokens or OAuth. Tool responses are JSON with consistent error shapes. Servers implement capability negotiation during the handshake so agents know which tools are available before calling them.
The biggest architectural divide is between local servers (file system, local database) that run as child processes of the editor, and remote servers (GitHub, Linear, AppHandoff) that run as hosted services. Local servers use stdio or localhost HTTP, start instantly, and have zero latency. Remote servers use HTTPS, require authentication, and add network latency but provide access to shared team data that local servers cannot.
Building Your Own MCP Server
If your team uses a tool that does not have an MCP server, building one is straightforward. The @modelcontextprotocol/sdk package provides the server framework. You define tools as functions with typed input schemas (Zod), register them with the server, and expose the server over HTTP. A basic MCP server with three tools can be built in under 100 lines of TypeScript.
// Minimal custom MCP server (TypeScript)
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';
const server = new McpServer({ name: 'my-server', version: '1.0.0' });
server.tool(
'get_status',
'Get current system status',
{ service: z.string().describe('Service name') },
async ({ service }) => ({
content: [{ type: 'text', text: JSON.stringify({ service, status: 'healthy' }) }]
})
);
// Expose over Streamable HTTP transport
// See @modelcontextprotocol/sdk docs for transport setupChoosing the Right MCP Servers
Start with the servers that match your daily workflow. If you use GitHub, add the GitHub MCP server. If you use PostgreSQL, add the PostgreSQL server. If you manage work in Linear, add the Linear server. Each server you add gives agents one more layer of context, and the compounding effect is significant — an agent with access to your code, database, tickets, and team communication writes meaningfully better code than one with just file access.
For teams building AI-first products with Lovable or similar tools, AppHandoff's MCP server provides the coordination layer that ties everything together. It combines the context from multiple sources into a single interface and adds mismatch detection, ticket workflows, and deployment tools that standalone servers do not provide. Start with the setup guide at /blog/how-to-set-up-mcp-with-lovable, or explore the MCP server page at /mcp-server for the complete tool catalog.