Help center MCP server: let AI assistants query docs

I am writing this as someone on the team that built and publishes a small MCP server, so I can tell you what one looks like from the inside and where its edges are. That matters because most advice on this topic describes what MCP could do. Here I describe what the communicate.so server actually does, based on its published code, and then use it as a worked example for exposing a help center.

The core idea is simple. More people now ask an AI assistant a question about your product before they ever open your site. If the assistant has a clean way to ask your documentation directly, its answer reflects your current guidance.

If it does not, it guesses from whatever it remembers or finds.

I keep three rules throughout. Every claim about a vendor links to that vendor's documentation, every statement about communicate.so comes from its code, and anything that is my design advice is labeled as advice.

Why customers' own AI assistants will query your docs

Assistants such as Claude and ChatGPT can connect to remote MCP servers. Anthropic's connector documentation says you can add any third-party connector as long as you have the URL of its remote MCP server, and OpenAI's developer mode documentation describes creating an app from a remote MCP server in ChatGPT. Both list streaming HTTP among the supported ways to connect.

That means a customer can, in principle, add your documentation server to their assistant and ask questions against it. The assistant then calls your search tool and reads your pages, and the answer it gives is grounded in your text. Without that, it relies on training data and web search results that may be months out of date.

Your customers already do the second thing. They paste an error into an assistant and ask what it means, and the assistant answers from a mix of your docs, forum threads, and old blog posts. A server does not stop this, but it gives well-informed users and their tools a better source.

There is a second audience, which is agents acting for people. When a shopper's assistant or a procurement bot evaluates your product, it reads what you publish. The guide to agent-readable products and the support for AI shoppers guide cover that wider picture, and a documentation server is one piece of it.

None of this replaces your on-site help. A visitor who is already on your pricing page still needs an answer in place. The server is an additional door into the same content.

What communicate.so's MCP server does today

The server is intentionally narrow. Its published instructions describe it as a "public, read-only server for Communicate developer documentation and API discovery" that "does not access workspaces, customer data, or product actions." That sentence is the contract, and the code enforces it.

It is registered as so.communicate/communicate-docs, version 1.0.0, and it is served over streamable HTTP at communicate.so/mcp. The server card lists supported protocol versions 2026-07-28, 2025-11-25, 2025-06-18, and 2025-03-26. A client that asks for a version the server does not list is answered with 2025-11-25.

It exposes three tools. One returns the developer guide with the API base URL, the OpenAPI location, and the authentication boundary. One returns a summary of the published REST operations, which are listing agents and sending a non-streaming chat message.

One returns the official support contact and supported inquiry categories.

Every tool carries annotations that mark it as read-only, non-destructive, idempotent, and closed-world. The server also publishes four resources, which are the developer guide, a pointer to the OpenAPI schema, a small visual companion page for the guide tool, and the server card itself. The visual companion is served as an MCP app resource with a locked-down content security policy.

The table is the reason I am cautious here. A reader might assume that a support platform's MCP server lets an assistant read their inbox. This one does not, and I would rather say so than blur it.

Authenticated access to a workspace goes through a separate REST API. The documented path uses OAuth client credentials to request a one-hour bearer token with the scopes agents:read and chat:write. That is the route for building your own integration, and it sits behind real credentials.

The pattern to copy for your own help center

The communicate.so server is a documentation server for one product. The same shape works for any help center, and the useful thing to copy is the design, not the content. Treat what follows as design advice drawn from the communicate.so server and the MCP specification.

A help center server needs very little. Two tools cover most needs, and a few resources help clients that prefer to browse.

• A search tool takes a short query and returns a ranked list of article titles, summaries, and URLs.
• A fetch tool takes an article identifier and returns the full text, the last updated date, and the canonical URL.
• A resource for the table of contents lets a client see the structure without searching.
• A resource for the server card lets a client read what the server is and how to connect.

OpenAI's developer mode page notes that developer mode does not require search and fetch tools, so the names are conventions rather than requirements. I still recommend them, because other clients and deep research features look for that shape, and the OpenAI guide to building MCP servers frames its examples around them.

Return the canonical URL with every result. A client can then show the customer a link, and the link is how you earn the visit and the trust. A result with no URL is a quote with no source.

Include the last updated date as a field. Assistants can then tell a customer that an article was revised last month, and they can prefer fresher pages when two disagree. Freshness is the one advantage a live server has over a scrape.

