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

There are no annotations, so the description carries the full behavioral burden. It only states the listing action and artifact format; it does not disclose whether the call is read-only, what identifiers are needed, whether results are paginated, or what the response contains.

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

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

The description is a single front-loaded sentence with no filler. It loses one point because 'opaque artifact IDs' is jargon that adds little to an agent's understanding.

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 tool with an output schema, the description conveys the basic operation and lets an agent infer the input. However, it omits parameter semantics and usage context, so it is 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?

Schema description coverage is 0%, and the description barely compensates. 'Produced by a run' weakly implies run_id identifies the run, but it does not explain how to obtain the run_id, its format, or what 'opaque artifact IDs' means in practice.

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 ('List') and a specific resource ('JSONL artifacts produced by a run'), making the core operation identifiable. It is reasonably distinct from sibling tools like runs, logs, and result, though the phrase 'opaque artifact IDs' is mildly confusing rather than clarifying.

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 is given about when to choose artifacts over siblings like collect, result, logs, export, or preview. The description implies it is for per-run artifact listing but does not state any selection criteria 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the check is read-only, whether it can modify the environment, what side effects a deep dependency check might have, or what the result looks like. The word 'Check' implies inspection but no explicit behavior 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?

The description is one concise sentence with no filler. It front-loads the core action and resource, then attaches the optional scope. 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?

This is a simple tool with a single optional parameter and an output schema, so the description does not need to explain return values. However, it omits usage context and alternative routing, and with no annotations it leaves the agent to infer safety and side-effect 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?

Schema description coverage is 0%, so the description must compensate for the undocumented 'deep' boolean. The phrase 'optionally its full CLI dependencies' gives a meaningful hint that deep controls whether CLI dependencies are included, but it never explicitly maps the parameter to the behavior.

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') and names concrete resources: MediaCrawler source, runner, and optionally full CLI dependencies. It does not explicitly contrast itself with sibling tools like 'status' or 'runs', so differentiation relies on the reader inferring that this is a health/verification check.

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 is given about when to use this tool versus alternatives such as 'status' or 'collect'. The description states what is checked but not the context, prerequisites, or conditions under which an agent should choose 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 must fully disclose side effects. It mentions 'delete' but fails to state that deletion is permanent, that dry_run defaults to true, or that setting dry_run to false actually removes matching runs. The destructive behavior is alluded to but left ambiguous.

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 tight sentence that front-loads the action and the target condition. Every word earns its place, with no wasted phrasing.

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, no annotations, and a destructive mode, the description is too sparse. It leaves the meanings of keep_latest, older_than_days, and dry_run implicit, and does not explain the preview-versus-deletion safety workflow. The presence of an output schema helps, but the missing parameter semantics remain a significant 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%, and the description does not explain any of the three parameters. The phrase 'bounded retention window' hints at older_than_days and keep_latest but does not map them to parameters, and dry_run is completely absent. The description does not compensate for the undocumented 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 action (preview or delete) applied to a specific resource (completed runs) with a qualifying condition (outside a bounded retention window). This clearly distinguishes it from siblings like delete_run or preview in scope, though it does not explicitly name 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 description provides no guidance on when to use this tool instead of delete_run or preview, nor does it explain the preview-then-delete workflow via dry_run. The retention-current use case is implied but not explicitly stated as the preferred cleanup path.

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 that the run is 'bounded' and that the returned run_id is 'durable', implying asynchronous background execution. However, it omits side effects such as browser launch, network activity, data persistence, or how to follow up on the 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?

A single, tight sentence communicates the action and primary output immediately with no filler. Every word earns its place.

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

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

For a tool with 14 parameters, no schema descriptions, and no annotations, this one-sentence description is insufficient. It does not explain what 'bounded' means, how to choose platform/mode, or how the run relates to sibling status/result/logs tools. The presence of an output schema helps return-value expectations, but invocation knowledge remains incomplete.

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 has 14 parameters with 0% description coverage, and the description adds no parameter-level meaning. Required parameters like platform and mode are completely unexplained, and meaningful defaults such as login_type, browser_mode, and timeout_minutes are left to inference.

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 ('Start'), a clear resource ('collection run'), and the key output ('durable run_id'). This clearly distinguishes it from sibling tools like stop, status, result, and logs, which manage or inspect runs rather than initiate 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?

No guidance is given on when to use this tool versus alternatives such as preview, export, or runs. The only context is the verb 'Start', so usage timing and selection criteria must be inferred by 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?

