A no-click workflow​

I once needed to add labels to dozens of articles at a time in a Zendesk help site to optimize search results. I was looking at hours of tedious clicks and entering terms.

The Zendesk Help Center REST API gave me a better way. It offers these endpoints:

• /articles/{article_id}/labels: List, add, or remove the labels on one article
• /articles/labels: List all labels or delete a label from every article
• /articles: List all articles and see each article's labels

I wired up an MCP server (to call the API and authenticate) and a Claude skill (to trigger the calls). This let me prompt Claude to handle any tasks the API supports.

Building the MCP server​

To build the MCP server, I prompted Claude with something like this:

Build a Python MCP server for managing labels on Zendesk Help Center (Guide) articles. It should allow OAuth authentication (see https://developer.zendesk.com/documentation/authentication/api-tokens-to-oauth).

It should let me perform actions for:

Labels:
- List all labels in the Help Center
- See how often each label is used, including labels that no article uses
- See the labels on a specific article
- Find all articles that have a given label, with each article's title, URL, section and category
- Find articles that have no labels
- Add or remove labels by name, on one article or many at once
- Delete labels I no longer need, one at a time or in bulk

Articles:
- List all articles, or only the articles in one section
- Get a specific article, including its full HTML body
- Search articles by keyword, with optional filters for section, label and locale, and sorting
- Return search results with each article's title, URL, section and category

Creating and updating articles:
- Create an article in a section, with a title, HTML body, locale and draft status (draft by default)
- Update an article's body or title

Requirements:

- Handle pagination so results are always complete.
- Every tool that adds, removes or deletes an entity must require confirm=True before it runs.
- Bulk actions should keep going when one item fails and report what succeeded and what failed.
- Give each tool a clear description so Claude knows when to use it.

When you're done, help me get a Zendesk client ID and secret and store them securely.

Building the skill​

Then I built and iterated on a skill with Claude's help that included instructions like:

## Rate limits

Zendesk's general API rate limit is 700 requests per minute. Use a concurrency limit of 5 concurrent requests and exponential backoff on 429 responses (retry up to 3 times, starting at 1 second, doubling each attempt).

---

## Pagination

Most Help Center list endpoints (/help_center/...) use offset-based pagination with a next_page URL in the response. Fetch the next_page URL and combine results until next_page is null.

Guide endpoints (/guide/...), including redirect rules, use cursor-based pagination. Use page[size] and page[after] query parameters, and check meta.has_more and meta.after_cursor in the response. Do not use per_page or page on these endpoints. They silently return only the first page with no indication that more pages exist.

---

## Labels

Labels are additive. Posting a label that already exists on an article is a no-op (does not duplicate).

Invoking the skill to use the MCP server​

When I invoked the skill, I gave it prompts like these (which I've genericized):

• Apply an "export_data" label to every article in the "Export data" section of the Data User Guide.
• Remove callouts with "Coming soon" at the top of all articles with a "sprint_201_release" label.
• List all articles that have no label, including their title and direct URL, and suggest labels.
• List all unused labels and delete them with my approval.

Expanding the skill​

Later I expanded the MCP server and skill to include more API actions, like:

Content tags:
- List all content tags in the Help Center, optionally filtered by a name prefix
- See how often each content tag is used, including tags that no article uses
- See the content tags on a specific article, by name
- Find all articles that have a given content tag, with each article's title, URL, section and category
- Find articles that have no content tags, optionally excluding certain sections
- Add or remove content tags by name, on one article or many at once, and create any tag that doesn't exist yet
- Rename a content tag
- Delete content tags I no longer need

Categories and sections:
- List all categories
- Get details for a specific category
- List all sections, or only the sections in one category
- Get details for a specific section

Export:
- Export all articles from a section or category
- Fill in section names, category names, label names and content tag names instead of IDs
- Return both a full version with article bodies and a condensed version without them

Redirect rules:
- List all redirect rules
- Find the redirect rule for a specific source path
- List redirect rules with the article title and URL filled in for the "from" and "to" articles
- Create a redirect from one article to another, using article IDs instead of full URLs, with a choice of redirect status (such as 301 or 302)
- Delete a redirect rule

Themes:
- List all themes and show which one is live
- Get details for a specific theme
- Export a theme and extract its files into a local folder
- List a theme's local files, grouped into templates, assets, settings and other
- Read and edit individual theme files
- Package a local theme folder into a zip that's ready to upload, leaving out hidden files and old zips
- Import a theme zip as a new, unpublished theme
- Publish a theme so it becomes live
- Delete a theme that isn't live

Combining MCP server toolchains​

For ultimate time savings, I used the Zendesk Guide MCP in tandem with an MCP server I built for another enterprise tool (Paligo CCMS) to perform multi-system actions, like:

• Publish the updated "Data User Guide" in Paligo to Zendesk and apply the Zendesk label "extract_data" to all new articles created in that guide in Paligo last week.

If you've worked with that toolchain before, you know how much time and effort a prompt like that saves! Any CMS with a REST API can work this way.

Is there a smarter way I could have done this? I would be grateful to know.

gdrive_mcp.py

What it is​

This MCP server performs actions like reading Google Drive files, creating files, and publishing content to them from another source. In particular, this MCP server let me manage content as Markdown.

Why I built it​

Formatting a Google Doc with a Google Drive connection in AI tool is notoriously unpredictable. Applied styles can be offset by a character or two, bullets can be misaligned, and formatting can disappear. This custom MCP server allows the content to be extracted from the Google Doc as Markdown using the Google Docs API's text/markdown export MIME type, formats the content straightforwardly Markdown, and converts it into a native Google Doc format.

paligo_mcp.py

What it is​

This MCP server performs actions like creating, updating, and deleting articles; creating publications and productions; uploading and inserting images; and managing taxonomies and variables. It is a wrapper around the Paligo API.

Why I built it​

It's tedious and time consuming to work with Paligo content by clicking around the Paligo UI performing one action at a time. AI agent skills using this MCP server can perform multiple actions at a time - even a full publishing workflow - from transforming a Google doc into XML according to the Paligo XML spec, uploading it to a new document in Paligo, adding it to a guide's table of contents, and triggering the publishing pipeline.

See Paligo Pal for a sample of an AI agent skill that uses the Paligo MCP server.

zendesk_guide_mcp.py

What it is​

This MCP server performs actions around Zendesk categories, sections, articles, labels, content tags, redirects, and themes. It is a wrapper around the Zendesk Help Center API, including both content management and theming.

Why I built it​

It's tedious and time consuming to work with Zendesk content by clicking around the Zendesk UI, and some features (like redirects) aren't even available there. AI agent skills using this MCP server allow me to use natural language prompts for things like:

• Apply an export_data label to every article in the Export data section of the Data User Guide.
• Remove callouts with Coming soon at the top of all articles with a sprint_201_release label.
• List all articles that have no label, including their title and direct URL, and suggest labels.
• List all unused labels and delete them with my approval.

For ultimate time savings, this MCP server can also be used in tandem with MCP servers for other enterprise tools (like Paligo CCMS) to perform multi-system actions like:

• Publish the updated Data User Guide in Paligo to Zendesk and apply the Zendesk label extract_data to all new articles created in that guide in Paligo last week.

zendesk_tickets_mcp.py

What it is​

This MCP server reads Zendesk ticket contents, including the user's question and any conversation following. It also reads fields like a user's organization, ticket labels, ticket status, and custom fields like a user's product platform. It is a wrapper around the Zendesk Ticketing API.

Why I built it​

Support tickets from users have a wealth of information around issues users experience and agent resolutions, which can reveal opportunities to deflect future tickets with strategic content. But with thousands of tickets in play, it's time consuming and ineffective to manually read through even a subset. AI agent skills using this MCP server can slice tickets into segments, analyze them for common issues and resolutions, and draft troubleshooting articles, FAQs, cheat sheets, and reference material.

ai-optimizer

What it is​

/ai-optimizer checks a drafted Help Center article against 25 research-backed criteria for how well AI agents can use it and whether they retrieve it through RAG, web fetch, or MCP tool calling. It returns a report ranked by priority (critical, high, and medium), with a readiness rating for each access pattern.

How it works​

The skill flags things like sections that can't stand on their own, acronyms that aren't defined in each section, inconsistent terms for the same thing, unclear pronouns, reworded error messages, screenshots without text equivalents, content hidden in tabs or accordions, generic headings, missing checkpoints, and missing failure modes. Every recommendation names the exact section and includes replacement text I can use as is.

Why I built it​

I wanted generated content to be easily consumed by the company's internal Claude instance and be structured well for use in Zendesk, including optimized search results.

diataxis-drafter

What it is​

/diataxis-drafter generates customer-facing Help Center articles in any Diátaxis type (how-to guide, tutorial, concept, troubleshooting, or reference).

How it works​

I give the skill a topic and Diátaxis type. The skill reads files catalogued by /source-librarian three cost-saving tiers: index files first, then metadata headers only, and finally full reads of just the files I confirm are relevant. Rules prioritize content sources to read first and most carefully. Flags are thrown for unknowns and contradictions for human review.

The skill also includes Diátaxis templates in a reference file so every article type has a predictable structure.

Why I built it​

I wanted to cheaply generate first drafts of articles to speed up the authoring process, including manually reading through multiple sources of product knowledge myself. I also wanted a way to pull directly from product code things like error messages, UI labels, and user paths.

Example prompts​

• Draft a how-to guide and a troubleshooting article on Feature X.
• Write a concept article about Feature Y.
• Draft an FAQ about the top 10 most common issues in support tickets about Feature Z.

paligo-pal

What it is​

/paligo-pal performs actions in the Paligo XML CCMS around documents, folders, forks, images, productions, imports, translation exports and imports, taxonomies, variables, users, and assignments. It also includes a Google Doc to Paligo pipeline that converts a doc into valid DocBook 5.1 XML, uploads its images, and turns Help Center links into Paligo cross-references.

How it works​

A custom Python MCP server connects Claude to the Paligo REST API so the skill can perform actions with natural language prompts. When interacting with documents, the skill applies Paligo's structural rules automatically. It respects section limits (converting extra headings to styled paragraphs), tells procedures apart from ordinary lists, and handles admonitions, tables, and image placement. Safety rules make it fetch the latest XML just before every update, so it never overwrites edits made in the Paligo editor. It also never guesses a document title or folder location.

Why I built it​

Managing and updating content in the Paligo UI requires a lot of clicks, especially for things like changing content across multiple files or managing images. Also, I had a use case for copying drafts from Google Docs into Paligo, which is slow and error prone when done by hand.

Example prompts​

• Convert this Google Doc to Paligo XML and post to a new document in the Product A Guide.
• Remove the Overview article from the Product B Guide by deleting the document and removing it from the table of contents.
• Upload image.png to the media directory and add it at the top of the Prerequisites article in the Product C Guide.

release-notes-drafter

What it is​

/release-notes-drafter drafts customer-facing release notes for a specified audience by looking at Github Releases, commits, and Jira tickets. It frames each note in the context of value added to users.

How it works​

The skill creates one note per Jira ticket associated with a release after filtering out internal work such as CI/CD changes, refactors, monitoring, and dependency upgrades, grouping changes that apply only to certain audiences. The final output lists every dropped item with a reason, so reviewers can check the call.

Notes are written to highlight value to users.

It also adjusts tone and formatting for each audience and replaces internal jargon with customer-facing terms.

Why I built it​

I wanted to produce release notes that were more than just changelogs that describe what was built. I wanted to communicate clearly to customers the why behind and changes and how it improves their product experience. I also wanted practical help with grouping notes by product and audience.

source-librarian

What it is​

/source-librarian is a low-cost skill that takes in Zendesk tickets, Jira issues, GitHub code, Confluence pages, Notion pages, transcripts, Slack threads, Google Docs, Google Slides, PDFs, plain text, and other sources of product knowledge so drafting skills can find material relevant to the topic they've been given to write about.

How it works​

For each new file, it reads the full content, strips boilerplate, applies tags from a 16-dimension product taxonomy, and writes a PII-free summary and drafting guidance into the file's YAML front matter. A compact master index and one index shard per workflow connects the dots between sources.

The classification process includes:

• A faceted taxonomy with 16 categories and about 400 terms, covering product areas, features, workflows, objects, user roles, lifecycle stages, compliance, issues, and technical components.
• Rules for required tags, so every source was findable by product area, workflow, and purpose, and troubleshooting and integration sources carried the detail they needed.

For support tickets specifically: instead of treating tickets as troubleshooting-only material, the skill surfaces how-to steps, warnings, best practices, and conceptual explanations that would otherwise stay buried in support conversations. Because tickets are high volume, a Python script extracts the content so the company isn't paying for tokens to do it.

Why I built it​

It's expensive for a drafting skill to find and read up to hundreds of files on every run. I needed a way to ingest each piece of content one time only, classify it, and index it so drafting runs know exactly where to find the information they need and read only the information they need.

style-pal

What it is​

/style-pal is an audit skill that checks a document against my company Technical Style Guide, with the Microsoft Style Guide as a fallback. It returns a numbered list of violations with a suggested fix for each.

How it works​

The skill checks for ampersands, title case and gerunds in headings, missing serial commas, click on instead of click, quotation marks used for emphasis, split infinitives, third-person instructions, unbolded UI elements and file names, passive voice, and more. Because the report is numbered, I can reply fix 1, 3, 5 or fix all but 2 and 4 so I stay in control of every change.

Why I built it​

I wanted to easily catch and fix inconsistencies without manually reading through the text from start to finish or running inadequate manual searches and replaces. I created it as a separate skill so I can run it on any piece of content I write, not just content generated by an AI agent skill in my plugin.

vocabulary-pal

What it is​

/vocabulary-pal audits a Google Doc, Markdown file, text file, or Word document against an organization's custom controlled vocabulary. It flags every non-preferred term and gives the preferred term, the style guide's reasoning, and a suggested rewrite.

How it works​

The skill handles details a simple find-and-replace can't: case-sensitive terms, hyphenation, acronyms that must be spelled out on first use, plurals and possessives, exceptions for terms shown literally in the product UI, and look-alike terms that mean different things. When the context is ambiguous, it flags both readings instead of picking one silently.

Why I built it​

Source materials I generated content from used all kinds of variations of terms, including their spelling and capitalization (for example, common internal use for web app was WebApp, which was not a product name). I wanted to easily catch and fix inconsistencies without manually reading through the text from start to finish or running inadequate manual searches and replaces. I created it as a separate skill so I can run it on any piece of content I write, not just content generated by an AI agent skill in my plugin.

zendesk-guide-pal

What it is​

/zendesk-guide-pal performs Zendesk Help Center operations, like managing article metadata, content tags, labels, redirect rules, and themes.

How it works​

A custom Python MCP server is a wrapper around the Zendesk Help Center API, including both content management and theming. The skill then accepts natural language prompts for actions like (among many others):

• Add or remove labels by name, on one article or many at once
• See how often each label is used, including labels that no article uses
• Create, update, or delete an article
• List all articles, or only the articles in one category or section
• Find all articles that have a given content tag, with each article's title, URL, section and category
• List all sections, or only the sections in one category
• Create a redirect from one article to another, using article IDs instead of full URLs, with a choice of redirect status (such as 301 or 302)
• Package a local theme folder into a zip that's ready to upload, leaving out hidden files and old zips
• Perform actions in dev or prod

Why I built it​

Performing actions through the Zendesk UI requires lots of repetitive clicking to get things done. This is especially true for custom themes managed locally. I wanted to save time and clicks so I could work faster, more efficiently, and without mistakes.

Example prompts​

• Apply an "export_data" label to every article in the "Export data" section of the Data User Guide.
• Remove callouts with "Coming soon" at the top of all articles with a "sprint_201_release" label.
• List all articles that have no label, including their title and direct URL, and suggest labels.
• List all unused labels and delete them with my approval.

For ultimate time savings, I used my Zendesk Guide MCP server in tandem with my Paligo MCP server to perform multi-system actions, like:

• Publish the updated "Data User Guide" in Paligo to Zendesk and apply the Zendesk label "extract_data" to all new articles created in that guide in Paligo last week.

Applying the question in techcomm​

I love as a technical writer when someone on the team comes to me with a request for new content. It shows they see the value of content and trust me to help. But this magic question works just as well on the requests I receive as it does on product feature requests. For example:

Request: "Can we make an FAQ for new customers?"

Actual problem: New customers don't know our help site exists, so they never find the answers already there.

What might actually solve it: Introduce the help site during onboarding.

Putting the question into a process​

A company I worked for used Jira heavily across the org. I created a Jira form and asked team members to use it to pass on their requests. I knew the form needed to be as short and as painless to fill out as possible, so I narrowed it down to five questions, with the most important at the top:

• What problem are you trying to solve?
• Describe the new content you're requesting.
• Who is the audience for the content?
• How urgent is this request?
• What have people been doing until now to meet this need? (A second magic question!)

Urgent is the most overused word in any request queue. For that question, I set up four options to help understand the request:

• Mission critical: Blocking a launch, legal obligation, or customer impact. Must address immediately to prevent measurable harm.
• Time sensitive: Tied to a specific date or event with external visibility. Delay would reduce relevance or credibility.
• Nice to have by a certain date: Helps a project or team but is not time-bound. Not blocking or externally visible.
• Flexible: Schedule when capacity allows. No impact if delayed. Optimize timing for impact.

A submitted form immediately became a ticket on my technical writing Jira board. This was helpful for a couple reasons:

• The requester gets status updates. Because the requester is the ticket reporter, they get notifications of status changes and new comments.
• Communication around the request is visible. Questions, answers, and progress updates happen in the ticket comments instead of private Slack conversations.
• The requester can see the trajectory of their request. My project's Kanban board shows where the request sits in the queue and what's ahead of it.
• A Jira dashboard shows my capacity and progress. Tracking what's on the table helps me and my leadership scope and prioritize.

Answering the question​

Next, the requester and I worked together to scope and prioritize the request. A couple more magic questions helped frame the discussion:

• What percentage of this request comes from customers?
• How much time will implementing this request save?
• Is this more important than other things I'm working on delivering?

From there, we could finally get down to whether it made sense to do what was asked, try another approach, or deprioritize the need.

Measuring the answer​

Finally, possibly most important of all: measuring if the intervention made a difference. Going back to the example above, where I avoided creating a new FAQ in favor of improving awareness of a help site that already had the answers, I put in a request for a visualization that showed if customers from a given organization visit the help site.

View date and User creation date sliders gave extra insight into things like how long it takes for customers to visit the site after an organization finishes onboarding. That way, I'm one step closer to figuring out how the education failure occurred.

Softening the answer​

It's important to note that good interpersonal skills (especially empathy) are critical when asking this magic question so the requester doesn't feel shut down and stop sharing ideas. They feel the pain firsthand and know a lot of things I don't. But in my experience, most people I've worked with have been more interested in solving the pain point than insisting on their solution. Ultimately, they're happy to see the needle move toward a better experience for users.

1. Who owns the project, and how long has it been around?​

Static-site generators on the newer side can be promising and exciting, but it can be a risk to lock in too early. Over time, interest in maintaining the project may wane, so new features to keep the tool aligned with advancing technology may never be added and bugs may never be fixed (unless you fix them yourself).

Take a look at static-site generators used by larger companies. While there's no guarantee, it's easier to trust that these projects will be maintained and advanced. For example:

• Hugo: Kubernetes docs (see Docs are Migrating from Jekyll to Hugo), Docker docs, and GitLab docs (see The GitLab documentation site gets a major design overhaul and A Better Docs UX With Docsy)
• Docusaurus: Electron docs (see the Docusaurus showcase too)
• Astro/Starlight: Cloudflare docs (see Open source all the way down: Upgrading our developer documentation)

2. How broadly is the tool used?​

The more companies and people who use it, the more you're going to see templates, add-ons, extensions, and answers to questions shared in GitHub repo comments and Stack Overflow. The number of stars in a tool's GitHub repo can be one clue.

However, take into account that some tools may have passed the height of their popularity. Few companies seem to run their documentation sites on Jekyll, even though it was a popular choice a few years ago. It's still a good tool but may no longer have large, active communities developing enhancements for full-blown docs sites.

3. How often is the tool updated?​

A tool that's updated infrequently or only with minor changes is probably less likely to support new requirements that emerge over time. A GitHub repo's code frequency graph can show you if contributions are waning.

Examples are Gatsby (which was popular a few years ago but is now in low-activity maintenance), and MkDocs (which was popular for years but went into maintenance mode in 2025).

4. What are your requirements?​

Be intentional and objective when thinking through what you need the static-site generator to support. For example, you may want it to support:

• AI workflows: Can the tool output clean Markdown or structured data? These are critical for consumers like LLMs and AI chatbots.
• API docs: Is the audience of your site primarily developers? What kind of API documentation do you need to publish? For example DocFX supports .NET API documentation.
• Certain search requirements: Does the search run in the browser, or does it need an outside service like Algolia?
• Integration with an existing app: Will you need to integrate your documentation site with a software product? You may want a static-site generator built on the same framework.
• Contributions from end users: Will end users contribute to your docs-as-code workflow? Some tools ship with a Change this doc link (or something similar) at the bottom of articles that takes users directly to a public GitHub repo, where they can add or change articles and submit a pull request.
• Contributions from non-technical authors: Will authors not comfortable with Git and Markdown contribute to the documentation? You may want support for an open-source headless CMS like TinaCMS, which allows you to put a familiar visual editor on top while still storing the content as Markdown in Git.
• Content reuse: Will you need to use some structured authoring in your body of content? While Markdown and docs-as-code tooling is probably not the best approach for that (look into XML and CCMSes), some tools support it to a degree.
• Customizations: How painless is it to add custom features that may not be offered by the tool, like paragraph anchors or feedback forms at the bottom of articles? Are themes available that allow you to add things like sidebars, version switches, and search? Are plugins or extensions offered (like in the Docusaurus plugin directory)?
• Translation: If not now, will you need to ship the documentation website in two or more languages?
• Product versioning: Will users need to navigate between docs for different product versions?
• Moving content later: How tied into a tool are you willing to be? For example, Markdown moves easily between tools, but MDX or RST may not. Tool-specific shortcodes or components can also make a future shift complex.
• Certain hosting options: Does it work with GitHub, Netlify, Vercel, or another service your company prefers?
• Accessibility: What are your requirements for accessibility?
• Automated deployment pipelines: How hard will it be to wire it up with linting tools like Vale or link checkers, or automated testing of code samples in CI?

5. Who can help you when things break?​

Will you be the primary owner of the docs-as-code workflow? If you're not an engineer or highly technical, this is huge. At least in fast-moving startups, time with engineers is precious - you likely want to use whatever time you can get with one to learn more about how the products work, not asking for help to customize the site, update dependencies, or upgrade a framework.

But once in a blue moon, you may run into an issue so far above your head that you will need to beg for engineering help. To prepare for times like that, you may not want to choose a Python-based tool if the engineering department spends most of their days programming in another language.

In summary​

When you narrow down on two or three options, run mini POCs with real content. This will give you a great feel for the tool and what it would be like working with it.

This post is based on a requirement for open-source tooling, but consider hosted platforms if it's right. Tools like Mintlify, GitBook or Fern have a lot to offer if the custom configuration and maintenance of an open-source approach doesn't fit your needs.