How to use MCP to write and maintain documentation
Connect your docs to an AI assistant, keep a person in charge of publishing, and copy 50 ready-made prompts.
AI and knowledge bases10 min read
Using MCP for documentation means connecting an assistant like We integrate with ClaudeClaude or We integrate with ChatGPTChatGPT to your docs tool, so it can search, read, and draft against your real articles instead of whatever you paste in. If you’re still deciding whether it’s worth it, start with using MCP with your knowledge base or our blog post on when to use MCP for help articles.
This guide is the practical part: how to connect it, a workflow that keeps mistakes off your help center, and 50 prompts to copy.
MCP vs RAG for documentation
RAG (retrieval augmented generation) feeds passages from your docs to a model so it can answer questions, which is how most AI support bots work. MCP lets an assistant take actions in your docs tool, including writing. Many teams use both.
| RAG | MCP | |
|---|---|---|
| Who it’s for | Your customers, through a bot or AI search | Your team, through their own assistant |
| Can it write? | No | Yes, if the server allows it |
| Use it to | Answer “How do I reset my password?” | Fix every article that mentions an old setting |
How AI uses your knowledge base explains the RAG side in more detail.
Which documentation tools have an MCP server?
Most do, but not all of them can write, and you need write access to draft and edit.
| Tool | Can it write? | Notes |
|---|---|---|
| HelpDocs | Yes | Drafts, working copies, analytics, and stale marking. HelpDocs MCP |
| Notion | Yes | Pages, databases, and comments. Notion MCP |
| Confluence | Yes | Through the Atlassian Rovo MCP server |
| GitBook | No | Read-only, one per published site. GitBook MCP |
| Mintlify | Partly | A separate admin server edits through pull requests |
As of November 2026. The question that matters most: do edits land as drafts, or go live straight away?
How to connect your docs to an AI assistant
Switch on MCP in your docs tool and copy its server URL. In HelpDocs that’s Settings > AI > MCP access, and the steps for each assistant appear right below it. Then add the URL to your assistant and sign in when it asks.
| Assistant | Where to add it |
|---|---|
| Claude | Customize > Connectors > + Add > Add custom connector (guide) |
| ChatGPT | The HelpDocs plugin in ChatGPT’s plugin directory (guide) |
| Claude Code | Run claude mcp add --transport http helpdocs YOUR_MCP_URL, then /mcp |
| Cursor | ~/.cursor/mcp.json, under mcpServers |
| VS Code | Command Palette > MCP: Add Server > HTTP |
| Scripts and CI | An API key from Settings > API (guide) |
To check it worked, ask something only your docs can answer. Real article titles mean you’re connected.
Search my HelpDocs articles for "[a word from one of your articles]" and list the titles you find.Set up house rules first
Without guidance, an assistant writes in its own wordy voice. A one-page rules file, built from your documentation style guide, fixes most of that. Put it in a Claude or ChatGPT Project, or your CLAUDE.md, along with three of your best articles as examples.
Your house rules file
Important
In HelpDocs, an edit to a published article goes live unless it’s saved as a working copy. That’s why the editing prompts below all say “save as a working copy”.
A workflow that keeps you in control
- Read first. Ask it to search and list before it changes anything, like grouping your no-result searches by theme.
- Ask for a plan. Which articles, what change, and why.
- Write to drafts or working copies, five articles at a time.
- Review like an editor. Look for things that are confidently, slightly wrong, like a menu that moved last month.
- Publish from your docs tool, never from the chat.
Step 4 is most of the job now. In GitBook’s State of Docs 2026, 56% of docs practitioners who use AI regularly said they spend less time writing and more time reviewing.
Keep it safe
An assistant can be tricked by instructions hidden in what it reads, like a support ticket saying “ignore previous instructions”. This is prompt injection, and no model is immune. Simon Willison’s lethal trifecta explains when it gets dangerous.
- Use your docs tool’s official server.
- Keep write confirmations on.
- Send edits to drafts or working copies, so a person publishes.
- Use the least access you need, like a read-only key for research.
- Keep billing, security, and legal articles human-written. When not to use MCP covers the rest.
- Don’t expect it to fix your docs on its own. The self-healing knowledge base has a blind spot explains why.
Use the prompts your server provides
Some servers include ready-made prompts that show up as slash commands. HelpDocs MCP has six: draft_article, rewrite_article, expand_section, improve_formatting, optimize_for_search, and simplify_article.
50 prompts for writing and maintaining docs
Replace anything in [brackets], then copy the prompt or open it in Claude or ChatGPT. Most are read-only, and the ones that write save drafts or working copies. The maintenance prompts fit into a regular knowledge base maintenance routine.
Research and planPrompts 1 to 11
Using HelpDocs, list every category with its article count and a one-line summary of what it covers. Then list any articles that aren't in a category. Don't change anything.
Read these three articles in full: [article 1], [article 2], and [article 3]. Describe the writing style in 10 bullet points: voice, sentence length, how steps are formatted, how UI labels are written, and how articles open and close. I'll use this as the style reference for everything we write today.
Fetch the internal article called "[Style guide]" and follow it for the rest of this conversation. Summarize the five rules you think matter most so I can check you've understood.Before we write anything about [topic], search the knowledge base for every article that mentions it, including partial matches. For each, give the title, status (published, draft, or private), and the sentence that mentions [topic].
Search our articles for the terms [term A], [term B], and [term C]. Tell me which we use most, where we're inconsistent, and which articles use each one. Suggest one term to standardize on, but don't edit anything.
Pull the searches from the last 60 days that returned no results. Ignore typos and one-off queries. Group the rest into themes, and for each theme tell me whether an existing article should have matched (a findability problem) or nothing covers it (a content gap). Rank by search volume.
A new customer's first week looks like this: [sign up, invite team, connect domain, import content, publish first article]. For each step, find the article that covers it. Flag steps with no article, steps covered by more than one article, and articles that skip a step a beginner would need.Here are the subjects of our last 50 support conversations: [paste list]. Match each to the help article that answers it. List the questions with no matching article, grouped by theme, most frequent first.We're launching [feature]. Here's the spec: [paste or link]. Propose the articles we need: title, one-sentence purpose, which category, and whether it's a new article or an update to an existing one (name it). Order them by what a customer needs first.
Read every category name and article title. Propose a new category structure based on how customers describe their problems, not how our team organizes the product. Show the current structure and the proposed one side by side, with every article mapped to its new home. Don't move anything.
Classify each article in [category] as a tutorial (learning by doing), a how-to guide (completing a specific task), reference (facts to look up), or explanation (understanding why). Flag articles that mix two or more types and suggest how to split them.Draft new articlesPrompts 12 to 19
Here are the release notes for [feature]: [paste]. Check whether any existing article already covers this. If not, create a draft article in [category] that explains what the feature does, who it's for, and how to use it, step by step. Match the style of [reference article]. Leave it unpublished and send me the link.
Here's a support conversation where we solved [problem]: [paste]. Remove anything specific to this customer (names, account details, and custom settings). Then write a draft troubleshooting article in [category]: the symptom as the customer would describe it, the likely causes, and the fix for each. Save as a draft.
This is a transcript of a demo where [teammate] walks through [workflow]: [paste]. Turn it into a step-by-step draft article. Keep the steps in the order shown. Where the transcript is vague ("click there", "this one"), write [CHECK] instead of guessing.
Read the code in [folder or file] that handles [feature]. Write a draft help article for non-technical customers that explains what the feature does and every setting it exposes, with the default value of each. Don't mention internal function names. Save it as a draft in [category] and list anything in the code you weren't sure how to explain.
Using these customer questions about [topic]: [paste], write a draft FAQ article. Use the customer's wording for each question. Answer each in two to four sentences and link to the full article where one exists. Save as a draft.
Customers often ask whether to use [option A] or [option B]. Read our articles on both, then draft an article that explains the difference, when to choose each, and what you can't change later. Use a table for the comparison. Save as a draft.
Find every article a brand-new customer needs in their first hour. Draft a single "Getting started" article that walks through them in order, with one short paragraph per step and a link to the full article. Don't copy whole sections. Save as a draft.
Draft an internal article for our support team about [topic]. Include the known edge cases, the questions to ask the customer first, and when to escalate. Base it on these notes: [paste]. Put it in a category only our support team can access, and save it as a draft for me to review.
Edit and rewritePrompts 20 to 26
Read [article]. Rewrite it for someone who has never used [product] before. Define any term a beginner wouldn't know, add any missing steps, and keep it under [600] words. Save your version as a working copy and list what you changed.
Read [article]. Show me a version that's at least 30% shorter without losing any steps or facts. Highlight what you removed and why. Don't save it yet.Read [article]. Suggest a clearer structure: headings, the order of sections, and where numbered steps would work better than paragraphs. Show the outline only. I'll approve it before you rewrite.Check [article] against our style guide. List every place it breaks a rule, with the sentence and the rule. Then save a corrected working copy. Don't change anything that isn't a style issue.Read [article] and find sentences over 25 words, paragraphs over four sentences, and any passive voice. Rewrite only those parts, show me before and after for each change, then save as a working copy.The section "[section name]" in [article] describes a process in paragraphs. Convert it into numbered steps, one action per step, with the UI label in bold. Keep all the detail. Save as a working copy.
For each article in [category], show me the title and first paragraph. Flag any article where the first paragraph doesn't say what the reader will be able to do by the end. Suggest a replacement opening for each one you flag.Maintain and optimizePrompts 27 to 40
We changed [what changed, e.g. "Settings > Domains is now under Settings > Publishing"]. Find every article that mentions the old location or behavior. For each, quote the sentence and propose the corrected sentence. Don't edit yet.Apply the corrections you proposed to the first five articles only, as working copies. Then stop and send me the list so I can review before you do the next five.
List every published article that hasn't been updated in more than 12 months, sorted by views in the last 90 days. High-traffic old articles first. Don't change anything.
For each article on that list that mentions [feature that has changed], mark it as stale with the reason "[feature] changed in [month]: check steps and screenshots". Don't edit the content.
Read every article that mentions [topic, e.g. "refunds"]. List anything they disagree on: numbers, time limits, steps, and what's included on which plan. Quote both sides of each contradiction with the article titles.Go through the articles in [category] and list every link. Flag links to our own articles that no longer exist or are archived, and links that point to an old URL for something that has moved. Don't edit anything.List every article in [category] that contains images, with the number of images and the date the article was last updated. Flag articles that describe [redesigned area] and were last updated before [date], because their screenshots are probably out of date.
Run our weekly docs check: (1) list articles marked stale and who marked them, (2) list drafts older than 30 days, (3) list the top 10 searches with no results this week, and (4) list any article with high views and very short content. Summarize in a short report. Don't change anything.
List every article title in [category]. Flag titles that are vague, clever, or don't say what's inside ("Getting the most out of X"). For each, suggest a title that matches how a customer would phrase the question.Find the five most-viewed articles in [category] with no description. Write a description of under 155 characters for each that answers the main question the article covers. Show them all to me first. Once I approve, save them as working copies.Read [article]. Check that the first paragraph answers the main question directly, each section heading says what's in it, and any answer that depends on plan or settings says so explicitly. Suggest changes that would make it easier for an AI assistant to quote accurately.Find pairs of articles that answer the same question. For each pair, tell me which one gets more views, what's unique in the other, and whether to merge them or make them more distinct.
Read [article]. Search for other articles it should link to, and articles that should link to it. List each suggestion with the sentence where the link would go.For each article in [category], suggest three to five search keywords based on the words customers actually use. Compare them with the missed searches from the last 30 days and tell me which missed searches each article should have matched.Translate, test, and combine toolsPrompts 41 to 50
List every published article that doesn't have a [language] version yet, sorted by views. Then list articles where the [language] version is older than the English one.
Translate [article] into [language]. Keep product names, UI labels, and code exactly as they appear in our [language] interface: [paste glossary or say "leave them in English"]. Save it as a working copy for a native speaker to review.
Compare the English and [language] versions of [article]. List any steps, warnings, or facts that appear in one and not the other. Ignore wording differences that don't change the meaning.
A customer asked: "[question]". Answer using only our published articles. Cite the article for every claim. If the articles don't fully answer it, say exactly what's missing instead of filling the gap from general knowledge.Write 15 questions a new customer might ask about [topic], in their words, not ours. Try to answer each from our articles only. Report which questions you could answer fully, partly, or not at all, and which article you used.A new support teammate starts Monday. Using our internal and public articles, write a one-page summary of how [feature] works, the five questions customers ask most, and which article answers each. Don't save it. Show it to me here.List the tickets closed in the last two weeks with the label [customer-facing]. For each, check whether our docs mention it. For the ones that change what customers see, propose which article to update and what to change. Don't edit yet.Read the thread in [channel] about [topic]. Pull out any decision or answer that customers would need to know. Check whether it's already documented, and if not, draft an article or an update. Save a new article as a draft, and an update as a working copy.
Using the release notes for [feature], draft a short changelog entry and the change needed in the related help article. Show them side by side. Save the article change as a working copy only. Don't post the changelog.Read our articles about [area], then read the current code in [repo/folder]. List every place the article says something the code no longer does: changed defaults, renamed settings, and removed options. Don't edit anything.
Write your own
Say whether it may write, name articles exactly, ask it to quote its sources, and tell it to write [CHECK] instead of guessing. This template covers all four:
Task: [what you want, in one sentence] Scope: [which articles, category, or search] Read first: [style guide, reference articles] Output: [list / outline / draft / working copy] Don't: [publish, delete, or edit anything outside scope] If unsure: [mark it [CHECK] / ask me]
Try it with HelpDocs. HelpDocs MCP works with Claude, ChatGPT, and any MCP-compatible assistant, with drafts and working copies built in, so you can review edits before they reach your readers. Start a free 14-day trial.
