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

With no annotations, the description must carry the full behavioral burden and falls short. It does not state whether tags are appended or replace existing tags, how duplicates or unknown tag names are handled, or whether the operation requires any special permissions. The output schema covers return values, but the mutation semantics remain opaque.

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 wasted words. It is appropriately sized for the operation, though it could have added one clarifying phrase about append-vs-replace behavior at little cost.

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 mutation tool with no annotations and no output schema explanation required, the description is too thin. It omits key behavior such as whether tags are additive, what happens to existing tags, and any constraints on tag names or duplicates, leaving an agent to guess at mutation semantics.

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

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

Schema description coverage is 100%, so the schema already documents both the draft_id and tags parameters, including that tags may be a string or list. The description adds no parameter-level detail beyond referencing the target, which is the expected baseline when the schema is complete.

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 clear verb (add) and resource (tags) plus the target type (draft/post), so an agent can immediately tell what it does. It does not explicitly distinguish itself from siblings like put_draft, which could also modify a draft's content, but the tag-focused operation is clear enough.

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: add tags to a draft. There is no explicit guidance on when to use this versus put_draft or other draft-modifying siblings, and no prerequisites or exclusions are mentioned.

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, yet it says nothing about it being a read-only lookup, permission requirements, or what happens when the ID does not exist. An agent can infer "read" from the verb, but nothing about failure modes or access constraints is disclosed.

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

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

A single short sentence with the key qualifier ("by its ID") front-loaded and no filler. There is nothing to trim, though also little substance.

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 tool is simple: one required parameter with full schema coverage and an output schema that documents return values, so most needs are covered structurally. The missing piece is any note on behavior for an unknown draft ID or on how this fits alongside list_drafts.

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

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

Schema description coverage is 100% — draft_id is typed as an integer and documented — so the baseline of 3 applies. The description adds only that the ID identifies a "specific draft," offering no format or scoping detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Get a specific draft") and adds the retrieval key ("by its ID"), which implicitly distinguishes it from the list_drafts sibling. It stops short of naming any sibling explicitly, so it does not fully earn 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?

There is no guidance on when to use this versus list_drafts or the various draft-mutation siblings (put_draft, prepublish_draft, publish_draft). The only hint is "by its ID," implying the caller already has an identifier, which is implied usage at best.

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 must carry the behavioral burden, and it does say the tool reads auth state plus basic user info. It stops short of disclosing important traits for a status tool — whether it errors when unauthenticated versus returning an unauthenticated status, and whether it is a cheap connectivity ping or a heavier lookup.

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 or redundancy. Nothing in it fails to earn its place.

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

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

An output schema exists, so return values need not be explained, and zero-parameter tools have a low bar. Even so, the description omits the one behavior that matters for a status tool — what happens when the caller is not authenticated — leaving it only minimally complete.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. The baseline of 4 applies; nothing in the description is needed or missing on this dimension.

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 a specific resource ('authentication status and basic user information'), so the agent knows exactly what it returns. It is clearly distinct from all siblings (draft/publication tools), though the description doesn't 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?

Usage is only implied — an agent can infer this is a session/credential check — but there is no explicit 'use this before X' or 'use this to verify Y' guidance, and no mention of alternatives. For a zero-parameter utility tool this is acceptable, but it leaves the agent to reason about when to call it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not mention read-only/safety traits, pagination behavior, permissions, or rate limits; it only adds the 'current publication' scope.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise, though its brevity contributes to gaps elsewhere.

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 tool is simple, has an output schema, and has complete parameter schema coverage, so the description needn't explain return values or parameter details. However, it still lacks enough usage and behavioral context for an agent to confidently choose it over sibling draft tools.

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

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

Schema description coverage is 100%, so the schema already explains limit, filter, and offset. The description adds no parameter semantics beyond the schema, which matches the baseline for fully documented parameters.

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 (drafts) and scopes it to the current publication. It does not explicitly distinguish itself from nearby tools like get_draft, but the basic purpose is clear.

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 when-to-use guidance, no exclusions, and no alternatives. An agent must infer that this is the bulk-listing tool versus get_draft or list_publications.

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 the access scope ('available to the authenticated user'), implying results are limited to the caller and that auth is required, and 'list' implies a read-only operation. It says nothing about pagination, ordering, or result limits, which is a meaningful gap for a collection endpoint.

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 scope constraint appears immediately after the verb and resource. Nothing could be removed without losing 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?