With no annotations, the description carries the burden of behavioral disclosure; it does disclose permanence ('Permanently') and the completed-run restriction. However, it does not explain the confirm parameter's role, side effects on associated data, authorization, or the response 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 front-loaded sentence with no filler; every phrase ('Permanently', 'one completed run', 'after explicit confirmation') earns its place. The most important destructive and gating traits appear first.

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 an output schema and only two parameters, so the description does not need to cover return values. It is incomplete as a standalone guide because it omits when-not-to-use, the confirm-to-true requirement, and any side-effect or authorization notes, making it adequate but not fully self-sufficient.

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%, but the description indirectly maps run_id to 'one completed run' and maps confirm to 'explicit confirmation.' It fails to state that confirm must be set to true or that run_id identifies the target, leaving some inference to the agent.

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 and target ('Permanently delete one completed run') and includes a distinct state constraint ('completed') and a confirmation gate, clearly separating it from siblings like stop, cleanup, and export. There is no ambiguity about what resource the tool acts on.

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 is given for when to choose this tool over siblings such as cleanup or stop; it does not explicitly state that running or incomplete runs should not be deleted or that the confirmation parameter must be supplied. 'After explicit confirmation' implies a prerequisite but does not provide routing rules 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?

With no annotations, the description must carry behavioral disclosure. It usefully reveals that output is credential-redacted but not anonymized, which is important context, but it leaves other behavioral aspects like side effects, permissions, or storage implications undisclosed.

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

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

A single sentence that is concise, front-loaded with the main verb, and contains no filler. Every phrase adds 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?

For a one-parameter tool with an output schema, the purpose is mostly clear. However, the lack of sibling differentiation and any side-effect disclosure leaves gaps that an agent might need to resolve before confident 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%, and the description does not explain 'run_id' or its expected format. The meaning is inferable from 'run artifacts', but the description adds no parameter-level guidance beyond the schema property name.

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 has a specific verb ('Create'), a precise resource ('ZIP of run artifacts'), and critical qualifiers ('credential-redacted, non-anonymized'). This clearly distinguishes it from siblings like 'artifacts' or 'result'.

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 states what the tool does but gives no guidance on when to choose it over sibling tools such as 'artifacts', 'result', or 'logs'. There are no alternative recommendations or exclusion criteria.

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 behavioral burden. It discloses that the tool is read-only, that logs are redacted, and that pagination uses an exclusive sequence cursor. This is useful behavioral context beyond the schema, though it does not mention permissions or performance implications.

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, tightly written sentence with no filler. The action and resource are front-loaded, and every phrase adds meaningful 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 tool is simple, has an output schema, and only three parameters, so the description plus schema is partially sufficient. However, it omits sibling differentiation and does not clearly map the cursor phrase to the 'after' parameter. More context would make it fully 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 0%, so the description must compensate for the three parameters. It indirectly hints at the cursor via 'exclusive sequence cursor', which relates to 'after', but it never explicitly explains run_id, after, or limit. This leaves too much inference to the agent.

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 ('Read'), a clear resource ('run logs'), and key properties ('redacted', 'exclusive sequence cursor'). This distinguishes it from sibling tools like artifacts, preview, or export, which likely handle different content types.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The only implied usage is 'read logs', but the description does not help an agent choose between logs, artifacts, preview, result, or export.

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 behavioral burden and does disclose two meaningful traits: credential redaction and the refusal to accept arbitrary file paths. It does not mention side effects or authorization, but 'Preview' strongly signals a read-only, non-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?

The description is a single front-loaded sentence with no filler, and the safety constraint earns its place by adding critical behavioral context.

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

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

For a simple, read-oriented tool with an output schema and self-descriptive schema property names, the description covers the core behavior and safety boundary. It falls short only in not articulating parameter semantics or explicit sibling differentiation, but those are partially recoverable from the schema and name.

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 needed to explain what run_id, artifact_id, limit, and offset mean, but it does not mention any of them. The word 'JSONL' and the conventional names give some indirect inference, but the description itself adds no parameter-level meaning.

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 ('Preview') and resource ('credential-redacted JSONL'), and adds a distinguishing constraint ('without accepting arbitrary file paths') that separates it from file-path-based alternatives among the 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?

