Manage multilingual Polyblog articles, localization coverage and editorial plans through OAuth.
Scored across 19 tools
Tools are mostly distinct by resource and action, and descriptions explicitly differentiate overlapping read versus preview and blog versus overview tools. A few pairs such as get_article vs show_article_preview, get_blog vs show_blog_overview, and list_blogs vs open_polyblog still share similar retrieval intent, though the descriptions mitigate confusion.
All tools use snake_case with a predictable verb-first pattern such as create_*, get_*, list_*, update_*, delete_*, set_*, and show_*. The convention is consistent across all 19 tools.
19 tools is slightly heavy for the domain but reasonable given the distinct areas covered: blogs, articles, translations, topic research, and preview/workspace views. Each tool appears purposeful, though some presentation and preview tools could potentially be consolidated.
Article lifecycle is well covered with create, generate, get, update, delete, search, preview, and translation listing. Blog lifecycle is incomplete because blogs can be created, listed, and fetched but not updated or deleted, and topic ideas lack direct title/angle editing beyond status and source management.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| article | Yes |
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.
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.
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.
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.
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.
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.
Use this when someone asks to start a new blog in Polyblog with a given name and languages. Returns the new blog's id, name, domain and languages; the name becomes the public .polyblog.io subdomain, so a name already taken fails. Not for adding a post to an existing blog.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Blog name, which becomes the public <name>.polyblog.io subdomain and has to be globally unique | |
| locales | No | Every language the blog publishes in, ISO 639-1 codes such as en and it | |
| description | No | Short description of what the blog is about, up to 600 characters | |
| defaultLocale | No | Main language, an ISO 639-1 code such as en | |
| articlesFormat | No | Format for the blog's posts: markdown or html |
| Name | Required | Description |
|---|---|---|
| blog | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=true), and the description adds genuinely useful behavior: the name must be globally unique because it becomes the public <name>.polyblog.io subdomain, and duplicate names fail. That failure-mode disclosure goes beyond what the annotations provide.
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 tight sentences: trigger first, then return/failure semantics, then exclusion. Every clause earns its place and nothing is padded.
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?
An output schema exists, yet the description still concisely signals return fields and, more importantly, the collision failure mode. Combined with annotations covering safety, an agent has everything needed to 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?
Schema description coverage is 100%, so all five parameters (including the required 'name' and its uniqueness/length constraint) are already documented. The description reinforces the name-to-subdomain mapping but adds no syntax or format detail beyond the schema, matching the baseline for full 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?
Specific verb+resource (create a blog) with scope, and it explicitly distinguishes itself from the sibling operation by function: 'Not for adding a post to an existing blog.' An agent can route correctly without opening the schema.
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?
'Use this when someone asks to start a new blog in Polyblog' gives a clear trigger, and the closing exclusion rules out the most likely confusion (adding a post). It stops short of naming the concrete alternative (create_article), so it is strong but not fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to permanently delete a blog post in every language. Given the original post's id, that post and all its translations are deleted and their pages go offline; given a translation's own id, nothing is deleted although the result still says deleted. Returns the id. Not for unpublishing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the original post (its originalArticleId); every language version of it is deleted |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| articleId | Yes | The id passed in. The API deletes every article whose originalArticleId equals it, so a translation id deletes nothing even though status is deleted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: the annotations only say destructive/openWorld/idempotent, while the description discloses that passing the original post id cascades to all translations and takes their pages offline, and — critically — that passing a translation's own id deletes nothing yet still reports success. That silent-failure trap is exactly the kind of behavior an agent cannot infer from structured fields.
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?
Front-loaded with the trigger and no filler sentences; every clause carries information. The single dense sentence packing both the original-id and translation-id branches is slightly hard to parse on first read, which keeps it just short of ideal.
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, single-parameter tool with full annotation coverage, a complete schema and an output schema present, the description covers the remaining risk surface: cascade scope, page-offline side effect, and the misleading-success edge case. Nothing an agent needs before invoking it 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 coverage is 100% and the schema already explains that 'id' is the original post's originalArticleId, so baseline credit is limited. The description nevertheless adds meaning the schema omits: the consequence of supplying a translation's own id (nothing deleted, misleading success result). That is genuine semantic value, though the format/lookup of the id itself is left to the schema.
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 precise verb+resource+scope: 'permanently delete a blog post in every language,' which distinguishes it from update_article and the read/search siblings. It also explicitly excludes a near-neighbor use case with 'Not for unpublishing.' An agent can route to this tool without opening any schema.
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?
Opens with an explicit trigger ('Use this when someone asks to permanently delete a blog post'), names the outcome scope (all languages), and closes with an explicit exclusion ('Not for unpublishing'). Both when-to-use and when-not-to-use are stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks you to write a new blog post on a topic or saved topic idea. Returns the draft's id, URL, title, word count and internal links (text only; published only with autoPublish). It uses paid AI and can take about a minute, and a call that times out can still save the draft. Not for saving your own text.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Title and optional angle to write about; omit when topicIdeaId is given | |
| blogId | Yes | Blog to write for | |
| locale | No | Language of the post, an ISO 639-1 code; defaults to the blog's default locale | |
| persist | No | false returns a preview without saving anything; defaults to true | |
| autoPublish | No | true publishes the post immediately; defaults to false, a draft | |
| topicIdeaId | No | Saved topic idea to write about; omit when topic is given | |
| sitemapMaxUrls | No | How many sitemap URLs to offer as internal links, from 1 to 500; defaults to 150 |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (destructive, non-idempotent, open-world); the description adds behavior an agent cannot get from them: paid AI cost, ~1 minute latency, and the critical warning that a timed-out call can still persist the draft. It also ties persist=false to a preview and autoPublish to immediate publishing, which is essential context for a destructive, non-idempotent tool.
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 tight sentences, front-loaded with the trigger condition and zero filler. The enumeration of return fields is mildly redundant given an output schema exists, but it is brief and sandwiched between higher-value disclosures.
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 7-parameter destructive mutation with an output schema, the description covers triggers, cost, latency, timeout behavior, preview and publish semantics, and exclusions. Remaining gaps (authorization/permission requirements, whether blogId must reference an existing blog) are minor given the schema covers parameters and returns.
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 every parameter (topic, topicIdeaId, locale, persist, autoPublish, sitemapMaxUrls) is documented in the schema itself. The description only echoes the topic/topicIdeaId choice at a high level, adding no syntax or format detail, so the baseline 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?
Names a specific verb and resource ('write a new blog post on a topic or saved topic idea') and scopes it to AI generation rather than manual authoring. The closing exclusion, 'Not for saving your own text,' implicitly separates it from create_article, so an agent can route without opening the schema.
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 a clear trigger ('when someone asks you to write a new blog post') and a when-not ('Not for saving your own text'). It stops short of naming the alternative sibling explicitly, leaving the agent to infer that create_article handles user-supplied text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to read, check or quote one blog post. Returns its title, summary, language, slug, blog, author, published state, dates and up to 8,000 characters of content, looked up by id or by slug plus language. Not for a visual preview card.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of the post, an ISO 639-1 code such as en; needed when looking up by slug | |
| idOrSlug | Yes | Article id, or its slug together with locale |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds a genuinely useful behavioral detail not in the structured data: content is truncated to 8,000 characters, and lookup is keyed by id or by slug+language. It omits error behavior when slug is given without locale.
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: the first front-loads the usage trigger, the second the return shape and lookup mechanics. No filler and no repetition.
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 an output schema present the description need not explain return values, yet it summarizes them usefully and covers both lookup paths. Only the failure mode of a slug lookup without locale is unaddressed, which is minor.
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 clause 'looked up by id or by slug plus language' restates what the idOrSlug and locale schema descriptions already state, adding no new format or constraint information.
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 (read/check/quote) and resource (one blog post), then enumerates the returned fields. It explicitly distinguishes itself from show_article_preview ('Not for a visual preview card'), so an agent can route correctly without opening the schema.
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 a clear trigger ('when someone wants to read, check or quote one blog post') and names the lookup modes plus one explicit exclusion. It does not mention discovery-oriented siblings like search_articles or list_article_translations as alternatives when the target post is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about one blog's setup, such as its domain, default language or languages. Returns the blog's id, name, custom domain, default locale, locales, cover image URL and dates, by id or name. Not for a visual overview with recent posts.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrName | Yes | Blog id, or the blog's name |
| Name | Required | Description |
|---|---|---|
| blog | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's main behavioral contribution is a list of returned fields, which overlaps with the existing output schema rather than adding new context such as lookup-failure behavior or case sensitivity of name matching.
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 tight sentences, front-loaded with the usage condition followed by return contents and the exclusion. Every sentence carries routing or scoping information with no filler.
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 single-parameter read tool with full annotation coverage and an output schema, the description is nearly complete: purpose, trigger, and alternative are all present. The enumerated return fields are somewhat redundant with the output schema, but nothing an agent needs to call the tool correctly 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 coverage is 100% and the single idOrName parameter is already documented in the schema, so the baseline is 3. The phrase "by id or name" merely restates what the schema parameter says and adds no new syntax, format, or matching-semantics detail.
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 (get) and resource (blog details), lists the concrete fields returned (domain, default locale, locales, cover image, dates), and explicitly distinguishes itself from the visual sibling show_blog_overview. An agent can identify the tool without opening the schema.
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 an explicit trigger ("when someone asks about one blog's setup") and an explicit exclusion ("Not for a visual overview with recent posts"), which routes the agent to show_blog_overview for that case. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how well their blog is translated, or which languages are missing posts. Returns per-language counts of posts, published posts and drafts with a coverage percentage, from the 100 most recently edited posts. Not for one post's translations.
| Name | Required | Description | Default |
|---|---|---|---|
| blogId | Yes | Blog id, or the blog's name |
| Name | Required | Description |
|---|---|---|
| blog | Yes | |
| sample | Yes | Coverage is computed from the 100 most recently edited posts; truncated means the blog has more |
| locales | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world behavior, so the safety profile is covered. The description adds useful behavioral scope beyond annotations by disclosing that results are computed only from 'the 100 most recently edited posts' and by specifying the return dimensions (posts, published posts, drafts, coverage percentage). It does not mention permissions, rate limits, or error behavior, so it stops short of a 5.
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 three tightly written sentences that front-load the trigger, then the return shape, then the exclusion. Every sentence earns its place, and there is no redundant restatement of the title or annotations.
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?
An output schema exists, so the description need not explain the full return structure, yet it still summarizes the useful return dimensions. Combined with rich annotations and a fully documented single parameter, the description gives an agent everything needed to select and call the tool 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?
The input schema has 100% description coverage and documents the single blogId parameter as 'Blog id, or the blog's name.' The description does not add any parameter-specific syntax or format guidance beyond that. With schema coverage this high, the baseline score 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 states a specific verb and resource: it checks how well a blog is translated and returns per-language post counts with coverage percentages. It distinguishes itself from the sibling tool list_article_translations by explicitly saying 'Not for one post's translations.' An agent can tell what this tool does without opening the schema.
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 opening sentence gives the triggering question ('how well their blog is translated' or 'which languages are missing posts'), and the final sentence gives the exclusion condition ('Not for one post's translations'). This covers both when to use it and when not to use it, leaving little inference for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what pages their blog's sitemap lists, or which pages are available to link to. Returns the sitemap's URL count and the first 25 URLs with language and last-modified date, read live from the blog's custom domain. Not for the posts stored in Polyblog.
| Name | Required | Description | Default |
|---|---|---|---|
| blogId | Yes | Blog whose sitemap to read | |
| locale | No | Only URLs in this language, a two-letter code such as en | |
| maxUrls | No | How many sitemap URLs to read and count, from 1 to 2,000; defaults to 500, and only the first 25 are listed |
| Name | Required | Description |
|---|---|---|
| sample | Yes | The first 25 URLs read; returned counts every URL read |
| baseUrl | Yes | |
| returned | Yes | How many sitemap URLs were read, at most maxUrls |
| totalUrls | Yes | |
| rootSitemap | Yes | |
| childSitemaps | Yes | |
| sampleTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the data is read live from the blog's custom domain, and only the first 25 URLs are surfaced even when more are counted. It stops short of noting failure modes (e.g., missing/unreachable sitemap), which keeps it from a 5.
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 sentences with zero filler, front-loaded with the usage trigger, followed by return shape and the disambiguation. Every sentence 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 an output schema present the description needn't enumerate return values, yet it still flags the count/first-25 distinction that could surprise an agent. Combined with rich annotations and a fully documented schema, nothing needed to call this tool correctly 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%, so blogId, locale and maxUrls are already documented with formats and bounds. The description restates the 25-URL listing cap but adds no meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.
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?
Specific verb+resource (read a blog's sitemap URLs) plus the concrete return shape: URL count and the first 25 URLs with language and last-modified date. It explicitly distinguishes itself from the sibling set with 'Not for the posts stored in Polyblog,' so an agent can rule out search_articles/get_article.
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 an explicit trigger ('when someone asks what pages their blog's sitemap lists, or which pages are available to link to') and an explicit exclusion ('Not for the posts stored in Polyblog'). Nothing about selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which languages a blog post exists in, or which translations are still missing. Returns each language version sharing the original article id, up to 100, with title, slug, published state and how it was translated; with blogId it also lists the blog's missing languages. Not for a whole blog's coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| blogId | No | Blog id; when given, the result also lists the blog languages that still lack this post | |
| originalArticleId | Yes | Id of the original article that every translation shares, as reported on each of its versions |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| truncated | Yes | |
| missingLocales | Yes | |
| missingLocalesKnown | Yes | |
| missingLocalesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds value beyond them: a result cap of 100, the exact fields returned, and the conditional behavior when blogId is supplied. It stops short of describing pagination or ordering, so not a 5.
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 sentences, front-loaded with the usage trigger and closing with the scoping exclusion. Dense but every clause earns its place; the middle sentence packs return fields and the 100-cap 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?
With an output schema present the description need not detail return values, yet it also names the key fields and the result cap. Combined with explicit usage and scoping, an agent has everything needed to call it 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?
Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the blogId effect ('with blogId it also lists the blog's missing languages'), but adds little syntax or meaning beyond what the schema already states. 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?
States a specific verb (List) and resource (a post's translations) and immediately scopes it to language versions sharing an original article id. It also explicitly distinguishes from the sibling get_blog_localization_summary by saying 'Not for a whole blog's coverage.' An agent can differentiate it from siblings without opening a schema.
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 trigger conditions ('when someone asks which languages a blog post exists in, or which translations are still missing') plus a clear exclusion ('Not for a whole blog's coverage'). This is when-to-use and when-not-to-use in one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which blogs they have in Polyblog, or a blog's id is needed. Returns each blog's id, name and custom domain, 25 per page by default with a cursor. Not for a blog's posts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Blogs per page, from 1 to 100; defaults to 25 | |
| cursor | No | The nextCursor of the previous page; absent for the first page |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| hasMore | Yes | |
| nextCursor | Yes | Cursor for the next page; null on the last page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds useful behavior beyond them: the page size default (25) and cursor-based pagination, plus what each result contains.
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 tight sentences: the primary use case leads, the exclusion follows. No filler and nothing redundant.
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 annotations carrying safety semantics and an output schema defining the return shape, the description covers everything an agent needs: purpose, trigger, pagination, and scope boundary.
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 both parameters (limit, cursor) are fully documented in the schema, so the baseline is 3. The description's mention of '25 per page by default with a cursor' restates schema information rather than adding syntax or format detail.
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+resource ('list your blogs') scoped to Polyblog, and further pins down the return payload (id, name, custom domain). It is clearly distinguishable from siblings like get_blog (single blog) and show_blog_overview.
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 an explicit trigger ('when someone asks which blogs they have, or a blog's id is needed') and an explicit exclusion ('Not for a blog's posts'). It does not name the alternative tool for posts, but the when/when-not conditions are concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what they could write about next from topic ideas already saved. Returns each idea's id, score out of 10, title, status and source, filtered by status or minimum score, 25 per page by default. Not for fetching new ideas.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Ideas per page, from 1 to 100; defaults to 25 | |
| blogId | Yes | Blog whose ideas to list | |
| cursor | No | The nextCursor of the previous page with the same filters; absent for the first page | |
| status | No | Only ideas with this status: new, used or dismissed; omit for all | |
| minScore | No | Only ideas with at least this AI score, 0 to 10 |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| hasMore | Yes | |
| nextCursor | Yes | Cursor for the next page; null on the last page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: lists the returned fields (id, score, title, status, source), describes filtering behavior, and states the default page size (25). Annotations already cover readOnly, idempotent, and safe operation, so this extra return-field info is a valuable addition.
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 that front-load the primary use case, then return fields, then an exclusion. Efficient with no wasteful repetition.
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?
Though an output schema exists, the description lists key return fields which helps confirm expectations. It covers usage, return content, filtering, pagination default, and exclusions, leaving no significant gap for this read-only listing 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 description coverage is 100%, so the schema fully documents each parameter's meaning and constraints. The description mentions filtering by status or minimum score, which maps to existing parameters but adds no new syntax or detail beyond the schema.
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) and resource (saved topic ideas) and explicitly excludes fetching new ideas, distinguishing it from the sibling refresh_topic_ideas.
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 a clear usage scenario ('when someone asks what they could write about next from topic ideas already saved') and names an exclusion ('Not for fetching new ideas'), routing the agent to the refresh alternative. No further alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to open their PolyBlog library and browse blogs and articles in an interactive workspace. Starts with up to 25 blogs; the view supports pagination and reading articles. Not for creating or publishing content.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| hasMore | Yes | |
| nextCursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: a 25-blog initial load, pagination support, and in-view reading. It doesn't clarify state persistence or refresh behavior, but that is minor given annotation coverage.
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 tight sentences, front-loaded with the use trigger, followed by behavioral detail and an exclusion. Every sentence earns its place with no filler.
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?
An output schema exists, so return values needn't be described, and with zero params the description carries the remaining burden. It covers purpose, scope, initial limit, and exclusions, though it could note whether the workspace requires prior authentication or persists across sessions.
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 zero parameters and 100% schema coverage, there is nothing for the description to compensate for, so the baseline of 4 applies. No parameter meaning is needed or missing.
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 ('open their PolyBlog library and browse blogs and articles in an interactive workspace'), making clear this launches a UI view rather than returning data like the many get_*/list_* siblings. It partially differentiates from siblings via the explicit exclusion clause, but doesn't contrast against the data-fetching tools by name.
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?
It gives a clear when-to-use trigger ('Use this when someone wants to open their PolyBlog library and browse') plus a when-not clause ('Not for creating or publishing content'). It stops short of naming the preferred alternative tools for programmatic listing or creation, so routing isn't fully unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks for new blog topic ideas from Reddit or RSS feeds. Returns counts and up to 5 of the saved ideas; it fetches the sources, scores candidates with paid AI and saves those that pass. Not for ideas already saved.
| Name | Required | Description | Default |
|---|---|---|---|
| blogId | Yes | Blog to find ideas for | |
| sources | No | Subreddits and RSS feeds for this run only; the blog's saved sources when absent | |
| audience | No | Who the blog writes for; defaults to the blog's context | |
| minScore | No | Lowest AI score, 0 to 10, an idea needs to be saved; defaults to 5 | |
| sinceHours | No | How far back to read, in hours, from 1 to 8,760; defaults to 168 (7 days) | |
| perSourceCap | No | Most candidates to score from each source, from 1 to 100; no cap by default | |
| limitPerSource | No | Items to read from each source, from 1 to 100; defaults to 25 |
| Name | Required | Description |
|---|---|---|
| saved | Yes | |
| status | Yes | |
| fetched | Yes | |
| topIdeas | Yes | |
| newCandidates | Yes | |
| sourceErrorCount | Yes | |
| duplicatesSkipped | Yes | |
| topIdeasTruncated | Yes | |
| alreadyPublishedSkipped | Yes | |
| sourceErrorDetailsSuppressed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, openWorldHint, readOnlyHint=false and idempotentHint=false. The description adds genuinely new context beyond those flags: external fetching, paid-AI scoring cost, and that only ideas passing a threshold are persisted. It does not address idempotency or repeat-run behavior, which is the one gap.
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 tight sentences with the trigger condition front-loaded, followed by mechanism and exclusion. The return-shape clause ('counts and up to 5 of the saved ideas') is slightly redundant with the output schema, but costs little.
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 7 parameters, nested sources object, an output schema, and rich annotations, the description covers the trigger, the exclusion, and the write/cost behavior an agent must know before calling. Only the non-idempotent re-run consequences are left implicit and are partly covered by annotations.
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 defaults, ranges, and the per-run vs saved-sources distinction are all documented in the schema. The description adds nothing about parameter semantics beyond noting the save threshold implicitly ('those that pass'), so baseline 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?
States a specific action (find/fetch new topic ideas) with named sources (Reddit or RSS feeds) and the pipeline it runs (fetch, AI-score, save passing candidates). The closing 'Not for ideas already saved' separates it from list_topic_ideas without the agent opening either schema.
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 a clear trigger condition ('when someone asks for new blog topic ideas from Reddit or RSS feeds') and an explicit exclusion ('Not for ideas already saved'). It does not name the sibling to use instead (list_topic_ideas), so routing requires a small inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to see their blog posts, drafts or published articles, optionally for one blog, language or slug. Returns id, title, language, slug and published state, most recently edited first, 25 per page by default with a cursor. It filters by those fields and does not search the text. Not for reading a post.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Only the post with this exact slug | |
| limit | No | Posts per page, from 1 to 100; defaults to 25 | |
| blogId | No | Only posts in this blog | |
| cursor | No | The nextCursor of the previous page with the same filters; absent for the first page | |
| locale | No | Only posts in this language, an ISO 639-1 code such as en or it | |
| published | No | "true" for published posts only, "false" for drafts only; omit for both |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| hasMore | Yes | |
| nextCursor | Yes | Cursor for the next page; null on the last page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and closed-world, so the safety profile is covered; the description adds genuinely new behavior: return fields, sort order ('most recently edited first'), default page size of 25 with cursor pagination, and the key limitation that it filters by fields rather than searching text.
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 sentences, zero padding, front-loaded with the trigger condition, then return/pagination behavior, then the exclusion. Every clause carries 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?
With an output schema present, the description need not enumerate return values, yet it still previews the key fields and result ordering. Together with the annotations and full schema coverage, an agent has everything needed to call and interpret this 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?
Schema coverage is 100% so the baseline is 3, but the description adds semantics beyond the schema: it explains that filtering is field-based and not full-text, restates the 25-per-page default with a cursor, and groups the filterable fields (blog, language, slug) so the agent understands the filter model.
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 (search/filter) and resource (blog posts) with scope: drafts or published articles, optionally narrowed by blog, language or slug. It clearly distinguishes itself from get_article by naming the exclusion 'Not for reading a 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?
Opens with an explicit trigger ('Use this when someone asks to see their blog posts, drafts or published articles') and closes with an explicit non-use case ('Not for reading a post'), routing the agent to get_article instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to mark a topic idea as used, dismiss it, or bring it back as new. Returns the idea with its new status and, when given, the article it produced; nothing else about the idea changes. Not for editing an idea's title or angle.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | New status: new, used or dismissed | |
| topicIdeaId | Yes | Topic idea id | |
| usedForArticleId | No | Id of the article written from this idea; only with status used |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| topicIdea | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnly=false, destructive=true, idempotent=true), so the bar is lower, and the description still adds real value: it says only the status changes ('nothing else about the idea changes') and that the returned idea includes the produced article when applicable. It does not contradict the destructive hint, though it could more explicitly note that dismissal is a state change requiring the idea to exist.
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, zero filler, with the primary use case front-loaded before the return behavior and the exclusion. Every clause 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?
An output schema exists, so return values need not be spelled out, yet the description still summarizes them usefully. Combined with the annotations covering safety/idempotency, an agent has everything needed to invoke this three-parameter mutation 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?
Schema description coverage is 100%, with the status enum and the 'only with status used' constraint on usedForArticleId already documented, so the baseline is 3. The description only echoes the conditional article parameter ('when given, the article it produced') without adding format or id-validation detail beyond the schema.
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 (mark a topic idea used/dismissed/reverted to new) and names the object in the same breath. It also delineates scope against the nearest alternative behavior ('Not for editing an idea's title or angle'), so an agent can distinguish it from update-style siblings without opening the schema.
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 triggering conditions ('when someone asks to mark ... used, dismiss it, or bring it back as new') and an explicit exclusion ('Not for editing an idea's title or angle'). It stops short of naming a sibling tool to route editing requests to, so it is clear but not fully routing-complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to choose which subreddits or RSS feeds their blog's topic research reads. Returns the saved sources; each list passed replaces the old one, and clear removes them all. Not for fetching ideas now.
| Name | Required | Description | Default |
|---|---|---|---|
| rss | No | Complete new list of up to 20 HTTPS RSS or Atom feed URLs; replaces the old list | |
| clear | No | true removes every saved source | |
| blogId | Yes | Blog id, or the blog's name | |
| No | Complete new list of up to 20 subreddit names, without /r/; replaces the old list |
| Name | Required | Description |
|---|---|---|
| blog | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable semantics beyond them: each passed list fully replaces the old one and 'clear' removes everything, and it states the return value ('the saved sources'). This exceeds annotation coverage without contradicting it.
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 tightly packed sentences with no filler: usage condition first, then replacement/clear behavior. Every sentence earns its place, though the prose could be slightly more compact.
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?
An output schema exists so return values need not be detailed, yet the description still notes it returns saved sources. Combined with replacement semantics and the explicit exclusion, an agent has what it needs to invoke this 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?
Schema description coverage is 100%, so the baseline is 3. The description's replacement semantics ('each list passed replaces the old one') broadly mirror what the schema already says for rss, reddit, and clear, adding little that isn't already structured.
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 action (choose which subreddits or RSS feeds topic research reads) with the resource being the blog's topic research sources. It's clear, though it phrases the verb indirectly as a user request scenario rather than as an operation name.
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 a clear triggering scenario ('when someone asks to choose which subreddits or RSS feeds...') and an explicit exclusion ('Not for fetching ideas now'), which steers the agent toward refresh_topic_ideas. The alternative isn't named explicitly, keeping it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to see how one blog post looks, with its status and details. Returns a preview card with the post's title, language, published state, metadata and up to 6,000 characters of content. Not for finding posts.
| Name | Required | Description | Default |
|---|---|---|---|
| articleId | Yes | Polyblog article id to preview, at most 200 characters |
| Name | Required | Description |
|---|---|---|
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds genuine behavioral value by disclosing the truncation limit (up to 6,000 characters of content) and the field set returned, which no annotation conveys.
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 tight sentences, front-loaded with the usage trigger before the return description, with no filler. The mid-sentence enumeration of returned fields partly overlaps the output schema, which costs a little efficiency but still aids quick scanning.
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?
An output schema exists, so the description needn't detail return values, yet it still summarizes them for orientation. With read-only annotations, a single fully-documented parameter and a clear usage clause, everything needed to invoke correctly is 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% for the single articleId parameter, whose length constraints are already documented in the schema. The description adds no syntax, format or sourcing guidance beyond that, so the baseline 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 states a specific verb+resource: previewing a single blog post, along with its status and details. It clearly distinguishes from discovery tools with 'Not for finding posts'. However it never differentiates from the sibling get_article, which an agent would plausibly confuse with a preview action.
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?
'Use this when someone wants to see how one blog post looks' gives a clear triggering condition, and 'Not for finding posts' is an explicit exclusion. It stops short of naming the alternative (e.g. get_article for full article data), so the guidance is contextual but not fully routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a quick overview of one of their blogs. Returns an overview card with the blog's domain, languages and up to 10 most recently edited posts. Not for translation coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| blogId | Yes | Polyblog blog id to render, at most 200 characters |
| Name | Required | Description |
|---|---|---|
| blog | Yes | |
| articles | Yes | |
| hasMoreArticles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds real context: the response is a summary card bounded at 10 posts, which tells the agent this is a lightweight/truncated view rather than a full listing. It does not mention pagination or whether the 10-post cap is configurable.
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 sentences, front-loaded with the use case, then the return shape, then the exclusion. Every sentence carries information, though 'Use this when someone wants' is slightly filler-heavy where a tighter trigger phrasing would do.
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 single-parameter read tool with an output schema, the description need not explain return values in depth, and the summary it does give ('overview card', 10-post cap) is sufficient orientation. Nothing critical for correct invocation 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?
There is a single parameter (blogId) with 100% schema description coverage, so the schema fully documents it. The description adds no syntax, format, or sourcing detail for blogId beyond what the schema already provides, making the baseline 3 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?
States a specific verb and resource ('quick overview of one of their blogs') and describes the concrete return payload: an overview card with domain, languages, and up to 10 recently edited posts. The trailing 'Not for translation coverage' separates it from get_blog_localization_summary, which an agent would otherwise plausibly confuse it with.
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?
'Use this when someone wants a quick overview' gives a clear triggering condition, and 'Not for translation coverage' supplies an explicit exclusion. It stops short of naming the sibling tool (e.g., get_blog_localization_summary) that should be used instead, so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to change a blog post's title, text, summary, slug, author or categories, or to publish or unpublish it. Returns the updated post; only the fields passed change, and each edit notifies the blog's webhooks. Not for adding a translation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the post to change | |
| slug | No | New URL slug, up to 300 characters; changes the post's URL | |
| title | No | New title, up to 300 characters | |
| author | No | New author name, up to 200 characters | |
| format | No | markdown or html, describing how content is written | |
| content | No | New body in the post's format, up to 100,000 characters; replaces the whole body | |
| published | No | true publishes the post, false turns it back into a draft | |
| categories | No | Complete new list of up to 50 categories; replaces the old list | |
| description | No | New summary, up to 1,000 characters |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing partial-update semantics ('only the fields passed change'), the return value, and the side effect that each edit notifies the blog's webhooks. The webhook disclosure meaningfully explains the openWorldHint=true and non-idempotent nature, and the partial-update note softens the destructiveHint=true by clarifying scope.
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 tight sentences: invocation trigger, behavior/return, exclusion. Everything is front-loaded and every clause carries information an agent needs.
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 a rich schema and an output schema present, the description only needs to cover routing and mutation behavior, both of which it handles fully. Nothing required to call this tool correctly 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%, so every parameter is already documented in the schema. The description names the same editable fields but adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline 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?
States a specific verb (change/edit) and resource (blog post) and enumerates the exact editable fields plus publish/unpublish. The closing exclusion ('Not for adding a translation') further separates it from list_article_translations and other siblings.
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 an explicit trigger ('Use this when someone asks to change...') and an explicit when-not ('Not for adding a translation'). The agent has a clear routing rule without needing to open any schema.
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.
search_articles2 fields changedOutput schema / properties / items / items / properties / coverUrlAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / items / items / requiredPrevious value: -[
- "id",
- "title",
- "locale",
- "slug",
- "published"
-]New value: +[
+ "id",
+ "title",
+ "locale",
+ "slug",
+ "published",
+ "coverUrl"
+]create_blog4 fields changedOutput schema / properties / blog / properties / coverUrl / $refAdded value: +"#/properties/blog/properties/logoUrl"Output schema / properties / blog / properties / coverUrl / anyOfRemoved value: -[
- {
- "maxLength": 2048,
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / blog / properties / logoUrlAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / blog / requiredPrevious value: -[
- "id",
- "name",
- "customDomain",
- "defaultLocale",
- "locales",
- "localesTruncated",
- "coverUrl",
- "created",
- "edited"
-]New value: +[
+ "id",
+ "name",
+ "customDomain",
+ "logoUrl",
+ "defaultLocale",
+ "locales",
+ "localesTruncated",
+ "coverUrl",
+ "created",
+ "edited"
+]get_blog1 field changedOutput schema / properties / blog / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "coverUrl": {
- "anyOf": [
- {
- "maxLength": 2048,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "created": {
- "anyOf": [
- {
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "customDomain": {
- "anyOf": [
- {
- "maxLength": 300,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "defaultLocale": {
- "anyOf": [
- {
- "maxLength": 50,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "edited": {
- "$ref": "#/properties/blog/anyOf/0/properties/created"
- },
- "id": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "locales": {
- "items": {
- "maxLength": 50,
- "type": "string"
- },
- "maxItems": 100,
- "type": "array"
- },
- "localesTruncated": {
- "type": "boolean"
- },
- "name": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "id",
- "name",
- "customDomain",
- "defaultLocale",
- "locales",
- "localesTruncated",
- "coverUrl",
- "created",
- "edited"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "coverUrl": {
+ "$ref": "#/properties/blog/anyOf/0/properties/logoUrl"
+ },
+ "created": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "customDomain": {
+ "anyOf": [
+ {
+ "maxLength": 300,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "defaultLocale": {
+ "anyOf": [
+ {
+ "maxLength": 50,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "edited": {
+ "$ref": "#/properties/blog/anyOf/0/properties/created"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "locales": {
+ "items": {
+ "maxLength": 50,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "type": "array"
+ },
+ "localesTruncated": {
+ "type": "boolean"
+ },
+ "logoUrl": {
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "customDomain",
+ "logoUrl",
+ "defaultLocale",
+ "locales",
+ "localesTruncated",
+ "coverUrl",
+ "created",
+ "edited"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]list_blogs2 fields changedOutput schema / properties / items / items / properties / logoUrlAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / items / items / requiredPrevious value: -[
- "id",
- "name",
- "customDomain"
-]New value: +[
+ "id",
+ "name",
+ "customDomain",
+ "logoUrl"
+]open_polyblog2 fields changedOutput schema / properties / items / items / properties / logoUrlAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / items / items / requiredPrevious value: -[
- "id",
- "name",
- "customDomain"
-]New value: +[
+ "id",
+ "name",
+ "customDomain",
+ "logoUrl"
+]open_polyblogcreate_article11 fields changedInput schema / properties / author / descriptionAdded value: +"Author name shown on the post, up to 200 characters"Input schema / properties / blogId / descriptionPrevious value: -"Target blog id"New value: +"Blog to add the post to"Input schema / properties / categories / descriptionAdded value: +"Up to 50 category names, each up to 100 characters"Input schema / properties / content / descriptionPrevious 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"Input schema / properties / description / descriptionAdded value: +"Short summary shown in listings and search results, up to 1,000 characters"Input schema / properties / format / descriptionAdded value: +"markdown or html; content is treated as HTML when omitted"Input schema / properties / locale / descriptionAdded value: +"Post language, an ISO 639-1 code such as en or it; required with originalArticleId"Input schema / properties / originalArticleId / descriptionPrevious 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."Input schema / properties / published / descriptionAdded value: +"true publishes the post on the blog; false or omitted keeps it a draft"Input schema / properties / slug / descriptionAdded value: +"URL slug such as my-first-post, up to 300 characters"Input schema / properties / title / descriptionAdded value: +"Post title, 1 to 300 characters"create_blog5 fields changedInput schema / properties / articlesFormat / descriptionAdded value: +"Format for the blog's posts: markdown or html"Input schema / properties / defaultLocale / descriptionPrevious value: -"ISO 639-1 code the blog writes in by default, e.g. \"en\""New value: +"Main language, an ISO 639-1 code such as en"Input schema / properties / description / descriptionAdded value: +"Short description of what the blog is about, up to 600 characters"Input schema / properties / locales / descriptionPrevious value: -"ISO 639-1 codes the blog publishes translations in"New value: +"Every language the blog publishes in, ISO 639-1 codes such as en and it"Input schema / properties / name / descriptionPrevious value: -"Blog name; also becomes the public <name>.polyblog.io subdomain and must be globally unique"New value: +"Blog name, which becomes the public <name>.polyblog.io subdomain and has to be globally unique"delete_article2 fields changedInput schema / properties / id / descriptionPrevious value: -"Article id to delete"New value: +"Id of the original post (its originalArticleId); every language version of it is deleted"Output schema / properties / articleId / descriptionAdded value: +"The id passed in. The API deletes every article whose originalArticleId equals it, so a translation id deletes nothing even though status is deleted."generate_article7 fields changedInput schema / properties / autoPublish / descriptionPrevious value: -"Publish immediately. Default false (saves as draft)."New value: +"true publishes the post immediately; defaults to false, a draft"Input schema / properties / blogId / descriptionPrevious value: -"Target blog id"New value: +"Blog to write for"Input schema / properties / locale / descriptionPrevious value: -"Locale code (defaults to blog defaultLocale)."New value: +"Language of the post, an ISO 639-1 code; defaults to the blog's default locale"Input schema / properties / persist / descriptionPrevious value: -"Save to Mongo. Default true. Set false for a dry-run preview."New value: +"false returns a preview without saving anything; defaults to true"Input schema / properties / sitemapMaxUrls / descriptionPrevious value: -"Max sitemap URLs to feed the LLM as the allowed internal-link pool (default 150)."New value: +"How many sitemap URLs to offer as internal links, from 1 to 500; defaults to 150"Input schema / properties / topic / descriptionPrevious value: -"Topic to write about. Skip if using topicIdeaId."New value: +"Title and optional angle to write about; omit when topicIdeaId is given"Input schema / properties / topicIdeaId / descriptionPrevious value: -"Use a previously-saved topic idea instead of supplying topic.title."New value: +"Saved topic idea to write about; omit when topic is given"get_article2 fields changedInput schema / properties / idOrSlug / descriptionPrevious value: -"Article id or slug"New value: +"Article id, or its slug together with locale"Input schema / properties / locale / descriptionPrevious value: -"Locale to disambiguate when looking up by slug"New value: +"Language of the post, an ISO 639-1 code such as en; needed when looking up by slug"get_blog1 field changedInput schema / properties / idOrName / descriptionPrevious value: -"Blog id (uuid) or name"New value: +"Blog id, or the blog's name"get_blog_localization_summary2 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Polyblog blog id or name to audit"New value: +"Blog id, or the blog's name"Output schema / properties / sample / descriptionAdded value: +"Coverage is computed from the 100 most recently edited posts; truncated means the blog has more"get_sitemap_urls9 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Target blog id"New value: +"Blog whose sitemap to read"Input schema / properties / locale / descriptionPrevious value: -"Two-letter locale to filter by (e.g. \"en\")"New value: +"Only URLs in this language, a two-letter code such as en"Input schema / properties / maxUrls / descriptionPrevious value: -"Cap on URLs returned (default 500, max 2000)"New value: +"How many sitemap URLs to read and count, from 1 to 2,000; defaults to 500, and only the first 25 are listed"Output schema / properties / returned / $refRemoved value: -"#/properties/childSitemaps"Output schema / properties / returned / descriptionAdded value: +"How many sitemap URLs were read, at most maxUrls"Output schema / properties / returned / maximumAdded value: +9007199254740991Output schema / properties / returned / minimumAdded value: +0Output schema / properties / returned / typeAdded value: +"integer"Output schema / properties / sample / descriptionAdded value: +"The first 25 URLs read; returned counts every URL read"list_article_translations2 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Optional blog id. When given, the reply also lists the blog locales that are still missing a translation."New value: +"Blog id; when given, the result also lists the blog languages that still lack this post"Input schema / properties / originalArticleId / descriptionPrevious value: -"Original article id — the id of the source-locale article; every translation shares it"New value: +"Id of the original article that every translation shares, as reported on each of its versions"list_blogs3 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The nextCursor of the previous page; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Blogs per page, from 1 to 100; defaults to 25"Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"list_topic_ideas6 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Target blog id"New value: +"Blog whose ideas to list"Input schema / properties / cursor / descriptionAdded value: +"The nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Ideas per page, from 1 to 100; defaults to 25"Input schema / properties / minScore / descriptionPrevious value: -"Minimum LLM score (0-10) to include"New value: +"Only ideas with at least this AI score, 0 to 10"Input schema / properties / status / descriptionPrevious value: -"Filter by lifecycle status (default: all)"New value: +"Only ideas with this status: new, used or dismissed; omit for all"Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"refresh_topic_ideas7 fields changedInput schema / properties / audience / descriptionPrevious value: -"Audience description. Defaults to the blog `context` field if omitted."New value: +"Who the blog writes for; defaults to the blog's context"Input schema / properties / blogId / descriptionPrevious value: -"Target blog id"New value: +"Blog to find ideas for"Input schema / properties / limitPerSource / descriptionPrevious value: -"Max items fetched per source (default 25)"New value: +"Items to read from each source, from 1 to 100; defaults to 25"Input schema / properties / minScore / descriptionPrevious value: -"Minimum LLM score (0-10) to keep a candidate (default 5)"New value: +"Lowest AI score, 0 to 10, an idea needs to be saved; defaults to 5"Input schema / properties / perSourceCap / descriptionPrevious value: -"Cap on scored candidates per source (default: no cap)"New value: +"Most candidates to score from each source, from 1 to 100; no cap by default"Input schema / properties / sinceHours / descriptionPrevious value: -"Lookback window in hours (default 168 = 7 days)"New value: +"How far back to read, in hours, from 1 to 8,760; defaults to 168 (7 days)"Input schema / properties / sources / descriptionPrevious value: -"Override the blog topicSources. If omitted, the blog `topicSources` field is used."New value: +"Subreddits and RSS feeds for this run only; the blog's saved sources when absent"search_articles7 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Filter to a specific blog"New value: +"Only posts in this blog"Input schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Posts per page, from 1 to 100; defaults to 25"Input schema / properties / locale / descriptionPrevious value: -"ISO 639-1 locale code, e.g. \"en\", \"it\""New value: +"Only posts in this language, an ISO 639-1 code such as en or it"Input schema / properties / published / descriptionPrevious value: -"Filter by published state"New value: +"\"true\" for published posts only, \"false\" for drafts only; omit for both"Input schema / properties / slug / descriptionPrevious value: -"Exact slug match"New value: +"Only the post with this exact slug"Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"set_topic_idea_status3 fields changedInput schema / properties / status / descriptionPrevious value: -"New lifecycle status for the topic idea"New value: +"New status: new, used or dismissed"Input schema / properties / topicIdeaId / descriptionPrevious value: -"Topic idea id from `list_topic_ideas`"New value: +"Topic idea id"Input schema / properties / usedForArticleId / descriptionPrevious value: -"Article id this idea produced; only meaningful with \"used\""New value: +"Id of the article written from this idea; only with status used"set_topic_sources4 fields changedInput schema / properties / blogId / descriptionPrevious value: -"Target blog id or name"New value: +"Blog id, or the blog's name"Input schema / properties / clear / descriptionPrevious value: -"Remove the topicSources field entirely."New value: +"true removes every saved source"Input schema / properties / reddit / descriptionPrevious value: -"Subreddit names (without /r/). Replaces the existing list."New value: +"Complete new list of up to 20 subreddit names, without /r/; replaces the old list"Input schema / properties / rss / descriptionPrevious value: -"Full RSS / Atom feed URLs. Replaces the existing list."New value: +"Complete new list of up to 20 HTTPS RSS or Atom feed URLs; replaces the old list"update_article9 fields changedInput schema / properties / author / descriptionAdded value: +"New author name, up to 200 characters"Input schema / properties / categories / descriptionAdded value: +"Complete new list of up to 50 categories; replaces the old list"Input schema / properties / content / descriptionAdded value: +"New body in the post's format, up to 100,000 characters; replaces the whole body"Input schema / properties / description / descriptionAdded value: +"New summary, up to 1,000 characters"Input schema / properties / format / descriptionAdded value: +"markdown or html, describing how content is written"Input schema / properties / id / descriptionPrevious value: -"Article id to update"New value: +"Id of the post to change"Input schema / properties / published / descriptionAdded value: +"true publishes the post, false turns it back into a draft"Input schema / properties / slug / descriptionAdded value: +"New URL slug, up to 300 characters; changes the post's URL"Input schema / properties / title / descriptionAdded value: +"New title, up to 300 characters"show_article_preview3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"show_blog_overview3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_article1 field changedInput schema / properties / idOrSlug / descriptionPrevious value: -"Article id (uuid) or slug"New value: +"Article id or slug"create_articlecreate_blogdelete_articlegenerate_articleget_articleget_blogget_blog_localization_summaryget_sitemap_urlslist_article_translationslist_blogslist_topic_ideasrefresh_topic_ideassearch_articlesset_topic_idea_statusset_topic_sourcesshow_article_previewshow_blog_overviewupdate_article
Add one secure layer between your agents and this server.