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

With no annotations, the description carries the full burden. It discloses '[WRITE][risk=medium]', 'No undo', 'captures prior stats for audit', and 'Takes a brief read lock while sampling', all beyond what structured data provides.

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 front-loaded with a purpose/risk header, followed by two concise behavioral sentences and a clean Args list. Every sentence earns its place with no repetition of schema defaults.

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 no annotations and no output schema, the description covers the operation's purpose, risks, locking, preview option, and all parameters. It is a complete and self-contained specification for this tool.

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

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

Schema description coverage is 0%, but the description includes an Args list that explains all three parameters: table (optionally schema-qualified), dry_run (preview), and target (config default). This fully compensates for the missing 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 opens with '[WRITE] ANALYZE TABLE to refresh index statistics', providing a specific verb and resource. This clearly distinguishes it from sibling tools like index_stats (read-only) and optimize_table (broader maintenance).

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 use case (refresh index statistics) and notes a brief read lock and no undo, giving clear context. However, it does not explicitly name alternatives or exclusions, so it stops short of a full 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly marks the operation as [READ], and lists the data areas (binary-log config, GTID mode, replicas). However, it does not mention permissions, output format, pagination, or error behavior. This is adequate for a simple read-only status tool but leaves some gaps.

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 front-loaded sentence for the purpose and one for the parameter. No wasted words, perfect structure.

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 read-only tool with no output schema, the description is largely complete. It states what the tool reads and explains the one optional parameter. It does not explain return values in detail, but that is less critical for a status tool. Overall, it is sufficient for basic use.

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 provides no description for the target parameter (0% coverage). The description fully compensates by explaining 'Target name from config; omit for the default.' This adds clear meaning to the parameter beyond the schema's type/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 uses a specific verb and resource: '[READ] Binary-log configuration, GTID mode, and connected downstream replicas'. This clearly identifies what the tool does and distinguishes it from sibling tools like replica_status or show_variables.

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. It does not mention prerequisites, related tools, or scenarios where this should be preferred. The only usage hint is the optional target parameter.

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

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

With no annotations provided, the description carries the full burden. It includes a [READ] tag indicating read-only behavior and frames the tool as an early-warning indicator, which is useful context. However, it does not disclose what the return value looks like (e.g., raw numbers, percentages, or a threshold flag) or any pagination/error behavior, leaving a gap in behavioral 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 concise, with a clear [READ] prefix and a substantive one-line purpose statement followed by a focused argument explanation. Every word earns its place, and the structure makes the key points immediately accessible.

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's simplicity (one optional parameter, no output schema, no annotations), the description gives the core purpose and argument. However, it omits specifics about the output format or how the 'early warning' is expressed, which could leave an agent uncertain about what to expect in the result. For a monitoring tool, a brief note on the return shape would make it fully complete.

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

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

The input schema only shows a parameter 'target' with a null default and no description. The description adds crucial meaning: it is 'Target name from config' and 'omit for the default', which clarifies both the source and optionality. Even though schema coverage is 0%, this single parameter is fully explained, compensating for the schema's lack of 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 identifies the resource 'Connection counters' and the comparison target 'max_connections', with an explicit 'early warning' purpose. It does not use a verb like 'retrieve' or 'show', but the [READ] tag and context make the action implicit. It is distinct from sibling tools focusing on queries, locks, or replication.

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

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

The phrase 'exhaustion early warning' implies a monitoring use case, suggesting this tool is for watching connection pool exhaustion. However, there is no explicit guidance on when to use this versus other monitoring tools like lock_waits or long_running_queries, nor any exclusions or alternatives 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?

With no annotations, the description carries the full burden. It discloses the write risk ('[WRITE][risk=medium]'), reversibility (undo drops the created index), the return value used for undo recording, dry-run preview behavior, and shape validation for the definition input. This is substantial behavioral 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 well-structured with a brief overview and sectioned Args list. It is slightly redundant ('Pass dry_run=True to preview' and then 'dry_run: If True, preview without creating') but every line generally earns its place given the parameter count.

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 no output schema, the description explains the return value (created table/name for undo) and the two invocation paths. It could add details about error handling or behavior on existing indexes, but for a creation tool with this many parameters, it is largely complete.

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

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

Schema description coverage is 0%, and the description compensates fully by detailing every parameter: table, columns, name, unique, definition, dry_run, target. It explains requirements, defaults, and mutual exclusivity, far exceeding what the bare JSON schema provides.

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 clear verb+resource statement: 'Create an index.' It distinguishes the tool's capability from siblings by explaining the two construction modes (table/columns or definition) and referencing drop_index's undo replay, making the purpose 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 provides context on when to use the table/columns path versus the definition path, notes mutual exclusivity, and mentions dry_run for preview. However, it does not explicitly contrast with sibling tools beyond referencing drop_index's undo mechanism, so usage guidance is strong but not fully explicit on alternatives.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the write risk, high-risk label, reversibility via SHOW CREATE TABLE, undo recording, and dry_run preview. It does not discuss permissions or return values, but the core behavioral traits are 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 front-loaded with a risk marker and a concise purpose statement. The explanatory paragraph and Args list are structured and focused, though the wording around capturing the index definition is slightly repetitive. Overall it is efficient with no wasted sentences.

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 4-parameter write tool with no annotations and no output schema, the description covers the essential semantic points: purpose, parameters, undo behavior, and dry-run. It could be more complete by indicating what the tool returns on success or on dry-run, but it is sufficiently 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%, and the description fully compensates by explaining all four parameters: table may be schema-qualified, name is the index to drop, dry_run previews instead of dropping, and target is a config-defined default. This adds practical meaning beyond the bare schema titles.

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?

