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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, and the description adds substantial behavior beyond them: a re-read/preflight step, mandatory hash and scope validation, a Ghost revision saved for every edit, readback verification, and fail-fast termination after the first remote failure. The fail-fast detail is especially valuable because it implies earlier edits in the batch are already committed, which the annotations 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?

One dense sentence, front-loaded with the core action and then the guards, with no filler. It is grammatically heavy (six chained clauses) but each clause conveys a distinct operational fact, so little 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?

For a destructive, up-to-25-item batch tool with an output schema present, the description covers the essential context: approval gating, hash binding, revision creation, readback and failure behavior. It does not address whether prior successful edits are rolled back on later failure, nor the concurrency meaning of target.updated_at, which is the main 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 0% on four parameters with deep nesting, so the description carries real burden. It usefully clarifies that preview_hash must be site-bound and exactly match the preview, and that scopes must match exactly, but it never explains the shape or semantics of the 'changes' array (target/operation/updated_at concurrency token) or 'user_confirmed', which the schema names only structurally.

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+resource ('Apply one approved Ghost change set') and enumerates the exact execution semantics: re-read/preflight the previewed batch, require the preview hash, save revisions, verify readback. It implicitly ties to the preview_changes sibling via 'the exact previewed batch', but it never names or contrasts that sibling, so an agent must infer the pairing.

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?

Preconditions are stated concretely: the change set must already be approved, must supply a site-bound preview hash, and must match exact approval scopes. That tells the agent when the call is valid. It does not state when NOT to use it or point to an alternative (e.g. re-run preview_changes after a mismatch), leaving one gap.

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 establish readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it does not crawl (acts only on supplied targets) and is bounded to 25 items per call. It stops short of explaining response shape, but an output schema exists, so that omission is acceptable.

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, no filler; the positive capability list comes first and the scope-limiting exclusions follow immediately. 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 read-only, bounded inspection tool with a full output schema and rich annotations, the description covers scope, limits, and exclusions. The remaining gap is parameter-level detail (required target fields), which is minor given the schema itself 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% for the single 'targets' parameter, so the description must compensate. It does clarify that targets are 'exact posts or Pages' and that the cap is 25, but it never explains the required per-item fields (id, type, updated_at) that the schema enforces, leaving the caller to read the raw 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 (Inspect) and resource (exact posts or Pages) and enumerates exactly what is checked: parseability, Lexical/card inventory, alt text, metadata, lengths, links, and a Sources/Kaynaklar heading. It also explicitly separates itself from crawling or quality scoring, so an agent can distinguish it from list_posts/get_post 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?

The description gives clear context for use: it operates on 'exact' targets supplied by the caller, capped at 25, which implies a bounded diagnostic pass rather than a search or browse. It also states what it does not do (no crawl, no quality scoring, no source judging), which implicitly rules out cases where list_posts/get_post would be more appropriate, but it never names an alternative tool or an explicit when-not condition.

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 this safe (readOnlyHint, idempotentHint, non-destructive, openWorld), so the safety bar is met elsewhere. The description adds genuinely new behavioral context: the check is non-secret-exposing and reports configured optional features, which tells the agent it can log/share results safely.

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: verb, resource, secondary output, and a security constraint, all of which earn their 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 and there are no parameters, so the description need not explain return values, and it correctly covers both the auth-verification outcome and the feature-reporting outcome. The only missing piece is guidance on when to prefer it over the related check_site_health 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?

The tool takes zero parameters and the schema is trivially complete, so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 4.

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 (verify) and resource (Ghost authentication) and adds a second concrete outcome: reporting which optional features are configured. It is clearly distinct from content-oriented siblings like get_post or list_tags, though it does not explicitly contrast itself with the similarly named check_site_health sibling.

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 by the purpose: an agent can infer it should call this to validate credentials or probe configuration. There is no explicit when-to-use framing and no mention of alternatives, notably the overlapping check_site_health sibling, so routing guidance 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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine value beyond that: it discloses the external HTTP-checking behavior (open world), the URL source (Ghost or GHOST_PUBLIC_PAGE_URL_TEMPLATE), and that checks run 'once' (no retry loop). It omits rate limits and auth requirements, keeping it below 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?

