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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds the guarantee 'Never returns secrets,' which is a valuable behavioral detail beyond the annotations. No other behaviors are disclosed, but given the tool's simplicity and annotation coverage, this is sufficient.

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 short sentences with no wasted words. The core function is front-loaded, and the safety guarantee is a concise addition. It is perfectly sized for the tool's simplicity.

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 zero parameters and the presence of an output schema, the description covers what the tool returns (providers with source and live status) and a key safety behavior. Nothing an agent needs to correctly invoke this tool 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 schema is empty with 100% coverage. Since there are no parameters to document, the description does not need to explain them. The baseline is high for a parameterless tool, and the description adds no parameter-related confusion.

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 it returns linked providers with source and live status, which gives a specific resource and what it provides. It implies a read-only listing but does not explicitly say 'list' or 'get all accounts.' It distinguishes from siblings like accounts_connect and accounts_remove by implying a read operation, though not 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 guidance is given on when to use this tool versus alternatives such as accounts_connect, accounts_remove, or others. There are no conditions or exclusions, leaving the agent to infer that it is for viewing accounts without any explicit direction.

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?

The description adds some behavioral details (validation, file permissions, request closure) beyond the all-false annotations, but these are cryptic. It does not explain what 'store' means, what happens to the request, or any side effects. Since annotations provide no safety profile (all false), the description carries the burden but fails to adequately disclose the mutation and its 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?

The description is extremely brief, which is technically concise, but it is a run-on list of actions without structure or context. It does not front-load a clear purpose and leaves the agent to infer meaning, making it more under-specified than genuinely concise.

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 an output schema, the description is incomplete for a mutation tool with all-false annotations. It omits when to use it, what the token and request_id represent, what 'complete' entails, and any prerequisites. An agent cannot reliably call this tool without additional context.

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

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

With 0% schema description coverage, the description must explain the two required parameters. It mentions 'pasted token' (loosely mapping to token) and 'close request' (mapping to request_id) but offers no details about formats, expected values, or how they interact. This is insufficient compensation for the absent schema descriptions.

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 lists three actions ('validate a pasted token live, store chmod 600, close request') without a clear, single-purpose statement. It gives a vague sense of completing an account link but does not explicitly say 'completes an account linking process' or what the resource is. The name and title are slightly clearer, but the description itself lacks specificity.

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 this tool versus siblings like accounts_connect, accounts_wait, or accounts_remove. The description gives no context about the linking flow, prerequisites, or exclusions, leaving the agent without direction.

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

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

Annotations are all false and offer no safety hints, so the description carries the burden. It discloses the core behavior and return fields (open-link, request_id, already:true), but it does not explain side effects such as whether a pending connection/request is created, whether repeated calls are safe, or how the returned link is used.

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 entire description is one compact sentence that front-loads the action, then lists return values in parentheses. No words are wasted, and the special already:true case is included efficiently.

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 single-parameter tool with an output schema present, the description is mostly complete: it names the provider values and the expected result shape. It could mention that the open-link requires user action or that request_id is used in a later completion step, but those are optional 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?

The schema merely defines provider as a string with no description and 0% schema coverage. The description compensates by listing the acceptable providers (github, vercel, cloudflare), giving an agent concrete input guidance that the schema alone lacks.

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 ('Start linking') and names the exact resources (github, vercel, cloudflare), clearly identifying this as the initial step in connecting an external account. This differentiates it from sibling tools like accounts_remove or accounts_complete, whose roles are distinct.

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 as the entry point to an account-linking flow ('Start linking') and signals a no-op when already connected ('or already:true'), but it never explicitly says when to use this instead of accounts_wait or accounts_complete, nor does it describe prerequisites.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds useful behavioral context beyond that: 'Prompts.' signals the tool will prompt (likely for confirmation), and 'CLI logins untouched' clarifies what is not affected. This gives the agent expectations for interaction and scope without contradicting the annotations.

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 very short and front-loads the core action, which is good. But 'Prompts.' is an ambiguous standalone fragment that is structurally awkward, and the three fragments could be clearer as connected sentences. It is concise but not polished enough to be a model of clarity.

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 single-parameter destructive tool with annotations and an output schema, the description covers the main behavior (delete token), the prompting behavior, and the boundary (CLI logins untouched). The primary gap is parameter semantics—provider format and accepted values are unstated—which prevents it from being fully complete for correct invocation.

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

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

Schema description coverage is 0%: the only parameter, provider, has no description beyond its title. The tool description does not explain what values provider accepts, what it identifies, or how it maps to the stored token. The agent must infer from the name 'provider' that it specifies which provider's token to delete, but this is not explicit enough to compensate for the schema gap.

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

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

The description opens with a specific action and resource: 'Delete a stored token.' This clearly identifies the tool's function. The phrase 'CLI logins untouched' further distinguishes it from broader account deletion, and the sibling list includes other account tools (accounts_connect, accounts_wait) so the scope is explicit.

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 use is implied: call this tool to delete a stored token. The exclusion 'CLI logins untouched' provides some boundary, telling the agent this tool is not for removing CLI login credentials. However, it does not explicitly name alternatives or specify conditions for choosing this over related account 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?

Annotations already mark the operation as readOnly, and the description adds useful behavioral detail: the call blocks, polls every 5 seconds, and stops when the user authorizes or a timeout occurs. It does not contradict the readOnly hint.

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

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

Two short sentences convey the blocking behavior, the exit condition, and the polling cadence with no filler. All information is front-loaded and relevant.

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 wait tool in an authorization flow, the description omits how to obtain request_id (presumably from accounts_connect) and what happens when timeout is reached. The output schema may cover return values, but the operational flow is not 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. It mentions timeout behavior and a 5s polling interval, but never identifies request_id as the authorization request handle, and does not clarify timeout_seconds as the configurable max wait.

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 operation as blocking until the user authorizes (link opened) or timeout, with a polling interval of 5s. It distinguishes the wait behavior from sibling tools by describing the blocking action, but it does not explicitly name or contrast accounts_complete or accounts_connect.

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 its siblings, such as calling it after accounts_connect or before accounts_complete. The description implies a waiting step in an authorization flow but does not state prerequisites or exclusions.

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

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