Description states a specific verb+resource: "Drop an index." It clearly distinguishes itself from sibling tools like create_index and the various analysis/index-health tools, and adds meaningful scope by noting reversibility and dry-run preview.

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

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

The intended use is implied by the verb "Drop an index" and is supported by dry_run guidance, but there is no explicit when-to-use or when-not-to-use versus alternatives such as redundant_indexes or unused_indexes. No exclusions or alternative tool names are given.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that the statement is not executed, which is crucial for safety. However, it does not mention potential permission requirements or behavior on invalid SQL, leaving some gaps.

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, front-loaded with purpose, and includes a clear args section. Every sentence serves a purpose without any fluff.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the main inputs and the crucial non-execution behavior. It lacks details about the exact structure of the returned JSON or any restrictions on SQL statement types, but is reasonably complete for typical use.

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's documentation of 'sql' and 'target' adds essential meaning beyond the bare schema types. It explains sql as a single SQL statement and target as an optional config target, though the meaning of 'target' could be clearer.

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 returns the JSON execution plan for a given SQL statement via EXPLAIN FORMAT=JSON. It uses a specific verb ('return') and resource ('JSON execution plan'), and explicitly says the statement is planned, not executed, distinguishing it from other tools that actually run queries or perform mutations.

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

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

The description provides clear context for when to use this tool (to obtain query plans) and implies it is safe because the statement is not executed. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an AI agent.

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

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

With no annotations, the description carries the transparency burden. It marks itself as `[READ]`, describes ranking/analysis rather than mutation, and states that each recommendation cites its numbers. It also warns that live fetching occurs when `tables` is omitted, which is useful 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 4 sentences plus a compact args list. It front-loads the core purpose, then explains modes, then parameters. No redundant or vague text.

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

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

For a tool with no output schema, it notes that recommendations cite their numbers, giving a hint about the return. It covers all parameters and usage modes. However, it doesn't detail the exact output structure or criteria for ranking beyond 'reclaimable data_free', so a 4 is warranted.

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 compensates fully: `tables` (injected rows vs live pull), `limit` (how many tables when not injected, default 50), and `target` (config name, omit for default). Every parameter is explained with behavior and 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 opens with '[READ] Rank tables by reclaimable data_free into OPTIMIZE TABLE candidates,' which names a specific verb ('rank'), a resource ('tables'), and a purpose (identify OPTIMIZE TABLE candidates). It distinguishes itself from siblings like `table_fragmentation` by referencing it as a data source and `optimize_table` by stopping at candidate ranking.

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

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

It explicitly describes two invocation modes: pass `tables` (as from `table_fragmentation`) for offline analysis, or omit to pull the worst-fragmented tables live. This tells an agent when each mode is appropriate, though it doesn't explicitly list exclusions or alternatives beyond the reference to `table_fragmentation`.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It explicitly labels the operation as [READ], indicating safety, but does not mention potential performance impact, permissions, or whether it scans all indexes. The minimal disclosure is insufficient for a tool that may be invoked on large databases.

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 well-structured, with the [READ] tag leading, then a clear purpose statement, and a brief parameter explanation. Every sentence adds value without any 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?

The tool is simple with one optional parameter and no output schema. The description conveys what the tool returns (column lists and cardinality) and the target parameter. It does not specify return formatting or any caveats, but for a read-only diagnostic tool, this is reasonably complete.

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

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

The input schema has zero description coverage, but the description compensates by explaining the 'target' parameter as a target name from config that can be omitted for the default. This provides meaningful semantics beyond the schema's bare type definition.

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 returns per-index column lists and cardinality, with the purpose of selectivity screening. Although it lacks an explicit verb, the [READ] prefix and specific resource (indexes) make the purpose unambiguous and distinguish it from sibling tools like unused_indexes or redundant_indexes.

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

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

The phrase 'selectivity screening' provides clear context for when this tool is appropriate, implying it is for examining index cardinality to assess selectivity. It does not explicitly list exclusions or compare to alternatives, so it stops short of a 5.

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

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

With no annotations, the description carries full burden and does exceptionally well. It discloses it's a high-risk write operation, has no inverse, keeps the session connected, captures audit info, refuses its own session id, and enforces dry_run. This far exceeds typical descriptions.

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 front-loaded with the purpose and risk tags, then provides necessary behavioral details and parameter documentation. Each sentence adds value, and the structure (overview, side effects, self-guard, Args) is clean and scannable.

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

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

The description is very complete, covering side effects, parameters, and safety. It lacks explicit mention of permission/authorization requirements (e.g., KILL privilege) and does not describe the return value or error conditions. Since there is no output schema, this leaves a small 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?

Despite schema description coverage of 0%, the description's Args section thoroughly explains each parameter: session_id comes from list_sessions, dry_run toggles preview, and target is from config with a default. This adds significant meaning beyond the schema's titles 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 clearly states the tool's function with a specific verb and resource: 'Cancel a session's running statement (KILL QUERY).' It also distinguishes it from related tools by noting 'The session stays connected; only its current statement is aborted,' which separates it from kill_session. The 'No inverse' note clarifies the irreversible nature.

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

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