The presence of an output schema means return values need not be explained, and with zero parameters the schema burden is minimal. However, the absence of annotations leaves the description responsible for safety and behavior disclosure, and it omits pagination, ordering, and any exclusivity versus list_drafts, so it is only minimally viable.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No conflicting parameter hints are present.

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 ('publications') with a scope qualifier ('available to the authenticated user'), which is more precise than a bare name restatement. It does not explicitly distinguish itself from the sibling list_drafts, but the resource noun makes the difference inferable.

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 statement of when to use this instead of list_drafts or the draft-related siblings, and no stated prerequisites beyond a vague reference to being authenticated. The agent must infer the use case entirely from the tool 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?

With no annotations at all, the description carries the full burden, and it does disclose meaningful behavior: chained side effects when prepublish/publish are true, newsletter delivery via send, and the shape of the return dict. It omits the highest-stakes facts — that publish=true makes the post publicly live, that send=true (the schema default!) emails subscribers, and any auth prerequisite. The 'create or update' claim is also unexplained since no identifier parameter controls which mode applies.

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 first sentence is well front-loaded and the Args block is scannable, but the description is bloated: a YAML block plus two full Python examples, a Returns section redundant with the output schema, and a meta-sentence explaining what the examples are for. Roughly half the text restates information an agent already has from the schema.

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 14-parameter mutation tool with 0% schema coverage, the description covers most of what an agent needs: parameter listing, enums, chaining semantics, and return shape (redundant given the output schema). The remaining gaps are the create-vs-update mechanism and the risk profile of publish/send, which matter for a write tool with no annotations.

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

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

Schema coverage is 0% and there are 14 parameters, so the description must compensate — and it does list every one, including enum values for audience and write_comment_permissions that the schema lacks. But several entries are near-tautological ('subtitle: Optional subtitle text') and send/share_automatically are dismissed as 'Passed to publish_draft' with no explanation, and no defaults are stated despite the surprising send=true default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Create or update a Substack draft from Markdown') and the body clarifies it builds a Post and posts a draft. It also names the sibling tools it can chain into (prepublish_draft, publish_draft), which helps distinguish it from those. It does not, however, differentiate itself from put_draft, the other draft-writing 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?

The two worked examples implicitly establish when to use the combined call versus decomposing into add_tags/prepublish_draft/publish_draft manually, and the closing sentence states that intent explicitly. What is missing is a stated rule for choosing between the two approaches and any precondition ('the draft must not already be published').

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 and does not say whether invoking checks mutates the draft, whether it is idempotent, whether failures block publication, or what permissions are needed. It only restates the action.

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, though the terseness comes at the cost of explaining 'prepublish checks'.

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 and the single parameter is documented, but for a tool sitting among several publish variants, the description should clarify how it differs from publish_draft_checked and whether the checks are read-only.

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

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

Schema coverage is 100% for the single draft_id parameter, so the schema already documents the argument. The description adds no semantics about what draft identifiers are valid or how the checks relate to that draft beyond the name, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names an action ('invoke prepublish checks') on a resource ('draft'), which is more than a tautology, but 'prepublish checks' is unexplained jargon and nothing distinguishes it from siblings like publish_draft_checked or publish_draft, which plausibly also perform validation.

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 call this versus publish_draft, publish_draft_checked, or get_status. Given the dense cluster of publish-related siblings, the absence of any exclusion or sequencing hint leaves the agent to guess.

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 behavioral load: it discloses that this path publishes to a live state and lacks the confirmation and prepublish validation of the checked variant, which is a meaningful risk disclosure. It stops short of saying whether publishing is reversible or what side effects occur (e.g. default email send), though the output schema covers return shape.

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 purpose and the legacy routing are front-loaded and the text is short. The parenthetical "(Legacy compatibility interface)" is then restated as "This tool remains for backward compatibility", a small redundancy that keeps it from 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?

An output schema exists and parameters are fully documented, so the description only needs to cover purpose, routing and risk. It does those, but leaves out what actually changes on the draft and whether the action is reversible — the one thing an agent deciding to call a publishing mutation would want.

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

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

