Skip to main content
Glama

Notipo

by io.github.kfuras

Direct Publish

direct_publish

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesPost content in markdown (required)
slugNoCustom URL slug
tagsNoTag names
titleYesPost title
publishNoPublish immediately (true) or create as draft (false)
categoryNoCategory name
imageTitleNoFeatured image title/text overlay
seoKeywordNoSEO focus keyword
seoDescriptionNoCustom meta description for SEO (max 160 chars)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdYesUse get_job to poll status

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Notipo toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools target clearly distinct resources and actions, separating creation, updates, deletions, list/get operations, and job monitoring. The main ambiguity is between direct_publish and publish_post, since both involve publishing, though their descriptions clarify creation vs. making a draft live.

Naming Consistency4/5

The majority of tools follow a clear verb_noun pattern: create_post, get_post, list_posts, update_post, delete_post, publish_post, list_categories, list_tags. The exceptions are direct_publish and sync_now, which deviate from the pattern but remain understandable.

Tool Count5/5

13 tools is well-scoped for a blogging and sync workflow covering posts, publishing, jobs, categories, tags, and settings. Each tool addresses a distinct part of the pipeline without redundancy or excessive granularity.

Completeness4/5

The surface covers the core post lifecycle, publishing jobs, sync triggers, WordPress metadata, and settings. The only notable gap is that direct_publish creates a WordPress post outside of Notion, while update_post explicitly syncs back from Notion, so updating a direct-published post may not be covered.

Resources