A single front-loaded sentence that leads with the verb and resource and packs the verification targets efficiently. No filler, though the constraint-heavy clause about URL templates makes it slightly 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, the undocumented required parameter and the absence of usage context leave meaningful gaps for an agent 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 0% and the single 'pages' parameter is never described in the text. The reader cannot learn from the description what the array elements (id, updated_at) are for or why updated_at is required alongside id, so the description 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?

The description names a specific verb (read/verify) and resource (current published pages) and enumerates the concrete checks performed: HTTP status, title, canonical URL, and SEO metadata. Its 'pages' scope is distinguishable from the sibling check_live_posts, though no sibling is named directly.

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 explicit when-to-use guidance, no prerequisites, and no alternatives named (e.g., check_live_posts, get_page). The agent must infer that this is a post-publish verification step from the word 'verify' alone.

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, openWorld, and non-destructive behavior, covering the safety profile. The description adds useful context that it checks URLs once and verifies HTTP status, title text, and rendered SEO metadata, but does not disclose auth needs, rate limits, timeouts, or error behavior.

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 compact sentence front-loads the action and verification targets with no redundant or filler language.

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 read-only external check with annotations and an output schema, the description is minimally adequate but has clear gaps in usage routing and parameter explanation. It tells the agent what is checked, but not when to choose it over closely related live-check siblings.

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%, so the description must carry parameter meaning. It mentions expected title text and rendered SEO metadata, but does not explain the required slug/title fields, the nested post array structure, or the maxItems/minItems constraints.

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 uses a specific verb ('Check/verify') and resource ('configured public URLs'), and the tool name/title make clear it targets posts rather than pages, distinguishing it from sibling check_live_pages. It also specifies the verification targets: HTTP status, expected title text, and supplied rendered SEO metadata.

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 description gives no explicit guidance on when to use this tool versus alternatives such as check_live_pages, check_connection, or check_site_health. The phrase 'once' implies a one-shot check but does not state conditions, prerequisites, or exclusions.

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 non-destructive, so safety is covered; the description's 'without crawling or writing' meaningfully confirms no external crawling and no state mutation, which the annotations alone don't convey. It still does not describe response behavior, but the output schema covers that.

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 listing the checks, with the constraining clause at the end. Dense but no filler sentences; it is efficient, if a bit jargon-saturated.

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 explained, and the check list is thorough. However, with zero required parameters and no explanation of the pages/posts inputs or default behavior when omitted, the description is not complete enough for an agent to call it confidently in all cases.

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 neither the pages nor posts array is mentioned in the description, so there is no semantic guidance on what these IDs represent or what happens when they are omitted (0 required params). The regex patterns document format but not meaning, leaving the description responsible for a gap it does not fill.

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 (check) and enumerates the surfaces inspected: published targets, canonicals, share prerequisites, and feature images. It is distinguishable from siblings like list_pages or check_connection, though phrases like 'server-selected Ghost and delivery surfaces' are jargon-heavy and vague.

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 'without crawling or writing' clause implies this is a non-invasive validation step, but there is no explicit when-to-use versus check_connection, check_live_posts, or check_live_pages. Usage 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-annotation context: the cross-session upload_image constraint and the 'ordered tags preserve the primary tag' side effect. It doesn't cover duplication/idempotency risk for repeated creates or rate limits, so it sits above baseline but not high.

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 filler, with the format capability front-loaded and the two hard constraints (image source, no publishing) placed after. Nothing repeats the schema or annotations verbatim.

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 the description covers the block-type breadth and the critical upload prerequisite. The only shortfall is silence on the many optional metadata fields an agent might otherwise guess at.

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%, so the description carries the burden, and it does explain the two content modes and the image-card src constraint (the highest-risk field). However, the many other post fields (slug, authors, excerpt, featured, SEO/OG/twitter metadata, canonical_url) are never mentioned, leaving a large gap at 0% 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?

