Wait, Why Six?
Here's the short version. There are fundamentally different ways that AI needs to interact with your product, and they don't collapse neatly into a single server:
- Your public documentation needs to be machine-readable
- Your API needs to be callable by AI agents
- Your product's own AI features need structured access to your systems
- Your internal teams need AI-assisted access to operational data
- Your web UI needs to be accessible through browser-based AI
- Your engineering team needs AI coding agents that understand your codebase
Each of these has a different audience, different security posture, and different reason for existing. Lumping them together is like saying "we need a website" when what you actually need is a marketing site, an app, a docs site, and an admin dashboard. Same technology, very different purposes.
The Architecture
Here's how these six servers map to your product:
┌──────────────────────────────────────────┐
│ EXTERNAL / PUBLIC │
│ │
Developers │ ┌──────────┐ ┌──────────────┐ │
building on ────────│ 1. Docs │ │ 2. API │─────────── AI agents
your platform │ │ MCP │ │ MCP Server │ │ acting on
│ │ Server │ │ │ │ behalf of
│ └──────────┘ └──────────────┘ │ your users
│ │
├──────────────────────────────────────────┤
│ PRODUCT / SEMI-PUBLIC │
│ │
Your product's │ ┌──────────────┐ ┌───────────────┐ │
AI features ────────│ 3. Product │ │ 5. Browser │─────── End users
│ │ Agent MCP │ │ MCP Server │ │ via AI in
│ │ Server │ │ (WebMCP) │ │ the browser
│ └──────────────┘ └───────────────┘ │
│ │
├──────────────────────────────────────────┤
│ INTERNAL │
│ │
Your teams ────────┌──────────────┐ ┌───────────────┐ │
(support, │ │ 4. Internal │ │ 6. Dev │─────── AI coding
eng, ops) │ │ Ops MCP │ │ Knowledge │ │ agents
│ │ Server │ │ MCP Server │ │ (Cursor,
│ └──────────────┘ └───────────────┘ │ Claude Code)
│ │
└──────────────────────────────────────────┘
Let me walk through each one.
1. The Documentation MCP Server
Who it's for: Developers building on your platform, using AI coding assistants.
What it does: Makes your API docs, guides, tutorials, and examples queryable by AI. Instead of a developer Googling your docs and copy-pasting, their AI assistant (Claude, Cursor, Windsurf, ChatGPT) pulls the current information directly from the source.
This is the easiest one to understand and probably the fastest to implement. Your docs are already public. The MCP server just makes them structured and machine-readable instead of requiring an AI to scrape your website and hope the training data is current.
Why it matters: If a developer asks their AI assistant "how do I authenticate with [your API]?" and the answer comes from six-month-old training data instead of your current docs, you've got a problem. The developer doesn't know the answer is stale. They just build something broken and open a support ticket.
Companies like Fern are already auto-generating these. Every docs site they host gets a free MCP server at your-site.com/_mcp/server. Google launched their Developer Knowledge API for the same reason. Apidog does this for API specifications.
The pattern: Mostly read-only. Unauthenticated or lightly authenticated. Think of it as your docs, but with a machine-friendly front door.
Developer's AI Assistant Your Docs MCP Server
(Claude, Cursor, etc.) (your-site.com/_mcp/server)
│ │
│ "How do I paginate results?" │
├──────────────────────────────────►│
│ │ Fetches current docs
│ Structured response w/ examples │ (not training data)
│◄──────────────────────────────────┤
│ │
2. The API MCP Server
Who it's for: AI agents acting on behalf of your users, and developers wiring up agentic workflows.
What it does: Exposes your actual API as callable MCP tools. Not documentation about your API. The API itself. Send a message. Create a contact. Pull a report. The real operations.
This is the one most people think of when they hear "MCP server." It's your product's capabilities wrapped in the MCP protocol so AI agents can call them. When someone in Claude says "send a text to Sarah," and your product handles messaging, this is the server that makes that happen.
Why it matters: This is the new distribution channel. Anthropic, OpenAI, and others are building directories where users discover and connect to MCP servers. If your product isn't there, you're invisible to AI-assisted workflows. And increasingly, invisible to the humans who use them.
Auth is the hard part here. Unlike the docs server, this one needs real authentication. OAuth 2.1 with PKCE is becoming the standard. The MCP spec formalized this in mid-2025, and Anthropic, OpenAI, and the directory platforms all expect it. If you already have OAuth for a Zapier or Slack integration, you're not starting from zero. But it's not trivial either.
One thing we keep running into: teams underestimate how long the OAuth piece takes. Not the implementation (that's maybe a week or two), but getting it reviewed, submitted to directories, and through the approval process. We've seen directory review times range from three to six weeks. So if you're planning a launch, back-date your OAuth work accordingly.
AI Agent (ChatGPT, Claude) Your API MCP Server
│ │
│ Tool: send_message │
│ {to: "+1555...", body: "Hey"} │
├───────────────────────────────────►│
│ OAuth │──► Your API
│ {status: "sent", id: "msg_123"} │◄──
│◄───────────────────────────────────┤
│ │
3. The Product Agent MCP Server
Who it's for: Your own AI features. Your product's chatbot, assistant, copilot, whatever you're calling it.
What it does: Gives your product's AI capabilities structured access to your own APIs, your connected integrations, and any internal services it needs. Think of it as the toolbox your AI features reach for.
This is the one people don't always think of as an "MCP server," but architecturally, it is. Your product has AI features (or it will). Those features need to call your APIs, maybe call third-party APIs through integrations you've set up, and potentially access things like knowledge bases or configuration.
Why it matters: Without this, your product's AI features are either calling your API the same way external consumers do (which means you can't give them elevated access or private tools) or they're hardwired into your codebase in a way that's brittle and hard to iterate on.
The MCP pattern gives you a clean boundary. Your AI agent talks to the MCP server. The MCP server talks to your APIs and integrations. You can add, remove, and modify tools without touching the agent code.
We've seen teams try to avoid this layer and wire their AI features directly into the product backend. It works until you want to add a second agent, or give your AI access to a connected integration, or let your AI feature do something that your public API doesn't support. Then you're either duplicating logic or creating spaghetti. The MCP layer prevents that.
Your Product's AI Features
(Chatbot, Copilot, Assistant)
│
│ Tool: get_account_health
│ Tool: search_knowledge_base
│ Tool: trigger_integration_sync
├──────────────────────────────────► Product Agent MCP Server
│ │
│ ┌───────────┼───────────┐
│ ▼ ▼ ▼
│ Your APIs Integrations Knowledge
│ (3rd party) Base
│◄─────────────────────────────────── Aggregated response
4. The Internal Operations MCP Server
Who it's for: Your teams. Support, engineering, ops, data, whoever needs to query internal systems.
What it does: Gives your internal teams AI-assisted access to things like customer data, support tickets, billing info, admin dashboards, and operational metrics.
This is the one that's hiding in plain sight. Every product company has some collection of internal tools (sometimes homespun admin dashboards, sometimes Retool, sometimes a messy spreadsheet that someone swears by). Your teams use these to answer questions like "what's going on with this customer's account?" or "how many people hit this error last week?"
An internal MCP server wraps those capabilities so your teams can ask those questions through an AI assistant instead of clicking around five different dashboards.
Why it matters: Your support team shouldn't have to memorize which Retool page has which query. Your engineering team shouldn't have to write a custom SQL query every time they need to investigate an issue. The data is there. The access patterns are well-understood. The MCP server just gives AI a structured way to get to it.
The auth story here is simpler: SSO, internal credentials, whatever your org already uses. The security posture is "same as your internal tools" because that's exactly what it is.
The thing that surprises people: once this exists, adoption is fast. Teams that were skeptical about AI become regular users once they can say "pull up the last 10 support tickets for this account" in their AI assistant instead of going through three screens in the admin panel.
We've seen a data team get asked if they use a popular data warehouse's MCP server and the answer was no. Meanwhile, they're running manual queries daily that would be trivially automated through it. Available doesn't mean adopted. The internal MCP server is often the highest-ROI one because you're eliminating friction your team doesn't even realize they're tolerating.
Internal Team Member Internal Ops MCP Server
(via Claude Code, etc.) │
│ ┌────────┼────────┐
│ "What's the error rate ▼ ▼ ▼
│ for account #4521?" CRM Dashboards Database
├──────────────────────► │ │ │
│ └────────┼────────┘
│ Structured answer with │
│ context from 3 systems │
│◄───────────────────────────────────┘
5. The Browser MCP Server
Who it's for: End users who are logged into your web UI and using browser-based AI.
What it does: Embeds an MCP server directly into your web application. When a user with a browser-based AI tool (like a Browser MCP extension) visits your app, their AI assistant can interact with your product using their existing authenticated session.
This is the newest pattern and the one I think will catch people off guard.
The idea: if someone is logged into your web app, and they have an AI assistant running in their browser, that assistant should be able to interact with your product without needing a separate API key or OAuth flow. The user is already authenticated. The browser session is already there. Why make them go set up an API integration to do something they could do by clicking around the UI?
MCP-B is pushing this model. About 50 lines of code embedded in your web app, no separate OAuth flow, no API keys. The MCP server inherits the user's existing session. Browser MCP takes a slightly different approach with a Chrome extension that works with your existing browser profile.
And then there's WebMCP, which just hit early preview in Chrome 146. This is Google and Microsoft working through the W3C to make this a proper web standard. Two new APIs: a declarative one (annotate your HTML forms and they become MCP tools) and an imperative one (navigator.modelContext for dynamic JavaScript interactions). The tools inherit your page's existing permissions and security policies. If your JavaScript can't access a resource, neither can the MCP tools.
That last part is important. WebMCP becoming a web standard means this isn't just a Chrome extension ecosystem play. It's the browser itself saying "websites should be agent-readable." If your product has a web UI, this is heading toward table stakes.
Why it matters: Not every user is going to go set up your API MCP server. That's a developer-level activity. But every user is going to have an AI assistant in their browser at some point (some would argue we're already there). The browser MCP is the path of least resistance for getting AI interaction with your product to the widest number of users.
Think of it this way: your API MCP server is for power users and developers. Your browser MCP server is for everyone else.
The tradeoff: It's session-scoped. When the user closes the browser or logs out, the AI loses access. That's actually a feature for security (no lingering tokens), but it means this isn't the right pattern for background agents or scheduled tasks.
User's Browser (Chrome 146+)
┌────────────────────────────────────────┐
│ │
│ Your Web App (logged in) │
│ ┌──────────────────────────────┐ │
│ │ WebMCP / Embedded MCP │ │
│ │ (declarative or imperative) │ │
│ │ navigator.modelContext │ │
│ └──────────┬───────────────────┘ │
│ │ │
│ Browser AI Agent │
│ ┌──────────┴───────────────────┐ │
│ │ "Summarize my recent │ │
│ │ activity this week" │ │
│ └──────────────────────────────┘ │
│ │
└────────────────────────────────────────┘
Uses existing session auth
Inherits page permissions + CSP
No API keys, no OAuth
6. The Dev Knowledge MCP Server
Who it's for: Your engineering team's AI coding agents (Cursor, Claude Code, Copilot, Windsurf).
What it does: Gives AI coding assistants structured access to your internal programming documentation, architecture decisions, API contracts, coding conventions, and system design. The stuff that's too big for a CLAUDE.md or .cursorrules file but critical for an AI agent to write good code in your codebase.
Every engineering team has this knowledge. It lives in Notion docs, architecture decision records, internal wikis, README files scattered across 40 repos, Slack threads that someone bookmarked, and the head of that one engineer who's been there since the beginning.
When your team uses AI coding assistants (and they do, or they will), those assistants are flying blind on everything that's specific to your organization. They can write generic TypeScript just fine. But they don't know that your team uses a specific error handling pattern, or that there's an internal API for user lookups that's different from the public one, or that the billing service has a quirk where you have to pass the tenant ID in a specific header.
Why it matters: The CLAUDE.md file (or equivalent) is the starting point, but it hits a ceiling fast. A few hundred lines of context is fine for basic conventions. But once you're dealing with dozens of internal services, multiple API contracts, deployment patterns, migration guides, and architectural context, you need something more structured.
An MCP server for dev knowledge lets your coding agents query for what they need, when they need it. "What's the auth pattern for internal service-to-service calls?" "How does the event bus work?" "What are the migration steps for adding a new database table?" Instead of stuffing all of that into a single file that gets stale and bloated, the MCP server exposes it as searchable, structured, up-to-date context.
The practical version: This could be as simple as an MCP server that wraps your internal docs site, your architecture decision records, and your API specs. It doesn't have to be fancy. It just has to be more useful than the alternative, which is your AI assistant guessing or your engineer spending 20 minutes finding the right Notion page.
The auth story: same as your internal code repos. If someone has access to the codebase, they have access to this. You're not exposing anything new, just making existing knowledge accessible to the tools your team is already using.
AI Coding Agent Dev Knowledge MCP Server
(Cursor, Claude Code) │
│ ┌────────┼────────┐
│ "What's the pattern ▼ ▼ ▼
│ for adding a new ADRs Internal API
│ service endpoint?" Docs Contracts
├──────────────────────► │ │ │
│ └────────┼────────┘
│ Relevant patterns, │
│ examples, conventions │
│◄────────────────────────────────┘
One thing worth noting: this server evolves differently than the others. It doesn't version with your API or your product releases. It versions with your engineering culture. When you adopt a new pattern, update the knowledge base. When you deprecate an approach, remove it. The AI agents downstream will immediately reflect the change. Compare that to the current state of affairs where tribal knowledge takes months to propagate through a team and years to fully displace the old way of doing things.
The Comparison
Here's how these six servers stack up against each other:
| Docs MCP | API MCP | Product Agent MCP | Internal Ops MCP | Browser MCP | Dev Knowledge MCP | |
|---|---|---|---|---|---|---|
| Audience | Developers using AI coding tools | AI agents acting for your users | Your own product's AI features | Your internal teams | End users in browser | Your engineering team's AI coding agents |
| Auth Model | Public / unauthenticated | OAuth 2.1 + PKCE | Service-to-service (JWT, internal) | SSO / internal credentials | Session-based (inherits browser) | Same as code repo access |
| MCP Clients | Cursor, Claude, Windsurf, ChatGPT | ChatGPT, Claude, custom agents | Your own agents, copilots | Claude Code, internal tools | Browser MCP, WebMCP | Cursor, Claude Code, Windsurf, Copilot |
| Read/Write | Read-only | Read + Write | Read + Write | Read + Write (scoped) | Read + Write (session-scoped) | Read-only |
| Scope | Docs, guides, API specs, examples | Your public API operations | Internal APIs + integrations + private tools | Internal tools, DBs, dashboards, tickets | Whatever the logged-in user can access | ADRs, internal docs, API contracts, conventions |
| Hosting | Edge / CDN-friendly | Your infrastructure or cloud | Your infrastructure | Internal network / VPN | Embedded in your web app | Internal / runs locally or on internal infra |
| Unique Consideration | Keep in sync with actual docs; stale = support tickets | Directory submission + review times (3-6 weeks) | Tool definitions evolve fast; version carefully | Highest ROI, lowest visibility; teams don't know they need it | Newest pattern; session-scoped = no background jobs | Versions with your eng culture, not your product |
| Lifecycle | Regenerates on docs build/deploy | Versioned with your API | Iterates with your product's AI features | Evolves with internal tooling | Evolves with your web app | Evolves with architecture + team conventions |
| Effort to Ship | Low (auto-generated options exist) | Medium-High (OAuth + directory listing) | Medium (if you already have internal APIs) | Medium (wrapping existing tools) | Low (embed code or WebMCP) | Low-Medium (wrapping existing internal docs) |
Bonus: The Optional 7th — Developer Portal MCP
If your product has a developer platform (APIs, SDKs, a CLI, a marketplace), there's an argument for a 7th server that's distinct from your docs MCP.
HubSpot did this. Their Developer MCP server doesn't just serve documentation. It lets developers interact with the HubSpot developer platform through their AI coding assistant. Create a new project. Add a feature to an existing app. Scaffold a webhook handler. Search the developer docs for answers. Walk through the CLI commands.
It's the difference between "here's the documentation" (server #1) and "let me help you actually build the thing" (server #7). One is a reference library. The other is a pair-programming partner that knows your platform.
Not every product company needs this. If you don't have a developer platform with a CLI and project scaffolding, it's probably overkill. But if you do, and developers are building apps or integrations on your platform, this is the kind of thing that dramatically reduces time-to-first-integration. The developer doesn't have to leave their IDE to figure out how your platform works. Their AI assistant already knows.
What This Means for Your Team
If you're a product leader or engineering lead looking at this and thinking "that's a lot of MCP servers," I hear you. But most of these aren't net-new infrastructure. They're structured interfaces to things you already have.
A few things to consider:
Start with the question, not the server. "How do AIs read and understand our stuff?" is a better starting question than "which MCP server should we build?" The answer might be: your docs are already good enough for AI training data, but your API has no MCP presence and you're invisible in Claude and ChatGPT. Or maybe your internal teams are drowning in manual lookups that an internal MCP server would trivialize. Or your engineering team is fighting their AI coding assistant because it doesn't understand your internal patterns.
Your docs MCP server is the lowest-hanging fruit. If you use a docs platform that auto-generates MCP endpoints (Fern, Mintlify, ReadMe, etc.), this might already be done for you. If not, it's still the simplest one to build because it's read-only and public.
Your API MCP server is the strategic one. This is where directory listings, discoverability, and distribution happen. If your product isn't listed in Claude's connectors or ChatGPT's app directory, users literally can't find you through the AI interface. The clock is ticking here. Anthropic's submission guide is worth reading now, even if you're not ready to submit.
Don't sleep on internal. I cannot stress this enough. The internal ops MCP server is the one with the highest ROI and the lowest priority on most roadmaps. Every time I talk to a team that's set one up, the reaction is the same: "We should have done this months ago." Your data team, your support team, your ops team: they all have tools that would be dramatically more useful with an AI interface. And unlike the public-facing servers, there's no directory review, no OAuth spec compliance, no submission process. Just build it and give your team access.
The dev knowledge server pays for itself immediately. If your engineering team uses AI coding assistants (they do), and your codebase has any meaningful internal conventions or architecture (it does), then the gap between "what the AI knows" and "what your team knows" is costing you right now. Every wrong suggestion the AI makes because it doesn't understand your patterns is time your engineers spend correcting it. An MCP server that wraps your internal docs isn't glamorous, but it might be the single most practical thing you ship this quarter.
Browser MCP is coming faster than you think. WebMCP becoming a W3C standard through Chrome means this isn't experimental anymore. If you have a web app, start thinking about this now. You don't have to ship it tomorrow. But the pattern of "user is logged in + AI assistant in browser = instant AI access to your product" is heading toward a standard expectation. It's the path of least resistance for end users, and it sidesteps the entire OAuth/API key setup that blocks most non-technical users from ever using your API MCP server.
Coordinate early. If different teams in your org are independently building MCP servers (and they might be), make sure the patterns are consistent. Same tool naming conventions, same error handling, same auth patterns where applicable. It's much easier to align now than to reconcile later.
The Bigger Picture
The way I think about this: MCP servers are to AI what web APIs were to mobile apps. Mobile apps needed structured ways to talk to your backend. AI agents need structured ways to talk to your product. The technology is different, but the architectural pattern is familiar.
And just like with APIs, the companies that treat this as a first-class concern (not an afterthought bolted on by one engineer in a sprint) will have better developer experience, better user experience, and better distribution.
The protocol itself matters less than the patterns. MCP might evolve, merge, or get competition. But the idea that "every product company needs multiple structured interfaces for AI to interact with their systems" isn't going away. Whether it's called MCP or something else in three years, the architecture is the architecture.
So. Six servers (maybe seven). Different audiences, different auth, different purposes. Not as scary as it sounds once you realize you're mostly just putting a machine-friendly interface on things you've already built.
And if you're sitting there thinking "we haven't even started on the first one," that's fine. That's most companies right now. But the ones that start thinking about this as an architecture (not a checkbox) are going to move a lot faster when it's time to ship.
(Happy to go deeper into any of these. Hit us up with questions.)
Further reading:
- MCP Servers for Documentation Sites (Fern)
- MCP, OAuth 2.1, PKCE, and the Future of AI Authorization (Aembit)
- Remote MCP Server Submission Guide (Anthropic)
- WebMCP Early Preview (Chrome for Developers)
- MCP-B: MCP for the Browser
- Google Developer Knowledge API and MCP Server
- Apidog MCP Server for API Specs (Apidog)
- HubSpot Developer MCP Server (HubSpot)