checklist

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

With no annotations provided, the description carries the full behavioral burden. It discloses that creation returns a CL-NNNN id, that the checklist is reusable, and that the free tier allows 3 checklists with unlimited runs. It stops short of error/duplicate-name behavior, but it is materially more transparent than a bare 'Create a checklist.'

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

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

Three short sentences pack in the core action, the fields, the return value, the follow-up sibling tool, and a quota constraint. There is no filler, and the most important information is front-loaded.

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?

Given there is no output schema and no annotations, the description does well by explaining the return ID, parameter shape, next workflow step, and free-tier limit. It does not detail error behavior or uniqueness constraints, but for a simple creation tool this is a reasonably complete definition.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description repeats their names but adds little meaning beyond the schema; the phrase 'a name, a category and an optional description' is also slightly ambiguous about whether category is optional, though the schema clearly marks only name as required.

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 ('Create a reusable checklist') and the resource, plus the returned artifact ('its CL-NNNN id'). It clearly distinguishes this tool from siblings like checklist_item_add, checklist_show, and checklist_delete.

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 makes the creation workflow clear and explicitly points to the next step: 'Add the steps with checklist_item_add.' It does not list exclusions or when-not-to-use conditions, but the context is sufficiently clear for an agent to choose this tool over its siblings.

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 provided, the description carries the full burden, and it does so well: it discloses permanent deletion, cascading deletion of steps, and the important safety property that started runs remain untouched and readable.

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 destructive action is front-loaded, and the second sentence provides the single most important caveat in a clear, well-structured way.

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

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

For a simple two-parameter destructive operation, the description is complete: it explains what is deleted, how confirmation works is already in the schema, and it resolves the biggest concern by explaining run preservation. No output schema is present, but the essential call semantics are fully covered.

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

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

Schema coverage is 100% and both parameters already have descriptive definitions. The tool description adds general deletion semantics but no new parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: deleting a checklist and its steps for good. It is clearly distinct from checklist_create and checklist_item_remove, and the permanence ties directly to the tool's name and title.

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 implies usage by describing the deletion behavior and adds useful context that started runs are unaffected. However, it never explicitly contrasts this tool with alternatives such as checklist_item_remove or states when not to use it.

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

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

With no annotations, the description carries the burden. It discloses the return value (I01-style id), the effect on sign-off (required steps block sign-off, optional ones do not), and the insertion behavior (position parameter, existing steps keep ids). It doesn't mention error cases or whether the operation is reversible, but the core behavioral traits are covered.

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

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

Two sentences, front-loaded with the main action and outcome, then a concise explanation of the required/optional distinction. No wasted words.

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 tool with 6 params, 100% schema coverage, and no output schema, the description covers the essential behavior: what it does, what it returns, and the key semantic distinction (required vs optional). It could mention error conditions or id format details, but the core is 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds context about the return id and the sign-off semantics of required, but doesn't add much beyond the schema for individual parameters. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Add'), a resource ('one step to a checklist'), and the key outcome ('return its I01-style id'). It also names the fields involved (text, optional section heading, required flag), which distinguishes it from sibling tools like checklist_item_remove and checklist_create.

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 implies when to use this tool: to add a single step to a checklist, with optional section heading and required flag. It doesn't explicitly name alternatives or exclusions, but the sibling list makes the context clear. The behavior of required vs optional steps is explained, which helps an agent decide whether to set required=true.

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 disclosure burden. It clearly indicates mutation ('Remove', 'bump the checklist version') and adds an important non-obvious behavior: active runs keep the step they started with and ticked data is not rewritten. This is meaningful context beyond a simple 'remove' statement.

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 concise sentences with no filler. The core action and object are front-loaded, and the second sentence adds one valuable behavioral detail. Every word earns its place.

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

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