States a specific verb, resource, quantity bound (1–10), and two accepted input formats (Markdown or native Ghost blocks), with an enumeration of supported block kinds. It distinguishes itself from publish_posts ('cannot publish') and from create_page_drafts (posts, not pages).

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 prerequisite ('Image-card src values must come from upload_image in this server session') and rules out publishing as an alternative route. It does not explicitly name which sibling to use when the goal is publishing, though 'cannot publish' strongly implies publish_posts.

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 mutation (readOnlyHint=false), non-idempotence, and non-destructiveness. The description adds genuinely useful behavior beyond that: status is always forced to draft, blocks must be 'bounded' native types, and image src values are session-scoped to upload_image. That session-scoping constraint in particular is not recoverable from annotations or 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?

Three tight sentences, front-loaded with the core action and count, followed by the hard constraint and the exclusion list. No filler or restatement 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?

An output schema exists, so return values need no explanation, and the description covers draft forcing, batch limits, image preconditions, and unavailable features. For a tool with this much nested schema complexity, slightly more on the blocks-vs-markdown tradeoff would help, but nothing critical 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 0% and the single top-level parameter hides a very deep nested block schema. The description partially compensates by naming the two input modes (markdown vs blocks) and the 1–10 batch bound, but it explains nothing about the allowed block types, per-block fields, or field limits that an agent must actually supply. Baseline for near-zero coverage with a complex 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 (Create), resource (pages), output state (drafts), batch size (1–10), and the two accepted input formats (Markdown or native Ghost blocks). This cleanly separates it from the sibling create_drafts, which targets a different content type.

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 exclusion list (tags, authors, templates, code injection, scheduling unavailable) gives strong negative guidance, and the image-src precondition tells the agent a prerequisite step. It stops short of explicitly naming when to prefer this over sibling create_drafts or upload_image sequencing details.

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, openWorldHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful payload context ('HTML, Lexical content, and complete SEO and social metadata'), but it does not disclose error behavior, not-found handling, or permission requirements beyond what annotations and the output schema 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?

The description is a single sentence that front-loads the verb, resource, identifier constraint, and payload contents. Every clause adds value with no redundancy or throat-clearing.

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 document return fields in detail. With annotations covering the safety profile and the schema covering the parameter structure, the description supplies enough to call the tool correctly, missing only failure/not-found context that an agent might need in edge cases.

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%, so the description must carry the parameter meaning. It does so by explaining that 'id_or_slug' accepts either an exact Ghost ID or slug, adding semantic value beyond the bare string type. It stops short of specifying slug format or case-sensitivity rules, but it compensates meaningfully 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 states a specific verb and resource ('Get one page'), scopes it to a single item, and names the accepted identifier forms ('exact Ghost ID or slug'). It also lists the returned content types, which distinguishes it from list_pages and from get_post for posts.

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 'by exact Ghost ID or slug' implies the tool is for direct retrieval when an exact identifier is known, not for discovery or search. However, it does not explicitly contrast with siblings like list_pages or get_post, nor does it state when not to use it, so guidance remains implied rather than explicit.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds that the payload includes HTML, Lexical content, and full SEO/social metadata, which is genuine behavioral context, though this partly duplicates the 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?

A single front-loaded sentence naming the action, lookup key, and payload scope with zero filler. 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 read-only single-parameter tool with an output schema and full annotation coverage, this is nearly complete. It omits edge-case behavior such as what happens when the ID/slug doesn't match any post, which would help the agent handle failures.

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 0% schema description coverage on the single parameter, the description must carry the load, and it does: it clarifies that id_or_slug accepts either a Ghost ID or a slug and that the value must be exact (no fuzzy matching). That adds real meaning beyond the bare 'string, minLength 1' 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 (Get) and resource (one post) with a clear scope of 'one' that separates it from list_posts, and names the lookup keys (Ghost ID or slug). It doesn't explicitly differentiate itself from the near-sibling get_page, but the resource noun does the work.

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: the word 'exact' signals that a precise identifier is required rather than a search, which is useful. However, no when-to-use vs when-not guidance or alternatives (e.g., list_posts, get_page) are named.

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, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds a real behavioral fact beyond them: staff email and roles are deliberately excluded from the output, and results are 'bounded'. It stops short of stating pagination/rate/auth specifics.

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; every clause (identity listing, post counts, privacy exclusion) 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?

