Plan and publish a content cluster
“Plan a 12-post cluster on managed WordPress hosting, then queue the first three as drafts on my main site.”
list_sites → call_platform_tool (keyword planning) → queue_blog_post ×3 → blog_post_status
Model Context Protocol connector
Run your WordPress AI agents from the assistant you already use. One MCP connector exposes every entitled tool, skill, and content pipeline in your workspace — so planning, writing, publishing, monetizing, and indexing WordPress content happen inside Claude, Cursor, or any Model Context Protocol client. Meet your WordPress AI agents →
It is a Model Context Protocol server that puts your WordPress AI agent workspace inside your own AI client. Your assistant discovers the tools your plan entitles, then calls them under your identity — the same agents, quotas, and publishing rules as the hosted app.
Most “AI for WordPress” tools give you a chat box on someone else’s website. This inverts that. The brain is yours — Claude, Cursor, whatever you drive daily — and the connector supplies the part a general assistant cannot have: entitled tools, connected sites, brand voice, monetization campaigns, a RAG index of your own content, and a multi-stage publishing pipeline that runs long after the conversation ends.
The important consequence: your client never holds a WordPress credential and never sees another tenant’s data. It holds one identity, and the gateway decides what that identity may do — every single call.
| Tool | Group | What it does |
|---|---|---|
whoami | Identity | Resolve who you are, which plan you are on, and how many agents and tools it entitles. |
list_agents | Discovery | List the WordPress AI agents your subscription includes, with each agent’s modes and the tools those modes grant. |
list_platform_tools | Discovery | Full JSON schemas for every entitled platform tool, plus which agent and mode grants each one. |
call_platform_tool | Execution | Execute one entitled tool under your identity. Entitlement is re-checked server-side on every call. |
list_sites | Sites | Your connected WordPress and CMS sites as sanitized references — site id, name, URL, platform mode. Never credentials. |
queue_blog_post | Content pipeline | Queue a post to the multi-stage pipeline: plan → monetize ∥ assets → write → publish. Returns a job id. |
blog_post_status | Content pipeline | Per-stage progress of a queued post, plus the final post URL once it publishes. |
list_recent_posts | Content pipeline | Recent pipeline posts for your account with status and published URLs. |
queue_research | Research | Commission a deep-research report that runs offline on the skill-runner fleet and lands in your workspace. |
list_skills | Skills | The installable agent skills your subscription includes — one per entitled agent mode. |
get_skill | Skills | Fetch one skill as a ready-to-install package so your client can operate AS that agent. |
list_platform_tools is the one that matters most: the connector does not hard-code a
menu. It asks the gateway what your plan entitles and returns real JSON schemas, so a new agent
or tool on your subscription appears in your client without a reinstall.
“Plan a 12-post cluster on managed WordPress hosting, then queue the first three as drafts on my main site.”
list_sites → call_platform_tool (keyword planning) → queue_blog_post ×3 → blog_post_status
“Design a Recipe custom post type with ACF fields for prep time, yield and nutrition, and register it on my site.”
list_platform_tools → call_platform_tool (CPT & ACF routes)
“What did my RAG chatbot index this week, and which pages are missing from it?”
call_platform_tool (site content + link graph)
“Find posts with buying intent and no affiliate CTA, then propose campaigns for them.”
call_platform_tool (CTA & monetization) → queue_blog_post for rewrites
“Commission a deep report on AI search citation patterns in home services, then brief a post from it.”
queue_research → queue_blog_post
“Install the Quick Poster skill and work the way that agent works.”
list_skills → get_skill → your client follows the agent’s own workflow
A tool is a button. A skill is the operating manual. list_skills and get_skill serve each entitled agent mode as an installable package — its purpose,
its tools, and the workflow it follows — so your client stops guessing how to use a tool and
starts working the way that agent works.
This is the difference between “an API your assistant can call” and “your agent team, running on your brain.” The skills are served on demand and gated server-side, so you only ever receive the modes your plan includes.
Each mode also carries its own export setting, so serving a skill never forces you to publish the
prompt behind it: playbook hands over the workflow and tool doctrine without the
prompt (the default), full embeds the mode prompt, and none withholds
the skill entirely.
The rule the design turns on: a tool list is a courtesy, the check at call time is the law. A client can advertise any tool it likes; the gateway resolves your plan, your agents, and their modes again on every single call, and answers 402 for an inactive plan or 403 for a tool you are not entitled to. Nothing about what your client claims can widen that.
Roadmap, not shipped. The items below describe the intended architecture of the connector. They are published so you can judge the direction — not as a claim about today.
Today the connector advertises its own tools and you discover your entitled platform tools through one of them. The direction is a handshake that already reflects your plan — your client sees exactly your tools, and nobody else’s, before it asks.
Publishing defaults to draft and quotas hold the line. The next step is an explicit confirm step for the small set of actions that change something publicly and cannot be quietly undone.
Content pipelines and research already run offline and return job ids. The goal is uniform job semantics across every long task — queue, poll, resume, and inspect per-stage transcripts from your client.
Sites resolve as sanitized references today. Next is operating a portfolio from one conversation: the same brief applied per site, with per-site brand voice, quotas and publishing rules enforced server-side.
The knowledge lane already supports write-back, so an agent’s learnings become retrievable next run. Wiring that into the WordPress lane means the connector gets better at your sites specifically.
CPTs, ACF fields, schema, and internal links are the substrate AI answer engines read. The connector is where that contract gets authored, applied, and audited from whichever assistant you already use.
The connector is live. Point any MCP client at:
https://hifibots-mcp-jm6unwvw5q-uc.a.run.app/mcpAdd it as a custom connector and sign in. OAuth 2.1 mints a platform key on your own profile and the connector proxies calls with it — you never handle a key, and revoking the grant ends access.
Add the URL with a bearer key from your dashboard:
{
"mcpServers": {
"hifibots": {
"url": "https://hifibots-mcp-jm6unwvw5q-uc.a.run.app/mcp",
"headers": { "Authorization": "Bearer hifi_YOUR_KEY" }
}
}
}Start with whoami — it returns your resolved identity, plan, and how many agents
and tools you are entitled to, which makes any connection or permission problem obvious in
one call.
It is a Model Context Protocol server that exposes your HiFiBots WordPress agent workspace to any MCP client. Your assistant discovers the tools your plan entitles, then calls them under your identity to plan, write, publish, and monetize WordPress content.
Any client that speaks MCP. Claude Desktop and claude.ai connect over OAuth 2.1; Claude Code, Cursor, Cline, Windsurf, and Zed connect with a bearer key in their MCP config; scripts can use the same key directly.
The plugin connects your WordPress site to the platform. The MCP connector connects your AI client to the platform. Most workflows use both: the connector drives the agents, the plugin is how their output lands on your live site.
No. Site credentials stay in the platform. The connector sees sanitized site references — a site id, name, URL, and platform mode — and never handles WordPress passwords or application passwords.
A skill is the agent’s operating instructions served as an installable package. Instead of your client blindly calling a tool, it installs the skill and works the way the agent works — the same purpose, tools, and workflow the hosted agent follows.
No. Entitlement is re-checked server-side on every call, and daily and period post quotas, publish idempotency guards, and tenancy fencing apply exactly as they do in the app.
It can queue posts to the multi-stage pipeline, which defaults to draft. Publishing straight to live is opt-in per call, and the pipeline stages stay pollable so you can review before anything goes public.
Yes. The connector is live and you can add it to any MCP client now. In Claude Desktop or claude.ai add it as a custom connector and sign in; in Claude Code, Cursor, Cline, Windsurf, or Zed add its URL with a bearer key from your dashboard.
Add https://hifibots-mcp-jm6unwvw5q-uc.a.run.app/mcp as a custom connector and sign in. OAuth 2.1 mints a platform key on your own profile and the connector proxies calls with it — you never paste a key.
Yes, per mode. Each agent mode carries a skill_export setting: playbook serves the workflow without the prompt (the default), full embeds the mode prompt, and none withholds the skill entirely.
Pair it with the connector plugin: the MCP connector drives the agents, and the WordPress plugin is how their output lands on your live site — chatbot, Riverstep inline editing, CPT and ACF registration, and instant RAG sync. Get the WordPress plugin →