> ## Content Index > Fetch the complete content index at: https://blog.helpdocs.io/llms.txt > Use this file to discover other available public pages before exploring further. # When to use MCP to write your help articles - URL: https://blog.helpdocs.io/when-to-use-mcp-knowledge-base/ - Published: 2026-09-17T13:00:59.000Z - Updated: 2026-09-17T13:00:59.000Z - Description: MCP is a powerful tool to speed up your documentation workflow, but be wary and understand it's not perfect. Here's why. - Author: River Sloane - Tags: Knowledge Bases There's a specific kind of Monday where you open a ticket, realize the answer isn't documented anywhere, and then think about the fact you've had this exact thought about this exact feature before. Possibly twice 😅 The article never gets written. Not because writing is hard. Writing takes twenty minutes. The problem is that the answer is currently spread across a support thread, a Slack message from March, a changelog entry, and one engineer's head, and assembling it takes the whole afternoon. MCP fixes the afternoon. It does *not* fix the twenty minutes, and anyone telling you otherwise is selling something. Knowing exactly where that line sits is the difference between a knowledge base that gets better with AI and one that quietly fills up with confident nonsense. ## MCP, without the acronym soup MCP stands for Model Context Protocol. Anthropic released it as an open standard on 25 November 2024, and the honest one-sentence version is that it's a standard plug shape for connecting AI assistants to the systems where your work already lives. Before it existed, every assistant needed a custom integration with every tool. [What is the Model Context Protocol (MCP)? - Model Context Protocol![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/icon/android-chrome-192x192-a4731e71-c8a4-43ba-9ef3-f4f541ea5911.png)Model Context Protocol![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/thumbnail/og-image-8ef3a56e-a08c-49d9-ae95-296ab119633f.png)](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro?ref=blog.helpdocs.io) That's a lot of one-off connectors, all of which someone has to maintain forever, and nobody wanted that job. MCP replaced it with one specification both sides implement. A server (your knowledge base, your CRM, your issue tracker) publishes what it can do. A client (Claude, ChatGPT, an agent you've wired up yourself) connects and uses it. The spec covers three things a server can offer: 1. **Resources** are data the assistant can read, like the contents of an article. 2. **Tools** are functions it can call, like creating a draft. 3. **Prompts** are templates for common jobs. For documentation work, tools are where the interesting stuff happens. It spread fast. OpenAI adopted it in March 2025 and Google DeepMind followed in April. In December 2025 Anthropic [handed the protocol over](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation?ref=blog.helpdocs.io) to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI. By that point there were more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript. So it's not one vendor's format that gets deprecated in eighteen months. That was the main reason to wait, and it's gone. ## Pasting is not connecting Here's the part that matters, and it rarely comes up if your entire AI experience so far has been pasting things into a chat box. When you paste an article into a chat window and ask for a rewrite, the assistant sees exactly what you handed it and nothing else. It doesn't know what's in the rest of your knowledge base. It doesn't know you already have three articles circling this topic like planes over an airport. It doesn't know you renamed that setting last quarter. So it fills the gaps with plausible-sounding guesses. Plausible-sounding guesses are the single worst thing you can put in a help center, because they read like they were written by someone who knew. Connect through MCP and the order of operations flips. [Awesome MCP ServersExplore 9,800+ official and community MCP servers for Claude, Codex, Cursor, and other AI agents. Find the right tools and setup guides for your workflow.![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/icon/icon-9fb00448-d47b-4a81-83cd-43651471e492.png)MCP Servers![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/thumbnail/og-c5cd376b-0cfe-48db-940c-e66a84ec95b9)](https://mcpservers.org/?ref=blog.helpdocs.io) The assistant searches your live knowledge base before it writes a word. It reads the current text of the article, not the version you remembered to paste. It checks whether something adjacent already exists. It pulls your search analytics and sees what people are failing to find. That's the whole shift. You go from a writing tool that guesses → a research assistant with hands. The [HelpDocs MCP server](https://www.helpdocs.io/mcp/?ref=blog.helpdocs.io) does four things. It searches your articles and categories. It reads the full content of any article. It creates, updates, and deletes articles and categories, including drafts. And it pulls analytics and account details. Four capabilities. They cover far more ground than the list suggests, which is most of what's left of this post. ## Where it actually earns its place ### Filling gaps you can already see Your search analytics contain a list of things people wanted and didn't get. No-result searches are the least glamorous report in your dashboard and comfortably the most useful, and almost nobody works through them, because doing it by hand is dreary. A good first prompt looks like this: > Pull our search analytics for the last 30 days. Group the no-result queries by theme. For each theme, search our existing articles and tell me whether we have partial coverage or nothing at all. Don't write anything yet. That last sentence is doing more work than the other four combined. We'll come back to it. ### Turning a support conversation into a draft Your inbox is where documentation gaps announce themselves, one customer at a time. The usual ending is that someone writes a genuinely excellent answer, once, to one person, and it vanishes into a closed ticket forever. With MCP connected you can hand over the thread and make the assistant check it against what's already published: > Here's a support thread we closed this morning. Search our knowledge base for anything covering this. If an existing article should have answered it, tell me exactly what's missing. If nothing covers it, create a draft in the Getting Started category, matching the structure and voice of our article on \[x\]. The "should have answered it" framing is the important bit. Roughly half the time the article exists and is incomplete, and bolting a fifth article onto the same subject makes your search results worse, not better. You've solved the ticket and damaged the help center. ### Bulk maintenance nobody has time for You renamed a feature. Forty articles mention the old name 😵 Some mention it in passing, some in screenshots you can't edit programmatically, and two of them are about something else entirely and use the word by coincidence. Good fit, with one condition. Read first, change second. > We renamed Collections to Categories. Search every published article mentioning "Collections" and list each one with the exact sentence containing the word. Don't edit anything. Then you scan the list, spot the two coincidences, and approve the rest one at a time. Fifteen minutes instead of two hours, and you were present for every change. The model will not spot those two coincidences. You will. That's the arrangement. ### Consistency passes Meta descriptions, alt text, missing internal links, articles with no category, articles last touched in 2022\. Each one is a tedious sweep across the whole knowledge base, and each one quietly degrades your search performance for years while you don't do it. Ask for the list first, always. "Find every published article with no meta description and show me the title plus first paragraph" gives you something to work through. "Write meta descriptions for everything" gives you a hundred edits you didn't read. ### Finding where you contradict yourself This one surprised us. Point an assistant with read access at your help center and ask it to find places where two articles say different things about the same setting. It's good at it, because the job requires holding your entire knowledge base in your head at once, and humans are famously bad at that. Fair warning: it's an uncomfortable report to read. ## MCP parts that don't work so well ### Anything that varies by customer If your product lets customers override settings on custom plans, an assistant writing a general article will describe the default as though it were universal. It isn't lying. It's generalizing from what it can see, and what it can see doesn't include the three big accounts where someone flipped that setting in 2023 as a favor. No model reasons its way to "except for Acme, Globex, and the one with the unusual contract." The information genuinely isn't in the knowledge base. This is the hardest limit on AI-assisted documentation and it does not get better with a smarter model, because the problem isn't intelligence. It's access. Any article where the honest answer is "it depends on your plan" needs a human who knows the plans. ### Anything expensive to get wrong Billing. Data deletion. Security settings. Permissions. Compliance and legal statements. Anything where a customer follows your article exactly, gets the wrong result, and it costs them money or data. Write those yourself. Run them past the assistant afterward if you like, but the first draft should come from a person who will feel bad if it's wrong. ### Anything genuinely new An assistant works from what it can read. That feature you shipped last Tuesday exists in your head, your commit history, and maybe a Linear ticket. It does not exist in your knowledge base. Ask for an article about it and you'll get fiction with excellent formatting and correct heading levels. The fix is unremarkable. Write version one yourself, then use MCP for everything downstream: related links, meta descriptions, consistency with what's already published, and the seven other articles that now need a sentence changed. ### When you'd be making volume instead of answering questions A write-capable connection is a genuine temptation to produce forty articles in an afternoon. Don't. Every thin article you add is one more thing standing between a customer and their answer. You can *absolutely* make your help center worse by adding to it, and MCP makes that much faster than it used to be. ## What the research says about your review step There's real evidence now on what happens when people assume AI-assisted work needs less checking than it does. It's worth reading before you start clicking Automatic. METR ran a [randomized controlled trial in 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?ref=blog.helpdocs.io) with 16 experienced open-source developers working 246 real issues in repositories they already knew well. They predicted AI would make them 24% faster. They were 19% slower. Then, having actually done the work, they said afterward that it had made them 20% faster. [The self-healing knowledge base has a blind spotTalk to enough vendors this year and you’ll hear a version of the same pitch. Flip a switch, and your knowledge base updates itself. No more stale articles, no more scrambling after a product change. AI handles it. It’s a good pitch. It’s also not quite what’![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/icon/bookmarked-favicon--1--05bd82ab-8aa2-48a9-87c8-fe2801410a93.png)HelpDocs BookmarkedRiver Sloane![](https://storage.ghost.io/c/75/1b/751bf80c-380f-4ff2-9c2a-e7861122c025/content/images/thumbnail/Firefighting-proactive-support--1--da5070fc-b382-4c9d-a831-caac1fea55b6.png)](https://blog.helpdocs.io/self-healing-knowledge-base-blind-spot/) Read that sequence twice. The belief survived direct contact with the evidence. METR are careful about how far this generalizes and so are we. These were experts working in code they knew deeply, which is much closer to an experienced writer editing their own help center than to a new hire. That's the comparison that should make you uneasy, not comfortable. The [2025 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2025/ai?ref=blog.helpdocs.io) names the mechanism. Asked for their biggest frustration with AI tools, 66% chose "AI solutions that are almost right, but not quite." Only 3.1% said they highly trust the accuracy of AI output. Almost-right is the expensive failure. Wrong gets caught. Almost-right ships 😆 Help articles are made of almost-right hazards. A menu path with two steps swapped. A setting name that was accurate one release ago. A caveat dropped because it wasn't in the source material. None of those look wrong at a glance, and all of them generate tickets. So: drafts, **not publishes**. Read the whole thing, not the first paragraph. If the article covers something you don't personally know, get it checked by someone who does, exactly as you would with a new hire's first attempt. ## A workflow that survives contact with reality Start read-only. Spend the first week with write permissions off completely, using the connection to search, read, and hunt for gaps. You will learn more about your own knowledge base in that week than in the previous year, and some of it will sting. Ask for lists before edits. "Show me everything matching this" beats "fix everything matching this," every single time. Again for those at the back—draft, never publish. Use the create-as-draft capability so nothing reaches a customer without a human opening it first. Edit like an editor, not a skimmer. The almost-right problem is precisely the one that skimming misses, which is why skimming feels so efficient. Check the things only you can check. Customer-specific behavior, plan differences, anything shipped in the last month. ## Where we've landed We're not going to tell you AI writes your knowledge base for you. It doesn't, and the products promising it are quietly relying on you to clean up afterward while they take credit for the speed. What MCP genuinely changes is the research half of the job. 💡 Get a more in-depth look at [how to prep MCP for your team over on our guide](https://www.helpdocs.io/learn/mcp-for-documentation/?ref=blog.helpdocs.io). Finding the gap. Reading what's already there. Noticing the four other articles that need updating when this one does. Spotting that you've contradicted yourself twice about the same toggle. That work is slow, unglamorous, and the actual reason good articles don't get written, and a connected assistant is legitimately excellent at it. The writing, the judgment, and the knowledge of which customer is on which plan stay with you. That's a reasonable division of labor. We'd rather be honest about where it sits than sell you the other version. If you want to try it in HelpDocs, the [setup guide](https://support.helpdocs.io/article/8wdmcyn6tg-connecting-to-helpdocs-mcp?ref=blog.helpdocs.io) takes about five minutes. Start read-only. Look at your no-result searches first, and brace yourself a little.