An output schema exists, so return-value documentation is not required, and the privacy note covers output scope. However, with three undocumented parameters and no usage guidance, the definition is only minimally complete for an agent to call it confidently.

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 three parameters (page, limit, search); the schema only supplies types and defaults. The word 'bounded' loosely gestures at the limit cap but does not explain pagination, the search field's matching behavior, or the maximum of 50, so the description 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?

States a specific verb and resource ('List ... author identities and post counts'), which clearly distinguishes it from siblings like list_tags and list_posts. Scope qualifiers ('bounded', 'public') further sharpen what is returned, though it never names a sibling it is meant to replace.

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 when-to-use, when-not-to-use, or alternative tool is mentioned. The agent must infer that this is the author-listing counterpart to list_tags/list_posts purely from the name.

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 fully covered by structured data. The description adds a modest amount of context ('bounded' implies a paginated/limited result, and it names the ID and updated_at values returned), but does not detail rate limits, pagination behavior, or total counts.

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 well-formed sentence with the resource and the payoff (IDs and timestamps) front-loaded. It is not padded, though it is arguably too short given the 9-parameter surface it should document.

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-value detail is fairly excused, but with 9 undocumented optional parameters and no usage context, the description is too thin for a filter-heavy list operation. It gives an agent no basis for choosing filters or understanding result bounds.

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 9 parameters, so the description carries the full burden of explaining them. It mentions nothing about limit/page pagination, the four order options, the status enum, search, or the four date-range filters, leaving every filter's semantics 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 (list) and resource (Ghost page records) and adds a workflow motivation (obtain exact IDs plus updated_at values). This clearly separates it from mutation siblings like publish_pages or create_page_drafts, though it does not explicitly contrast with the parallel read tool list_posts, so it falls short of a 5.

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 'obtain exact IDs plus updated_at values' gestures at a use case, but there is no explicit when-to-use guidance, no when-not-to-use, and no named alternative (e.g. list_posts vs list_pages, or get_page for a single record). An agent must infer the context from the name alone.

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 genuine value beyond them by disclosing the output shape ('concise' records) and the operational purpose (fetching IDs and updated_at for subsequent mutations). It omits pagination behavior and default limits.

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 short sentences, zero waste, with the operation stated first and the workflow rationale second. Nothing is redundant or 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 and annotations exist, so return values and safety need not be explained. However, with 11 undocumented filtering/pagination parameters, the description is thin for a tool of this complexity; it should at least hint at what can be filtered.

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 11 parameters, including filters like tag, search, status, author_id, and four date bounds. The description mentions no parameter at all, so an agent must infer filter semantics entirely from bare names and enum values. This 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?

Specific verb+resource: 'List concise Ghost post records.' The word 'concise' usefully signals this returns trimmed records rather than full post bodies, distinguishing it implicitly from get_post. It does not explicitly name a sibling alternative, so it falls short of a 5.

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?

Explicit when-to-use: 'Use this before updating or publishing to obtain exact IDs and updated_at values' gives a concrete workflow context and rationale. It does not state when NOT to use it or name alternatives like get_post, so no exclusion 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only 'with post counts' as output context, and an output schema exists, so little behavioral value is added beyond 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?

A single short sentence with zero waste and the key detail (post counts) front-loaded. Nothing extraneous or buried.

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?

The output schema covers return values, but with an undocumented search/filter parameter and pagination knobs, plus no usage context, the description is too thin for an agent to call this confidently. It should at least sketch filtering and pagination behavior.

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?