If you already run a retrieval pipeline for an on-site agent, the server can reuse the same index. The guide to RAG for customer support explains the retrieval side, and the server becomes a thin front door onto it.

Structure the content before you expose it

A server makes your content easier to reach, and it also makes weak content easier to see. If articles are long, duplicated, or contradictory, the assistant will relay the confusion. The work that improves an on-site agent improves a documentation server in the same way.

The knowledge base structure guide covers the patterns that matter most. One question per article, a clear title that matches how customers ask, and a short answer first with detail below it.

• Give every article one job, so a search result maps to one answer.
• Put the direct answer in the first two sentences, then add steps and exceptions.
• Name products, plans, and versions in the text, since a client cannot see your navigation.
• Remove stale articles or mark them clearly, because an assistant cannot tell that a page is forgotten.
• Use plain headings that match the questions customers type.

If your content sits in several places, connect them before exposing anything. The guide to training AI on a help center walks through the sources most teams have, and the data sources page shows the connectors communicate.so supports for pulling them into one place.

Also decide what stays out. Internal runbooks, draft articles, and customer-specific notes should never share an index with public pages. The safest server exposes a separate public index that contains only content you would publish on the web.

Keep the server read-only and small

A documentation server has no reason to change anything. Mark every tool as read-only, say so in the server instructions, and do not add write tools later without a separate review. The communicate.so server does this in its annotations and in its instructions, so a client and a human reader see the same promise.

The MCP tools specification lists what servers must do. They "MUST" validate all tool inputs, implement proper access controls, rate limit tool invocations, and sanitize tool outputs. Even a public docs server should honor all four, and the MCP security guide for support agents explains each in a support context.

The communicate.so server shows what those look like at small scale. It checks the Origin header against an allow-list that permits the main site and the app domain, or a request with no Origin. It requires a JSON content type and rejects request bodies over 64 KB.

It validates tool arguments and accepts only an optional query string.

These checks cost little and remove whole classes of problems. A server that accepts any origin and any body size invites misuse, even if it only returns public pages. A docs server that is small and strict is easy to review.

Caching also helps. For clients on the newest protocol version, the server marks tool and resource listings as publicly cacheable for an hour, which cuts repeated calls. For a help center, cache search results briefly and invalidate on publish.

Keep the tool count low. The MCP tool curation guide explains why a handful of well-named tools beat a long list, both for accuracy and for safety.

Treat your own articles as untrusted input

It is tempting to assume your docs are safe because you wrote them. That assumption fails if any part of the help center accepts outside contributions, such as community answers, comments, or imported tickets. Text from those places enters the model's context as soon as a tool returns it.

OpenAI's MCP guidance is direct about this. In its risk table it advises "Do not use a MCP if it could contain malicious or untrusted user input, even if you trust the developer of the MCP." A docs server that returns community content falls under that warning, so the safest public index contains only reviewed pages.

Simon Willison explains why the risk exists. In his lethal trifecta post he writes that LLMs are "unable to reliably distinguish the importance of instructions based on where they came from." A hidden line in a community comment can look like an instruction to the assistant reading it.

Defend in layers. Index only reviewed pages, strip hidden text and unusual markup before indexing, and return plain text with clear boundaries between the article body and metadata. If a page is user-generated, leave it out of the server.

Make the server's own text boring. Tool descriptions should say what the tool does and nothing else. Descriptions are read by the model, so a creative description is an unnecessary risk.

Publish a server card and make the server discoverable

A server nobody can find helps nobody. MCP is moving toward standard discovery documents, and communicate.so publishes the current ones. They are cheap to produce and they let clients and scanners learn what the server is.

The server card lives at a well-known path and describes the server's name, title, version, description, endpoint, and supported protocol versions. A separate registry manifest follows the MCP registry schema and lists the remote endpoint. Every response from the server also includes a Link header that points to the card with the describedby relation.

In the code, the card's tool list is treated as compatibility metadata for public discovery scanners, and the live tools/list response is the runtime authority. I recommend the same split. Put the facts in the card for discovery, and make the protocol response the source of truth.

The agent-readable product guide covers the other discovery files, including llms.txt.

Discovery for AI search is a separate effort, because search assistants cite pages rather than call servers. The guide to GEO for help centers covers making the same articles easy for those systems to quote.

