Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
December 2025 Update: MCP is now supported by Claude, Cursor, Windsurf, and many other AI tools. This module includes production-ready server examples.
What is MCP?
Model Context Protocol (MCP) is an open standard for connecting AI models to external data sources and tools. Developed by Anthropic, it provides a unified way for LLMs to interact with:- Databases (PostgreSQL, MongoDB, SQLite)
- APIs (GitHub, Slack, Notion)
- File systems (local, S3, Google Drive)
- Development tools (Git, Docker, Kubernetes)
- Any external service
Think of MCP as USB for AI — a standard interface that lets any AI model connect to any tool, and any tool connect to any AI model.
Why MCP Matters in 2025
| Before MCP | With MCP |
|---|---|
| Custom integration per tool | Standard protocol for all |
| Tight coupling to one model | Model-agnostic |
| Rebuild for each project | Reusable servers |
| Limited community sharing | Open ecosystem |
Who’s Using MCP?
- Claude Desktop - Native MCP support
- Cursor - IDE with MCP integrations
- Windsurf - AI coding assistant
- Continue - Open-source AI coding
- Zed - Next-gen code editor
Architecture
Building an MCP Server
Basic Server Structure
Database MCP Server
Using MCP with Claude Desktop
Configure inclaude_desktop_config.json:
Building an MCP Client
Integrating MCP with LangChain
Common MCP Servers
The MCP ecosystem has grown rapidly. Here are the most popular servers:Filesystem
Read/write files, list directories.
npx @anthropic-ai/mcp-server-filesystemPostgreSQL
Query databases, list tables.
npx @anthropic-ai/mcp-server-postgresGitHub
Manage repos, issues, PRs.
npx @anthropic-ai/mcp-server-githubSlack
Send messages, read channels.
npx @anthropic-ai/mcp-server-slackGoogle Drive
Read/write documents.
npx @anthropic-ai/mcp-server-gdrivePuppeteer
Web scraping, automation.
npx @anthropic-ai/mcp-server-puppeteerMemory
Persistent knowledge graph.
npx @anthropic-ai/mcp-server-memoryBrave Search
Web search integration.
npx @anthropic-ai/mcp-server-brave-searchQuick Install for Claude Desktop
Best Practices
Security First
Security First
- Validate all inputs
- Use read-only database connections when possible
- Implement rate limiting
- Log all tool calls
Error Handling
Error Handling
Resource Management
Resource Management
- Use connection pooling for databases
- Implement timeouts for external calls
- Clean up resources on shutdown
Documentation
Documentation
- Write clear tool descriptions
- Document expected inputs and outputs
- Include examples in descriptions
MCP vs Function Calling
| Aspect | MCP | OpenAI Function Calling |
|---|---|---|
| Standard | Open protocol | Proprietary |
| Reusability | High (server-based) | Per-application |
| Multi-model | Yes | OpenAI only |
| Complexity | Higher initial setup | Simpler |
| Ecosystem | Growing | Mature |
Next Steps
Agentic Architecture
Design patterns for building multi-agent systems
Interview Deep-Dive
Explain the Model Context Protocol architecture. Why was it created, and what problem does it solve that function calling alone does not?
Explain the Model Context Protocol architecture. Why was it created, and what problem does it solve that function calling alone does not?
Strong Answer:
- MCP solves the N-times-M integration problem. Before MCP, if you had N AI applications and M external tools, you needed N times M custom integrations. Every application had its own way of connecting to GitHub, its own database query tool, its own file system access layer. MCP introduces a standard protocol layer so that any MCP client (your AI application) can connect to any MCP server (a tool provider) through a single interface. Think of it like USB for AI — before USB, every peripheral needed its own proprietary cable.
- Function calling, as implemented by OpenAI and Anthropic, solves a different problem: it lets an LLM express intent to call a function during generation. But the function itself must be implemented and hosted by your application. Function calling says “the model wants to call
get_weather(city='Tokyo')” — but you still have to write theget_weatherfunction, handle authentication, manage connections, and deal with errors. MCP encapsulates all of that on the server side. The MCP server for weather handles the API key, the HTTP calls, the error handling, and exposes a clean tool interface. - The architectural distinction is the client-server separation over a transport layer. MCP servers run as separate processes communicating via stdio or SSE. This means a single MCP server can be shared across multiple AI applications. If you build a PostgreSQL MCP server once, every MCP-compatible client — Claude Desktop, Cursor, your custom agent — can use it without modification. With function calling, you would reimplement the database integration in each application.
- The practical limitation of MCP today is ecosystem maturity. The protocol is well-designed but the tooling is still evolving. Error handling semantics, authentication standards, and streaming behavior are not fully standardized across implementations. In production, you need to add your own retry logic, timeout handling, and input validation on top of what MCP provides.
search_customers(name='...') rather than run_sql(query='...'). Third, input validation: every argument the LLM passes to a tool must be validated and sanitized. The LLM might generate a SQL injection payload not out of malice but because it saw one in its training data. Fourth, rate limiting per user session to prevent the LLM from accidentally running a full table scan in a loop. Fifth, comprehensive audit logging of every tool call, its arguments, and its results. In a regulated environment, you also need approval flows where certain tool calls require human confirmation before execution.You need to build a custom MCP server that connects an AI coding assistant to your company's internal APIs. Walk me through the design.
You need to build a custom MCP server that connects an AI coding assistant to your company's internal APIs. Walk me through the design.
Strong Answer:
- First, I would scope the tool surface area. The biggest mistake in MCP server design is exposing too many tools. LLMs perform worse when given 50 tools to choose from compared to 5 well-designed ones. I would start by identifying the 5-8 most common operations the coding assistant needs: search the codebase, read file contents, query the CI/CD pipeline status, look up internal documentation, and create JIRA tickets. Each tool gets a precise name, a detailed description (this is the model’s only guide for when to use the tool), and a strict input schema.
- Second, I would design the tool descriptions as if I were writing documentation for a junior developer. The model uses the description to decide when and how to use the tool. A description like “Search code” is insufficient. A description like “Search the codebase for files matching a pattern or containing specific text. Use this when the user asks about where something is defined, how something is implemented, or wants to find examples of a pattern. Returns file paths and matching line numbers” gives the model the context it needs to use the tool appropriately.
- Third, I would implement robust error handling. MCP tool calls will fail — API timeouts, auth token expiry, malformed inputs. Each error case should return a clear, actionable error message as a TextContent response, not throw an exception. The model needs to understand what went wrong so it can decide whether to retry, adjust its approach, or inform the user. A raw stack trace is useless to the model.
- Fourth, authentication. The MCP server needs to authenticate against your internal APIs. I would pass API tokens via environment variables in the MCP server configuration, never hardcoded. For per-user authentication (the assistant acts on behalf of the logged-in developer), you need a token delegation pattern where the client passes the user’s auth token as part of the session initialization.
- Fifth, I would implement response truncation. Internal APIs can return enormous payloads — a codebase search returning 500 results, a CI log with 10,000 lines. The MCP server must truncate these to a reasonable size (say, 2,000 tokens) and indicate that results were truncated, so the model can request more specific queries.
list_tools, does it handle unknown tool names gracefully, does it respect the MCP message format? These are protocol-level tests that do not depend on the internal APIs. Third, integration tests that run against a staging environment of the internal APIs, triggered manually or nightly. These verify that the actual API contracts have not changed — field names, response formats, pagination behavior. I would also add a health check tool to the MCP server itself that verifies connectivity to all dependent APIs, so the client can check if the server is fully operational before exposing tools to the model.Compare MCP with OpenAI's function calling and tool use. In what scenarios would you choose one over the other?
Compare MCP with OpenAI's function calling and tool use. In what scenarios would you choose one over the other?
Strong Answer:
- Choose function calling when you are building a single application, using one provider, and your tools are tightly coupled to your application logic. For example, a customer support chatbot that needs to look up orders, issue refunds, and update tickets — these tools are specific to your business domain, they need access to your application’s database and authentication context, and they will never be reused by another application. Function calling is simpler to implement (just define the schema and handle the call), has no infrastructure overhead (no separate server process), and is deeply integrated with the provider’s streaming and tool-use capabilities.
- Choose MCP when you need tool reuse across multiple AI applications, provider portability, or when the tools represent capabilities that are independent of your application logic. Database access, file system operations, API integrations to third-party services like GitHub or Slack — these are the sweet spot for MCP. Build the server once, use it from Claude Desktop during development, from your production agent in deployment, and from Cursor for coding assistance.
- The hybrid approach is what most production systems end up with. Application-specific tools (order lookup, business logic) are implemented as function calls within your application. Infrastructure and third-party integration tools are implemented as MCP servers. This gives you the simplicity of function calling where it matters and the reusability of MCP where it matters.
- One often-overlooked consideration is latency. Function calling happens in-process — the tool execution is a direct function call with microsecond overhead. MCP involves inter-process communication (stdio or HTTP), which adds milliseconds per tool call. For an agent that makes 10-15 tool calls per task, those milliseconds compound. If latency is critical, keep hot-path tools as in-process function calls and use MCP for less frequent, heavier operations.
- Another consideration is model compatibility. Function calling schemas differ between OpenAI and Anthropic — parameter naming, required fields, how you return results. If you switch providers, you rewrite your function calling integration. MCP is provider-agnostic by design. If provider portability is a requirement (and in enterprise it usually is), MCP reduces switching costs significantly.