All three parameters (page, limit, search) have 0% schema description coverage, and the description mentions none of them. It does not explain pagination defaults, the 50-item cap on limit, or what 'search' matches against, leaving the coverage gap unaddressed.

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 ('Ghost tags'), and adds the notable detail that results include post counts. It is clearly distinguishable from siblings like list_posts or list_authors, though it does not explicitly say so.

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 guidance on when to use this versus other listing tools, no mention of prerequisites, pagination expectations, or when not to use it. The agent must infer usage entirely from the name.

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 partly covered. The description adds real value beyond that: the plan is HMAC-bound (so it is verifiable/tamper-evident and presumably consumed later), and it explicitly disclaims emailing, deploying, and headless visibility.

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, purpose front-loaded, with the second sentence delivering only information that is not already in annotations. 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 need not be described, and the safety story is well covered. However, with four required parameters and zero schema descriptions, the missing explanation of interval_hours and the per-post object fields leaves a real gap for correct invocation.

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%, so the description must carry the load. It explains two of the four required parameters well ('ordered draft list', 'IANA local start time') and conveys the ordering constraint the schema cannot, but it never mentions interval_hours nor the id/updated_at shape of each posts item.

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 transformation: an ordered draft list plus an IANA local start time becomes exact UTC timestamps inside an HMAC-bound plan. That is clearly distinct from the write-side siblings like schedule_posts or apply_change_set, though neither is named 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?

The negative guarantees ('never writes, emails, deploys') imply this is a dry-run/planning step to run before a real scheduling action, but the description never states when to choose it over schedule_posts or apply_change_set. Usage must be inferred.

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, so the safety profile is covered. The description still adds real value: the hard 25-item limit, the fact that results are a stateless site-bound hash, and the returned approval scopes and before-snapshots. It stops short of discussing staleness or failure behavior, 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?

Two sentences, zero filler, and the read-only guarantee is front-loaded at the end where it caps the summary cleanly. Every clause adds information an agent can act on.

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 minimal narration, yet the description still names the key payload elements. For a single-parameter preview tool this is nearly complete; only the optimistic-concurrency semantics of target.updated_at are left unmentioned.

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%, so the description carries the burden; it compensates partly by conveying the 25-item cap ('up to 25 exact posts or Pages') and hinting at exact-match edits. But it explains nothing about the operation variants (update_fields, replace_body, append/prepend_section, replace_exact_text) or the updated_at concurrency precondition.

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 and resource ('Read up to 25 exact posts or Pages') and enumerates exactly what comes back (before snapshots, field/Lexical impact, approval scopes, preview hash). This is clearly distinguishable from the write-side sibling apply_change_set 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?

The closing 'This tool never writes' implies the use case (dry-run before a mutation) but never names apply_change_set or states the when-to-use/when-not condition. An agent must infer the preview-then-apply workflow on its own.

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 flag destructive/openWorld/non-idempotent, but the description adds genuinely new behavior: version-checked optimistic concurrency and a deploy hook that fires exactly once only after complete success. It does not spell out what happens on a version mismatch or partial failure, 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?

Two tight sentences with the confirmation gate and the deploy-hook side effect front-loaded. 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 a dangerous, open-world mutation with an output schema available separately, the description covers the critical safety-relevant facts: the confirmation gate, the version check, and the exactly-once side effect. Return values are handled by the output schema, 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?

With 0% schema description coverage, the description must carry the load; it hints at the pages array ('batch'), the version field ('version-checked'), and the confirmation flag. It omits the 25-item cap, the 24-hex id format, and the required updated_at on each item, so the two parameters remain only partially explained.

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 ('Publish Ghost pages') scoped as an 'exact, version-checked batch', which cleanly separates it from the sibling publish_posts and the single-page drafts tools. An agent can identify the operation and its batching nature 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 prerequisite: the call only applies after user_confirmed=true, and frames it as a batch operation. It stops short of naming alternatives (e.g., publish_posts vs publish_pages, or trigger_deploy for the hook alone), so no explicit when-not 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 already flag destructive/non-idempotent/open-world, and the description adds substantial non-obvious behavior: the deploy hook fires exactly once only after complete success, the operation is version-checked, and newsletter email is never sent. These side-effect disclosures go well beyond the annotations and directly inform safe invocation.

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 front-loaded sentences with no filler: action first, then side-effect guarantees, then the negative guarantee about newsletters. Every clause adds decision-relevant 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?

An output schema exists, so return values need not be described, and the description covers gating, atomicity of the deploy hook, and the newsletter exclusion. It stops short of clarifying partial-failure behavior or whether the batch is all-or-nothing, which matters for a destructive multi-item 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?