For a simple two-parameter mutation with fully documented schema, the description covers the essential operational behavior: what is removed, how the item is identified, the version effect, and the effect on in-flight runs. It does not describe the return value or irreversibility, but the operation is simple enough that these are minor gaps.

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 fully documents both parameters. The description's 'I01-style id' phrasing aligns with the schema's 'e.g. I03' example but adds no new semantic information beyond what is already in the input 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 ('Remove'), a specific resource ('one step from a checklist'), and the mechanism ('by its I01-style id'). It also mentions the version bump side effect. This clearly distinguishes it from checklist_item_add and the other checklist tools.

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 intended usage is strongly implied: use it to remove a step from a checklist. However, there is no explicit guidance about when to prefer this over alternatives, no exclusions, and no mention of prerequisites or constraints beyond the description of the operation itself.

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 safety and behavior disclosure. It discloses the row cap ('at most 500 rows'), ordering ('newest change first'), and implies a read-only listing. It could mention pagination or auth, but for a simple list tool the key behaviors are covered.

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

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

Two sentences front-load the core output and then add filtering, a row cap, and sort order. No filler or repetition of the title. Every sentence contributes distinct information.

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

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

With no output schema, the description still communicates the returned fields, optional filters, row limit, and ordering. For a low-complexity list tool with two optional parameters, nothing essential is missing. It is complete enough for an agent to invoke and interpret results.

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

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

Schema coverage is 100% and each parameter already has a clear description with matching semantics. The description's 'filter by category or by a word in the name' paraphrases the schema without adding new constraints. A baseline 3 is appropriate because the schema does 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?

The description names a specific action and resource: listing every checklist, and enumerates the fields returned (category, version, step count, run count). The title reinforces the verb, and the resource clearly distinguishes it from the run_* siblings. It could name checklist_show explicitly, but the list-versus-detail distinction 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 makes the use case clear: retrieve checklists with optional filtering by category or name substring. It doesn't explicitly name alternatives such as checklist_show for a single checklist's details, so it stops short of full routing guidance. Still, the context is self-evident for a list operation.

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 burden, and it does well by disclosing ordering, grouping, required counts, run counts, and the printable as_text behavior. It does not describe the response envelope or error handling, but for a read-only show tool the core behavior is transparent.

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

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

Two sentences with no filler. The primary output content is front-loaded, and the optional as_text behavior is presented as a clear secondary instruction. 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?

With no output schema, the description adequately explains what the structured view contains and what the as_text branch returns. The parameters are simple and fully documented in the schema, so an agent has enough context to call the tool correctly.

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

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

The input schema already covers both parameters well, so the baseline is 3. The description adds meaning beyond the schema by specifying the as_text output comes 'with a box against each step,' which clarifies the printable form. This is modest but real added value.

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 clearly identifies the resource (one checklist) and the content of the view: ordered steps, grouped by section, required-count, and run-count. It distinguishes itself from checklist_list by emphasizing 'one checklist,' though it starts with a noun phrase rather than an explicit verb like 'shows.'

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

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

Usage is implied rather than explicitly stated: 'One checklist' signals this is for looking at a single checklist, and the as_text sentence explains when that option is useful. However, it does not explicitly contrast with siblings like checklist_list or run_show, nor does it state when not to use this tool.

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 burden of behavioral disclosure. It explicitly states that data under the token stays and that a wrong or expired key changes nothing, which is valuable non-destructive and failure-mode context for an activation mutation.

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-load the action and key requirement, then add side-effect guarantees and a pointer to verification. No wasted words or repetition beyond the schema format.

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 one-parameter activation tool with no output schema and no annotations, the description covers the action, key eligibility, non-destructive behavior, failure mode, and how to confirm success. It could add explicit return-value expectations, but license_status confirms it largely covers that gap.

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

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