Annotations already indicate the tool is mutating (readOnlyHint=false), idempotent (idempotentHint=true), and not destructive (destructiveHint=false). The description adds one useful implementation detail: it prefers the `patch` binary and falls back to a naive implementation. However, it does not explain failure behavior, conflict handling, or whether the fallback can partially apply changes.

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. Every clause adds information, including the fallback behavior. It is appropriately sized for the tool's apparent simplicity.

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 minimal schema descriptions, the description is too thin to fully support correct invocation. It omits behavior of dry_run, failure handling, and any distinction against direct file editing tools. The presence of an output schema does not compensate for these 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 0%, so the description carries the full burden for explaining parameters. It clarifies that `patch` should contain a unified diff, but it says nothing about `path` semantics or the `dry_run` flag. This is only partial compensation for an otherwise bare schema.

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

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

The description states a specific verb ('apply'), a concrete resource ('a file'), and a precise input format ('unified diff'). This clearly distinguishes it from sibling file-editing tools like write_file or edit_file, which operate on raw content or line edits.

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 a use case—applying a unified diff—but provides no explicit guidance about when to prefer this tool over alternatives such as edit_file, nor any exclusions or prerequisites. The agent must infer the appropriate 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?

Annotations already mark this as read-only, and the description adds important behavioral context: it returns only paths and sizes, never contents, and covers only mutating-tool audit records. This clearly sets expectations about what the agent will and will not receive, going well beyond the annotation alone.

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 worded sentence that front-loads the verb and resource while adding the critical 'never contents' constraint. Every word earns its place; there is no filler or redundancy.

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-only tool with one optional parameter and an output schema, the description covers the essential behavior, scope, and safety profile. It is slightly incomplete because it does not mention the sibling audit_search or explain when this recent-list tool is preferable, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry meaning for the single count parameter. The phrase 'last N' directly conveys that count controls how many records are returned, which is the essential semantic. It does not detail bounds or edge cases, but for one optional integer with a default, this is 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 states a specific verb ('Return'), a clear resource ('mutating-tool audit records'), and a precise scope ('paths and sizes only, never contents'). It is unambiguous about what the tool does, but it does not explicitly differentiate it from the sibling audit_search, so it misses full marks.

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 alternatives. The sibling list includes audit_search, which likely overlaps, but the description never mentions it or explains when the recent unfiltered list is preferable. The only clue is 'last N', which implies recency, but no when/when-not guidance is provided.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context by clarifying that the tool filter uses substring matching on the tool name and that the 'ok' parameter accepts true/false/any. This goes beyond the schema, which lacks enums or descriptions, and helps the agent understand the expected input 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, well-structured sentence that front-loads the action and key filtering criteria. Every word contributes value, with no fluff or redundancy.

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 search tool with an output schema and read-only annotations, the description covers the essential filtering semantics. The only minor gap is the lack of mention of the 'count' parameter's meaning, but this is a common concept and the default value is in the schema. Overall, it is complete enough 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 0%, so the description must compensate. It explains the 'tool' parameter (substring match) and the 'ok' parameter (true/false/any), but does not explain the 'count' parameter, which defaults to 50. This partial coverage adds value but leaves one parameter undocumented in both the schema and 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 states the verb 'Filter' and the resource 'audit trail', and specifies the filtering criteria (tool name substring and ok status). It is clear and specific, but does not explicitly differentiate from the sibling 'audit_log' tool, which likely shows the unfiltered log. Still, the purpose is unambiguous.

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 searching/filtering the audit log, but provides no explicit guidance on when to use this tool versus alternatives like 'audit_log' or other search tools. No exclusions or alternative conditions are mentioned, leaving the selection decision to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds useful behavioral context by explaining that the tool runs headless Chrome and returns extracted DOM text rather than, say, a screenshot or raw HTML. The 'Opt-in' note also conveys that this is an intentionally chosen, more invasive rendering step.

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

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

Two short sentences carry the core information with no filler. The first sentence front-loads the purpose and output, the second delivers the critical opt-in behavior. This is an appropriately sized description for a straightforward tool.

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 description is adequate for a high-level understanding but incomplete for safe invocation without guessing. With no output schema and three parameters, the agent would benefit from knowing that max_chars bounds the returned text and that rendering can time out. The opt-in flag helps, but the description still leaves important operational details 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?

The schema has 0% description coverage, so the description must compensate, but it only says 'Render JS page' and 'return DOM text.' It never explains that max_chars truncates the returned text or that timeout_seconds bounds the render wait. The url parameter is implied by 'page,' but max_chars and timeout_seconds are left entirely to the agent to infer from their names.

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 resource—'Render JS page in headless Chrome'—and clearly states the output: 'return DOM text.' This distinguishes it from plain fetch tools like http_fetch that do not execute JavaScript. The 'Opt-in' note further signals that this is a deliberate alternative to standard fetching.

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 'Opt-in' marker gives clear guidance that this tool should be used deliberately, not as a default fetch mechanism. It implies that the agent should choose it when JavaScript rendering is required, but it does not explicitly name the alternative or state 'use http_fetch for non-JS pages.' Thus it is clear but lacks explicit exclusions.

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

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

Annotations already mark this as non-readable, destructive, non-idempotent, and not open-world. The description adds useful behavioral context beyond those flags: output is written to files and the operation is 'opt-in' and 'prompts,' meaning user approval may be required. It does not describe overwrite behavior, but the destructive annotation already covers that risk.

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 extremely short and front-loaded: the core action comes first, followed by two important constraints. Every word earns its place and there is no redundant phrasing or restating of the tool name.

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 output schema exists and annotations cover safety, the description is minimally viable: it states purpose, output type, writable-path constraint, and prompting behavior. However, with four parameters and zero schema descriptions, an agent still lacks details about URL handling, dest path rules, width, and timeout behavior, so completeness is only average.

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 compensate. It only hints that dest must be in writable roots; it gives no guidance on URL format, dest naming/extension, width semantics, or timeout_seconds behavior. Without parameter descriptions, an agent must rely on titles and defaults alone, which is insufficient for confident invocation.

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?

Clearly states a specific action and result: 'Screenshot page to PNG.' It also adds a unique constraint, 'in writable roots,' which helps distinguish it from browsing/fetching siblings like browser_fetch or fetch_text. The verb+resource+output format removes ambiguity about 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?