Schema coverage is 0%, so the description must carry the parameter burden. It explains user_confirmed as a gate and hints that entries are version-checked (implying updated_at is used for optimistic concurrency), but it never explains the posts array shape, the 24-hex id format, or the 25-item cap already visible in 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 ("Publish Ghost posts") and qualifies the scope as an "exact, version-checked batch," which cleanly separates it from publish_pages, unpublish_posts, and schedule_posts. An agent can identify the action and its nature 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 precondition ("after user_confirmed=true") that defines the context for invocation, which is meaningful for a terminal publish action. It does not, however, name alternatives such as schedule_posts or apply_change_set, so routing among siblings 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.

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

Annotations declare destructiveHint=true and openWorldHint=true, so the description does not need to re-state that this mutates state. It adds real value beyond them by bounding the blast radius: no newsletter sends, no deploy trigger. Idempotency (annotated false) and retry/duplicate behavior are not addressed.

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 the action described first and the constraints and exclusions following. Every clause carries information an agent needs; there is 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 need no explanation, and the annotations plus description together cover the safety profile and side-effect boundaries. The remaining gap is the unexplained plan_hash parameter and the unstated plan-first workflow, which matters for a destructive, non-idempotent 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%, so the description carries the full burden. It reinforces the required user_confirmed=true and the phrase 'exact current drafts' hints that the posts array's updated_at values act as a staleness guard, but plan_hash — arguably the most important parameter — is never explained and no format guidance is given for the date-time fields.

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 (schedule) plus resource (exact current drafts) and the outcome (future web publication), which separates it from publish_posts and unschedule_posts. It does not explicitly contrast with plan_schedule, its most closely related sibling, 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?

Gives a hard precondition (user_confirmed=true) and two explicit exclusions (does not send newsletters, does not trigger deployment), which is genuine when/when-not guidance. It never tells the agent to run plan_schedule first to obtain plan_hash, leaving half of the intended workflow implicit.

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?

Adds substantial behavior beyond the annotations: exactly-once POST semantics, that the hook URL cannot be caller-supplied (security-relevant), and that failures are never auto-retried. These are precisely the facts an agent needs before firing a non-idempotent, destructive call.

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 dense sentences with zero filler; the confirmation precondition and the no-retry warning are both front-loaded where they matter most.

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?

Output schema exists so return values need no explanation, and the description covers the remaining risk surface: single-shot execution, no caller-controlled URL, no retries, gated on user confirmation. Nothing an agent needs to invoke it safely 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 0%, so the description must carry the meaning of user_confirmed, and it does explain it as a confirmation gate rather than just a boolean name. It stops short of restating required/const-true constraints, but the intent is clear.

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 (POST to the configured deployment hook) and the exact resource it affects, and no sibling tool performs deployments, so it is trivially distinguishable from list/get/preview/publish 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 precondition (only after user_confirmed=true), which functions as when-to-use guidance. It does not name alternatives, but none exist among the siblings for triggering a deploy, so the gap is minor.

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?

Goes well beyond the annotations by disclosing two non-obvious traits: the batch is version-checked (explaining why updated_at is required) and a configured deploy hook fires exactly once only after complete success. This tells the agent the operation has an external side effect and a success-conditional trigger, which destructiveHint/openWorldHint 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?

Two tight sentences, front-loaded with the action and scope, with no filler. Each clause carries distinct information (versioning, confirmation gate, deploy hook timing).

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 described, and annotations cover the safety profile. The description adds the key side-effect and versioning context, but omits what happens on partial batch failure or whether unpublishing is reversible — relevant for a destructive batch 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?