The schema already fully documents the key parameter, so the baseline is 3. The description adds meaningful semantics by explaining the key must be issued at checkout for this server or bundle and that invalid keys are no-ops, going beyond the schema's simple format description.

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 action, 'Turn Pro on for this connection,' with a clear resource (license/Pro status) and key format. It also distinguishes itself from the sibling license_status by focusing on activation rather than checking status.

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 clearly conveys when to use the tool: when activating Pro with a checkout-issued key for this server or bundle. It also references license_status as the follow-up confirmation step, though it stops short of explicitly saying 'use license_status instead to check current status.'

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 burden of behavioral disclosure. It explicitly states 'No arguments, nothing changes,' indicating a read-only, side-effect-free operation. It does not detail error handling or authentication requirements, which are minor omissions for a simple status check, but the core behavioral trait (no mutation) is clearly communicated.

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 two sentences, tightly packed with all essential information. It is front-loaded with the primary action and output, then adds the use case and side-effect note. Every sentence earns its place with no redundancy or fluff.

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 tool with no input parameters and no output schema, the description fully covers what an agent needs: the return format (JSON with product, tier, reason, checkout URL), the trigger condition, and the lack of side effects. Nothing essential is missing.

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

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

The tool has zero parameters, and the description confirms 'No arguments.' Per the scoring rules, 0 parameters earns a baseline of 4. The description adds no parameter-specific meaning because none exist, and it correctly reiterates the absence of arguments, aligning with the empty 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: 'Report this endpoint's licence state for your token as JSON'. It explicitly enumerates the returned fields (product, tier, reason, checkout URL), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like license_activate by focusing on status reporting rather than activation.

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 clear trigger for use: 'Call it to explain a free-tier refusal.' This tells the agent when to invoke this tool. It does not explicitly discuss alternatives or exclusions, but the purpose is distinct enough from siblings that the guidance is adequate; it could be improved by noting it is the only read-only license info tool, though that is 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?

With no annotations, the description carries the full burden of explaining behavior. It usefully discloses that na never counts as passed, that re-answering overwrites the previous answer, and that the run must be open. However, it omits the pending state allowed by the schema and says nothing about effects on run status or sign-off, leaving some behavioral ambiguity.

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

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

Three sentences with no filler. The first sentence states the core action, and the following sentences add only essential edge-case semantics. The structure is front-loaded and every sentence earns its place.

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

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

The tool is simple, the schema fully documents its parameters, and the description clarifies the most important behavioral nuances. The only notable gap is the absence of a mention of the pending reset state and any return/confirmation behavior, but these are minor for this 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 100%, so the schema already documents all six parameters, including defaults, formats, and examples. The description adds prose around na semantics and the who/when intent, but does not need to compensate for missing parameter documentation.

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 ('Mark') with a specific resource ('one step') and the exact allowed outcomes (pass, fail, na). This clearly distinguishes run_check from run-level sibling tools like run_sign_off, run_status, and run_report.

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: this tool records step-level answers, can be used again while the run is open, and the latest answer is the effective one. It does not explicitly name alternative sibling tools or state when not to use it, so it stops short of a 5.

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 burden of behavioral disclosure. It clearly states permanence ('for good'), cascading deletion ('with every answer on it'), and the refusal behavior for signed-off runs. The confirm parameter's schema reinforces this with 'no undo and nothing is copied anywhere first.'

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

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

Three short sentences with no filler. The core action is front-loaded, the most important constraint (signed-off runs are refused) is stated immediately, and the alternative behavior is given last. Every sentence earns its place.

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

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