Schema description coverage is 100%, so all three parameters (send, draft_id, share_automatically) are already documented in the schema with defaults. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and target state ("Publish a draft to live post state"), which is precisely distinguishable from siblings like prepublish_draft and schedule_draft. It also names the near-duplicate sibling publish_draft_checked so the agent can tell the two apart 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 description explicitly states this tool exists only for backward compatibility and recommends publish_draft_checked instead, giving the reason (explicit confirmation and prepublish validation). That is a clear when-to-prefer-the-alternative rule, which is exactly what usage guidance should do.

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. It usefully discloses that confirmation is required and prepublish checks are run, but it does not explain side effects, irreversibility, permissions, or what happens if checks fail.

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 definition is a single front-loaded sentence with no wasted language. It is appropriately concise, though its brevity leaves important selection and safety details to other fields.

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 tool has a rich schema with full parameter coverage and an output schema, so return values need not be described. However, for a publishing mutation with no annotations, the description should do more to clarify how it differs from sibling publish/prepublish tools and what the checks imply.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds no parameter-specific meaning beyond the existing schema text, making 3 the appropriate baseline.

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 action and resource: publishing a draft through a safer path with confirmation and prepublish checks. It partially distinguishes itself from siblings like publish_draft and prepublish_draft by calling out the safer/checked workflow, though it does not explicitly compare them.

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 'A safer publishing path' implies when to choose this over a normal publish operation, but the description never names alternatives or states when not to use it. Usage is inferable 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?

No annotations are provided, so the description carries the full burden, yet it says nothing about whether the update is a full replacement or a merge, what permissions are required, whether changes are reversible, or what happens to omitted fields. 'Update an existing draft' implies mutation and a precondition (draft must exist), but that is the extent of the disclosure.

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 waste. The brevity edges into under-specification rather than verbosity, but structurally nothing is misplaced.

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?

This is a mutation tool with no annotations, a nested free-form update_payload, and only an output schema to lean on. The description should clarify which fields are updatable and what the payload actually does, but it offers nothing beyond the schema's example fields.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, and the description adds no syntax, format, or constraint detail beyond it. Baseline 3 applies when the schema does all the work.

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 ('update') and resource ('existing draft by draft ID'), which is clear enough on its own. It does not differentiate from siblings like post_draft_from_markdown or prepublish_draft that also touch drafts, so an agent still has to infer where the boundary lies.

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 conditions for use, no exclusions, and no alternatives. It never says whether this should be used for content edits versus publishing/scheduling flows covered by publish_draft or schedule_draft, leaving routing entirely 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?

No annotations are provided, so the description carries the full burden, yet it discloses nothing about side effects: whether the draft auto-publishes at the given time, what permissions are required, whether scheduling an already-scheduled draft overwrites or errors, or whether the time must be in the future. For a mutation tool this is a substantial 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, which is efficient. Its brevity reflects under-specification more than careful economy, but on this dimension alone it is well-formed.

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?

Although an output schema exists and parameters are fully documented, the description leaves the core behavior of a scheduling mutation unexplained (auto-publish semantics, preconditions, interaction with prepublish_draft). An agent could invoke it but could not predict its consequences.

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

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

Schema description coverage is 100% — both draft_id and the ISO 8601 format of `at` are documented in the schema — so the baseline of 3 applies. The description adds no meaning beyond it, notably omitting whether `at` must be in the future or which timezone assumptions apply.

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 verb-and-resource pair ("schedule" + "draft") is identifiable, but "for release" is ambiguous — it does not say whether this queues automatic publishing, marks a prepublish date, or merely records intent. It also does not distinguish itself from close siblings such as publish_draft, prepublish_draft, and unschedule_draft.

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 schedule rather than publish_draft or prepublish_draft, and no mention of unschedule_draft as the inverse operation. An agent must infer the workflow entirely from sibling names.

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 of behavioral disclosure. It identifies the operation as an unschedule mutation and implies a precondition, but says nothing about permissions, reversibility, error behavior if the draft is not scheduled, or what state the draft returns to.

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 front-loaded sentence with no unnecessary words. It is appropriately sized for a simple one-parameter tool, though its brevity leaves important behavioral details unstated.

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. For a simple mutation tool with one well-documented parameter, the description is minimally adequate, but it omits behavioral context about post-conditions and failure modes that would matter when unscheduling a draft.

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 schema has 100% description coverage and documents the single draft_id parameter. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Unschedule ... draft') and adds the precondition that the draft was previously scheduled. It is clear, but it does not explicitly distinguish itself from the sibling schedule_draft beyond the antonym in the verb.

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 guidance on when to use this tool versus alternatives such as schedule_draft or put_draft. The phrase 'previously scheduled' implies a precondition, but no when-to-use or when-not-to-use rules are stated.

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