The description provides clear context: it cancels a running statement without disconnecting the session, and offers a dry_run option for preview. It does not explicitly name alternatives or when-not-to-use scenarios, but the behavioral distinction is strong. Since it doesn't explicitly compare to kill_session, it stops short of a 5.

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

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

With no annotations, the description fully discloses the destructive nature: write operation, high risk, no safe inverse, no undo, audit trail capture, and refusal behavior even under dry_run. This is exceptionally transparent for a mutation tool.

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 compact and front-loaded with the critical warning. Each sentence adds necessary information: effect, irreversibility, audit trail, dry-run behavior, refusal condition, and parameter meanings. 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 destructive tool with no output schema and no annotations, the description covers all required aspects: what it does, side effects, safety guardrails, parameter semantics, and an important edge case. It leaves no significant behavioral question unanswered.

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%, but the description explains every parameter: session_id comes from list_sessions, dry_run previews without killing, and target is a config-based override with a default. This fully compensates for the lack of 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 opens with 'Terminate a session (KILL CONNECTION)', which is a specific verb and resource, clearly distinguishing this from sibling tools like kill_query. The scope is unambiguous: it kills a database session, not a query.

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

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

It provides clear usage context: sessions come from list_sessions, dry_run=True can preview, and the tool refuses its own session id. It stops short of explicitly naming alternative tools or stating when not to use it, but the caveats and workflow guidance are strong.

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 includes '[READ]' to indicate a read-only operation, and specifies the output includes table count and data/index sizes sorted largest first. However, without annotations, it does not disclose permission requirements, whether system schemas are excluded, or potential performance implications, leaving gaps for a tool with no annotation support.

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, front-loading the purpose in the first sentence and allocating a short line for the parameter explanation. Every word earns its place with no 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 tool with one optional parameter and no output schema, the description covers the core purpose, output contents, ordering, and parameter semantics. Given its simplicity, it is sufficiently complete, though it could mention what 'user schemas' excludes (e.g., system schemas), but that is a minor gap.

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

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

The schema provides only the name and type for the 'target' parameter with zero description coverage. The description compensates by explaining that target refers to a configured target name and omitting it uses the default, providing essential meaning beyond the schema.

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

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

The description clearly states the tool lists user schemas with table count and data/index size, ordered largest first. This specific verb-resource combination distinguishes it from sibling tools like table_sizes and list_transactions.

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. The description only states what the tool does, without mentioning exclusions or related tools, leaving the agent to infer 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?

No annotations are provided, so the description must carry the behavioral disclosure. It marks the operation as [READ] and equates it to SHOW ENGINES, which implies a read-only query. However, it does not address potential permission requirements, error behavior, or exact return format, leaving some gaps for a tool with no 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 extremely concise: two sentences containing the purpose and the argument definition. It is front-loaded with the primary action and contains no unnecessary words.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description provides sufficient context: the purpose, the parameter semantics, and the read-only nature. It could mention return values or prerequisites, but for this low complexity, the description is nearly 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%, but the description compensates by explaining the 'target' parameter: it is a target name from config and can be omitted for the default. This adds meaningful semantics beyond the schema's type and default values, making the parameter clear.

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

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

Clearly states it lists storage engines and identifies the default, using the known SQL command SHOW ENGINES. The verb 'list' and resource 'storage engines' are specific, distinguishing it from sibling tools like list_transactions or list_sessions.

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. It does not mention any exclusions or when not to use it, and no sibling tools are referenced as alternatives for different 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?

With no annotations, the description carries the full burden. It explicitly marks the operation as [READ], describes per-command aggregation, and adds the behavioral nuance of flagging sleeping sessions. It doesn't disclose permissions or side effects, but for a read-only listing this is adequate.

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 compact and front-loaded with the [READ] tag and main purpose, followed by a brief args list. No filler or redundant repetition of schema defaults.

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 two-parameter read-only tool with no output schema, the description covers the core purpose, the key diagnostic behavior (flagging sleeping sessions), and both parameters. It is sufficiently complete for an agent to invoke it correctly without further clarification.

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 'Args' section adds plain-language explanations for both parameters (include_sleeping and target), fully compensating for the schema's lack of property descriptions. This goes beyond the bare schema.

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

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

The description states 'Current sessions (processlist) with per-command counts' and specifically calls out flagging sleeping sessions as connection-pool leak suspects, giving a clear verb+resource+scope. This distinguishes it from sibling tools like list_transactions or lock_waits.

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

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

It clearly implies usage for diagnosing connection-pool leaks by flagging sleeping sessions, and the [READ] tag suggests safe inspection. However, it does not explicitly mention when not to use it or name alternatives.

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

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

No annotations are provided, so the description carries the behavioral burden. The '[READ]' tag clearly indicates a read-only operation, and 'oldest first' discloses ordering behavior. This is meaningful transparency beyond the schema.

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

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

The description is extremely concise, front-loaded with the read-only tag and purpose, followed by a clear parameter explanation. No wasted words.

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

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

For a simple read-only list tool with no output schema, the description covers purpose, ordering, and the parameter. It omits return field details, but this is acceptable given the straightforward nature of the operation.

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

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