The description conveys when to use this tool: whenever a visual PNG screenshot of a page is needed, with the constraint that output must go to writable roots. It does not explicitly name alternatives or say when not to use it, but it provides enough context for an agent to route correctly against fetch-type 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?

The description adds the permission requirement 'Needs Account:Read', which is beyond the readOnlyHint annotation. However, it does not describe the tool's behavior, return format, or any side effects. Since annotations already mark it as read-only, the added permission note provides minimal behavioral context.

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 very short with two fragments, but the first fragment is cryptic and not a proper sentence. It is concise but under-specified, lacking a clear verb and structure. The permission note is separate but does not improve clarity.

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 an output schema and no parameters, the description fails to state the tool's purpose clearly. It does not explain what 'first account' means, whether it returns a list or a single object, or why it would be used. The description is incomplete for an agent to confidently invoke it.

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 schema coverage is 100% (no parameters to document). The baseline for 0 parameters is 4, and the description does not need to add parameter information. This dimension is adequate by 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 description 'First account id/name' is a noun phrase without a verb, so it does not clearly state an action. It could be interpreted as a command to fetch the first account, but the intent is ambiguous. It does not distinguish itself from siblings like cloudflare_zones, though the 'account' focus hints at a retrieval.

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. There is no mention of context, prerequisites beyond the permission note, or how it fits into a workflow. The agent is left to guess when this should be called.

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

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

Annotations declare readOnlyHint=true, so the description does not need to restate that. It adds the detail that zone can be a name or id, which is a minor behavioral note. However, it does not disclose any other behavior such as pagination, limits, or how records are ordered, but given the annotation coverage this is acceptable.

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

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

The description is a single, front-loaded sentence with no filler. It states the core action and the key nuance about the zone parameter. 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?

While an output schema exists, the description is incomplete for a tool with three parameters and zero schema descriptions. It does not explain what 'name' and 'dtype' are used for, nor does it mention any filtering or options. An agent would have to guess or inspect other tools to understand the full interface.

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 lack of parameter documentation. It only explains that 'zone' can be a name or id, but leaves 'name' and 'dtype' entirely unexplained. With three parameters, two are completely ambiguous, making it hard for an agent to call correctly.

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 ('List DNS records') on a specific resource ('for a zone'), and clarifies the zone can be provided by name or id. This clearly distinguishes it from sibling tools that create, delete, or purge DNS records.

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. It does not mention that it is a read-only listing operation or when one might prefer cloudflare_dns_create or delete. The agent must infer usage from the verb 'List' and 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?

Annotations already communicate that this is a mutating, non-idempotent operation with a destructive hint, and the description does not contradict that. However, it adds no extra behavioral context, such as duplicate record handling, permission requirements, or reversibility, leaving the burden entirely on annotations.

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 short but not effectively concise: the second sentence ('Prompts.') is an unexplained fragment that adds noise. For a tool with six parameters and no schema descriptions, this brevity constitutes under-specification rather than thoughtful conciseness.

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, the description is insufficient for correct invocation. Required parameters are undocumented, there is no mention of how this fits with cloudflare_dns list/delete workflows, and no error conditions or edge cases are noted. For a mutating Cloudflare operation, this is a significant completeness 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 provides zero information about the six parameters (zone, dtype, name, content, ttl, proxied). An agent cannot infer accepted values or formats, such as what dtype values are valid or whether zone expects a name or ID, making this a critical gap.

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

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

The description names a specific verb ('Create') and resource ('DNS record'), which clearly conveys the core function and distinguishes it from siblings like cloudflare_dns_delete. However, the trailing 'Prompts.' is an unexplained artifact that slightly detracts from clarity.

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 cloudflare_dns (listing) or cloudflare_dns_delete, nor any prerequisites such as selecting a zone. The name implies creation, but the description provides no explicit context, exclusions, or workflow hints.

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

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

Annotations already declare destructiveHint=true, so the description's 'Delete' adds no new behavioral insight. It doesn't disclose irreversibility, permission requirements, or side effects. The 'Prompts.' fragment is meaningless. With annotations covering the destructive nature, the description adds negligible value.

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 main sentence is concise and front-loaded, but the trailing 'Prompts.' is waste and unclear. Under-specification rather than efficient conciseness—it omits essential 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 destructive 2-parameter tool with an output schema (not shown), the description should at least note that deletion is permanent or requires a valid zone and record ID. It lacks any such context, leaving an agent to guess. The output schema may cover return values, but prerequisites and side effects are missing.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by id' but doesn't explain that 'zone' is the Cloudflare zone identifier or that 'record_id' is the specific DNS record ID. No format or examples. The description adds minimal meaning beyond the bare parameter names.

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 ('Delete') and resource ('DNS record by id'), which is clear and distinguishes it from cloudflare_dns_create. The trailing 'Prompts.' is odd but doesn't mislead. It lacks explicit sibling differentiation but the action is obvious.

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

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

No guidance on when to use this tool versus alternatives like cloudflare_dns or cloudflare_dns_create. No mention of prerequisites (e.g., needing a zone ID) or when deletion is appropriate. Usage is implied but not explicit.

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

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

Annotations already mark the tool as destructive (destructiveHint=true), so the description adds little. 'Prompts.' could imply a confirmation step, but it is vague and unexplained. No additional behavioral context such as impact on cache or reversibility is provided.

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 short but not effective. The second sentence 'Prompts.' is unclear and appears to be a placeholder or incomplete thought. It does not earn its place and detracts from clarity.

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 tool with one parameter and no parameter explanation, the description is inadequate. It does not mention required inputs, effects, or any cautions. The presence of an output schema does not compensate for missing parameter and usage details.

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 explain the 'zone' parameter. It does not indicate whether a zone ID or name is expected, or any format. The single parameter remains completely undocumented.

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 phrase 'Purge a zone cache' clearly identifies the action and resource. It is distinct from sibling Cloudflare tools like cloudflare_dns or cloudflare_zones, though it does not explicitly name alternatives.

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 or when to prefer a sibling. The cryptic 'Prompts.' adds no context. There is no mention of prerequisites like obtaining the zone ID.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to restate that it is a read-only operation. It adds a practical note that a token is required, which is useful behavioral context. However, it does not describe what happens if the token is missing or invalid, nor any pagination or error behavior. With annotations covering the safety profile, the added token requirement justifies a 3.

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 extremely concise: two short sentences that immediately state the purpose and a key requirement. There is no filler, and the core action is front-loaded. Every word adds value, making it an ideal model of efficiency.

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 optional parameter, no required fields) and has an output schema, so the description need not detail return formats. However, the 'name' parameter is completely unexplained, and the token requirement lacks specifics (e.g., how to provide it or error behavior). These gaps prevent the description from being fully complete, though the overall simplicity keeps it from being inadequate.

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 description coverage is 0%, so the description must compensate for parameter clarity. The schema has a single optional 'name' parameter with a default, but the description never mentions it. The agent is left without any explanation of what 'name' does—whether it filters zones, acts as an exact match, or something else. This is a significant gap given the schema provides no descriptions, and the description does not address the parameter at all.

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 the action ('List zones') and identifies the resource (zones) along with the returned fields (id, name, status, plan). It differentiates from sibling tools like cloudflare_dns or cloudflare_purge, which focus on other Cloudflare operations. The verb and resource are specific, leaving no ambiguity about 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?

