ChimpanSEO

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds real behavioral detail beyond them: scope is limited to the homepage, execution is synchronous and takes a few seconds, and findings carry actionable tips rather than bare pass/fail. It does not cover failure behavior for unreachable sites, but the added context is substantive.

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 core action, then the checklist, then the differentiator (actionable tips) and the speed promise. Every element earns its place, though the long enumerated checklist makes the first sentence dense.

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 no output schema, the description appropriately characterizes the return ('each finding includes a concrete tip'), defines scope (homepage-only), and sets timing expectations. Missing only edge-case behavior such as unreachable sites or how results are scoped/limited, which is minor for a single-parameter read 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?

Only one parameter (siteId) and the schema already documents it at 100% coverage ('Site id, from list_sites'). The description contributes nothing further about the parameter, so the baseline of 3 is correct when the schema carries the load.

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 and resource ('fetches the site's homepage and checks on-page technical SEO factors') and it enumerates exactly what is measured (title/meta, canonical, H1, viewport, HTTPS, Open Graph, JSON-LD, alt coverage, indexability, response time). No sibling tool performs an audit, so the agent can distinguish this immediately.

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?

Usage is only implied — an agent infers it audits one site after list_sites. There is no explicit when-to-use, no stated alternatives, and no exclusions (e.g., that it only checks the homepage, not a full crawl, which is set indirectly inside the purpose sentence). The 'no background job needed' remark hints it contrasts with async siblings like get_generation_status but does not name them.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely non-redundant behavior: cancellation succeeds regardless of current status, meaning an already-published slot can be removed — that is a subtle destructive consequence the annotations alone do not convey.

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 action and its source are front-loaded in the first clause, with the caveat following in a parenthetical. It is slightly dense with two cross-references, but every clause carries actionable information.

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

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

For a single-parameter destructive mutation with annotations and no output schema, the description supplies the key caveat an agent needs (status-agnostic removal) plus the source of the id. It does not state a return value, but with no output schema that omission 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?

There is a single parameter with 100% schema description coverage, and the schema already explains that scheduledArticleId comes from list_scheduled_articles or schedule_article. The description's pointer to the same source adds no new 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?

The description states a specific verb and resource — removing a slot from the editorial calendar — and ties it to the sibling that surfaces those slots (list_scheduled_articles). An agent can immediately distinguish this from schedule_article or publish_article 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?

It gives clear context (equivalent to deleting from the dashboard calendar) and a concrete caveat: it works regardless of the slot's status, so verify via list_scheduled_articles' wp_post_id/article_id that it hasn't already published. It stops short of naming explicit alternative tools for the not-yet-published case, but the when-to-use caution is real guidance.

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

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

Annotations only cover the boolean safety profile; the description adds substantial context beyond that — it consumes the monthly article quota, it is non-publishing, it returns a jobId immediately rather than the article, generation takes 1-6 minutes, and polling every ~15-20s is required. Even the timeout rationale for the async redesign is disclosed.

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 purpose, constraint, and async contract in tight sentences. The trailing parenthetical about older integrations hitting a 60s client timeout is historical color that an agent does not need in order to invoke the tool correctly, so one sentence is not fully earning 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 no output schema, the description carries the return-value burden and does so: it names the jobId, the status values 'ready'/'error', and the expected latency. For a 2-param async generation tool, nothing an agent needs to call and follow up 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 both topic and siteId (including the list_sites provenance and its effect on language/tone/SEO tags) are already fully documented in the schema. The description restates 'a given topic and site' without adding syntax or format detail, 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?

States a specific verb+resource ('starts generating a new SEO/GEO-optimized article via AI') scoped to a topic and site, and explicitly contrasts itself with the sibling publish_article. An agent can distinguish this from refresh_article or get_generation_status 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?

Explicitly routes the agent: 'Does NOT publish it — call publish_article separately once you're happy with it,' and names get_generation_status plus the polling cadence and terminal states. When-to-use, what-to-do-next, and the alternative are all spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the return payload is full HTML plus metadata, which is why a separate tool exists. It doesn't mention auth or size/latency considerations, but for a read-only single-record fetch that is minor.

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?

One sentence, front-loaded with what it returns, followed immediately by the reason it exists relative to list_articles and the triggering scenarios. 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?

No output schema exists, yet the description tells the agent the response contains full HTML content and metadata, and when the result is worth acting on (pre-publish check). For a one-parameter read tool with full annotation coverage, 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% and the single articleId parameter is fully documented in the schema, including its UUID format and where to obtain it. The description's 'by id' adds nothing beyond the schema, so the 3 baseline 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 (fetch) and resource (one article's full HTML content and metadata) scoped by id. It also explicitly differentiates from the sibling list_articles, which 'deliberately omits content', so an agent can route correctly without 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?