The description explains the only parameter 'target' as a config-based name with a default behavior, which adds significant meaning beyond the schema's bare type and null 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 clearly states the tool reads InnoDB transactions ordered oldest first, with a specific use case (stuck-transaction hunting). This differentiates it from sibling tools like list_sessions or lock_waits.

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

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

The phrase 'stuck-transaction hunting' provides clear context for when to use this tool. It does not explicitly name alternatives or exclusion scenarios, but the intended usage is evident.

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

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

No annotations are provided, so the description carries the full burden. It starts with '[READ]', clearly indicating a read-only operation. It explains the core behavior (build wait-for tree, identify root blocker, parse deadlock) and notes that the live path is 'flavor-branched'. It does not disclose return format or edge cases, but the main behaviors are transparent.

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

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

The description is well-structured with a concise purpose sentence, usage guidance, and an Args section. It is not overly verbose, but the Args block repeats some default values already in the schema. Overall, it is efficient 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?

Given the tool's complexity (deadlock analysis) and lack of output schema, the description explains the inputs and high-level output expectations ('name the root blocker, parse the last deadlock'). It does not detail the response structure, but it provides enough for an agent to select and invoke the tool correctly. Sibling context helps establish its role.

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. The 'Args' section explains all three parameters: pairs (injected lock-wait pairs, omitted for live), include_deadlock (parse deadlock, default True), and target (target name, omit for default). This goes beyond the schema's bare types and defaults, providing crucial meaning for 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?

The description clearly states the tool's function: 'Build the InnoDB wait-for tree, name the root blocker, and parse the last deadlock out of SHOW ENGINE INNODB STATUS.' This specifies the verb (build, name, parse) and the resource (InnoDB wait-for tree and deadlock). It is distinct from sibling tools like lock_waits, which only list waits.

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

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

The description provides clear context on when to use it: 'Pass pairs (as from lock_waits) for pure/offline analysis, or omit to pull the current lock-wait graph live.' This explains the two modes and references a sibling tool. However, it does not explicitly state when not to use it or name alternative tools for comparison.

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

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

With no annotations, the description carries the burden of disclosing safety. It explicitly marks the operation as a read and identifies the underlying system tables for MySQL and MariaDB, adding valuable behavioral context about flavor-branching. It does not cover possible output size or permissions, but the read-only nature is clear.

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?

At just three lines, every sentence is informative. The [READ] prefix and source-table details are front-loaded, with no filler or repetition.

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 tool with one optional parameter, the description covers purpose, sources, and parameter meaning. It lacks an explicit return-format description, but that may be self-evident from the name and content, and the sibling tools fill in broader 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 schema provides only a default null, but the description explains 'target' as a target name from config and says to omit for default, giving it practical meaning beyond the schema. With a single parameter, this is sufficient.

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 '[READ]' and states 'InnoDB wait-for edges (blocked session -> blocking session)', clearly identifying the tool as a read-only resource for lock-wait relationships. This distinguishes it from sibling tools like lock_wait_rca, which provides analysis rather than raw data.

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 inspecting lock-wait dependencies but does not explicitly state when to choose this over lock_wait_rca or list_transactions. No exclusion criteria or alternative references are given, leaving usage context mostly inferred.

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

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

With no annotations provided, the description carries the transparency burden. It discloses the read-only nature via '[READ]', the filtering by min_seconds, and the time ordering. However, it does not mention details such as result fields, whether all schemas/users are included, performance impact, or behavior when no queries match—leaving gaps in 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 exceptionally concise, with a one-sentence summary followed by a minimal Args list. Every sentence is necessary and informative, with no redundant content. It is well-structured 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 simple read-only tool with two optional parameters, the description covers the core behavior and parameter semantics adequately. The only notable gap is the lack of any mention of return format or output fields, but given the absence of an output schema and the tool's low complexity, this is a minor omission.

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 no descriptions (0% coverage), but the description's Args section explicitly defines both parameters: min_seconds as 'Minimum age in seconds' and target as 'Target name from config; omit for the default.' This adds essential semantic value and fully compensates for the schema's lack of explanatory text.

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 exactly what the tool does: it lists active statements running at least `min_seconds`, ordered oldest first. The specific verb (implied 'list') and resource ('active statements') with clear criteria distinguish it from siblings like top_queries or list_sessions, even without naming 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?

The description implies when to use this tool (when you need to see active long-running statements) but gives no explicit guidance on when to prefer it over similar tools such as top_queries or slow_query_rca. No exclusions or alternatives are mentioned, making the usage context clear but not fully 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?

With no annotations, the description fully discloses the write nature, no-undo risk, audit trail of prior stats, InnoDB mapping to ALTER TABLE ... FORCE, and brief locks. This is exemplary 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 concise, front-loaded with purpose and risk, and uses a clear Args block. Every sentence adds value without 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?

The description covers operation, caveats, and parameters well. It falls just short of being complete by not specifying the return value or success message, but given no output schema this is a minor gap for a write tool.

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

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

Schema description coverage is 0%, but the Args section thoroughly explains every parameter: table format with schema qualification, dry_run semantics, and target default. It fully compensates for the missing schema coverage.

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

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

Description clearly states 'OPTIMIZE TABLE (rebuild, reclaim data_free)' with specific action and resource, distinguishing it from read-only analysis tools like table_fragmentation. The purpose is unambiguous and not a tautology.

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?