Do both. A server serves assistants that connect directly, and good page structure serves assistants that browse. They reinforce each other because the same clean articles feed both.

Build and test a minimal server

You do not need a large framework. A remote MCP server handles JSON-RPC messages over HTTP, and a minimal one answers four requests. These are initialize, tools/list, tools/call, and resources/list with resources/read.

• Answer the initialize request by returning a protocol version you support, your capabilities, and your server info.
• Answer tools/list with each tool's name, description, input schema, and annotations.
• Answer tools/call by validating the arguments and returning both text content and structured content.
• Answer resources/list and resources/read for the table of contents and the server card.
• Reject unknown methods and unknown tools with the standard JSON-RPC error codes.

The communicate.so server returns structured content next to a text copy, with an output schema that describes the shape. That lets modern clients use the data directly while older ones still read the text. It is worth copying.

Test with a real client early. The MCP project provides an inspector that you can run with npx @modelcontextprotocol/inspector, and the ReadMe in Intercom server repository suggests it for checking a connection. Point it at your endpoint, list the tools, call each one, and read the raw responses.

After the inspector passes, try an assistant. The follow-up article on connecting Claude and ChatGPT to a support inbox lists the current steps for adding a remote server to each. A public docs server without authentication is the simplest case, and ChatGPT's developer mode documentation lists no authentication among its supported modes.

Write a short set of questions your customers really ask, and check that each returns the right article as the first or second result. This is a plain relevance test, and it finds problems that a protocol test never will.

Measure what assistants ask

A server gives you a new source of insight. Every search is a question a customer or their assistant wanted answered. Log the queries, the results returned, and whether the fetch tool was called afterward.

Queries with no good result point to gaps in your docs. The knowledge gap analysis guide describes how to turn unanswered questions into new articles, and the same method works for server queries.

• Track the most common queries and check each returns a strong article.
• Track queries with no result or a weak result, and add them to the writing backlog.
• Track which articles are fetched most, since they are candidates for tighter editing.
• Track repeated identical queries from one client, which may signal a loop or a confusing result.
• Review the log for odd inputs, since a public server will receive some.

These signals sit alongside your on-site numbers. The analytics page shows how communicate.so reports on questions and answers, and the self-service rate guide explains how to read the results.

Keep privacy in view. Queries can contain personal details if a customer pastes an error with an email address. Retain logs only as long as you need, and apply your normal retention rules.

Where an on-site agent still matters

A documentation server answers a question with a source. An on-site agent answers a question with a source in the customer's context, and it can hand the conversation to a person when the question needs one. The two do different jobs.

The comparison of chatbots and AI agents explains what an agent adds beyond retrieval. A customer who is mid-checkout does not want to open a separate assistant, they want an answer in the window they are already using.

The server also cannot know who the customer is. It returns the same public answer to everyone. Questions about an account, an order, or a refund need identity and permission, which belong in an authenticated flow with the controls described in the security guide.

For the answers that must be right, accuracy work still applies on both sides. The guide to reducing AI hallucinations in support covers grounding techniques that apply whether the retrieval comes from a server or a widget.

A practical plan has two parts. Put a read-only docs server in front of public content so outside assistants get your words, and run an on-site AI agent for visitors and customers who need help in context.

From question to cited answer: the call flow

A concrete flow shows how little is moving. A person asks their assistant how to authenticate against the communicate.so API. The assistant, which has the server connected, decides that the developer guide tool is relevant and calls it.

The call is a JSON-RPC message with the method tools/call and the tool name communicate_get_developer_guide. The server validates the request, checks that the arguments contain at most an optional query string, and returns the guide as both text and structured content. The structured part includes the docs URL, a markdown URL, the OpenAPI location, the API base URL, the authentication description, and the support email.

The assistant then writes its answer from that result. The authentication line it reads says to use OAuth client credentials to request a one-hour bearer token with the agents:read and chat:write scopes, and that direct workspace keys remain supported. The customer gets an answer drawn from the server's text, with a link to the docs page.

Two details make this reliable. The result is the same for every caller, so there is nothing to personalize or leak. The tool also ignores the query and always returns the complete canonical summary, which is a deliberate choice for a small server where every answer fits in one response.

