How To Let AI Agent Research On Published Articles

Learning how to let AI agent research on published articles is mostly an access problem, not a prompting problem. The agent can read and reason well enough. What it usually cannot do is see your blog at all, so it answers from its training data and guesses. Fix the access layer and the same model becomes useful. This post walks through the specific path we use: connect a WordPress site to Creator OS, give the agent a read-only MCP connection, and point it at the posts you have already published.

  your published articles
  (WordPress site: REST API, sitemap, RSS)
            |
            v
  read-only MCP connection  -->  MCP tools   -->  AI agent
  (chosen at sign-in)            blog_create_article
            |                    get_post_analytics
            |                    list_posts
            v                       |
  Creator OS workspace  <-----------+
            |
            v
  drafts, updates, internal links

What It Means To Let An AI Agent Research On Published Articles

Research in this context is not web search. It is the agent reading a defined set of your own published pages, holding them all in view at once, and producing something you could not produce by skimming one page at a time. Three outputs matter:

• A summary of what a group of articles actually says, as opposed to what you think they say.
• A comparison across posts, so you can see where two of them contradict each other or repeat the same point.
• A gap list: questions a reader would ask after your post that no post answers.

For that to work, the agent needs a list of your posts and the full text of each. Creator OS gives you both through one connection, and if you want performance data alongside the text, it can pull per-post analytics and daily account metrics for the social platforms you have connected.

Why Published Articles Are the Best Research Source You Already Own

You have already paid for this research. Every published post represents hours of your time, and it is the only content corpus that reflects your actual positions. A general web search returns other people’s framing. Your own archive returns yours.

There is a second reason. When text and numbers sit next to each other, the agent’s gap list becomes a priority list instead of a wish list. Cross-reference a post’s text against how it performs on the platforms you publish to and you get a different read than you would from either source alone. A piece that gets pushed out a lot but collects almost no engagement has a different problem from one that never gets seen. The first needs a different angle or a sharper opening. The second needs more distribution. An agent holding both the text and the metrics can sort your archive into those buckets in one pass.

How To Give Your AI Agent Read Access to Your Blog

In Creator OS, connect the site first. From the CLI:

creatoros blog:connect

That opens the WordPress connection flow for a WordPress.com or self-hosted site on your own domain. For a self-hosted install you can pass credentials directly:

creatoros blog:connect-selfhosted --site https://yoursite.com --username <login> --password <app password>

Check what is connected:

creatoros blog:sites

Then confirm the agent can see articles:

creatoros blog:list --limit 20

Now the agent side. Creator OS ships a hosted MCP server at https://mcp.creatoros.ca/mcp. Nothing to install. For Claude Code:

claude mcp add --transport http creatoros https://mcp.creatoros.ca/mcp --header "Authorization: Bearer cos_live_..."

For Claude, ChatGPT, Cursor, Windsurf, and VS Code, the same URL goes into the connector or mcpServers entry. The important step is the next one: when you sign in and pick the workspace, choose read only. A read-only connection only sees read tools, and the API refuses writes from it. More on why that matters further down. Full setup steps live at the MCP docs.

Choosing Between WordPress REST API, Sitemaps, and RSS Feeds

These are the three ways an agent can reach published articles, and they are not equivalent.

If your goal is summarization and gap analysis, you need bodies, so the REST API path or a Creator OS blog connection is the one that works. A sitemap alone tells you a URL exists. It cannot tell you whether the post answers a question.

A useful pattern is to combine them. Use the sitemap or blog:list to enumerate, then pull each article through blog:get. That keeps the agent from fetching pages it does not need.

Prompting the Agent To Summarize, Compare, and Find Content Gaps

Generic prompts return generic output. Name the corpus, name the output format, and name the constraint.

Here is a prompt that works because it is scoped:

Read the last 20 published articles on my connected site.
Group them into topic clusters and name each cluster.
For each cluster, list the questions a reader would still have
after reading every post in it.
Then flag any two posts that make overlapping or contradictory
claims, and quote the exact sentences.

Output a table with columns: cluster, existing posts, gaps.
Do not suggest new posts outside the clusters you found.

The last line matters. Without it, the agent drifts into unrelated keyword suggestions. With it, you get a scoped gap list tied to content you already own.

Run a second pass for comparison:

For the posts on my site tagged with the same category as
"your-post-slug", list every claim that appears in more than
one post. Then list every post whose title promises something
the body does not deliver.

