Polyblog Multilingual Blog

Save a blog post

create_article

Destructive

Use this when someone gives you a finished blog post, or a translation of one, to save in their blog. Returns the new post's id, title, slug, language and published state; it stays a draft unless published is true. A translation is saved with the original's id as originalArticleId and its own locale. Not for writing a post with AI.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	No	URL slug such as my-first-post, up to 300 characters
`title`	Yes	Post title, 1 to 300 characters
`author`	No	Author name shown on the post, up to 200 characters
`blogId`	Yes	Blog to add the post to
`format`	No	markdown or html; content is treated as HTML when omitted
`locale`	No	Post language, an ISO 639-1 code such as en or it; required with originalArticleId
`content`	Yes	Post body in the chosen format, Markdown or HTML, up to 100,000 characters
`published`	No	true publishes the post on the blog; false or omitted keeps it a draft
`categories`	No	Up to 50 category names, each up to 100 characters
`description`	No	Short summary shown in listings and search results, up to 1,000 characters
`originalArticleId`	No	Makes this article the `locale` version in an existing article's translation group. It is the original article's id, never a sibling translation's id; absent means a new original.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`article`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 28, 2026

addedInput schema / properties / author / description

Added value: +"Author name shown on the post, up to 200 characters"

changedInput schema / properties / blogId / description

Previous value: -"Target blog id"New value: +"Blog to add the post to"

addedInput schema / properties / categories / description

Added value: +"Up to 50 category names, each up to 100 characters"

changedInput schema / properties / content / description

Previous value: -"Article body (Markdown or HTML based on format)"New value: +"Post body in the chosen format, Markdown or HTML, up to 100,000 characters"

addedInput schema / properties / description / description

Added value: +"Short summary shown in listings and search results, up to 1,000 characters"

addedInput schema / properties / format / description

Added value: +"markdown or html; content is treated as HTML when omitted"

addedInput schema / properties / locale / description

Added value: +"Post language, an ISO 639-1 code such as en or it; required with originalArticleId"

changedInput schema / properties / originalArticleId / description

Previous value: -"Create this article as the `locale` version of an existing article, inside that article's translation group. Pass the ORIGINAL id — the one `list_article_translations` reports — never a sibling translation id. Omit it to create a new original."New value: +"Makes this article the `locale` version in an existing article's translation group. It is the original article's id, never a sibling translation's id; absent means a new original."

addedInput schema / properties / published / description

Added value: +"true publishes the post on the blog; false or omitted keeps it a draft"

addedInput schema / properties / slug / description

Added value: +"URL slug such as my-first-post, up to 300 characters"

addedInput schema / properties / title / description
```
Added value: +"Post title, 1 to 300 characters"
```

First observedSep 11, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-derivable behavior: the post remains a draft unless published is true, what the response contains, and how translations are linked. It does not address the destructive/overwrite implication flagged by annotations.

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?

Three dense sentences, front-loaded with the usage condition, then behavior, then the translation rule and exclusion. No filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter creation tool with an output schema and full annotation coverage, the description supplies everything an agent needs: trigger condition, draft-by-default behavior, translation workflow, and the exclusion. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining the cross-parameter relationship between originalArticleId and locale ('its own locale') that no single schema property states. It also clarifies published semantics, though other params like format and categories are left to the schema.

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 ('save' a 'finished blog post') plus the two supported cases (new post or translation). It also explicitly distinguishes itself from the AI-writing tool by saying 'Not for writing a post with AI', so an agent can separate it from generate_article without reading the schema.

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 a clear usage trigger ('when someone gives you a finished blog post, or a translation of one') and one explicit exclusion ('Not for writing a post with AI'). It does not name the alternative tool (generate_article) outright nor mention update_article for edits, so routing is strong but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Polyblog Multilingual Blog tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?