The description implies the tool is used to list zones, but it does not explicitly state when to use it versus alternatives or when not to use it. It mentions a prerequisite ('Needs token') but no exclusions or alternative tools are referenced. The guidance is implied rather than explicit, so it meets the threshold for a 3 but lacks direct routing to or away from other 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?

The readOnlyHint and openWorldHint annotations already establish that this is a safe, non-mutating local query. The description adds that it reads active sockets via ss or netstat, but it does not disclose potential permission requirements or how the limit interacts with the query.

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 compact sentence with no filler. It front-loads the resource and method, 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?

For a simple read-only tool with one optional parameter and an output schema, the definition is mostly adequate. The main gaps are the undocumented limit semantics and the lack of guidance distinguishing this tool from similar network inspection siblings.

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

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

Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The agent must infer from the property name and default that limit caps the number of returned connections, but the description provides no compensating clarification.

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 jointly specify a clear verb (List) and resource (active TCP/UDP sockets), with useful implementation detail ('via ss or netstat'). It does not explicitly differentiate from sibling network tools such as port_list or network_check, so it stops short of a 5.

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

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

The description implies the tool is for inspecting current TCP/UDP socket connections, which gives some usage context. However, it gives no explicit guidance on when to prefer it over alternatives like port_list, port_check, or network_check, and no 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?

Annotations provide no safety hints (all false), so the description carries the full burden. It discloses that write operations require confirmation ('Writes need confirm+full'), which is a meaningful behavioral trait. However, it does not explain the meaning of 'full', nor does it address error handling, result format, or side effects beyond the confirmation requirement. This is a partial disclosure but not comprehensive.

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 extremely concise—one sentence—and front-loads the key constraint (SELECT-first). It wastes no words. However, its brevity comes at the cost of clarity, omitting essential details about parameters and usage. It is concise but under-specified, which balances to a middle score.

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 tool executes arbitrary SQL, making it complex and potentially dangerous. With no schema descriptions, no annotations, and an output schema that is not described in the text, the description is inadequate. It does not explain return behavior, error handling, parameter details, or the 'full' requirement for writes. For a tool of this power, the description is far from 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 all four parameters. It only indirectly references the 'confirm' parameter and introduces the ambiguous term 'full'. The dsn, sql, and limit parameters are not explained at all. Given the high parameter count and lack of schema descriptions, the description fails to clarify parameter meanings.

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 the tool executes SQL queries, specifically SELECT-first, and supports postgres and sqlite. It distinguishes the tool from siblings like db_tables (which lists tables) and db_status (status) by its focus on arbitrary SQL execution. However, it does not explicitly name these alternatives, so it lacks the explicit differentiation seen in higher-scoring examples.

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 does not provide explicit guidance on when to use this tool versus alternatives such as db_tables or db_status. While the SELECT-first wording implies a preference for read-only queries, there is no mention of when to choose this tool over others or any exclusions. The usage context is only implied, not 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by stating 'keyless' and specifying the targets (sqlite files, postgres/redis reachability), which goes beyond the annotations. It does not, however, describe what the probe actually does (e.g., open connections, ping, read files) or what conditions count as reachable, so it only modestly increases transparency.

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 very short and front-loaded: 'Keyless DB probe' immediately conveys the core purpose, followed by the list of targets. It wastes no words, though it is a fragment rather than a complete sentence and omits a clear imperative verb, which slightly reduces structural quality.

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 zero-parameter tool with an output schema, the description is minimally adequate: it names the target systems and the probe intent. Yet given the large sibling set containing db_query, db_tables, and redis_get, the description would benefit from stating when this probe is preferred (e.g., for quick health checks without credentials) and what 'reachability' means. The missing usage context prevents a higher score.

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 schema description coverage is 100%, so the schema fully describes the input surface. The description adds nothing about parameters, but none are needed; the baseline of 4 for zero-parameter tools 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 identifies a specific resource (sqlite files, postgres/redis) and a distinct operation kind (probe for reachability/status), which is not a generic restatement of the name 'DB status'. However, it is phrased as a noun phrase rather than a clear imperative verb like 'Check', and it does not explicitly contrast with db_query/db_tables or redis_get, so it is clear but not maximally action-oriented.

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 db_query, db_tables, redis_get, or system_summary. The word 'keyless' hints that it is for probing without credentials, but the description never states a condition like 'use this to check reachability before running a query' or names any sibling alternative.

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?

All annotations are false, so the description carries the full burden for behavioral disclosure. It only says 'List tables,' with no indication of whether connections are opened, whether the operation is expensive, error behavior, or any side effects. This is minimal but not directly contradictory with the annotations.

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?

Five words with no filler, and the core action is front-loaded. 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?

The tool is simple and has an output schema, so return values need no explanation. However, the DSN parameter is undocumented, and with zero useful annotations the description leaves an agent without enough context about valid input and behavior for a fully confident call.

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

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

