The Notipo server lets you manage the full lifecycle of WordPress blog posts — from creation and editing to publishing and monitoring — directly through an AI agent or MCP-compatible client.
Post Management
List all posts – Retrieve all posts with title, status, WordPress URL, category, and timestamps.
Get a specific post – Fetch full details of a post by ID, including WordPress post ID and Notion page ID.
Create a post – Create a post via Notion with markdown content, SEO metadata, tags, category, and optional immediate publishing.
Direct publish – Publish markdown straight to WordPress (bypassing Notion), handling image uploads, Gutenberg block conversion, featured image generation (AI or Unsplash), and SEO metadata.
Update a post – Modify content, title, slug, tags, category, and SEO fields of an existing post, then re-sync to WordPress.
Publish a draft – Make a previously drafted post live on WordPress.
Delete a post – Permanently remove a post from Notipo, WordPress, and reset its Notion page status.
Taxonomy
List categories – Retrieve all WordPress categories synced to Notipo.
List tags – Retrieve all WordPress tags synced to Notipo.
Job Monitoring
Get job status – Poll the status of a sync or publish job (PENDING, RUNNING, COMPLETED, FAILED) with progress and error details.
List recent jobs – View recent sync/publish jobs, filterable by status.
Account & Configuration
Get settings – Check connected services (Notion, WordPress), your plan (FREE, TRIAL, PRO), detected SEO plugin (Rank Math, Yoast, SEOPress, AIOSEO), and feature settings.
Trigger a sync – Immediately sync Notion pages to queue pending posts (Pro plan only, 15-second cooldown).
Generate featured images for posts using Google Gemini AI.
Integrate with n8n workflows for automated publishing pipelines.
Sync content from Notion pages to WordPress by changing page status to 'Post to Wordpress' or 'Publish', including markdown extraction, image caching, and SEO metadata.
Generate featured images from Unsplash.
Publish posts to WordPress with full markdown to Gutenberg conversion, image hosting in the media library, and automatic SEO metadata via Rank Math, Yoast, SEOPress, or AIOSEO.
Apply SEO metadata automatically on publish via the Yoast WordPress plugin.
Open-source WordPress publishing for AI agents — MCP server, REST API, and CLI. Or sync from Notion.
Point your agent (Claude, Cursor, ChatGPT, n8n, any HTTP client) at Notipo and it publishes to your self-hosted WordPress — no plugin required. Notipo handles the full pipeline: markdown → Gutenberg conversion, image hosting in your WordPress media library, AI- or Unsplash-generated featured images, and Rank Math / Yoast / SEOPress / AIOSEO metadata applied automatically on publish.
Connect Notion, change a page status to Post to Wordpress or Publish, and Notipo handles the rest — markdown extraction, image caching to WP media library, featured image generation, SEO metadata via Rank Math / Yoast / SEOPress / AIOSEO.
Notipo exposes a Model Context Protocol (MCP) server with 13 tools for AI agents, plus a REST API and a CLI. Claude Desktop, Cursor, Windsurf, Claude Code, ChatGPT — any MCP-compatible agent can publish posts end-to-end.
# CLI: publish a post end-to-end
npm install -g notipo
notipo posts create --title "Why Every Dev Should Have a Blog" --publish
# REST API: one call runs the full pipeline
curl -X POST https://app.notipo.com/api/posts/create \
-H "X-API-Key: $NOTIPO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"Hello","body":"## Intro\n\nMarkdown in, WordPress out.","publish":true}'// MCP: drop into Claude Desktop config
{
"mcpServers": {
"notipo": {
"type": "http",
"url": "https://app.notipo.com/api/mcp",
"headers": { "x-api-key": "your-api-key" }
}
}
}See notipo.com/ai-agents for the full AI-agent integration story.
Related MCP server: wp-cli-mcp
The hosted version at notipo.com is the supported, batteries-included product — managed infrastructure, automatic upgrades, instant Notion webhook delivery, and a free tier with 5 posts/month. Pro is $19/month for unlimited posts plus AI featured images.
This repository is the same code that runs the hosted product. You can self-host it under the AGPL-3.0 license — see DEVELOPMENT.md for the local dev story and docker-compose.yml for production deployment with Traefik + Let's Encrypt.
Self-hosting is unsupported — no help beyond what's in this repo, no upgrade path. If you need any of those, the hosted product is faster, cheaper, and already running.
Backend: Fastify, TypeScript, Prisma, PostgreSQL 17
Job queue: pg-boss (Postgres-backed, no Redis)
Frontend (admin): Next.js 16 + shadcn/ui + Tailwind
AI: Google Gemini (featured images), Model Context Protocol (agent integration)
Other: Sharp (images), Stripe (billing), Resend (transactional email), Sentry (errors), PostHog (product analytics), Notion SDK, WordPress REST API
CLI: zero-dependency npm package, native fetch only
Monorepo (Turborepo + npm workspaces):
apps/
api/ — Fastify backend, MCP server, job workers
web/ — Next.js admin UI
packages/
cli/ — `notipo` npm package (MIT-licensed thin client)
shared/ — TypeScript types and enums
plugins/
notipo-seo-meta-writer/ — WordPress plugin for Yoast/AIOSEO metadata bridgeYou'll need: Docker, Docker Compose, a domain pointed at your server, a Notion integration, and a WordPress site with Application Passwords enabled (WP 5.6+).
git clone https://github.com/kfuras/notipo-app.git
cd notipo-app
cp apps/api/.env.example .env
# Edit .env — at minimum set DATABASE_URL, ENCRYPTION_KEY, API_KEY,
# DOMAIN, ACME_EMAIL, RESEND_API_KEY
docker compose up -dThe compose stack pulls multi-arch images (linux/amd64 + linux/arm64) from
ghcr.io/kfuras/notipo-api and ghcr.io/kfuras/notipo-web, so it works on both
x86 servers and Apple Silicon / ARM hardware.
The compose stack starts Traefik + the API + admin UI + Postgres, with Let's Encrypt TLS on first run. See docker-compose.yml for details.
For local development without Docker:
docker compose -f docker-compose.dev.yml up # Postgres only
npm install
npm run migrate -w @notipo/api
turbo dev # API on :3000, web on :3001See DEVELOPMENT.md for the full development guide.
API reference: notipo.com/docs/api/introduction
MCP server (13 tools): notipo.com/docs/api/mcp
n8n integration: notipo.com/docs/api/n8n
All docs: notipo.com/docs
Architecture & development: DEVELOPMENT.md and .claude/CLAUDE.md
This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0) — see LICENSE.
In plain English:
✅ You can use, modify, and self-host Notipo for any purpose, including commercial.
✅ You can fork it and contribute changes back.
⚠️ If you run a modified version as a hosted service, you must publish your modifications under the same license. This is the "Affero clause" — it closes the network-service loophole that plain GPL leaves open.
✅ The notipo CLI package is published to npm under MIT (it's just a thin API client wrapper).
✅ The notipo-seo-meta-writer WordPress plugin is published under MIT (compatible with WordPress's GPL ecosystem).
If you want to use Notipo's code in a proprietary hosted product without AGPL obligations, open an issue — commercial licensing may be available.
PRs welcome. See CONTRIBUTING.md for guidelines and CODE_OF_CONDUCT.md for community standards.
For security disclosures, see SECURITY.md — please don't open public issues for vulnerabilities.
Hosted SaaS: notipo.com
AI Agents: notipo.com/ai-agents
Blog: notipo.com/blog
Twitter/X: @kjetilfuras
Create a new blog post. Creates a Notion page and triggers sync to WordPress. The body should be markdown. Set publish=true to publish immediately, or leave false to create a draft.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Post content in markdown | |
| slug | No | Custom URL slug | |
| tags | No | Tag names | |
| title | Yes | Post title | |
| publish | No | Publish immediately (true) or create as draft (false) | |
| category | No | Category name | |
| seoKeyword | No | SEO focus keyword | |
| seoDescription | No | Custom meta description for SEO (max 160 chars). Auto-derived from content if not set. |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Use get_job to poll status |
| notionPageId | Yes | Newly created Notion page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects beyond annotations: creates Notion page, triggers sync to WordPress, and specifies body format as markdown. No contradiction with readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Front-loaded with purpose, then provides key details in a structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, output schema presence, and annotations, the description covers essential information: creation side effect, markdown requirement, and publish flag usage. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds value by clarifying that body should be markdown and explaining publish parameter behavior, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Create' and resource 'blog post', and distinguishes from sibling tools like delete_post and update_post by specifying it creates a Notion page and triggers sync to WordPress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on using the publish parameter, but does not explicitly mention when to use this tool versus alternatives like direct_publish or publish_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a post from Notipo, WordPress, and reset the Notion page status. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to delete |
| Name | Required | Description |
|---|---|---|
| deleted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a destructive operation, but the description adds meaningful context beyond that: it specifically names the systems affected (Notipo, WordPress, Notion) and warns irreversibly with 'This cannot be undone.' This gives the agent a clear picture of side effects without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences with zero redundancy. The primary action is front-loaded, and the critical warning about irreversibility is placed immediately after, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter operation, the description covers the key context: what is deleted, where, and that it cannot be undone. An output schema exists and the annotations cover the destructive nature, so the description does not need to explain return values or safety posture. Minor details like failure atomicity or required permissions are not mentioned, but that is a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter postId with 100% coverage. The description adds no additional semantic detail about the parameter, so it correctly receives the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a post') and precisely identifies the scope: deleting from Notipo, WordPress, and resetting the Notion page status. This clearly distinguishes the tool from the sibling tools, none of which perform deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a post needs to be deleted, and it is the only deletion-oriented sibling. However, it does not explicitly discuss when to use this tool versus alternatives, nor does it mention exclusions or prerequisites such as requiring an existing post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a blog post directly to WordPress without Notion. Handles image uploads, Gutenberg conversion, featured image generation, and SEO metadata. Body must be markdown. Set publish=true to go live, false for draft. Use this instead of create_post when you don't need Notion.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Post content in markdown (required) | |
| slug | No | Custom URL slug | |
| tags | No | Tag names | |
| title | Yes | Post title | |
| publish | No | Publish immediately (true) or create as draft (false) | |
| category | No | Category name | |
| imageTitle | No | Featured image title/text overlay | |
| seoKeyword | No | SEO focus keyword | |
| seoDescription | No | Custom meta description for SEO (max 160 chars) |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Use get_job to poll status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish mutating non-destructive write semantics, and the description adds meaningful behavioral context beyond them: the processing pipeline (image uploads, Gutenberg conversion, featured image generation, SEO metadata), the markdown input constraint, and the live-vs-draft semantics of publish. No contradiction with annotations. Not a 5 because it doesn't disclose overwrite or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, pipeline capabilities, input constraint plus flag semantics, and sibling routing. Front-loaded with the core purpose and zero filler for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, annotations cover the safety profile, and the schema covers all 9 params at 100%, so the description's burden is limited. It adequately covers the pipeline behavior and routing. The remaining gap is the direct_publish vs publish_post boundary and consequences for existing slugs/drafts, which is minor given the strong structured coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters and the baseline is 3. The description adds a light pipeline frame that connects params to behaviors (featured image generation to imageTitle, SEO metadata to seoKeyword/seoDescription), but it repeats rather than extends the schema's markdown and publish-flag semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Publish a blog post directly to WordPress'), adds the scoping differentiator 'without Notion', and explicitly names the sibling it replaces ('Use this instead of create_post'). An agent can distinguish it from create_post and publish_post without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance: 'Use this instead of create_post when you don't need Notion,' which names the alternative and the condition. However, it does not address the sibling publish_post (e.g., when a draft already exists), leaving one boundary ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a sync or publish job. Returns status (PENDING, RUNNING, COMPLETED, FAILED), progress steps, and any error message.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID returned from create_post, update_post, or publish_post |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| post | Yes | |
| type | Yes | SYNC_POST | PUBLISH_POST |
| error | Yes | |
| result | No | Job-specific result payload |
| status | Yes | PENDING | RUNNING | COMPLETED | FAILED |
| createdAt | Yes | |
| startedAt | Yes | |
| completedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by detailing the returned fields (status, progress steps, error message), which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose, input, and output. Front-loaded with the verb and resource, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema, the description is sufficient. It covers what the tool does and its key return fields. Minor omission: does not mention handling of invalid jobId, but that is likely implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's jobId description already states it comes from create_post, update_post, or publish_post. The tool description repeats this same info, adding no new semantics. At high coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'status of a sync or publish job', specifying what is returned. It differentiates from siblings like list_jobs by focusing on a single job, but does not explicitly contrast them, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a specific job's status, but does not provide explicit when-to-use vs. alternatives (e.g., when to use list_jobs instead). No guidance on prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific post by ID, including status, WordPress URL, and category.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | Yes | |
| wpUrl | Yes | Public WordPress URL once published |
| status | Yes | DRAFT | PUBLISHED | SYNCED | FAILED, etc. |
| category | Yes | |
| wpPostId | Yes | WordPress post ID once synced |
| createdAt | Yes | |
| updatedAt | Yes | |
| notionPageId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds that it returns specific fields (status, URL, category) but does not disclose other behavioral traits like rate limits or authentication needs. With annotations covering safety, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and key outputs. Every word is relevant, and there is no verbose or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 1 parameter, an output schema is present, and the description covers the essential return fields. The description is complete and appropriate for the tool's complexity, requiring no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (postId described as 'The post ID'). The description adds meaning by linking the parameter to the output, stating that the tool returns details like status, URL, and category for that ID. This provides context beyond the schema, earning a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'post', and specifies that it gets details by ID, including specific fields like status, WordPress URL, and category. This distinguishes it from sibling tools like list_posts (list vs single) and create_post (create vs get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing details of a specific post, but does not explicitly state when to use or avoid this tool versus alternatives like list_posts or get_job. No exclusion criteria or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Notipo account configuration: which services are connected (Notion, WordPress), current plan, feature settings, and trigger statuses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | FREE | TRIAL | PRO |
| wpSeoPlugin | Yes | Detected SEO plugin: RANK_MATH | YOAST | SEOPRESS | AIOSEO |
| codeHighlighter | Yes | |
| notionConnected | Yes | |
| wordpressConnected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds useful context about the specific content returned (services, plan, features, triggers). No behavioral traits beyond annotations are disclosed, but the added value is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists specifics. Every word contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, has an output schema, and annotations indicate safety, the description fully covers what the tool does and returns. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description naturally cannot add parameter info. Baseline for zero parameters is 4, and no further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account configuration, specifying exactly what it includes (connected services, plan, features, triggers). This distinctively separates it from sibling tools like get_post or list_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing settings but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. No comparison with siblings is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all WordPress categories synced to Notipo. Use these names when creating posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that categories are 'synced to Notipo' and includes 'all' categories, which gives useful scope context but does not disclose additional behavioral details like ordering or whether empty categories are included. That is acceptable for a simple read-only list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core resource and action are front-loaded, and the usage note earns its place by linking to a downstream workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with an output schema and annotations covering safety, the description is complete. It explains what is returned, where the data comes from, and how the result should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds contextual value by explaining that the returned names should be used when creating posts, which helps the agent understand how the output connects to another tool. There are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List all WordPress categories synced to Notipo') and clearly identifies the resource. It distinguishes categories from sibling tools like list_tags, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the output should be used ('Use these names when creating posts'), which connects directly to the create_post sibling. It does not explicitly state when not to use it versus list_tags, but the category-specific wording makes the intended context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent sync and publish jobs. Useful for monitoring pipeline activity.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of jobs to return (default 10) | |
| status | No | Filter by job status |
| Name | Required | Description |
|---|---|---|
| jobs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope context ('recent sync and publish jobs'), but does not disclose additional behavioral details such as sorting or time-window semantics. This is adequate but not rich beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed by a relevant usage hint. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with fully documented parameters, safety annotations, and an output schema, the description provides sufficient context. The agent can select and invoke the tool correctly without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit and status are already fully documented in the schema. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List recent sync and publish jobs') and clearly scopes the operation to job-listing, distinguishing it from singular get_job and from other list_* siblings. It is immediately obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for monitoring pipeline activity' gives a clear context for when to use the tool. It does not explicitly mention alternatives or exclusionary conditions, but the intended use case is evident from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all posts for your Notipo account. Returns title, status, WordPress URL, category, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| posts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds return field details but does not mention pagination, limits, or ordering. No contradiction, but depth is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently conveys purpose and output, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema exists, the description lists the returned fields adequately. However, it omits details on whether the list is paginated or limited, which would add completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%, and the description does not need to compensate. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all posts for your Notipo account' with a specific verb and resource, and lists the returned fields, distinguishing it from siblings like get_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the tool's purpose is straightforward, no guidance is given on when to use it versus alternatives (e.g., get_post for a single post). The description implies use for listing all posts but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all WordPress tags synced to Notipo. Use these names when creating posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by clarifying the data source ('WordPress tags synced to Notipo'), which gives agents a better sense of the returned data's scope and provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, with the main action front-loaded and a practical usage note included. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-parameter tool with an output schema, the description is complete. It states what is returned, provides usage guidance, and annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied. The description does not need to explain inputs, and the schema confirms no arguments are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a specific resource ('WordPress tags synced to Notipo'), and a clear scope that distinguishes it from sibling tools like list_categories and list_posts. An agent can immediately know what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use these names when creating posts, which gives a concrete usage context. It does not explicitly list when not to use it or name alternatives, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a draft post to WordPress (make it live).
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to publish |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Use get_job to poll status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds the key behavioral detail that the post transitions from draft to live, which is useful. It does not mention prerequisites, failure conditions, or side effects, but for this simple operation the added context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and outcome with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one fully documented parameter, annotations, and an output schema present, the description is sufficient for an agent to select and invoke this tool correctly. No critical contextual information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole parameter, postId, is already documented as 'The post ID to publish'. The description adds the draft-to-live context but does not meaningfully extend the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Publish'), the resource ('a draft post to WordPress'), and the effect ('make it live'). It distinguishes the tool from create_post and update_post, though it does not explicitly differentiate it from the sibling direct_publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of alternatives. In particular, the presence of direct_publish as a sibling makes this a meaningful gap, since an agent cannot tell which publishing workflow to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an immediate sync from Notion. Checks for any posts with trigger statuses and queues sync jobs. Pro plan only. Has a 15-second cooldown between calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| triggered | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details beyond annotations: it checks trigger statuses, queues sync jobs, requires a Pro plan, and enforces a 15-second cooldown. The readOnlyHint=false and destructiveHint=false annotations are not contradicted; the description enriches them with real operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences cover the action, the internal process, and the constraints. Every sentence adds value and the description is front-loaded with the core purpose before details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description does not need to explain return values. It fully covers what the tool does, how it behaves, and the operational limits, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool takes zero parameters, so there is nothing for the description to add beyond what the schema already shows. The baseline of 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Trigger an immediate sync from Notion,' which clearly states the verb, resource, and action. It further explains the internal behavior ('checks for posts with trigger statuses and queues sync jobs'), making it easily distinguishable from sibling tools like publish_post or update_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when an immediate sync from Notion is desired. It also adds operational constraints ('Pro plan only', '15-second cooldown'), though it does not explicitly name alternatives or when-not scenarios. The uniqueness of the action makes exclusions less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing post's content or properties in Notion, then re-sync to WordPress. Only provided fields are updated.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | New content in markdown (replaces entire body) | |
| slug | No | New URL slug | |
| tags | No | New tag names | |
| title | No | New title | |
| postId | Yes | The post ID to update | |
| publish | No | Set true to also publish after updating | |
| category | No | New category name | |
| seoKeyword | No | New SEO focus keyword | |
| seoDescription | No | New meta description for SEO (max 160 chars) |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Use get_job to poll status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds non-obvious behavior: updates happen in Notion and then re-sync to WordPress. The partial-update rule ('Only provided fields are updated') is also useful and not otherwise stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with no filler. It front-loads the action and includes the most important behavioral constraint without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema, output schema, and annotations, the description covers the core behavior, the cross-system sync side effect, and the partial-update rule. It could have more explicitly addressed when to use the publish parameter versus publish_post/direct_publish, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying partial-update semantics, which is not necessarily inferable from optional schema properties alone. It correctly avoids repeating individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and clearly identifies the resource: an existing post's content or properties in Notion, followed by re-sync to WordPress. It distinguishes itself from siblings like create_post and delete_post by emphasizing 'existing post'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for modifying an existing post and that only provided fields are updated. It does not explicitly mention alternatives like publish_post or direct_publish, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.4create_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobId": {
+ "description": "Use get_job to poll status",
+ "type": "string"
+ },
+ "notionPageId": {
+ "description": "Newly created Notion page",
+ "type": "string"
+ }
+ },
+ "required": [
+ "jobId",
+ "notionPageId"
+ ],
+ "type": "object"
+}delete_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "deleted": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "deleted"
+ ],
+ "type": "object"
+}direct_publish1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobId": {
+ "description": "Use get_job to poll status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "jobId"
+ ],
+ "type": "object"
+}get_job1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "completedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "createdAt": {
+ "type": "string"
+ },
+ "error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "post": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "wpUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "status",
+ "wpUrl"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "result": {
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Job-specific result payload"
+ },
+ "startedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "PENDING | RUNNING | COMPLETED | FAILED",
+ "type": "string"
+ },
+ "type": {
+ "description": "SYNC_POST | PUBLISH_POST",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "status",
+ "error",
+ "createdAt",
+ "completedAt",
+ "startedAt",
+ "post"
+ ],
+ "type": "object"
+}get_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "createdAt": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "notionPageId": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "DRAFT | PUBLISHED | SYNCED | FAILED, etc.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updatedAt": {
+ "type": "string"
+ },
+ "wpPostId": {
+ "description": "WordPress post ID once synced",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "wpUrl": {
+ "description": "Public WordPress URL once published",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "status",
+ "wpUrl",
+ "category",
+ "createdAt",
+ "updatedAt",
+ "wpPostId",
+ "notionPageId"
+ ],
+ "type": "object"
+}get_settings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "codeHighlighter": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "notionConnected": {
+ "type": "boolean"
+ },
+ "plan": {
+ "description": "FREE | TRIAL | PRO",
+ "type": "string"
+ },
+ "wordpressConnected": {
+ "type": "boolean"
+ },
+ "wpSeoPlugin": {
+ "description": "Detected SEO plugin: RANK_MATH | YOAST | SEOPRESS | AIOSEO",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "notionConnected",
+ "wordpressConnected",
+ "plan",
+ "wpSeoPlugin",
+ "codeHighlighter"
+ ],
+ "type": "object"
+}list_categories1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "wpCategoryId": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "wpCategoryId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "categories"
+ ],
+ "type": "object"
+}list_jobs1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobs": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "completedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "createdAt": {
+ "type": "string"
+ },
+ "error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "description": "PENDING | RUNNING | COMPLETED | FAILED",
+ "type": "string"
+ },
+ "type": {
+ "description": "SYNC_POST | PUBLISH_POST",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "status",
+ "error",
+ "createdAt",
+ "completedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "jobs"
+ ],
+ "type": "object"
+}list_posts1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "posts": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "createdAt": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "description": "DRAFT | PUBLISHED | SYNCED | FAILED, etc.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updatedAt": {
+ "type": "string"
+ },
+ "wpUrl": {
+ "description": "Public WordPress URL once published",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "status",
+ "wpUrl",
+ "category",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "posts"
+ ],
+ "type": "object"
+}list_tags1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "tags": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "wpTagId": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "wpTagId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tags"
+ ],
+ "type": "object"
+}publish_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobId": {
+ "description": "Use get_job to poll status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "jobId"
+ ],
+ "type": "object"
+}sync_now1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "triggered": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "triggered",
+ "message"
+ ],
+ "type": "object"
+}update_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobId": {
+ "description": "Use get_job to poll status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "jobId"
+ ],
+ "type": "object"
+}v0.1.0create_postdelete_postdirect_publishget_jobget_postget_settingslist_categorieslist_jobslist_postslist_tagspublish_postsync_nowupdate_postScored across 13 tools
Each tool targets a distinct operation, though create_post and direct_publish have overlapping purposes (both create posts) but their descriptions clearly differentiate the workflows (via Notion vs direct). Overall, an agent can easily distinguish them.
Most tools follow verb_noun pattern (create_post, list_posts, etc.), but 'direct_publish' uses an adjective+verb and 'sync_now' uses verb_adverb, which are minor inconsistencies. Overall, the naming is predictable.
With 13 tools, the server covers the full range of operations needed for managing posts between Notion and WordPress without being excessive. Each tool serves a clear purpose.
The tool set provides CRUD for posts, publishing, syncing, and monitoring jobs. However, it only lists categories and tags without create/update/delete capabilities, which is a minor gap.
WordPress MCP server: publish posts, AI images, SEO and full site management, self-hosted
WordPress MCP server: generate SEO posts, AI images, autoblog & WooCommerce on your self-hosted site
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Publish HTML, Markdown, and multi-file sites as shareable URLs instantly via MCP.