Names the alternative and the reason to prefer this tool, plus concrete trigger scenarios: after generate_article or refresh_article, or before deciding whether to publish. That is explicit when-to-use guidance with an exclusion built in.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: it enumerates the three terminal states and what each payload contains, which is critical for a polling tool with no output schema.

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 no filler; the polling purpose and the jobId dependency are front-loaded, followed by the state/payload breakdown.

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 no output schema, the description correctly carries the burden of explaining return states and their fields. It omits polling cadence/backoff guidance, which would help an agent avoid hammering the endpoint, but nothing essential for a correct call 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 jobId parameter is fully documented with a UUID pattern. The description adds value by clarifying that the jobId may come from refresh_article as well as generate_article, whereas the schema description only mentions generate_article.

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 (poll the status of a generation job) and names the two producer tools, generate_article and refresh_article, that create the jobId. An agent can distinguish this polling tool from get_article or list_articles immediately.

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?

Clearly establishes the context: use this after a generate_article or refresh_article call, keyed by the returned jobId. It does not explicitly say when to stop polling or route to get_article once status is 'ready', but the workflow is strongly implied by the status semantics.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the pre-generation usage context, but does not disclose auth needs, rate limits, or response format beyond the listed fields. With annotations carrying the safety burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with what is checked, followed by a clear usage directive. Every clause earns its place and there is no redundancy.

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

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

For a zero-parameter, read-only tool with no output schema, the description explains exactly what information is returned (plan, limit, used, remaining) and when to call it. Annotations cover the safety profile, so nothing essential 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?

The tool takes zero parameters, so there are no parameter semantics to document. Per the rubric, a 0-param tool has a baseline of 4, and the description does not need to compensate for anything.

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 names a specific verb ('Check') and enumerates exactly what is checked: current plan, monthly article limit, articles used, and articles remaining. This clearly distinguishes it from all siblings (generation, article retrieval, publishing) which are unrelated to usage/quota.

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 trigger: 'call this before generating to use the quota consciously instead of guessing.' This tells the agent when to use it. No when-not conditions or alternatives are named, but no alternative tool exists for this purpose, so the guidance is practically complete.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive behavior, so safety is covered. The description adds the returned field set (title, status, site, link), which is useful since no output schema exists, but says nothing about ordering guarantees, pagination, or how 'most recent' is defined.

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?

One tight sentence that front-loads the verb and scope before listing the returned fields. No filler or redundancy.

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

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

For a simple read-only list tool with a fully documented single parameter and annotations covering safety, the description is nearly complete. Naming the returned fields compensates for the missing output schema, though ordering and default-limit behavior remain unstated.

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 single limit parameter (default 10, max 50) is fully documented in the schema. The description adds nothing about the limit or default behavior, 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?

States a specific verb (list) and resource (articles) scoped to 'most recent articles generated on this account', with the returned fields named. It implicitly separates itself from list_scheduled_articles and get_article, though it never names the alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. An agent must infer from the name that this lists generated articles rather than scheduled ones or a single article, with no routing to list_scheduled_articles or get_article.

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

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 usefully adds that results span past and future slots, but says nothing about ordering or how the default limit of 50 affects the view.

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 tightly written sentences with zero filler. The resource and scope come first, the usage rule second, so an agent gets the essential information immediately.

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 two-parameter read-only listing with no output schema and annotations covering safety, the description is nearly sufficient. The remaining gap is how results are bounded and ordered, which could matter when queue times get long.

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?

Only siteId carries a schema description (50% coverage); limit is constrained in schema but not explained. The description mentions 'site' only as an output field and adds no filtering or pagination semantics beyond the schema, so it neither compensates nor regresses.

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 scheduled_article slots') and enumerates the returned fields (topic, target date, status, site), including the past/future scope. This separates it cleanly from the sibling list_articles, which is a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit call-site rule: use this before schedule_article to see what's queued and avoid duplicate dates/topics. It does not, however, say when to prefer it over list_articles or note that past slots are included for historical checking.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds useful behavioral context by disclosing the platform scope (WordPress/Framer/Webflow) and the exact fields returned, which matters because there is no output schema. It does not mention ordering or whether there could be many sites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the verb and resource, then packs scope and return fields without waste. 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?

