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.
Distraction-free editor with toolbar shortcuts, slash commands, drag-and-drop images, and one-click publish. No Notion required.
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 + BlockNote editor + 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?
Annotations already declare destructiveHint: true. The description adds that the operation 'cannot be undone' and mentions resetting the Notion page status, providing useful behavioral context 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?
The description is two sentences long, front-loads the primary action, and contains no unnecessary words. Every sentence adds value.
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 low complexity (1 required parameter) and presence of an output schema, the description adequately covers the tool's purpose, effects, and constraints. No additional details are needed for an agent to correctly invoke this tool.
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 single parameter 'postId' has a clear description. The tool description does not add any extra meaning or constraints beyond what the schema already provides, so baseline of 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 'delete' and the resource 'post', and specifies the affected systems (Notipo, WordPress, Notion page status). This distinguishes it from sibling tools like update_post or create_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?
No explicit guidance on when to use this tool versus alternatives. The only additional information is a cautionary note that the operation cannot be undone, which implies careful use but does not provide context or exclusions.
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 provide minimal info (readOnlyHint, destructiveHint). Description adds significant behavioral details: image uploads, Gutenberg conversion, featured image generation, SEO metadata, markdown requirement, publish/draft toggle. No contradictions with 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 sentences, front-loaded with main purpose, no wasted words. Efficient and clear.
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 tool with 9 parameters and an output schema, the description covers core functionality (image handling, conversion, SEO, markdown requirement, publish/draft). Output schema presumably explains return values; no missing critical info.
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%, but description adds value by specifying 'Body must be markdown' (reinforcing body parameter) and explaining the publish parameter's effect. Does not explain other params but schema already covers them.
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 'Publish a blog post directly to WordPress without Notion' – specific verb and resource. Explicitly distinguishes from sibling create_post: 'Use this instead of create_post when you don't need Notion.'
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?
Explicitly states when to use ('when you don't need Notion') and names the alternative (create_post). Provides clear usage context.
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. The description adds 'synced to Notipo' as context but does not elaborate on behavior like pagination or edge cases. It meets the minimum with 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 sentences with no redundancy. The purpose is front-loaded and the usage hint is added efficiently.
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 parameterless list tool with an output schema, the description covers purpose and usage. No further details about return format are needed as the output schema handles that.
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 cannot add value beyond the schema. Baseline score of 4 applies as per guidelines for 0 parameters.
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 lists WordPress categories synced to Notipo, with a specific verb and resource. It distinguishes from sibling tools like list_tags and list_posts which list different entities.
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 explicitly mentions to use the names when creating posts, indicating when to use. However, it does not provide explicit alternatives or exclusions, though it's clear enough given sibling names.
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 indicate readOnlyHint=true and destructiveHint=false. Description adds 'recent sync and publish jobs' but no additional behavioral details like sorting or pagination beyond the limit parameter.
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 front-loaded sentences with no redundant words. Every sentence contributes to purpose and usage context.
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?
Tool is simple with 2 parameters, schema covers them, output schema exists, and annotations cover safety. Description suffices but could mention return format (list of job objects) which is likely in output schema.
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 fully describes both parameters (limit, status). Description does not add any extra meaning beyond what the schema provides.
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?
Description clearly states 'List recent sync and publish jobs' with a specific verb and resource, and distinguishes from siblings like 'get_job' (single job) and 'list_posts' (different resource).
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?
States 'Useful for monitoring pipeline activity' but does not provide explicit when-not-to-use or mention alternatives like 'get_job' for detailed job info.
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, informing the agent that this is a safe read operation. The description adds that it lists 'ALL' tags, which is helpful, but does not disclose additional behavior such as data limits or sync freshness. With annotations covering the safety profile, a score of 3 is appropriate.
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 consists of two short, effective sentences. The main action is front-loaded, and every word adds value. No redundancy or unnecessary 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?
Given the presence of an output schema (implied by 'Has output schema: true'), the description does not need to explain return values. It covers the essential: what is listed and how to use the results. The tool is simple, and the description is fully adequate.
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?
There are no parameters, and schema description coverage is 100% (since there are none to describe). The description does not need to add parameter details. Per guidelines, 0 parameters yields a baseline of 4.
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 'List' and the resource 'all WordPress tags synced to Notipo'. It also adds usage context by mentioning to use these names when creating posts, which distinguishes it from sibling tools like list_categories.
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 to use the tool: to retrieve available tag names for creating posts. It does not explicitly state when not to use or specify alternatives, but the context is sufficient for most scenarios.
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 mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds minimal behavioral context beyond 'make it live', omitting side effects, permission requirements, or state changes.
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 concise sentence that front-loads the core purpose. No superfluous words or 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 1-param tool with an output schema, the description is nearly complete. Lacks mention of error conditions or prerequisites, but overall adequate.
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% for the single parameter 'postId', with schema description 'The post ID to publish'. The tool description adds no extra meaning beyond what the schema provides.
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 explicitly states the verb 'publish', the resource 'draft post', and the effect 'make it live' with platform context 'WordPress'. It clearly distinguishes from sibling tools like create_post (draft creation) and delete_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 implies use for publishing drafts but provides no explicit when-to-use, when-not-to-use, or alternatives. It does not distinguish from sibling 'direct_publish' or mention prerequisites.
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?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds behavioral context: it checks trigger statuses and queues sync jobs, with a cooldown. It does not contradict annotations and adds useful behavioral details.
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 concise sentences: action, internal process, and constraints. No fluff, front-loaded, every sentence adds value.
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 zero parameters, annotations covering safety, and an output schema present (though not shown), the description sufficiently tells the agent what the tool does, its triggers, and restrictions. It is complete for the tool's complexity.
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?
Input schema has zero parameters, so schema coverage is 100%. The description adds no parameter information (none needed). Baseline for zero parameters is 4, and no additional value 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 verb 'trigger' and the resource 'sync from Notion', and explains the specific actions (checks for trigger statuses, queues sync jobs). It distinguishes this tool from siblings which are CRUD operations on posts and jobs.
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 explicitly mentions 'Pro plan only' and a '15-second cooldown', providing usage constraints. It implies usage for immediate sync but does not explicitly state when not to use or compare to alternatives.
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?
Annotations indicate it's not read-only and not destructive, and the description confirms updating existing content. However, it does not disclose side effects, permissions, or rate limits beyond the basic update action.
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 concise (two sentences), front-loaded with the core action, and contains no redundant information. 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?
Given 9 parameters and an output schema, the description is minimal. It doesn't explain prerequisites, output, or workflow integration. However, the output schema likely covers return values, making it adequate but not thorough.
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 explains each parameter. The description adds no additional meaning beyond stating 'Only provided fields are updated', which is already implied by optional parameters.
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 title and description clearly state the tool updates an existing post, with specific resource (post) and action (update). It distinguishes from sibling tools like create_post and delete_post by mentioning re-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?
The description implies partial update behavior with 'Only provided fields are updated', but lacks explicit when-to-use or when-not-to-use guidance. The sibling tool list provides context, but no direct alternatives are mentioned.
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. Dates show when Glama detected each change.
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_postEach 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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kfuras/notipo-app'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