For a destructive two-parameter tool with no annotations and no output schema, the description is nearly complete: it covers purpose, permanence, cascade effects, and the key refusal case. A small gap is that it does not describe the success response or clarify what 'abandon' concretely does, but the schema and description together are sufficient 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 100%, so the baseline is 3. The description adds some behavioral context for the run parameter by noting signed-off runs are refused, but it does not add new syntax or format details beyond what the schema already provides for run and confirm.

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: 'Delete a run for good, with every answer on it.' It also distinguishes this from related run tools by emphasizing permanent deletion and the refusal of signed-off runs, so an agent can tell it apart from run_show, run_status, and run_sign_off.

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 when deletion is appropriate and explicitly warns against deleting signed-off runs, directing the user to 'Abandon a run you no longer want instead.' It loses a point because the suggested alternative 'abandon' is not a named sibling tool in the provided list, making the guidance slightly less actionable.

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 burden of behavioral disclosure. It usefully states ordering ('newest first'), content ('checklist, progress and sign-off state'), and the 500-row limit, but it does not clarify side effects, return format, or the nuance that open_only actually means open and complete runs.

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

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

Three short sentences deliver ordering, contents, filter options, and a maximum result count with no filler. The most important facts are front-loaded and every sentence adds value.

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 no output schema and no annotations, so the description must stand alone for return expectations; it does so by naming the included run state. Parameter semantics are fully covered by the schema, and the row limit is disclosed, though exact output field names and pagination behavior beyond the limit are not specified.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description only summarizes filter categories ('checklist, status, reference, open only') without adding new semantic detail, and it omits the with_failures parameter entirely.

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 clearly states that this lists runs, ordered newest first, with checklist, progress, and sign-off state. It is immediately distinguishable from sibling tools like run_show, run_status, or run_start by focusing on plural listing with filtering and a row cap.

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 implies usage for batch retrieval of runs and lists available filters, but it does not explicitly say when to prefer this over siblings like run_show or run_status, nor mention any exclusions or alternative tools.

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 must carry the full burden of behavioral disclosure. It describes the output format but does not disclose whether the tool is read-only or has side effects. The mention of out_path and overwrite implies file creation, but it is not explicitly framed as a write operation or its implications (e.g., does it modify the run or create a resource?). This lack of clarity on mutability and side effects is a notable 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?

The description is two sentences with no waste. It front-loads the core purpose and then adds the Pro-specific detail. Every clause contributes meaning, and the structure is logical and scannable.

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 tool with three parameters and no output schema, the description is fairly complete. It explains the report contents, the tier differences, the download link validity, and the overwrite behavior. However, it does not mention potential failure conditions (e.g., run not found) or whether the report generation has any prerequisites, but these are minor gaps given the schema already defines parameters.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying that out_path is Pro-only, explaining the behavior of overwrite (default false, refuses existing), and noting that run can be an id or title. These enrich the parameter meaning 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 clearly states what the tool does: it produces a run report as plain text, with specific contents (steps, marks, who answered, notes, counts, signature). It also distinguishes Pro vs every tier and mentions the download link feature. This is a specific verb-resource pair, easily distinguishable from siblings like run_show or run_status.

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 provides no guidance on when to use this tool versus alternatives. It mentions tier differences but does not state when to prefer run_report over run_show, run_status, or other run-related tools. There are no explicit when/when-not conditions or references to sibling tools, leaving selection 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?

With no annotations provided, the description must carry the behavioral burden. It describes the returned content in detail and 'Show' implies a read-only operation, but it does not explicitly state that there are no side effects, what permissions are required, or how errors/edge cases behave.

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 one dense, front-loaded sentence with no filler or repetition. Every clause adds a distinct piece of useful information about what the tool returns.

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 tool with one simple, well-documented parameter and no output schema, the description comprehensively enumerates the response contents: steps, answers, authors, timing, grouping, counts, failures, and sign-off status. An agent has enough to select and invoke the tool correctly.

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

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

The input schema already documents the single 'run' parameter with an example and the title fallback, giving 100% coverage. The tool description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states that the tool returns the whole run with steps, answers, counts, failures, and sign-off eligibility, so an agent can tell what it does. It does not explicitly differentiate from similar siblings like run_status or run_report, which keeps it from 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 'The whole run' implies this is the comprehensive-detail tool, but the description never says when to use it instead of run_status, run_check, or run_report. Usage context is only implied, not explicitly stated.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It transparently describes the freezing side effect, the refusal policy, the force override, and the fact that exceptions persist on the record and print on the report—far beyond a terse 'Signs off a run'.

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 two sentences with the primary action front-loaded ('Sign off a completed run with a name and a date, which freezes it') and the crucial conditions packed into the second sentence. Every clause contributes useful information; no wasted words.

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?