Provides clear context: schedule off-peak for hot tables, use dry_run to preview, and notes the online DDL lock behavior. It does not explicitly name alternative tools for pure analysis, but the guidance is sufficient for correct usage.

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 starts with '[READ]', disclosing the read-only nature, and states that sections are 'captured defensively so one failing probe does not sink the rest,' which reveals error-isolation behavior. Since no annotations are provided, this is valuable, though it doesn't cover permissions or performance impact.

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 compact and well-structured: a one-line summary, a list of included sections, a note on error handling, and a parameter explanation. Every sentence provides useful information without 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?

Given the tool's multi-metric scope and the absence of an output schema, the description adequately lists the expected sections and hints at partial data via the defensive-capture note. It could be more explicit about the overall output structure, but the key information is present.

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

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

The schema only defines 'target' as a string/null with default null and no description (coverage 0%). The description's Args section explains 'Target name from config; omit for the default,' fully clarifying the parameter's meaning and default behavior, thereby compensating 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 clearly states the tool's purpose: 'One-shot server health snapshot' and lists the specific metrics it captures (version, flavor, uptime, connection headroom, sessions, longest query, fragmented table, replica role). This distinguishes it from sibling tools that focus on individual metrics.

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 establishes a clear context: use it for a quick, broad health check ('One-shot server health snapshot'). However, it does not explicitly mention when to prefer this over sibling tools or any exclusions, so it lacks explicit alternatives.

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

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

No annotations are provided, so the description carries the full burden. It includes a '[READ]' prefix indicating a non-destructive operation and states what the tool identifies. However, it does not disclose potential side effects, performance costs, or output format, though for a read-only diagnostic this is partially mitigated.

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 [READ] tag. It gives a one-sentence definition of the output and a minimal parameter explanation with no unnecessary words.

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

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

The tool is simple with one optional parameter and no output schema. The description explains what it returns (redundant indexes) and how to use the parameter, which is adequate for an agent to invoke it correctly. It could mention whether results include table names or DDL statements, but that is not critical.

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

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

The input schema for 'target' gives no description beyond type and default. The tool description compensates by explaining that target is a config name and is optional, adding meaningful context. With only one parameter and 0% schema coverage, this is sufficient.

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 defines the tool's purpose: it identifies indexes whose columns are a leading prefix of another index (duplicates). This distinguishes it from siblings like unused_indexes or index_stats. However, it lacks an explicit verb such as 'list' or 'find', so it is clear but not perfectly formatted.

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 like unused_indexes or index_stats. It only explains the target parameter, with no mention of exclusions, prerequisites, or recommended use cases.

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

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

With no annotations, the description carries the burden and does well: it prefixes with [READ], explains the flavor branching between MySQL 8.x and MariaDB, and notes normalization. It lacks details on permissions or rate limits, but for a status read these are less critical.

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: front-loaded with the [READ] tag and purpose, followed by a short caveat, flavor explanation, and parameter docs. Every sentence contributes, with no fluff.

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

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

The description covers purpose, behavior, and parameters, including the primary/standalone caveat. It does not describe the return structure or field details, but given the absence of an output schema and the tool's simplicity, the coverage is reasonably complete.

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

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

The only parameter 'target' is explained as 'Target name from config; omit for the default.' This fully compensates for the schema's 0% description coverage, though it is terse and assumes familiarity with config.

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 reads replica thread state and lag, referencing SHOW REPLICA/SLAVE STATUS. It distinguishes itself from siblings by focusing specifically on replica status and noting flavor-branched behavior.

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 context that the result is empty on a primary/standalone server, implying it is for replicas. However, it does not explicitly mention when to use this tool over alternatives like replication_lag_rca, making usage guidance somewhat implicit.

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

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

With no annotations provided, the description carries the burden. It begins with '[READ]' signaling a non-mutating operation and explains the offline vs. live pull behavior, including 'flavor-branched' logic. This adds meaningful context beyond the schema, though it does not detail return format or error scenarios.

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 well-structured: a one-line summary, a brief usage note, then a clear argument list. No wasted words; every sentence earns its place. The slight redundancy of describing 'status' twice is minor and does not detract.

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's complexity and absence of an output schema, the description covers the input modes and parameter semantics thoroughly. However, it does not describe the format of the 'cause + action' output, which would be helpful for an RCA tool. Otherwise, it is quite 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%, but the description fully compensates by explaining both parameters: 'status' is an injected replica status record (optional), and 'target' is a config-based target name (optional with default). This gives clear semantic meaning beyond the raw schema types.

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 'Map' with a clear resource: replica thread state/lag/error fields to cause+action. This distinguishes it from sibling tools like replica_status (which retrieves status) and other RCA tools (slow_query_rca, lock_wait_rca) focused on different domains.

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

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

The description explicitly explains two usage modes: passing a status from replica_status for offline analysis, or omitting it to fetch live replica status. This gives clear contextual guidance, though it does not explicitly exclude alternatives or state when to prefer this tool over sibling RCA tools.

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

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

With no annotations provided, the description carries the full burden. It discloses that the operation is a WRITE with medium risk, irreversible, truncates a specific internal table, and that no undo is recorded. It also mentions the dry_run preview option. This is exemplary 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 compact and front-loaded with the [WRITE] and risk/irreversibility warnings. It uses a short paragraph plus Args list; no wasted words. Every sentence adds value.

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

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