For a large help center the design changes. You cannot return everything, so the search tool ranks and the fetch tool returns one article at a time. The flow is the same, with one more hop.

• The assistant calls search with the customer's question in plain words.
• The server returns a short ranked list with titles, summaries, URLs, and dates.
• The assistant picks the best match and calls fetch with that article's identifier.
• The server returns the article text, and the assistant answers and cites the URL.

Seeing the flow clarifies why content quality matters more than protocol detail. The protocol part takes an afternoon, and the answer quality depends on how well your articles match real questions, a theme the guide to GEO for help centers develops further.

Freshness, versions, and removed pages

A live server is only better than a scrape if it stays current. That requires a decision about how content gets from your editor to the index. The decision is small but it determines whether the server helps or misleads.

The simplest approach rebuilds the public index whenever an article is published, edited, or unpublished. Many help center tools send a webhook on those events, and the webhook can trigger a re-index. If yours does not, run a scheduled rebuild at a frequency that matches how often you edit.

Handle removals deliberately. An article that disappears from the index should also disappear from search results the same day, or the assistant will keep citing a page that now returns an error. A removed page is a worse outcome than a missing one, because the customer follows a broken link.

Versioned products add another wrinkle. If your documentation differs by plan or release, put that in the article metadata and in the result summary. An assistant can then tell a customer that a feature exists on one plan and not another, instead of presenting the answer as universal.

• Re-index on publish, edit, and unpublish events, and run a nightly rebuild as a safety net.
• Return the last updated date and the product or plan an article applies to.
• Remove unpublished pages from search results at once.
• Return a clear not-found result for an unknown identifier instead of an empty success.
• Keep redirects for renamed articles so cited links keep working.

Retention applies here too. The data retention guide covers how long to keep copies of content and logs, and an index is another copy that needs an owner.

Server, widget, or API: choosing the right door

A help center server is one of several ways to put your answers in front of people and agents. Each serves a different reader and carries different risks. The table below compares the main options by the jobs teams ask them to do.

The table shows why these tools complement each other. A docs server covers the public question from outside, a widget covers the question inside your site, and an API covers integrations with real credentials. Most teams need the second first and add the first when customers begin to ask assistants about them.

The MCP versus API comparison goes deeper on when each protocol fits, and the in-app support widget guide covers the on-site option.

There is also a longer-term direction, in which customers' assistants talk to your support system on their behalf and not only read your docs. That raises authentication, consent, and disclosure questions that a read-only server avoids. The guides on personal agents and on agent-to-agent support discuss where that is heading.

Read the personal agent protocol overview and the agent-to-agent support guide when you are ready to look past documentation.

A four-step rollout

Teams that add a docs server tend to over-plan it. The safe path is short and reversible, and each step produces something you can check. I would take it in this order.

• Audit the content, remove duplicates and drafts, and mark the articles that are safe to publish publicly.
• Build a public index from those articles only, and expose a search tool and a fetch tool with read-only annotations.
• Test with the MCP inspector and with a real assistant, using twenty real customer questions as the check.
• Publish the server card and registry manifest, add the server to your documentation, and watch the logs.

Plan a review point after two weeks. Look at the questions that returned weak results and fix those articles first. Those fixes help your on-site agent too.

If you are also setting up an on-site agent, the onboarding checklist gives the order of work, and the comparison of help desk MCP servers shows how other vendors approach the same questions.

Make your server easy to trust

Customers who connect a server are told to be careful. Anthropic's custom connector page carries a security notice that custom connectors "allow connections to unverified services," and OpenAI's developer mode page describes its MCP support as "powerful but dangerous." Your server asks a stranger to extend trust, so help them do it.

Publish the endpoint on your own domain, under a path that is easy to recognize. A server hosted on a random subdomain looks like a phishing attempt, and a customer is right to hesitate. The communicate.so endpoint lives on the main site for that reason.

State plainly what the server can and cannot do, in the server instructions and on a documentation page. The communicate.so instructions say the server is read-only and does not access workspaces, customer data, or product actions. A reader who sees that promise in the protocol and on the page has two matching signals.

• Document the endpoint, the tool names, and the read-only guarantee on a public page.
• Link to the page from the server card so clients and scanners can find it.
• Name a security contact, and respond when someone reports a problem.
• Avoid asking for credentials on a public docs server, since there is nothing private to protect.
• Announce changes to the tool list, and keep tool descriptions plain.

