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

With no annotations, the description carries the full disclosure burden, and it delivers little. 'Local' usefully implies no external service call, but it does not say whether the tool mutates anything, what a failed or passing check looks like, or how results are surfaced. For a validation tool with zero annotation coverage this is a meaningful 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?

A single front-loaded sentence with no filler, and the purpose leads. It is arguably too terse for a six-parameter tool, but nothing in the sentence is wasted.

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?

Six parameters, no schema descriptions, no annotations, and no output schema, so the agent has to infer both the check semantics and the response shape entirely from one sentence. The description should at minimum say what is checked and what the caller gets back; neither 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 0% across six parameters, so the schema supplies only names and types. The description refers generically to 'draft fields' without clarifying which of title, content, excerpt, seoTitle, coverImage, or seoDescription are evaluated, why title and content are required, or how seoTitle relates to title. It does not compensate for the coverage gap.

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 specific verb and object: running an SEO check against draft fields. It also anchors the activity to the publishing workflow ('before manual publishing'), which hints at its role among the draft tools. It stops short of differentiating itself from siblings like get_article_draft or update_article_draft, and never says what the check actually returns or validates.

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 phrase 'before manual publishing' implies the moment to invoke it, but there is no explicit when-to-use versus alternatives, no prerequisites, and no note on what to do if the check fails. Usage is suggested rather than stated.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose one non-obvious side effect: a temporary image URL is automatically uploaded and converted into the permanent cover image. It says nothing about required permissions, whether the draft is immediately published or private, what happens on slug collision, or whether fields are validated.

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, front-loaded with the core action and then the image-upload tip. No filler or repetition, though the brevity is partly under-specification rather than deliberate economy.

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 16 parameters, 0% schema coverage, no annotations, and no output schema, the description is far too thin for the tool's complexity. An agent cannot confidently populate most optional fields or predict the return value from this definition alone.

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 0% across 16 parameters, so the description is the only source of parameter meaning — and it explains just one of them (temporaryCoverImageUrl). It never clarifies the relationship or difference between coverImage and temporaryCoverImageUrl, nor what linkPolicy, imagePrompt, categoryId, authorRole, or canonicalUrl do.

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 ('Create a completed article draft'), so the agent knows this is a creation/authoring tool. It does not distinguish itself from the sibling update_article_draft or explain why one would create a draft here versus elsewhere, so it stops short of the top score.

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 one concrete usage instruction — pass a temporary image URL here to have it uploaded and attached — which is genuinely useful routing for that parameter. However, it offers no guidance on when to use create_article_draft versus update_article_draft, no prerequisites (e.g. needing a siteSlug from list_publications), and no mention of what happens on an existing slug.

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?

With no annotations, the description carries the full behavioral burden. 'Get' implies a read, but there is no statement of read-only safety, permission/auth requirements, or behavior when the draft does not exist (error vs empty). For an unannotated retrieval tool this leaves meaningful gaps.

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 front-loaded sentence with no filler; the resource and scope come first. It is efficient, though extremely terse given everything left unsaid.

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 means the description should explain what a 'draft' return contains, and no annotations means behavior must be disclosed; neither is done. With two undocumented required params and no return-value context, the definition is under-specified for a retrieval 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 0% and both required parameters (siteSlug, postSlug) are only self-descriptive by name. The description does not explain that these identify the target draft, what format slugs take, or whether the values are case-sensitive, so it fails to compensate for the coverage gap.

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 ('Get'), a specific resource ('NexusPress article draft'), and a qualifier ('existing'), which distinguishes it from create_article_draft and update_article_draft. It does not explicitly address the list_publications/categories siblings, so sibling differentiation is only partial.

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 phrase 'for review' hints at intent but gives no explicit when-to-use guidance. Nothing tells the agent how this differs from list_publications or when a draft should be fetched rather than listed or checked via check_draft_seo.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read via 'List' but does not state whether results are paginated, ordered, cached, or what happens if the publication has no categories. For a no-annotation tool this is a significant 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?