It implies the tool is for safely previewing redacted JSONL artifacts, and the 'without accepting arbitrary file paths' clause hints at a security-driven selection criterion, but it never explicitly names when to use this tool instead of a sibling or what conditions disqualify 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 burden of behavioral disclosure. It does reveal meaningful traits: the result is 'bounded' and 'redacted,' and 'Get' signals a read-only operation. However, it does not explain redaction rules, the exact bound, or behavior with different record_type values.

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 concise sentence with no filler, and it front-loads the verb and resource. It could carry more useful detail, but structurally it is efficient and easy to parse.

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 annotations, three undocumented parameters, and several overlapping sibling tools, this description is too thin. It does not clarify what 'typed artifacts' means, how limit applies, what the bound is, or how this tool differs from status, artifacts, and preview.

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 description adds no parameter-level meaning. The three parameters—run_id, limit, and record_type—must be inferred from their names and defaults. The phrase 'typed artifacts' only loosely hints at record_type.

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 the specific verb 'Get' and names three concrete resources: run status, typed artifacts, and a bounded redacted result sample. This clearly conveys the core action, though it does not explicitly distinguish this tool from overlapping siblings like status, artifacts, and preview.

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

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

There is no guidance on when to use this tool versus status, artifacts, preview, or export. The description gives no context about prerequisites, such as whether a run must be completed, or when a bounded sample is preferable to a full result.

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 behavioral burden. It conveys a read-only listing operation and adds 'durable' and 'recent' as filters, but it does not describe side effects, ordering, pagination, or any prerequisites. This is adequate for a simple list tool but leaves some behavior implicit.

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

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

One sentence front-loads the operation and includes the purpose. There is no redundant or filler content.

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 list operation with one optional parameter and an output schema, the description is largely complete: it states the resource, the recency/durability scope, and the intended use. It could briefly explain how run IDs connect to sibling tools, but this is not critical.

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 should compensate for the undocumented 'limit' parameter, but it does not mention it. The parameter's title and default value make its basic meaning inferable, but the description adds no semantic value 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 uses a specific verb and resource: 'List recent durable runs' and attaches a clear purpose, 'so an agent can recover their run IDs.' It is unambiguous about the resource, though it does not explicitly distinguish itself from sibling tools such as status or result.

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 'so an agent can recover their run IDs' provides a concrete usage context: agents that need to retrieve run IDs should call this tool. It does not name alternatives or exclusions, but the single optional parameter and list purpose make the appropriate situation clear.

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 signals a read-only operation through 'Get', but does not disclose additional behaviors such as failure modes, repeated-call safety, or permission requirements. It adds little beyond the basic 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?

One concise sentence with no redundancy. The core action and returned data categories are front-loaded, and every word contributes to understanding the tool's purpose.

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 description clearly states the tool's purpose and the run it targets. However, it omits any usage guidance or behavioral caveats; for a simple read-only status tool this is mostly complete but not exhaustive.

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 has a single run_id parameter with no description, so schema coverage is 0%. The phrase 'for a run' maps run_id to the target run, but adds no detail about format or source. The property title 'Run Id' is self-explanatory, making this minimally adequate.

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 the specific verb 'Get' with the resource 'run' and enumerates exactly what is returned: lifecycle state, outcome, and current artifact counts. This distinguishes it from sibling tools like 'runs' (listing runs) and 'result' (likely final output), even without explicitly naming 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?

No explicit guidance is given about when to use this tool versus siblings such as 'result' or 'check'. The only cue is the implied condition that you need a run's lifecycle state, outcome, and artifact counts, but no alternatives or exclusions are 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?

With no annotations, the description carries the full burden. It discloses idempotency and that it targets a process tree, but it does not state side effects on collected data, reversibility, permission requirements, or behavior when no process is running.

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 short, front-loaded sentence; every word earns its place. 'Idempotently' is a high-value qualifier and 'running crawler process tree' precisely scopes the target.

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 a simple schema and an output schema, the definition omits usage context and behavioral side effects, which matters because annotations are absent. An agent cannot tell whether stopping is safe mid-write, whether data is persisted, or how stop relates to cleanup/delete_run.

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 no description for run_id (0% coverage), and the description never mentions run_id, its format, or where to obtain it. The schema title 'Run Id' and the tool's object give some implicit context, but the description itself adds no parameter-level meaning.

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 ('stop'), an object ('running crawler process tree'), and a key semantic ('idempotently'), which makes it distinguishable from sibling tools like delete_run or cleanup. It is not a tautology and conveys exactly what the 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?

No guidance is provided on when to use stop versus delete_run, cleanup, or status. The only implication is that it applies to a currently running process, but there are no exclusions, prerequisites, or alternative selection criteria.

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