This also protects your brand. A customer who connects an unofficial server that imitates yours could be misled by it. Publishing the official endpoint in one clear place gives people a way to check which one is real.

Frequently asked questions

What is a help center MCP server?

It is a remote server that speaks the Model Context Protocol and exposes your documentation to AI assistants through tools like search and fetch. An assistant calls the tools to retrieve your articles, then answers using their text. It gives the assistant a direct line to your content.

Does communicate.so offer a help center MCP server for my content?

As of October 2026, the published server covers communicate.so developer documentation and API discovery. It does not search a customer's own help center or access workspace data. Check the server card and product pages for current capabilities.

What tools does the communicate.so MCP server expose?

It exposes three read-only tools. They return the developer guide, a summary of the published REST API, and the official support contact. It also publishes resources for the guide, the OpenAPI pointer, a visual companion, and the server card.

Is the communicate.so MCP server authenticated?

No. It is a public, read-only server with no customer data behind it, and its instructions say so. Authenticated access to a workspace goes through the REST API with OAuth client credentials.

Can ChatGPT and Claude connect to a documentation server?

Both support remote MCP servers. Anthropic documents adding a custom connector by URL, and OpenAI documents creating an app from a remote MCP server in developer mode. Plan availability and settings vary, so check each vendor's current documentation.

Do I need search and fetch tools?

They are conventions, not requirements. OpenAI states that developer mode does not require them. They remain a good default because other features and clients look for that pair.

Should a help center server be read-only?

Yes. A docs server has no reason to change anything, and read-only annotations plus matching instructions make the promise explicit. Review any proposal to add a write tool separately.

What should each search result contain?

A title, a short summary, the canonical URL, and the last updated date. The URL lets the assistant cite you and send the customer to your page. The date helps it prefer fresher content.

How is this different from llms.txt?

An llms.txt file is a static file that points language models to useful pages. A server answers live queries and returns structured results. They complement each other, and communicate.so publishes an llms.txt file alongside its server.

How is this different from search engine optimization?

Search optimization helps people and crawlers find your pages through search results. A server lets an assistant that has connected to it query your content directly. The guide on GEO for help centers covers the search side.

What are the security risks of a public docs server?

The main ones are untrusted content in the index, abuse through oversized or malformed requests, and scope creep toward private data. Index only reviewed pages, validate inputs, rate limit, and keep customer data out. The security guide covers each.

Should community content be in the index?

Leave it out of a public server unless it is reviewed. OpenAI advises against using an MCP that could contain malicious or untrusted user input. Hidden instructions in a community post could steer an assistant.

How do I keep the index fresh?

Rebuild or update it whenever an article is published, changed, or removed, and expose the last updated date. Cache search results briefly. Stale answers are the main reason to have a live server.

What does a server card contain?

The communicate.so card lists the server name, title, version, description, endpoint, and supported protocol versions. A separate registry manifest lists the remote endpoint under the MCP registry schema. Responses also include a Link header that points to the card.

How do I test my server?

Run the MCP inspector against your endpoint, list the tools, and call each one. Then connect a real assistant and ask the questions customers actually ask. Check that the right article appears near the top.

Will an assistant always use my server?

No. The assistant decides when to call tools, and users decide which servers to connect. Treat the server as an additional route to your content and keep your pages easy to read as well.

What should I log?

Log queries, returned article IDs, fetch calls, and errors, with a retention period you can defend. Review no-result queries for content gaps. Avoid storing more personal data than needed.

Can the server answer account-specific questions?

A public docs server cannot, because it has no identity and no private data. Account questions need an authenticated flow with scoped access. Use an on-site agent or a protected API for those.

How much does it cost to run?

The cost depends on your hosting and traffic, and I do not have a verified figure to give you. A read-only server with cached results is light compared with a full application. Measure your own traffic before you plan capacity.

Where should I start?

Start with content structure, then publish a small public index with a search and a fetch tool. Test it with the inspector and a real assistant, and then publish a server card. Add measurement before you expand.

Give assistants your answer

Customers are already asking assistants about your product, and a read-only help center server lets those assistants quote you. Start with clean articles, expose a small public index, and keep the server narrow, as communicate.so does with its own. When you are ready to put grounded answers on your site as well, see how to embed widgets on communicate.so.