A single front-loaded sentence with no filler. It is appropriately sized for a simple list operation, though the economy comes at the cost of detail rather than from dense 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 one required parameter, no annotations, and no output schema, the description should at minimum clarify the scope key (siteSlug) and basic return behavior. Neither is present, so it is thin for even a simple lookup 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 0% for the single required parameter 'siteSlug'. The description mentions 'one NexusPress publication', which loosely hints at the scoping parameter, but never explains that siteSlug identifies the publication or what format it takes. The description does not compensate for the undocumented parameter.

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 ('List') and resource ('categories') with an explicit scope ('for one NexusPress publication'). It is clear what the tool does, though it offers no differentiation from the six sibling tools (which concern publications, article drafts, and images) beyond the distinct resource 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer that this is a read-only lookup used when categories for a specific publication are needed.

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?

No annotations are provided, so the description carries the full burden. For a zero-parameter enumeration it is reasonable that nothing destructive happens, but the description never says whether results are paged, filtered, or scoped to the authenticated account, nor what a "publication site" object 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?

A single front-loaded sentence with the verb and scope stated immediately and no filler. Every word 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 trivial zero-param read with no output schema, this is minimally viable: it names the resource but says nothing about the shape of the returned sites or how the result feeds the sibling create_article_draft. A note on what identifiers the caller gets back would close the 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?

The tool takes no parameters, so there is nothing for the description to disambiguate — the baseline of 4 applies. No parameter information is missing because no parameters exist.

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?

Clear verb+resource: "List NexusPress publication sites," which is specific about what is enumerated. It does not differentiate itself from the sibling list_categories, which is also a listing tool, so the agent must infer the distinction from the resource noun alone.

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?

"available for drafting" implies the usage context (call this before creating a draft), but there is no explicit when-to-use, when-not-to-use, or named alternative among the six siblings. Usage is implied rather than stated.

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?

No annotations are provided, so the description carries the full burden. It does disclose two behaviors — dependent fields get auto-completed, and temporaryCoverImageUrl is fetched and attached — but it does not explain the core mutation semantics an agent needs: whether omitted optional fields are preserved or wiped, that title/content/siteSlug/postId must be re-sent on every update, or any permission requirements.

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 primary action is front-loaded and the image-URL tip is a well-scoped conditional follow-up. "Automatically complete dependent fields" is slightly vague for how much weight it carries, keeping it short of a 5.

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 17-parameter mutation tool with no annotations, no output schema and no parameter descriptions, the description is far too thin. An agent cannot tell what will be overwritten, which fields are mandatory on every call, or what the image auto-upload expects, so it is not equipped to invoke this correctly without guesswork.

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 0% across 17 parameters, and the description explains only one of them (temporaryCoverImageUrl), adding genuine value by tying it to the DALL-E temporary-URL workflow. The other 16 — including linkPolicy, canonicalUrl, categoryId, imagePrompt, authorRole — get no semantic help from either schema or description, a large gap at this parameter count.

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 ("Update an existing draft") and adds the side effect of completing dependent fields. It contrasts implicitly with the create_article_draft sibling through the update/file targeting (postId), but never names an alternative explicitly. Clear enough for selection, but not sibling-routing.

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: you use this when you already have a draft to modify. One useful conditional rule is given for temporaryCoverImageUrl (pass a DALL-E URL to auto-upload), but there is no guidance on when to prefer update vs create_article_draft, or what happens when only some fields are supplied.

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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the destination service (Cloudinary) and the permanence effect of the operation, but says nothing about authentication requirements, overwrite/duplicate behavior, size or source-access constraints, or what identifier comes back.

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 front-loaded sentence with zero filler; the action, the input source, and the outcome are all stated compactly.

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 and no annotations, the description should tell the agent what comes back (the permanent Cloudinary URL/ID) so it can be chained into article drafts. That return-value information is absent, and no auth or failure behavior is covered, leaving a real gap for a no-annotation, no-output-schema 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?

One parameter with 0% schema description coverage, so the schema only supplies the name 'url' and a URI format. The phrase 'temporary URL' adds real meaning (an externally hosted, likely expiring link that must be publicly fetchable) but does not specify accessibility, expiry, or format expectations.

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 (upload), resource (image), source (temporary URL), and destination (Cloudinary), with the goal of permanence stated explicitly. It is fully distinguishable from the sibling tools, none of which relate to image ingestion.

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 concrete triggering context ('temporary URL, e.g. from DALL-E') that an agent can pattern-match on when a generator returns an ephemeral link. It does not name when-not-to-use it or any alternative upload path, so it stops short of full routing guidance.

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