Given no annotations and no output schema, the description explains the operation's effect, irreversibility, the dry-run option, and both parameters. It is complete enough for an agent to invoke the tool safely and 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 explain parameters. It does so for both: dry_run ('If True, preview without resetting') and target ('Target name from config; omit for the default'). This fully compensates 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 states a specific verb ('Reset') and a specific resource ('statement-digest accumulators'), with an immediate note that it truncates performance_schema.events_statements_summary_by_digest. This clearly distinguishes it from sibling tools like kill_session or set_global_variable.

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 communicates irreversible side effects and recommends dry_run=True for preview, which is valuable usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., when you need to clear aggregated query statistics), though the context makes it evident.

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

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

No annotations are provided, so the description carries the full burden. The [READ] prefix indicates a safe, non-mutating operation, which is valuable. However, it does not disclose potential failure modes, output format, or security/permission requirements, leaving gaps in behavioral 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 concise, with a clear first line stating purpose and a compact parameter note. Every sentence adds value, and the [READ] prefix is an efficient behavioral cue. No redundancy or fluff.

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

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

The tool is simple with one optional parameter and no output schema. The description lists the returned data fields, which is helpful, but it does not explain the return format (e.g., object keys) or provide context about the target instance. For a basic info tool, this is adequate but has room to add more 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?

Schema description coverage is 0%, so the description must compensate. It does so by explaining that 'target' is a name from config and can be omitted for the default, adding meaning beyond the schema's raw type. Though brief, it clarifies the only parameter's role.

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 purpose with a specific resource ('server') and the exact data it returns: version, flavor (mysql/mariadb), uptime, and read-only state. The [READ] prefix reinforces it as a read operation. This distinguishes it from sibling diagnostic tools by listing its specific output.

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 siblings such as 'show_variables' or 'overview'. The parameter explanation ('target: Target name from config; omit for the default') is useful for invoking the tool but not for choosing it. No exclusions or alternative recommendations 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?

With no annotations, the description carries full disclosure responsibility. It covers the write nature, risk level, reversibility, immediate SET GLOBAL effect, runtime-only persistence, refusal of dangerous variables, and undo behavior. It also explains that dry_run enforces the same safety checks. This is exemplary 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 well-structured with a tag, one-liner, behavior details, refusal list, and Args. It is longer than necessary but every sentence adds value, and the key information is front-loaded. Slight verbosity keeps it from a 5.

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

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

Given no annotations and no output schema, the description is remarkably complete. It covers safety, reversibility, persistence, parameter semantics, and edge cases. For a write tool, this is thorough enough for an agent to invoke correctly and understand the consequences.

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

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

Schema description coverage is 0%, so the description's Args section compensates fully. It explains each parameter: name gives an example, value specifies the type, dry_run explains the preview behavior, and target clarifies config usage. This meets the parameter semantics need completely.

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 precise action: "[WRITE][risk=medium] SET GLOBAL a server variable." This is a specific verb and resource, clearly distinguishing it from read-only sibling tools like show_variables or list_sessions. The purpose is unambiguous and immediately understandable.

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

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

The description provides clear usage context: it warns about runtime-only persistence, recommends dry_run for preview, and explicitly lists refused globals to prevent lockout. It does not name alternative tools for comparison, but it gives enough context to know when to use this tool and its limitations.

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

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

With no annotations, the description carries the full burden. It explicitly begins with [READ], indicating a read-only operation, and references the SQL command SHOW GLOBAL STATUS. However, it does not disclose return format, potential performance impact, or privilege requirements.

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 brief and front-loaded with [READ] and the core purpose. The Args section is cleanly structured, and every sentence adds value without redundant information.

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

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

While the tool is simple, the description does not specify the return format (e.g., list of name-value pairs) or any limitations (e.g., pattern matching behavior). It gives enough to start but lacks details that would help a complete understanding.

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 compensates by explaining both parameters. It clarifies pattern as an optional substring filter with examples, and target as a config name with a 'default' fallback. This adds meaningful detail beyond the schema.

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

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

The description clearly states the tool shows global status counters (SHOW GLOBAL STATUS), using a specific verb and resource. It is distinctly different from siblings like show_variables or connection_stats.

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 explains how to use arguments (pattern, target) but gives no guidance on when to choose this tool over alternatives. No exclusions or comparison with sibling tools 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?

The description explicitly labels the operation as '[READ]', which is a critical behavioral disclosure. Since no annotations are provided, this serves as the primary safety signal. However, it does not disclose other behaviors that might be relevant, such as whether the read is from a live connection, whether the returned variables are system-wide (not session), or any potential performance implications. It adds context beyond the bare tool name but leaves gaps.

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 remarkably concise: a one-line purpose, then a compact Args list. Every line earns its place. The '[READ]' prefix front-loads the most critical behavioral fact. No filler or redundant text.

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 listing tool with no output schema and no annotations, the description covers purpose, read-only nature, and parameter details sufficiently. It is missing a note on the return format (e.g., a list of key-value pairs), which an agent might need to interpret results, but this gap is not critical for a straightforward SHOW GLOBAL VARIABLES. The lack of guidance on when to use vs 'show_status' slightly reduces completeness.

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 types and titles for 'pattern' and 'target'. The description adds substantial meaning: it explains 'pattern' as an optional substring filter with concrete examples ('innodb_buffer', 'max_connections'), and explains 'target' as a config-based target name with a note to omit for the default. This fully compensates for the low schema description coverage.

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

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