That second request finds the most common quality problem on any blog: titles written for clicks and bodies written for something else. The agent can only find it if it has full text, which is why the REST API route beats a sitemap for this work.

Turning Research Into New Posts, Updates, and Internal Links

Research that stays in a chat window is wasted. Push it into drafts. Creator OS gives the agent a write path for exactly that. Through the CLI you pass the article body as inline HTML or a file, and the call is tied to the blog account you connected:

creatoros blog:create --title "How To Let AI Agent Research On Published Articles" --file post.html

Drafts are the default unless the publish flag is set. So the agent can generate a full article and leave it for you to review. The same applies through the MCP tools, where blog_create_article creates the article and destructive tools are marked so the AI app asks first.

For updates to existing posts, the agent can revise a body without touching the URL:

creatoros blog:update <articleId> --file revised.html --slug stable-url

Internal links are the cheapest win here. Ask the agent to match each new draft against your archive and insert links where a phrase in the draft matches a topic you already covered. Creator OS tracks short links at go.creatoros.ca when you need click data on outbound or social links, though for on-page internal links you want plain in-body links. If your pipeline crosses into social, the same research summary can be turned into a post with the AI social media agent and WordPress blog workflow.

If you write with Claude Code, the installed skills matter here. creatoros init installs 14 skills including blog, post-longform, and analytics. creatoros sync updates skills later without overwriting files you edited; updates land as .new files. The full list is at the CLI docs.

Guardrails: Keeping the Agent Read-Only and Avoiding Duplicate Content

Two rules cover most of the risk.

1. Separate the read connection from the write connection. A read-only MCP connection sees only read tools, and the API refuses writes from it. Use that connection for research sprints. Keep the write connection for when you are deliberately creating drafts.
2. Never publish on the first pass. Create as draft, read the draft yourself, then publish. The default in Creator OS is draft unless publish is set, which means the safe behavior is also the default behavior.

On duplicate content: the failure mode is not technical, it is editorial. An agent asked to find gaps will happily propose a post that restates one you already have. Add a dedup step to your prompt:

Before suggesting a new article, check whether any existing
post already answers the question. If one does, propose an
update to that post instead, with the specific section to
change.

That single instruction converts a generic content calendar into a maintenance plan. Related reading on keeping agent access narrow: read-only connections for AI agents.

Measuring Results: Which Article Insights Actually Drive Traffic

Research output is a hypothesis until you measure it. Pull performance next to the content:

creatoros analytics:posts --platform <p> --sortBy engagement --limit 25
creatoros analytics:daily --from 2025-01-01 --to 2025-03-31

For the blog side, read the numbers in your WordPress analytics and compare them with the Creator OS social metrics, since the two answer different questions. What the agent can do cheaply is cross-reference: take the posts your metrics say are winners, pull their full text, and ask what they have in common that the losers lack. Opening structure, word count, number of internal links, whether the first paragraph names the target phrase.

Judge each post on its own numbers rather than against a fixed benchmark. A page that ranks high but collects only a handful of impressions is usually matching a query nobody searches, which points at the topic scope or the title. A page sitting far down the results with steady impressions is a different fix: links and depth. Have the agent read both the text and the metrics and sort your archive into those two buckets, then work one bucket at a time instead of rewriting at random. The request shapes for pulling metrics are in the docs.

Get Started With Creator OS and Run Your First Research Agent

The Creator plan is $19.99/month or $59.99/year and covers up to 8 connected accounts, 7 socials plus Skool. API keys, the MCP server, the CLI, and the agent skills are included in every plan. The Agency plan is $49/month or $399/year for 5 sets of socials, up to 40 connected accounts, and $99/month or $599/year for 10 sets, up to 80 accounts. Start at creatoros.ca/sign-up.

A sensible first run: connect your blog, open a read-only MCP connection, ask for topic clusters and gaps across your last 20 posts, and create one draft from the best gap with blog:create. Then compare the draft to what you have and decide between a new post and an update. If you are running this across several client sites, each workspace holds one set of socials and each API key is pinned to one workspace, so an agent holding one key cannot post to another. Read more about that split in the post on running an AI agent for agencies.

If you would rather watch it happen than read about it, the walkthroughs are on the KevBuildsApps YouTube channel. For a look at how agent skills get built and wired into real editing and publishing pipelines, the launch video is at youtube.com/watch?v=-QBJH_PK3pY. The docs, including the exact base URL and full request shapes, are at creatoros.ca/docs.