Intermediate

MCP Servers, Tools & Resources

The MCP ecosystem exploded in 2025 — from a handful of reference servers at launch to over 16,000 community servers indexed by mid-2025. This page covers the most important pre-built servers, how to evaluate servers from the ecosystem, and what you need to know to build your own MCP server.

Official Pre-Built Servers

Anthropic released the first set of production-quality reference MCP servers alongside the protocol. These serve as both practical integrations and reference implementations for how MCP servers should be structured.

Server	What it connects to	Key tools	Transport
Filesystem	Local files and directories	read_file, write_file, list_directory, search_files	stdio
GitHub	GitHub repositories, issues, PRs	search_repos, get_file, create_issue, list_prs	stdio
Git	Local git repositories	git_log, git_diff, git_status, git_blame	stdio
Postgres	PostgreSQL databases	query, list_tables, describe_table	stdio
Slack	Slack workspaces	send_message, read_channel, list_channels, search_messages	stdio
Google Drive	Google Drive files and docs	search_files, read_file, list_folder	stdio
Puppeteer	Web browsers (headless)	navigate, screenshot, click, extract_text	stdio

The Community Ecosystem

Beyond official servers, the community built 16,000+ servers covering nearly every major SaaS product, database, API, and developer tool by mid-2025. Unofficial registries like mcp.so index these servers and provide discovery, ratings, and install instructions.

Popular community server categories

Databases: MySQL, SQLite, MongoDB, Redis, Supabase, PlanetScale
Dev tools: Jira, Linear, Notion, Confluence, Sentry, Datadog
Cloud providers: AWS, GCP, Azure resource management
Communication: Discord, Teams, Email (SMTP/IMAP), Telegram
Data: CSV files, Excel/Sheets, Airtable, Salesforce
APIs: Stripe, Twilio, HubSpot, Shopify

Evaluating community servers

Check GitHub star count and recent commit activity — abandoned repos are common
Review what credentials the server requests — avoid servers that request broad scopes when narrow scopes would suffice
Read the tool descriptions carefully — misleading descriptions are a security vector (see MCP Security page)
Prefer servers with pinned dependencies and published checksums
Run community servers in sandboxed environments, not with production credentials

Writing MCP Tool Definitions

When building your own MCP server, the quality of your tool definitions determines whether the AI uses your tools correctly. The name and description are what the LLM reads to decide when and how to call your tool — they are more important than the implementation.

Good tool definition principles

Name: verb_noun format, unambiguous — search_files not files
Description: explain when to use this tool (not just what it does); include what it returns
Parameters: use enum for constrained values; mark required vs optional clearly
One tool, one responsibility: avoid multi-purpose tools that take a mode parameter
Return format: document what the response looks like so the AI knows how to parse it

Common tool definition mistakes

Vague description: "does file stuff" — AI cannot reliably decide when to use it
Overloaded tool: one tool that reads, writes, and deletes based on a mode param
No return type documentation — AI cannot interpret the result
Missing required/optional distinction — AI hallucinates required parameters
No error cases documented — AI doesn't know what to do when the tool fails

MCP Resources in Depth

Resources expose data that the AI reads as context — files, database rows, documents, API responses. Unlike tools (pull data by executing code), resources are more like a content addressable store identified by URIs.

Resource URI patterns:

file:///home/user/docs/spec.md — local file
postgres://mydb/public/users/42 — database row
github://anthropics/mcp/blob/main/README.md — repository file
slack://workspace/channel/general — channel history

Resources can be static (file contents) or dynamic (database query results). Dynamic resources are fetched at access time. The AI requests a resource by URI; the MCP server returns the content.

MCP Transport Options

Transport	How it works	Best for	Notes
stdio	Parent process spawns server as subprocess; communicates via stdin/stdout	Local tools, desktop apps (Claude Desktop, Cursor)	Simple, zero network config; default for local servers
HTTP + SSE	HTTP requests + Server-Sent Events for streaming responses	Remote/shared servers, web deployments	Standard web stack; requires authentication
WebSocket	Persistent bidirectional connection	Low-latency real-time tool interactions	More complex to set up; useful for streaming tool results

Building Your Own MCP Server

Minimal MCP server checklist:

Choose an SDK: @modelcontextprotocol/sdk (TypeScript/Node), mcp (Python)
Define your tools with name, description, and JSON Schema for parameters
Implement tools/list — returns your tool definitions
Implement tools/call — receives tool name + arguments, executes, returns result
Optionally implement resources/list and resources/read for data access
Choose transport: stdio for local tools, HTTP+SSE for remote
Add error handling: always return a structured error, never crash the server
Test with Claude Desktop or mcp inspector (official debugging tool)

Before publishing to the ecosystem:

Review the MCP Security page — tool descriptions and return values are injection vectors. Your server's tool descriptions appear directly in the AI's context; a compromised or malicious description can redirect the AI's behaviour.

Checklist: Do You Understand This?

Name five pre-built official MCP servers and what each one connects to.
What five questions should you ask before using a community MCP server in production?
What is the difference between a Tool and a Resource in MCP?
What are the three transport options for MCP, and when would you choose each?
What makes a good MCP tool description, and what does a bad one look like?
What does the mcp inspector tool do, and when in your development process should you use it?