Given the 5-parameter tool with no output schema and no annotations, this description is largely complete: it explains the freezing side effect, refusal logic, force override, and exception persistence. The only notable gap is that it does not describe what happens to the run's status after a successful sign-off beyond 'freezes it', nor what the agent should do when a refusal occurs. Still, it's adequate for an agent to invoke correctly.

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

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

Schema description coverage is 100%, with every parameter already documented (by, run, date, note, force). The description adds only high-level references to signing with a name and date and the force flag, which does not materially exceed the schema's own semantic detail. Baseline 3 is appropriate.

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

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

The description starts with a specific verb ('Sign off') on a specific resource ('a completed run') and states the effect ('freezes it'), which clearly distinguishes this from sibling tools like run_start, run_status, or run_report. No ambiguity about what this tool does.

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 provides clear context: it is for completed runs and is refused while required steps are unanswered or failed, unless force is true. It does not explicitly name alternative tools for other situations or advise when to avoid it, but the refusal conditions effectively communicate the expected usage context.

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 burden, and it discloses the most important behavioral trait: steps are copied into the run so later checklist edits do not affect it. It also states the cost model (free, uncapped) and the returned id. It does not cover failure modes or prerequisites, but the core side-effect semantics are exposed.

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 three short sentences with the purpose and return value front-loaded. The second and third sentences earn their place by explaining snapshot semantics and cost behavior without any wasted words.

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 5-parameter, no-output-schema, no-annotation tool, the description plus schema cover the main workflow: what is started, what is returned, and the key copy-on-start behavior. The only notable gap is that the optional note parameter is not described anywhere, and prerequisites such as the checklist needing to exist are left implicit.

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 80%, so the schema already documents most parameters and the description does not need to repeat them. The description adds no parameter-level meaning beyond the schema; only the optional note parameter remains undocumented in both places.

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 verb and object, 'Start a dated run of a checklist', name the exact action and resource, and the return value (RUN-YYYY-NNNN id) is explicitly stated. This clearly separates it from sibling run_* tools, whose verbs point to checking, showing, listing, or deleting runs.

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 or when-not-to-use guidance, and no sibling tool is named as an alternative. The intended use is only implied by the verb 'Start' in the title and first sentence, plus the reassurance that runs are free and never capped.

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 present, the description carries disclosure weight. It discloses a key behavioral constraint: a signed-off run is refused because a signature is the stopping point. It also implies the tool mutates state by moving runs between 'open' and 'abandoned'. It does not cover every side effect, but it is meaningful and not misleading.

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

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

Two sentences with no filler. The core purpose and the key restriction are front-loaded, and every phrase earns its place. The description reads naturally and is easy to scan.

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?

Despite having no output schema and no annotations, the description explains the two possible state transitions and the critical signed-off exception. It leaves out details like permissions or edge cases, but for an agent selecting this tool among siblings, it is sufficiently contextual to run the operation correctly.

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

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

Schema coverage is 100% and the parameter descriptions already clarify the run, status, date, and note fields. The description frames the status values with real-world context, but it does not add a substantial amount of meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The title and description clearly state two specific actions: reopen a run or abandon it. It is easy to distinguish from sibling tools like run_sign_off, run_delete, and run_start because it explicitly describes the conditions under which a run is moved to 'open' or 'abandoned'.

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, scenario-based guidance: use it for reopening a run to re-answer steps or abandoning a run when the job did not happen. It also implicitly rules out signed-off runs by stating they are refused. It does not name alternatives by name, but the context is strong and the purpose is not ambiguous.

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