Schema description coverage is 0% and the single parameter dsn has only a default. The description merely repeats the DSN concept instead of defining what a valid DSN looks like, where to obtain one, or how it affects the listing. It does not compensate for the missing schema 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 and resource: 'List tables for a DSN.' It clearly distinguishes the tool from related siblings like db_query (query execution) and db_status (server status), and the title reinforces the same meaning.

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 about when to call this tool instead of db_query, db_status, or other database-related tools. 'For a DSN' only states the parameter scope, not when listing tables is the appropriate action or what prerequisites apply.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and scope. The description adds specific behavioral detail: the order/tayers of checks (DNS, TCP, owner, HTTP, resources) and accepted target forms. It does not contradict the annotations and gives an agent a clear picture of what will happen when invoked.

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 terse line with no filler. It front-loads the core concept ('layered diagnosis') and packs the accepted formats and diagnostic layers without waste. Every token contributes to the tool's behavior.

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 single-parameter tool with an output schema present, the description covers the input format and the diagnostic layers sufficiently. However, terms like 'owner' and 'resources' are left undefined, and there is no example or note on what a typical invocation looks like. It is adequate but leaves room for misinterpretation.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning. It explains that the single 'target' parameter can be host:port, http(s)://, or service:NAME, which directly informs how to fill the argument. Some sub-terms like 'owner' and 'resources' are not expanded, but the core syntax is useful.

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 clear action ('layered diagnosis') and defines the target formats (host:port, http(s)://, service:NAME). It also lists the diagnostic layers (DNS/TCP/owner/HTTP/resources), which distinguishes it from simpler single-purpose siblings like dns_lookup or port_check. However, it does not explicitly name any alternative tool, so differentiation is implicit rather than explicit.

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 input syntax but no guidance on when to choose this tool over siblings such as port_check, dns_lookup, network_check, or service_status. It implies a use case for layered diagnosis but does not state exclusions or provide decision criteria. There is no mention of prerequisites or typical scenarios.

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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the useful behavioral detail that noise directories are hidden, but it does not define what counts as noise or how depth and max_entries affect the output. This is meaningful but incomplete behavioral 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?

The description is a single, front-loaded sentence that states the action, output format, and the key filtering behavior. There is no redundant or filler wording. Every part of the 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 simple read-only tool, the description is mostly adequate, and the presence of an output schema reduces the need to describe return values. However, the ambiguity of 'noise dirs hidden' and the lack of usage differentiation from list_directory are noticeable gaps. An agent could still invoke the tool correctly, but may misjudge what is omitted from the output.

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 provides no explanation of path, depth, or max_entries. An agent must rely solely on the parameter names and defaults in the schema, which is thin for a tool with three parameters. The description adds no value beyond what the schema already exposes.

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 ('Render') and resource ('ASCII tree of a directory'), making the tool's function immediately clear. The parenthetical 'noise dirs hidden' adds a meaningful behavioral qualifier. This distinguishes it from sibling tools like list_directory, which would not produce a tree structure.

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 guidance on when to use directory_tree versus alternatives such as list_directory, find_files_tool, or file_search. There is no mention of when the tree format is preferable, nor any exclusions or conditions. Usage must be inferred entirely from the tool name and one-line description.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying platform differences (df vs drive usage) and the 'allowed path' concept, which goes beyond the annotation. It does not contradict annotations, and the added context is useful.

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, efficient sentence that front-loads the main purpose. Every word earns its place, with no filler or repetition. It is concise and well-structured.

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 tool with one optional parameter and an output schema, the description is mostly sufficient, but the phrase 'allowed path' is ambiguous—it does not define what 'allowed' means (e.g., permissions, path type, or allowed directory). The return format is covered by the output schema, but the missing clarification of 'allowed path' could confuse an agent. Given the tool's simplicity, this gap is notable but not fatal.

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 explain the 'path' parameter. It mentions 'size of one allowed path,' which gives a hint that the path is used to retrieve its size, but it does not clarify that the parameter is optional (as indicated by the schema default ''), nor does it explain the default behavior when no path is provided. The description partially compensates but lacks full semantic detail.

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 the tool's function: 'Show filesystem usage' plus size of one allowed path. It is specific (verb 'Show', resource 'filesystem usage') and differentiates from siblings by noting platform-specific behavior (df on Linux/macOS, drive usage on Windows). No sibling tool has a similar purpose, so it stands alone.

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

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

The description implies usage contexts (displaying disk usage and path size) but does not explicitly state when to use this tool versus alternatives. There are no obvious sibling tools for disk usage, so the lack of explicit exclusions is acceptable, but it doesn't provide guidance on when not to use it or alternative approaches.

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?

The annotations already indicate a read-only operation (readOnlyHint=true) and external world access (openWorldHint=true). The description adds no behavioral context beyond restating the core function, such as reliance on DNS servers, possible timeouts, multiple address records, or error behavior.

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

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

The description is a single, efficient sentence with no filler. The verb is front-loaded, and every word contributes to meaning. It is appropriately sized for a tool of this simplicity.

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, read-only, and has an output schema, so the description covers the basics. However, it lacks any guidance on when to reach for this tool over related network tools and does not describe output characteristics such as address families or failure cases. It is minimally viable but leaves room for useful context.

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 single required parameter has no schema description (0% coverage), but the description clarifies that 'host' expects a hostname rather than a URL or raw IP. This provides minimal semantic value, though it does not specify format details like whether FQDNs, trailing dots, or protocol prefixes are accepted.

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 a specific verb ('Resolve') and resource ('a hostname') with a concrete result ('to addresses'). It is recognizable as a DNS lookup, but it does not explicitly differentiate itself from sibling tools like network_check or host_identity.

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 web_search, network_check, or http_fetch. The intended usage is only implied by the tool's name and terse description, and no exclusions or follow-up tools 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?

Annotations already flag this as destructive, so the description does not need to restate that. It adds value by disclosing that --privileged is blocked, a meaningful security boundary. The core behavior of running a shell command inside a container is clearly stated.

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 extremely concise and front-loaded. Every word earns its place: the primary action, the target resource, and the key security restriction are all included with no filler.

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

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

The tool is relatively simple and has an output schema plus annotations covering destructiveness, so the description does not need to explain return values. However, it leaves important operational context unstated, such as whether the container must already be running and how timeout_seconds affects execution.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It loosely maps 'command' via 'Run sh -c' and 'container' via 'inside a container', but it completely omits timeout_seconds and gives no detail on command format or container identifier expectations.

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

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

The description states a specific action ('Run sh -c') and a specific resource ('inside a container'), which clearly identifies the tool's function. It is inherently distinguishable from sibling tools like docker_ps, docker_logs, or docker_inspect, none of which execute arbitrary commands inside a container.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as run_command, docker_logs, or docker_start. The only qualification is '--privileged blocked,' which is a constraint rather than a usage guideline.

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

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

Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds that the tool returns state, image, ports, and mounts, which is useful context. However, it does not disclose error behavior (e.g., if the container does not exist) or that the output is detailed JSON, but the output schema likely covers the format. With annotations, the description adds moderate value.

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 that front-loads the key information types. There is no waste or redundancy, making it highly efficient.

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, so return values do not need to be explained. The description gives a high-level summary of what is inspected. However, it does not mention that this is for a single container or that it provides low-level configuration details, which could help an agent decide when to use it. Overall, it is minimally adequate given the output schema and 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?

The input schema has a single required parameter 'container' with no description, and schema description coverage is 0%. The description does not explain the expected format (ID or name), nor does it clarify that this is the container to inspect. Given the low coverage, the description should compensate but does not.

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 the tool inspects a container and lists the categories of information returned (state, image, ports, mounts). This is clear and specific, though it could explicitly say 'inspect' rather than relying on the name. It distinguishes from siblings like docker_ps (list) and docker_logs (logs) by indicating detailed info, but does not name alternatives.

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

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

No guidance on when to use this tool versus docker_ps, docker_logs, or other container tools. The description does not state when inspection is appropriate or provide exclusions. The use case is only implied by the name and description.

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

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

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the notion of 'tailing' (recent log lines) but does not clarify whether the tool streams continuously or returns a one-shot snapshot, nor how the 'lines' parameter affects 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?

The description is a single sentence with no filler; it is immediately readable and front-loaded. No words are wasted.

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

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

For a simple read-only log tool with two parameters, the description is minimally adequate, but it omits whether the operation blocks/follows, how to specify the container, and how it differs from other log tools. The output schema and readOnlyHint fill some gaps, but the vague 'Tail' behavior leaves important runtime uncertainty.

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 elaborate on either parameter. 'container' and 'lines' are self-evident from their names, but the description fails to explain that 'lines' controls the number of lines returned or that 'container' expects an ID/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?

States a specific verb ('Tail') and resource ('logs of a container'), making its operation clear and distinguishable from sibling Docker tools like docker_inspect or docker_ps. The 'container' in the description aligns with the required parameter, leaving no doubt about the target resource.

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 this tool versus alternatives such as vercel_logs, journal_query, or job_output. The description merely restates the action without prerequisites, exclusions, or selection 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?

The readOnlyHint annotation already discloses that this is a safe read operation. The description adds useful behavioral context by noting that running containers are shown by default and that 'all=true' expands coverage, which goes slightly beyond the annotation but does not provide deeper details such as output format or environment assumptions.

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

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

The description is a single sentence that front-loads the core operation and then explains the one parameter's effect. There is no filler or redundant restatement of the tool name.

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 listing tool with one optional boolean parameter, a readOnly annotation, and an output schema. The description covers the default and all-case behavior, leaving no missing information needed to invoke the tool correctly in its likely use contexts.

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 only provides a boolean named 'all' with a default of false, and schema description coverage is 0%. The description compensates by explaining the effective meaning: running containers by default, and all containers when 'all=true'. This gives the agent enough semantic understanding to set the parameter correctly.

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 containers'), which makes the tool's primary function immediately clear. It also clarifies the default behavior (running only) and the way to override it, distinguishing it from the many docker_* siblings that inspect, modify, or manage containers.

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 the tool: when you need to list containers, especially running ones. However, it does not explicitly state when not to use it or mention alternatives like docker_inspect or docker_logs for more detailed per-container information.

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?

The annotation already marks this as destructive (destructiveHint: true), so the description doesn't need to repeat that. It adds the 10s timeout, which is useful but not comprehensive. It doesn't explicitly state that restarting stops and then starts the container, which would imply downtime. Given the annotation covers the destructive nature, the description provides only a minor behavioral detail, so a 3 is appropriate.

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, efficient sentence that states the operation first and the timeout parenthetically. No wasted words; it is appropriately concise and 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?

For a destructive tool with an output schema and a single parameter, the description is too sparse. It doesn't provide usage context (when to use vs. stop/start), doesn't mention that the container will be stopped and restarted, and doesn't clarify the parameter format. Even though the output schema exists, the description leaves the agent with gaps about invocation and side effects.

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

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

Schema coverage is 0% and the description only says 'Restart a container,' which implies the parameter is the container but doesn't specify whether it's an ID, name, or how to format it. The description adds minimal meaning beyond the schema's bare 'container' string field. For a single-parameter tool, more detail (e.g., 'Provide the container ID or name') would be expected.

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 the action ('Restart') and the target ('a container'), making the tool's purpose unambiguous. It distinguishes from siblings like docker_start, docker_stop, and docker_rm by the specific verb. The timeout note adds a useful detail without confusing the core purpose.

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 docker_stop followed by docker_start. It doesn't mention scenarios (e.g., container unresponsive) or why restart is preferred over stop/start. The agent is left to infer usage from the name alone.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate that this is destructive. It adds the precondition that the container should be stopped, which is useful behavioral context beyond the schema, but it does not explain what happens if a running container is passed or whether removal is irreversible beyond the annotation.

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 extremely short and front-loaded with the key action and target resource. There is no wasted wording, though the under-specification in other dimensions prevents a perfect conciseness score.

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 one-parameter destructive tool with an output schema and annotations covering safety, the bare description is minimally adequate. However, it lacks explicit guidance about handling running containers, and the single parameter is not semantically enriched, leaving some ambiguity for an agent deciding how to 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 schema has one required parameter, 'container', with no description, and schema description coverage is 0%. The description repeats that a container is removed but does not clarify whether the value should be a container ID, name, or how to identify the container, so the parameter remains under-specified.

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 ('Remove') and resource ('container'), plus the relevant state condition ('stopped'). This clearly distinguishes it from sibling tools like docker_start, docker_stop, and docker_restart, which perform different lifecycle operations.

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 word 'stopped' implies the tool is for containers that are not running, which hints at when to use it, but it does not explicitly say 'use docker_stop first for running containers' or name alternatives. The usage guidance is therefore only implied, not explicit.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds no additional behavioral information such as side effects, state changes, or required container existence. It does not contradict annotations, but fails to enrich them.

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 extremely concise with a single sentence, but it is under-specified rather than efficiently front-loaded. There is no wasted wording, but the lack of essential details means it does not earn its place as a standalone definition.

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 tool is simple with one parameter, the description should cover at least the container identifier and expected behavior. It does not mention what happens if the container is already running, whether it must exist, or the output format. The output schema exists but is not shown, so the description carries responsibility for usage context, which it fails to provide.

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 one required parameter 'container' with no description, and schema coverage is 0%. The description does not explain what the container parameter should be (ID, name, format) or any constraints. This is a critical gap because the agent has no guidance on how to fill the parameter correctly.

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 'Start a container' clearly states the verb and resource, making the primary action unambiguous. However, it does not differentiate from sibling tools like docker_stop, docker_restart, or docker_exec, though the distinct verb helps. It is specific enough for an agent to know what it does, but lacks context about scope.

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 such as docker_restart or docker_start with specific flags. No exclusions, prerequisites, or conditions are mentioned. The description merely states the action without any 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?

The description adds a behavioral detail beyond annotations: the 10-second timeout. Annotations already declare the operation is destructive and not read-only, so the description does not need to restate that safety profile.

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 entire description is one short sentence with no redundant words. The core action is front-loaded, and the timeout is presented as a concise parenthetical detail.

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 one-parameter tool with an output schema and safety-related annotations, the description covers the essential operation and the timeout. It does not explain return values, but the output schema handles that, and no major contextual gap remains for normal usage.

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 one required parameter ('container') with no description, and the description provides 0% schema coverage. The description only restates the resource concept but does not clarify whether the parameter expects a container ID, name, or other identifier, so it fails to fully compensate for the missing schema 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 ('Stop') with a clear resource ('a container') and adds a timeout detail, making the tool's function immediately obvious. It also distinguishes itself from sibling tools like docker_start, docker_restart, and docker_rm by naming the exact operation.

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 clearly conveys when to use the tool: when you want to stop a container. It does not explicitly contrast with sibling tools such as docker_restart or docker_rm, but the context is clear enough to avoid obvious misuse.

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?

The annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false, covering safety aspects. The description adds useful context: the 'writable roots' constraint and the total size cap. However, it does not elaborate on what happens when dest already exists (overwrite behavior is only in the schema default) or the implications of the idempotent hint. It adds some value but not rich behavioral detail.

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, efficient sentence that front-loads the action and key constraint. It is appropriately concise, though it could briefly mention overwrite or timeout behavior without becoming verbose.

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 download tool, the description covers the core operation and a key constraint (writable roots, size cap). However, it omits details like what happens on URL failure, the exact handling of the overwrite flag, and any guidance on relative vs. absolute dest paths. With an output schema present, return value details are covered, but the description leaves room for ambiguity in edge cases.

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

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

Schema description coverage is 0%, meaning the schema has no property descriptions. The description mentions 'writable roots' as a constraint on dest, which provides some semantic guidance, but it doesn't explain the format of url, dest, overwrite, or timeout_seconds beyond what their names imply. Since the description carries the full burden for parameter semantics but only hints at one constraint, it is insufficient.

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 the action: downloading an http(s) URL to a file, with the constraint 'inside writable roots.' This is a specific verb+resource combination that distinguishes it from general fetch or read operations, though it doesn't explicitly name alternative siblings like fetch_text or http_fetch.

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 such as fetch_text, http_fetch, or browser_fetch. The description only explains what it does, leaving the agent to infer the appropriate context. No exclusions or when-not-to-use conditions are provided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's implicit write behavior adds nothing new. The 'Prompts.' hint suggests an interactive confirmation step, but this is too vague to be useful and does not disclose consequences like overwrite behavior or error handling. No contradiction with annotations, but minimal added transparency.

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 extremely short, but this is under-specification rather than conciseness. The fragment 'Prompts.' is poorly structured and adds confusion. It does not front-load key usage information, and every word should earn its place; here they do not.

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 parameter documentation, this description is wholly inadequate. It does not explain the purpose of 'writable roots', what 'Prompts' means, how overwrite works, or any return behavior. Even with an output schema present, the operational context is missing, making it impossible for an agent to use 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?

With 0% schema description coverage, the description must explain parameters but does not mention remote_path, dest, or overwrite at all. It provides zero semantic meaning for any of the three parameters, leaving the agent without guidance on what each field expects.

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 ('Copy remote file into writable roots') which conveys a clear verb and resource, but the phrase 'writable roots' is ambiguous and the trailing 'Prompts.' is confusing. It does not clearly differentiate from siblings like download_file or drive_list, and the mention of prompting is unexplained.

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. There is no mention of appropriate scenarios, exclusions, or references to sibling tools. The description gives no context about when copying a remote file is preferable over other operations.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds the RCLONE_REMOTE prerequisite, which is useful, but it does not disclose expected output format, pagination behavior, error handling, or any network/rate implications. Given the annotations cover the safety profile, the description adds minimal additional behavioral context.

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 that front-loads the core action and resource. It is efficient and avoids fluff. The inclusion of the RCLONE_REMOTE prerequisite is valuable. It is slightly terse but structurally sound.

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 tool has two parameters with zero schema descriptions, an output schema exists but the description does not reference it, and annotations are sparse, the description is incomplete. It does not explain how to construct a path (e.g., remote:folder), what max_entries does, or how results are returned. A more complete description would provide examples or clarify parameter 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 0%, and the description provides no parameter documentation. The path parameter is implied by 'remote path' but not explained in terms of format or examples, and max_entries is entirely undocumented. The description fails to compensate for the missing schema descriptions, leaving agents guessing about valid inputs.

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 the action 'List' and the resource 'rclone remote path', which is specific enough to distinguish from local file listing tools like list_directory. The prerequisite 'needs RCLONE_REMOTE' adds context. However, it does not specify whether the listing returns files, directories, or both, leaving some ambiguity about the exact scope.

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. The sibling list includes list_directory, file_search, and drive_get, but the description does not differentiate drive_list from these or explain when a remote listing is appropriate. The only hint is the RCLONE_REMOTE prerequisite, which is an environmental requirement rather than a usage condition.

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

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

The description adds the dry_run behavior, which is not covered by annotations. However, it does not disclose other behavioral traits such as what happens if the old string is not found, whether the file is modified in place, or how replace_all affects the operation. Annotations indicate non-readonly and non-destructive, but the description does not elaborate on side effects. It provides some context but is thin.

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 concise and front-loaded with the core action, which is good. However, it is so short that it omits essential parameter details and usage context. While conciseness is valued, it comes at the cost of completeness, making it only minimally acceptable.

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 tool has five parameters with three required and an output schema, the description should cover input semantics and notable behaviors. It does not explain the required parameters (path, old, new) or the replace_all option, and it does not mention error conditions or return value expectations. It is incomplete for an agent to use this 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?

Schema description coverage is 0%, so the description must compensate by explaining parameters. It only mentions dry_run, and even that is already present in the schema with a default and title. It does not explain path, old, new, or replace_all, leaving the agent to infer their meaning from parameter names. This is insufficient for a low-coverage situation.

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: 'Replace an exact string in a file.' This clearly identifies the verb and resource. It implicitly differentiates from patch-based tools by emphasizing 'exact string,' but it does not explicitly name alternatives or contrast with siblings like apply_patch or write_file.

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. The description does not mention scenarios where edit_file is preferred over apply_patch or write_file, nor does it state any exclusions or prerequisites. Only the dry_run flag is mentioned, which is a usage detail, not a selection criterion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavior beyond that: it strips boilerplate, produces LLM-ready text, and limits redirects to three. This gives the agent useful expectations about transformation and safety without contradicting the annotations.

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

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

A single, front-loaded sentence with no filler. It states the action, transformation, output format, and a key constraint in under ten words. Every element 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, has an output schema, and read-only annotations, so the description covers core purpose and transformation. However, it lacks alternatives guidance and parameter details, making it slightly incomplete for an agent deciding between similar fetch 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 0%, so the description must compensate, but it does not explain max_chars or timeout_seconds behavior. While the URL parameter is obvious, the truncation and timeout semantics are left entirely to inference from names and defaults.

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 resource ('Fetch URL, strip boilerplate, return LLM-ready text') and includes a concrete constraint ('<=3 redirects'). This clearly distinguishes it from sibling search tools like web_search and from raw HTTP tools like http_fetch.

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 use for retrieving a URL's content as clean, LLM-ready text, but it does not explicitly state when to choose this over alternatives such as browser_fetch or http_fetch. There is no exclusion guidance or mention of cases like JavaScript-heavy pages.

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

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds useful prerequisite context ('Source must be readable, destination must be writable'), but it does not explain overwrite behavior or what happens when the destination already exists and overwrite is false. This is a moderate gap given the overwrite parameter exists.

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 focused sentence, front-loaded with the core action. Every part earns its place, and there is no unnecessary detail.

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 three-parameter copy tool, the description is mostly adequate, especially with an output schema present. However, it leaves the overwrite behavior implied rather than stated, which is important for an agent predicting side effects. The permission prerequisites are helpful but incomplete coverage of the tool's 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, but it only names source and destination without adding path format details or any semantics for the overwrite parameter. The overwrite behavior—whether existing files are replaced or cause an error—is not explained anywhere in the 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 states a specific action and resource: 'Copy a file or directory.' This clearly distinguishes it from sibling tools like file_move, file_delete, and file_restore. No ambiguity about 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?

The description gives clear context: use this when a copy of a file or directory is needed. It does not explicitly contrast with file_move or other file operations, so it misses the full 'when not to use' guidance, but the core usage is clear enough.

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

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

Annotations already convey destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds a valuable behavioral guarantee not present in the annotations: it never deletes a configured root itself. It does not detail failure modes such as missing paths or non-empty directories without recursive=true, but the core destructive boundary is clearly 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?

Two concise sentences, front-loaded with the action and target. Every clause earns its place: the first defines the operation and recursive behavior, and the second states a crucial safety limit. No filler or redundant repetition of schema or annotations.

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 tool with an output schema and annotations covering idempotence and destructiveness, the description is largely sufficient. It covers the purpose, the recursive condition, and the key safety exception. Minor ambiguity remains around what 'configured root' means and whether recursive deletion removes contents or just the directory itself, but these are acceptable gaps at this complexity.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains that path can reference a file or directory and that recursive=true enables directory deletion, while also adding the root-protection constraint on path. It does not specify path resolution or exact non-recursive directory behavior, but the essential semantics are well covered.

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 the operation explicitly with a specific verb and resource: 'Delete a file, or a directory when recursive=true.' The safety constraint 'Never deletes a configured root itself' adds meaningful scope and distinguishes it from read, copy, move, and restore siblings. It is not a tautology and leaves no doubt about 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?

The description implies when to use the tool: when a file or directory needs to be removed, with recursive=true required for directories. However, it does not explicitly contrast with alternatives such as file_restore, file_move, or other file operations, and it gives no 'when not to use' guidance. The root-protection statement is a behavioral constraint rather than usage direction.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying recursive search behavior and the fallback chain (ripgrep to grep to Python). However, it omits details like output format, error handling, or match limits beyond the default, leaving the agent with incomplete behavioral expectations.

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: the first front-loads the core purpose, the second adds relevant implementation context. No filler words, and each 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 tool with three parameters, no schema descriptions, and a large sibling set, the description is too sparse. It lacks parameter semantics for root and max_matches, no usage guidance, and doesn't clarify return value behavior despite having an output schema. An agent would need to infer too much.

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. It clarifies that pattern is a regex, but leaves root (presumably a directory path) and max_matches (maximum number of matches) unexplained. This is insufficient given zero schema descriptions.

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 the tool recursively searches file contents for a regex pattern, which is a specific verb+resource. However, it does not differentiate from siblings like search_text_tool or fuzzy_find_tool, which also search text, so it lacks explicit sibling distinction.

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 only mentions implementation details (ripgrep fallback), not selection criteria or exclusions. An agent would have no basis to choose this over similar search 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?

Annotations already mark this as destructive and non-read-only, and the description does not contradict them. It adds useful context like supporting both files and directories and restricting operations to writable roots, but it does not disclose what happens to the original after a move or how overwrite failures 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?

One sentence of 13 words that is front-loaded with the core action and scope. No filler or redundant restatement of the tool name/title.

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