notipo

Direct Publish

direct_publish

Publish a blog post directly to WordPress from markdown, bypassing Notion. Handles image uploads, Gutenberg conversion, featured image generation, and SEO metadata. Set publish=true to go live or false to save as draft.

Instructions

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

Name	Required	Description
`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)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`jobId`	Yes	Use get_job to poll status

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.4Jul 4, 2026

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"
+}

First observedv0.1.0Jun 23, 2026

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.

Deploy Server