MCP FAQ: Essential Model Context Protocol Questions Answered
Model Context Protocol (MCP) landed in late 2024 and immediately changed how we think about AI tool integration. Instead of building custom plugins for every AI assistant, you write one MCP server and it works everywhere. Cursor, Claude Desktop, Cline — they all speak the same language.
But the spec is young. Documentation is scattered. Real-world examples are thin. I've spent the last two months building MCP servers and answering the same questions repeatedly. Here's what everyone actually wants to know.
What exactly is MCP solving?
Before MCP, every AI tool needed custom integration code. Want to give Claude access to your database? Build a Claude integration. Want Cursor to read your monitoring data? Different integration, different API, different authentication flow.
MCP standardizes this. You write one server that exposes your data through a consistent interface. Any MCP-compatible client can consume it. The protocol handles transport, authentication, and capabilities negotiation. You just implement the data access layer.
Think of it like HTTP for AI context. HTTP didn't invent web servers, but it made them interoperable. MCP does the same for context providers.
How does MCP differ from OpenAI plugins or custom tools?
OpenAI plugins were vendor-locked and required hosting on OpenAI's infrastructure. Function calling requires you to define schemas in your prompts and handle execution in your application code.
MCP runs locally or on your infrastructure. The server declares what it can do (resources, prompts, tools), and clients discover capabilities dynamically. No centralized registry. No approval process. No waiting for vendor support.
Function calling is still relevant — MCP servers often expose tools that LLMs call via function calling. But MCP handles the connection, authentication, and data serialization. You're not mixing protocol concerns with business logic.
What's the difference between resources, prompts, and tools?
This confuses everyone initially. All three expose functionality, but the interaction model differs.
Resources are readable data. Think file contents, database records, API responses. The client reads them, usually to inject context into conversations. A codebase MCP server might expose code://src/auth.ts as a resource. The AI assistant reads it when discussing authentication logic.
Prompts are templated conversation starters. They bundle instructions with dynamic data. A code review prompt might inject recent commits and coding standards, then start the conversation with "Review this code for security issues." The user triggers prompts explicitly — they're shortcut buttons for complex interactions.
Tools are functions the LLM can call during inference. Search functions, calculators, API mutations. The LLM decides when to invoke them based on the conversation. A GitHub MCP server might expose create_issue as a tool. When you say "file a bug about that timeout", the LLM calls the tool with extracted parameters.
Glue's MCP server exposes your codebase as resources (individual files), tools (semantic search, architecture queries), and prompts (code review templates, feature documentation workflows). The AI assistant decides what to use based on your question.
Do I need to write my own MCP server?
Probably not initially. The ecosystem already has servers for common needs: filesystems, databases, GitHub, Slack, Google Drive. Install them, configure credentials, move on.
Build your own when:
You're exposing proprietary data sources
Existing servers don't match your security requirements
You need custom business logic in the integration layer
Performance requires optimization for your specific use case
Writing a basic MCP server takes an afternoon. The TypeScript SDK is solid, and Python support is improving. Start with the filesystem server source code as a template. Most servers are under 500 lines.
How do MCP servers handle authentication?
This is the biggest operational question. MCP supports multiple auth strategies, and choosing wrong causes headaches.
Environment variables work for local development. Your MCP client config loads credentials from env vars, passes them to the server at startup. Simple but not scalable.
OAuth flows work for third-party services. The MCP server implements OAuth, stores tokens locally, handles refresh. GitHub and Google Drive servers use this pattern. Users authorize once; the server manages token lifecycle.
Custom headers work for internal services. The client sends auth headers with each request. Your server validates against your existing auth system. This integrates cleanly with enterprise identity providers.
No authentication works for public data sources or when the MCP server itself runs in a trusted environment. The server trusts the client because the client runs on the user's machine.
Glue's MCP server uses API key authentication. Generate a key in the web UI, add it to your MCP client config, and the server validates requests against your organization's permissions. No OAuth dance, no token refresh logic — just standard API key handling.
What's the performance impact of MCP?
Depends on your server implementation. MCP itself is lightweight — JSON-RPC over stdio or HTTP. The bottleneck is usually your data source.
Reading a 10MB file through MCP takes the same time as reading it directly. But if your server queries a database across the internet for every request, that latency shows up in AI responses. Cache aggressively. Precompute when possible. Return minimal data.
MCP servers are long-running processes. The client starts them once and reuses the connection. Don't bootstrap expensive resources on every request. Initialize database connections, load indexes, authenticate once at startup.
Watch memory usage. AI assistants might request dozens of resources during a single conversation. If your server holds all that in memory, you'll hit limits fast. Stream large responses. Use cursors for paginated data. Clean up after reads complete.
Can I use MCP servers in production applications?
Yes, but think carefully about the architecture. MCP was designed for desktop AI assistants, not high-scale production systems.
The stdio transport doesn't support multiple clients. One client, one server process. If you're building a web application where hundreds of users need MCP access, you need the HTTP/SSE transport and load balancing infrastructure.
Security becomes critical at scale. Desktop MCP servers run with the user's permissions. Production MCP servers need proper authorization, rate limiting, audit logging. The protocol doesn't enforce these — you build them into your server.
Consider MCP for internal tools first. Developer productivity tools, support systems, data analysis platforms. Places where user count is bounded and you control the deployment environment. Prove the pattern before building customer-facing features on it.
How does MCP integrate with existing code intelligence platforms?
This is where things get interesting. Most MCP servers expose narrow functionality — one API, one database, one service. Code intelligence platforms like Glue index entire codebases and need to surface multiple data types.
Glue's MCP server exposes your codebase through all three MCP primitives:
Resources for individual files and documentation
Tools for semantic search and architecture queries
Prompts for code review workflows and feature analysis
When you ask your AI assistant "Why is the auth service so complex?", it uses the semantic search tool to find relevant code, reads those files as resources, and considers churn metrics exposed through additional tools. One MCP connection, multiple data sources unified behind a consistent interface.
This is the real power of MCP. Not just exposing data, but connecting different aspects of your codebase so AI tools understand relationships. Complexity metrics mean nothing without the code. Code makes no sense without ownership context. MCP lets you bundle all of it into a single, discoverable interface.
What are the security implications?
MCP servers run with the permissions of the user who started them. On your laptop, that's your user account. In production, that's whatever service account runs the process.
This is both feature and footgun. Feature: no separate permission system to manage. The filesystem MCP server can read what you can read. Footgun: if your AI assistant gets confused, it might delete files you can delete.
Implement read-only modes for high-risk operations. Require explicit confirmation for mutations. Log all tool invocations. These aren't protocol requirements — they're operational necessities.
For enterprise deployments, consider running MCP servers in sandboxed environments. Containers with limited filesystem access, network isolation, resource constraints. The protocol doesn't care where the server runs, as long as the client can connect.
Where is MCP heading?
The protocol is under active development. Expect rapid iteration through 2025. A few areas to watch:
Better streaming support for large responses. Current implementations buffer everything in memory. Streaming protocols would enable larger context windows without memory explosion.
Enhanced discovery mechanisms for finding available MCP servers. Right now you manually configure each server. A discovery protocol would let clients find and propose connections automatically.
Standardized server packaging for easier distribution. Today you clone repos and run npm install. Docker containers or single-binary distributions would simplify deployment.
Protocol extensions for specialized domains. Code analysis has different needs than database access. Domain-specific primitives would make servers simpler to write and more powerful to use.
The core abstraction is solid. Resources, prompts, and tools cover most use cases. The ecosystem needs time to mature around these primitives.
Should you adopt MCP now?
If you're building AI features, yes. The protocol is stable enough for production use. The ecosystem has critical mass. Waiting means building custom integrations you'll replace later.
Start small. Pick one data source your AI tools need access to. Find an existing MCP server or write a minimal one. Get it working with Claude Desktop. Expand from there.
The best time to adopt new protocols is when they solve real problems you're facing today. MCP solves context injection. If you're manually copying code into ChatGPT or building one-off AI integrations, MCP is ready now.