For a no-argument listing tool with full annotation coverage, the description supplies what annotations and the empty schema cannot: the platform scope and the returned field set, compensating for the absent output schema. Minor gaps (ordering, pagination, whether unconnected sites are filtered) are acceptable at this complexity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-argument tool is 4. The description correctly avoids inventing filter semantics.

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 ('sites'), scopes it to the ChimpanSEO account, and enumerates the platforms and returned fields (id, name, url, platform, language). No sibling tool (audit_site, list_articles, etc.) lists sites, so the agent can distinguish this immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance or mention of alternatives, but the intent is strongly implied: it is the natural first step to obtain site ids needed by audit_site, generate_article, and the other site-scoped siblings. Adequate but leaves the routing inference to the agent.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds useful platform scoping and the draft-vs-publish choice, but says nothing about side effects, permissions, or what publishing overwrites on the target site.

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 action and its draft variant come first, then the platform restriction. Every clause carries information, including the (Beta) qualifier that explains why the exclusion exists.

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 three-parameter mutation tool with no output schema and full annotation coverage, the description supplies the essential preconditions (article must be pre-generated, WordPress-only). It omits any note about the response or what happens to the published post, but nothing critical to 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?

Schema coverage is 67%, with siteId and articleId already documented in the schema (including the generate_article/list_articles provenance hint). The description only implicitly maps to the status parameter via 'or save as draft' and adds no format or default details beyond the schema's enum and default.

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 (publish) plus resource (article) and the target platform (WordPress), and clarifies the draft alternative. It does not distinguish itself from the close sibling schedule_article, which an agent could easily confuse with immediate publishing.

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 when-not condition: WordPress only, Framer/Webflow unsupported. It also implies the article must already exist ('previously generated'). It stops short of routing to alternatives such as schedule_article for future-dated publishing.

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

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

Beyond the destructive/openWorld annotations, it discloses the key side effect an agent must know: published articles get automatically re-published to WordPress with title and status unchanged. It also reveals the async contract (immediate jobId, poll get_generation_status, 1-4 minute latency), which the annotations do not cover.

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 core action and its effects, then a clearly labelled ASYNC line for the async contract. Every sentence carries operational 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 mutation with no output schema, the description covers everything an agent needs: what changes, the external re-publish side effect, and how to follow up on the async job. 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 description coverage is 100% and articleId is fully documented in the schema (including its list_articles source), so the description adds nothing about parameters. Baseline 3 applies since the schema carries the full burden.

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 gives a precise verb+resource ('Rewrites an existing article') and enumerates the concrete changes it makes (dates/stats/examples, headings, FAQ, +300 words). It also anchors to a known UI action, making it immediately distinguishable from sibling generate_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?

Usage is implied by 'existing article' and by the WordPress re-publish branch, and it routes the caller to get_generation_status for polling. However, it never explicitly states when to choose refresh_article over generate_article or when not to use it.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, closed-world), so the description only needs to add context — and it does: it discloses the entitlement requirement (scheduling-enabled plan) and that scheduled items land on the same editorial calendar the dashboard shows. It does not address duplicate-schedule behavior, which matters given idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; the core action and scope come first and the prerequisite follows. 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?

For a non-idempotent mutation tool with no output schema, the definition covers the action and the plan prerequisite but omits what happens on duplicate scheduling, what the caller gets back, and the draft-vs-publish consequence. Adequate but with clear gaps for a 5-parameter write operation.

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 only 40% schema description coverage, the description carries extra burden: it conveys that 'topic' is the subject to generate and that 'scheduledFor' must be a future date/time, reinforcing the schema. However, it says nothing about 'dualLanguage' or how 'publishStatus' (draft vs publish, default publish) changes the outcome, leaving two of five parameters to the bare 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 ('Schedule a topic to be generated and auto-published at a future date/time on a WordPress site') and scopes it to the future, which implicitly separates it from generate_article and publish_article. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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 real prerequisite ('Requires a plan with scheduling enabled') that tells the agent when the call will succeed. It gives no guidance on when to prefer this over generate_article or publish_article, so the usage context is only implied by the word 'future'.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's value-add is the latency disclosure ('fast — a few seconds, not a background job') and the output bias (experiment/case-study angle, informed by site differentiators). It does not state whether results are cached or rate-limited, which keeps it 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?

Two sentences, front-loaded with purpose then usage, and the latency caveat is placed at the point of decision. The middle clause about the experiment/case-study bias is slightly dense but earns its place by describing output character.

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?

Usage, latency and output character are well covered for a read-only generation tool, but there is no output schema and the description never says what a 'topic suggestion' actually is (title only, title plus rationale, structured object). That is the one remaining gap.

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 siteId, count and creativity including ranges and defaults. The description adds no parameter-level syntax or format detail beyond what the schema 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 ('Generates topic suggestions for a site's next articles') and immediately frames the output as distinct from the sibling content-creation tools. The mention of the dashboard's topic generator and the experiment/case-study bias lets an agent tell this apart from generate_article without 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?

Explicitly says to use this 'before generate_article or schedule_article instead of inventing topics yourself', naming both the alternative tools and the condition that selects this one. No inference required.

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