With 0% schema description coverage, the description compensates well: 'version-checked' explains why each page needs updated_at, and 'after user_confirmed=true' explains the confirmation gate. It still leaves the id format, the 25-item batch cap, and per-item failure behavior unexplained, so it is not fully compensating.

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 ('Unpublish Ghost pages') with scope qualifiers ('exact, version-checked batch'), which cleanly separates it from the sibling unpublish_posts and from publish_pages. An agent can identify the operation 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 precondition 'after user_confirmed=true' implies the confirmation workflow, but this is already encoded in the schema as a const-true required field, so it adds little. No guidance on when to choose this over publish_pages, unpublish_posts, or apply_change_set, and no when-not conditions.

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=false, but the description goes well beyond them: it discloses optimistic-concurrency semantics (version-checked), deploy-hook side effects (runs exactly once, only after complete success), and a critical negative guarantee (newsletter email never sent). This is exactly the extra behavioral context annotations cannot carry.

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 destructive action and its gate front-loaded, followed by side-effect guarantees. No filler and nothing repeated from the name or 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?

An output schema exists, so return values need not be explained, and the safety profile is fully covered by annotations plus description. What is missing is failure/partial-batch behavior (what happens if one post's version check fails mid-batch) and the batch size ceiling, which matter for a destructive 25-item 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?

Schema description coverage is 0%, so the description must compensate, and it only partially does. 'Version-checked' hints that the required updated_at field must match server state, and user_confirmed=true is gated explicitly, but the 24-hex id format and the 1–25 batch limit are never mentioned, so most parameter semantics still rest on regex patterns the agent must decode.

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 (unpublish) and resource (Ghost posts) plus scope qualifiers (exact, version-checked batch). This cleanly separates it from siblings like unpublish_pages, unschedule_posts, and publish_posts without needing to open 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?

The description gives a hard precondition (user_confirmed=true) that tells the agent when this tool is callable, which is genuine usage guidance. However, it never names an alternative or states when NOT to use it versus unschedule_posts or a future single-post unpublish, leaving that 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=false and openWorldHint=true, so the mutation profile is covered. The description adds two non-obvious behaviors beyond the structured data: the mandatory confirmation flag and the guarantee that deployment is not triggered — both load-bearing for a destructive operation.

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 zero filler; the core effect is front-loaded and the precondition and side-effect constraint follow in descending priority.

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 described. For a destructive, non-idempotent, multi-item operation the description covers confirmation and the no-deploy guarantee, but leaves partial-failure behavior and the updated_at concurrency contract unexplained.

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%, so the description must carry parameter meaning. It explains user_confirmed (required, must be true) and 'exact current' implies the updated_at value is a concurrency token, but it never explains the posts array shape or why updated_at must match. This is partial compensation rather than full.

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+effect: 'Return exact current scheduled posts to draft.' The word 'exact' hints at the optimistic-concurrency behavior, and it is clearly differentiated from sibling mutate-tools like schedule_posts, unpublish_posts and trigger_deploy. It stops short of naming the alternative it is not (e.g. unpublish_posts), which is why it isn't a 5.

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 hard precondition ('Requires user_confirmed=true') and a negative scope ('never triggers deployment'), which is real usage guidance. However, it never says when to choose this over unpublish_posts or schedule_posts, so the alternative-selection guidance is only implied.

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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral facts: the sandbox root GHOST_UPLOAD_ROOTS, the 20 MB ceiling, and three explicit refusal classes (remote URLs, SVG, symlink escapes). It omits auth requirements and what happens on success.

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 dense sentence with zero filler. The accepted case is front-loaded and the refusal list follows compactly, so the reader gets the contract in a single pass.

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 explained, and the input contract's rejection rules are fully stated. The remaining gap is operational detail around path format and permissions, which an agent would need to call this correctly on the first try.

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 0% and the single 'path' parameter has no description, so the description must carry the load. It does convey that the value is a filesystem path constrained to GHOST_UPLOAD_ROOTS, but it never clarifies absolute vs relative form, extension expectations, or whether the file must already 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?

Specific verb ('Upload') plus resource ('an image to Ghost') with the source narrowed to 'a local image inside GHOST_UPLOAD_ROOTS'. No sibling tool performs uploads, so even without a named alternative an agent can place it 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?

It states clear usage boundaries: files must be local and under GHOST_UPLOAD_ROOTS, and remote URLs, SVG, symlink escapes, and >20 MB files are refused. There is no competing sibling to route away from, so no explicit alternative is needed, but nothing states prerequisites such as auth or when an upload should precede publish_posts.

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