The description states a clear action and resource: '[READ] Global variables (SHOW GLOBAL VARIABLES)'. This is specific and aligns with the tool name. However, it does not explicitly contrast itself with the sibling tool 'show_status', which could be confused by an AI agent. The purpose is clear on its own, but lacks sibling differentiation.

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 parameter-level usage instructions (how to use 'pattern' and 'target') but gives no guidance on when to choose this tool over alternatives like 'show_status' or 'set_global_variable'. There is no explicit context or exclusions, leaving the agent to infer appropriate usage from the tool name and purpose.

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

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

With no annotations provided, the description carries the full behavioral burden. It starts with '[READ]' indicating a read-only operation, and explains the live vs offline data source behavior ('pulled live from performance_schema'). It also discloses the selection algorithm (picks greatest total time) and how EXPLAIN feeds the RCA, providing substantial behavioral insight.

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 front-loaded with a concise summary ('[READ] RCA for the worst statement digest, with cause + action'), followed by a brief explanatory paragraph and a structured Args list. Every sentence adds value, and the length is appropriate for the parameter complexity.

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 4 optional parameters, no annotations, and no output schema, but the description explains the input modes, selection criteria, and output type ('cited causes and concrete actions'). It provides enough context for an agent to invoke the tool correctly, including how to do offline analysis and how to use EXPLAIN.

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 zero property descriptions, but the description includes a dedicated 'Args' section that explains all four parameters. For example, 'statements: Injected digest rows (as from top_queries); if omitted, the worst statements are pulled live' adds meaning beyond the bare schema. This fully compensates for the schema coverage gap.

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

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

The description explicitly states 'RCA for the worst statement digest, with cause + action' and elaborates that it picks the digest with greatest total time and maps metrics to cited causes and actions. This clearly distinguishes it from sibling RCA tools like lock_wait_rca and replication_lag_rca, which focus on different resources (lock waits, replication lag).

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

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

The description provides clear context for when to use the tool: for root cause analysis of the slowest statement digest. It also gives specific mode guidance: 'Pass statements for pure/offline analysis, or omit to pull the top digests live from performance_schema.' However, it does not explicitly list alternative tools or exclusion criteria beyond this.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It provides the return envelope structure, explains the 'truncated' flag, and notes that data_free represents reclaimable space for OPTIMIZE TABLE. The [READ] prefix signals read-only intent, but permissions are not addressed.

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

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

The description is well-structured with a summary line, Args section, and Returns section. It front-loads the core purpose and includes important behavioral notes about the envelope and truncation behavior. It is longer than two sentences, but each part contributes necessary information.

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

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

Given the absence of an output schema, the description thoroughly explains the return envelope and the meaning of 'truncated'. It covers parameters and the operation's goal. A minor gap is the exact structure of entries within 'tables', but overall it is sufficient for a diagnostic tool.

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

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

Schema description coverage is 0%, so the description must compensate. It defines 'limit' as 'Number of tables to inspect (default 50)' and 'target' as 'Target name from config; omit for the default,' adding meaningful semantics beyond the bare schema types. The description of 'target' could be slightly more detailed, but it is functional.

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?

[READ] data_free per table (space OPTIMIZE TABLE could reclaim), worst first.' clearly identifies the tool's resource and metric. It is specific and informative, but it doesn't explicitly distinguish from sibling 'fragmentation_analysis', which might serve a similar diagnostic 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?

The description lacks explicit guidance on when to choose this tool over alternatives. While it includes a useful note about the 'truncated' field and re-running with a higher limit, that is about result interpretation rather than tool selection.

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

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

With no annotations, the description carries the full burden, and it effectively discloses the read-only nature via '[READ]' and the truncation behavior with specific instructions to re-run with a higher limit. This is valuable context beyond the schema. It doesn't mention permissions or exact source of sizes, but the transparency is strong.

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 well-structured: a clear one-line summary, followed by labeled Args and Returns sections. Every sentence provides useful information, and there is no unnecessary verbosity.

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 low complexity (two optional parameters), lack of annotations, and absence of an output schema, the description is complete. It explains the return envelope, the 'truncated' flag, and how to handle pagination, which is sufficient 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?

The input schema has zero parameter descriptions (0% coverage), but the description fully explains both parameters: 'limit' specifies count and ordering, and 'target' is clarified as a config name with a default. This compensates completely for the absence of 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 returns the largest tables by data and index size, which is a specific resource and scope. However, it lacks an explicit verb like 'list' or 'get', and does not distinguish itself from sibling tools like table_fragmentation or index_stats, so it doesn't fully meet the top criteria.

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

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

The intended usage is implied by the purpose: use this tool to see the largest tables by size. However, there is no explicit guidance on when to use this versus alternatives, no exclusions, and no mention of alternative tools, so it only meets the 'implied usage' level.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does an excellent job by explicitly marking the operation as '[READ]', explaining the non-InnoDB flag's significance, and detailing the return envelope including the 'truncated' boolean and the instruction to re-run with a higher limit. This goes well beyond basic parameter listings.

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 well-structured with separate sections for the operation, additional context, arguments, and return format. It is concise, each sentence adds value, and the essential information is front-loaded with the [READ] marker and the core 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?

