I have been thinking about a question inspired by a conversation with a customer:
Could we eventually use an MCP connection to identify content that should be rewritten—and could an agent help make the changes?
The more I think about it, the more I believe “what should be rewritten?” is only one part of the question.
Sometimes the right action is a rewrite. Other times, the content needs:
- A missing example or clarification
- An official answer
- A product status update
- Review by a subject matter expert
- Consolidation with another resource
- A redirect to canonical content
- Staff Verification
- Promotion or resurfacing
- Archiving or reduced discoverability
- No change at all
The more useful question may be:
Can an MCP-connected agent help us identify the most important content maintenance opportunities, determine the appropriate intervention, and route the work to the right team?
Testing the idea with the Success Community MCP
I used the Success Community MCP to explore what a real version of this workflow could look like across public content.
Some of the signals currently available include:
- High-traffic Knowledge Base articles that have not been updated recently
- Articles receiving unhelpful votes
- Popular Product Ideas whose statuses have not changed in a long time
- Questions that have not received a response
- Broader content-health and engagement signals
- Search terms and keyword patterns that may reveal content gaps
For example, an MCP call can identify a Knowledge Base article with strong traffic and an older update date. Another can surface articles receiving negative feedback. Another can find popular Ideas that have remained in the same status for years.
Each signal is useful, but none of them tells the whole story on its own.
An old article is not necessarily inaccurate. An unhelpful vote may reflect one missing scenario rather than a fundamentally bad article. A completed Idea may have an old status date but still accurately represent what happened.
That is where an agent could add value.
Instead of simply returning several disconnected reports, the agent could read the content, inspect the surrounding context, compare related resources, and recommend the most appropriate next step.
A possible “Top Ten Updates” workflow
A community manager could receive a prioritized list of the ten highest-impact content opportunities across the community.
The list would be based on priority and likely impact—not simply what changed during the last seven days.
Each item could include:
- Content title and link
- Content type
- Signals that caused it to surface
- The agent’s diagnosis
- Recommended intervention
- Suggested owner or team
- Confidence in the recommendation
- Whether human review is required
- A proposed next step
- An optional drafted response, revision, or update outline
The result would be a practical work queue rather than a generic content report.
What might cause content to surface?
Some initial candidate signals could include:
- High views combined with an old update date
- High views combined with unhelpful votes
- An old accepted answer that continues to receive traffic
- Frequently viewed content without an accepted or official response
- Unanswered questions
- Popular Ideas without a recent product status update
- Search demand without a strong matching resource
- Duplicate or overlapping content
- Broken links
- High-value content missing a trust or review signal
- Content receiving renewed activity after a long quiet period
- Popular internal or public content that has not been reviewed recently
- Content that appears inconsistent with current product terminology or behavior
These signals would produce candidates, not automatic conclusions.
The agent would still need to investigate whether the issue is real and determine the appropriate intervention.
Not every candidate should be rewritten
For each candidate, the agent might recommend one of several actions:
- Rewrite or materially refresh
- Add a missing section
- Add a concrete example
- Correct an obsolete statement
- Add an official response
- Accept or verify an answer
- Update a Product Idea status
- Consolidate duplicate resources
- Link to a canonical article
- Archive obsolete content
- Reduce discoverability
- Promote useful content
- Route the item to a specialist
- Leave the content unchanged
This distinction matters.
A system that assumes every detected issue should result in an AI-generated rewrite could quickly create more noise than value. The goal should be to recommend a defensible action based on observable signals and actual content context.
How should the Top Ten be prioritized?
A practical scoring model might combine:
- Audience reach or demand
- Risk of inaccurate or misleading information
- Evidence that users are not being helped
- Strategic relevance to the organization
- Confidence in the recommendation
- Estimated effort and ease of remediation
For example:
- Audience reach or demand: 25%
- Risk of incorrect information: 25%
- Evidence users are not being helped: 20%
- Strategic relevance: 15%
- Agent confidence: 10%
- Ease of remediation: 5%
Those weights should not be universal.
A support-focused community may place more weight on unanswered questions and incorrect guidance.
A developer community may prioritize outdated API and integration documentation.
An ideation community may care most about popular Ideas without a recent product response.
A customer education community may prioritize heavily viewed learning content with poor feedback.
Each organization should be able to align prioritization with its own community goals and company priorities.
Routing matters as much as ranking
The community manager may own the overall workflow, but should not necessarily own every update.
In the Success Community, a starting routing model might look like this:
- Questions and answers → Support
- Product Ideas → Product
- Knowledge Base articles → Documentation
- Technical API or integration content → Developer Relations or Engineering
- Broader member discussions → Community Manager or CSM
- Incorrect product claims → Product plus Documentation or Support
- Duplicate or obsolete community content → Community Manager
- Customer-specific issues → CSM or Support
- Content needing an official trust signal → Authorized staff reviewer
Routing should also consider the nature of the issue, not only the content type.
A discussion may reveal a documentation gap and need both Community and Documentation involvement.
A Product Idea marked Completed may need Product to confirm the outcome and Community to post an updated explanation.
A Knowledge Base article may need Documentation to revise it and Product or Engineering to validate the technical details.
The agent could recommend a primary owner, supporting teams, and the reason for the routing decision.
Where should the human stay in the loop?
This may be the most important design question.
An agent could probably handle much of the investigation and preparation work:
- Assemble candidate content
- Filter out clearly ineligible items
- Analyze supporting signals
- Read the full content
- Identify related or duplicate resources
- Recommend an intervention
- Suggest an owner
- Draft a reply or revision
- Explain its confidence and reasoning
Publishing or making substantive changes is more nuanced.
Human approval should likely be required for changes involving:
- Product roadmap or status commitments
- Official product behavior
- Technical guidance
- Security or compliance information
- Policies or legal language
- Official or accepted answers
- Staff Verification
- Archiving, merging, redirecting, or noindexing
- Substantive Knowledge Base rewrites
- Changes that affect another team’s owned content
There may eventually be low-risk actions that can happen automatically after the organization defines clear rules.
Possible examples include:
- Fixing formatting
- Updating a known broken internal link
- Replacing an approved obsolete term
- Routing a task to the correct queue
- Applying an already-approved template
- Flagging content for review after a defined threshold
Even then, changes should be traceable and reversible.
The goal should not be to release an autonomous rewriting machine across the community.
The goal should be to give community managers a prioritized, explainable work queue and help the right teams act on it faster.
A possible agent workflow
A real workflow could operate in several stages.
1. Retrieve candidate pools
The MCP gathers candidates from multiple signals:
- Stale high-traffic articles
- Unhelpful article votes
- Unanswered questions
- Popular Ideas with stale statuses
- Search and keyword gaps
- Duplicate or overlapping content
- Content-health anomalies
2. Apply eligibility rules
The workflow excludes content that should not be evaluated, such as:
- Private or permission-restricted content
- Staff-only and test categories
- Deleted or draft content
- Intentionally historical material
- Content already being actively updated
- Items whose age is expected and harmless
Public eligibility needs to be confirmed rather than assumed. A broad MCP query may still return test or staff content unless filtering is explicitly applied.
3. Investigate each candidate
The agent reads the content and considers:
- Content type and category
- Views, votes, reactions, and recent activity
- Creation and update dates
- Comments and answers
- Accepted-answer or Idea status
- Related Knowledge Base articles
- Duplicate discussions
- Product and release context
- Whether the content appears accurate, complete, and current
4. Recommend an intervention
The agent identifies what should happen, why, and who should own it.
5. Rank the candidates
Candidates receive a blended priority score based on the organization’s configured priorities.
6. Produce the weekly list
The community manager receives a clear Top Ten list with links, evidence, routing, and prepared next steps.
7. Track the outcome
Over time, the workflow could track:
- Accepted recommendations
- Dismissed recommendations
- Assigned owners
- Completed changes
- Time to completion
- Recurring content issues
- Directional changes after updates
That last stage would need careful framing. A traffic or engagement change after an update does not necessarily prove that one action caused the outcome.
Every community will need a different workflow
There probably is not one universal version of this.
Some communities are primarily support communities. Others focus on peer networking, product feedback, developer education, customer advocacy, or knowledge management.
Teams also divide ownership differently.
Documentation may own the Knowledge Base at one company, while Support or Community owns it somewhere else. Product may respond directly to Ideas in one organization, while another has a dedicated feedback or research team.
The right workflow should account for:
- The community’s purpose
- The content types it contains
- Which teams own each content type
- The organization’s business and member priorities
- The available data signals
- What makes content valuable, risky, stale, or unhelpful
- How candidates should be prioritized
- Which actions an agent may take
- Where human review is required
- How work should be routed and tracked
Rather than copying someone else’s rules, a community team could ask its AI assistant to interview them and design a workflow around their operating model.
Sample prompt: Design an agent-assisted community content workflow
Help me design an agent-assisted content maintenance workflow for my online community.
Do not assume that every piece of content needing attention should be rewritten. The appropriate action might be to update, expand, answer, verify, consolidate, redirect, archive, promote, route to another team, or leave unchanged.
Ask me focused questions, one at a time, about:
Our community’s purpose and primary audiences
The content types we manage
The teams that own each content type
Our most important business and member outcomes
The data and signals available to us
What makes content high-value, risky, stale, or unhelpful
How candidates should be prioritized
Which work should be routed to Support, Product, Documentation, Community, Customer Success, Engineering, or other teams
Which actions an agent may perform automatically
Which actions require human review or approval
How recommendations, assignments, decisions, and changes should be logged
How often the workflow should run
What the final output should look like
Challenge unclear assumptions and identify cases where age, low engagement, or negative feedback may not actually indicate a problem.
After asking the questions, create:
A list of candidate-detection rules
A configurable prioritization model
Content and issue routing logic
Human-in-the-loop approval levels
A recommended agent workflow
A proposed weekly “Top Updates” report
Example prompts or instructions for each agent involved
Audit, permission, and safety requirements
A small pilot plan using public content only
Open decisions the team still needs to make
Keep the workflow practical and explainable. Do not recommend autonomous publishing or substantive content changes unless the approval rules I provide explicitly allow them.
The output should not just be a generic AI content strategy.
It should be an operating workflow that reflects how that specific community and company actually work.
What would matter most in your community?
Which signals would be most useful for identifying content that needs attention?
Would you prioritize:
- Traffic
- Age
- Negative feedback
- Unanswered questions
- Stale Product Idea statuses
- Search demand
- Broken links
- Missing official responses
- Duplicate content
- Missing trust signals
- Something else entirely?
And where would you draw the line between:
- Agent-recommended
- Agent-drafted
- Human-approved
- Fully automated
I would love to hear how other community teams would design this workflow for their own communities.