Despite lacking an output schema, the description fully documents the return envelope and truncation behavior, making the tool's behavior predictable. All parameters are explained, and the read-only nature is disclosed. This is complete for a status inspection tool with two optional parameters.

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

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

The input schema provides only types and defaults for limit and target with zero description coverage. The description compensates by explaining that limit is the number of tables to inspect (default 50) and target is the config target name (default null), giving the agent the necessary semantic context to invoke the tool 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 begins with '[READ]' and clearly states the tool returns per-table engine, row format, row estimate, and last update time. This specific resource and attribute set distinguishes it from sibling tools like table_sizes or fragmentation_analysis, which cover different table properties.

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

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

It provides clear context for when to use the tool (to inspect table engine/row format and identify non-InnoDB tables), and it explains the limit/truncation behavior so users know to increase limit when truncated. However, it does not explicitly compare itself to sibling tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It labels itself '[READ]', documents the return envelope including the 'truncated' flag and advises re-running with a higher limit when truncated, providing behavioral expectations beyond what the schema offers. It does not mention side effects or permissions, but for a read-only query tool, the disclosed behavior 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 efficiently structured: an initial summary, followed by parameter documentation, then return format. Every sentence adds value; there is no 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?

The description is complete for the tool's complexity: it covers all three parameters, the return envelope, and the truncation behavior. Since there is no output schema, the description adequately explains the response structure.

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 fully compensates by explaining each parameter: order_by lists the allowed values, limit gives the range and default, target explains the omit behavior. This adds substantial meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Top statement digests from performance_schema by a whitelisted metric', with a concrete resource (performance_schema) and specific metric list. This distinguishes it from sibling tools like long_running_queries or slow_query_rca, which focus on different aspects.

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

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

The description provides clear context for what the tool does but does not explicitly state when to use it versus alternatives. It implies usage for ranking queries by a metric, but there is no exclusions or alternative tool references, so guidance is only implied.

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

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

With no annotations provided, the description carries the full burden, and it does well. It discloses the write operation and risk level, explains the inverse tool runs with its own risk/audit, emphasizes that a token can only be applied once, and mentions the dry_run preview. This provides thorough 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 front-loaded with the action and risk, followed by concise explanatory notes and an Args list. Every sentence contributes value; 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?

The description covers the key behavior, args, and constraints, making it effective for a 3-parameter tool with no output schema. Minor omissions include the return format or what happens after a successful apply, but overall it is complete enough for safe use.

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 explain parameters, and it does. It explains undo_id, dry_run, and target in plain language, including sources and behavior. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Apply a recorded undo by dispatching its inverse tool.' It uses a specific verb ('apply') and resource ('recorded undo'), and it distinguishes itself from sibling tools like undo_list (which lists undos) by focusing on the application step.

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 context ('Apply a recorded undo') but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or conditions. It mentions dry_run as a preview, but no explicit 'use this when...' guidance.

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

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

With no annotations, the description carries the full burden and discloses read-only intent, ordering, measured truncation via an extra row fetch, and the meaning of effectVerified. This goes well beyond a simple 'list' statement and warns about probable vs confirmed 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 well-structured with a concise lead definition, an output contract, critical caveats, and an args section. Every sentence adds actionable information without 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?

Given no output schema and no annotations, the description provides everything needed: return shape, truncation semantics, re-run guidance, per-entry verification meaning, and parameter behavior. This is unusually complete for a list tool.

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

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

Despite zero schema-level property descriptions, the description fully documents both parameters: limit has a default and cap, and target is explicitly marked as unused. This compensates completely 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 '[READ] List recorded, not-yet-applied undo tokens (most recent first)', giving a specific verb and resource. It clearly distinguishes from the sibling undo_apply, which is the corresponding action tool.

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

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

It explicitly says to use the returned undoId with undo_apply, providing direct integration guidance. It also notes that target is unused, preventing wasted parameter use, though it does not enumerate alternative read tools.

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

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

With no annotations, the description carries the burden and does well by revealing the data source, the restart-reset behavior, and the fact that only zero-I/O secondary indexes are returned. This goes beyond the tool name and adds important context. It does not detail the output format, but the 'drop candidates' hint implies a list of index identifiers.

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 concise, front-loaded with the key purpose, and uses a short second line for the important caveat. The parameter documentation is compact and clear. Every sentence adds value; no fluff.

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

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

For a simple read-only tool with one optional parameter, the description covers purpose, data source caveat, and parameter meaning. It lacks an explicit statement of the return value (e.g., list of index names), but the tool is simple and the purpose is clear. Overall it is complete enough for reliable 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 coverage is 0%, so the description must explain the parameter. It does: 'target: Target name from config; omit for the default.' This is sufficient for an optional config-like parameter, adding meaning beyond the bare JSON schema type.

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

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

The description clearly identifies the tool as listing secondary indexes with zero I/O events since restart, and explicitly frames them as drop candidates. This distinguishes it from sibling tools like redundant_indexes or index_stats by the 'unused' criterion and drop-candidate purpose. The verb is implied by '[READ]' and the noun phrase, but not strictly stated as 'list'.

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 that the data comes from performance_schema counters that reset on restart, and advises confirming over a full business cycle. This helps the agent decide when results are meaningful. It does not explicitly name alternative tools to use instead, but the caveat forms practical usage guidance.

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