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

With no annotations, the description carries the behavioral burden. It discloses the data source, the row filter, and the sort order, which accurately conveys what the tool does. It does not explicitly state that it is read-only, but 'from information_schema.PROCESSLIST' strongly implies a non-mutating query.

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

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

A single, compact sentence contains the source, filter, and ordering with no wasted words. Key scope information ('Non-Sleep') is front-loaded.

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

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

For a zero-parameter, output-schema-backed query tool, this description is nearly complete. It covers source, filtering, and ordering. The only notable gap is an explicit pointer to sibling mysql_processlist for the full/sleep-inclusive view.

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?

There are zero parameters, so the baseline is 4. The description appropriately introduces no parameter details since none exist; the schema already documents this fully.

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

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

The description identifies the exact source (information_schema.PROCESSLIST), the filter (Non-Sleep), and ordering (longest first), making it clear this returns active queries rather than all connections. It lacks an explicit verb like 'lists' or 'returns', but the intent is unambiguous and it is distinguishable from the sibling mysql_processlist.

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

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

Usage context is implied: 'Non-Sleep threads' signals this is for active queries rather than all processlist entries. However, the description does not explicitly state when to prefer this over mysql_processlist or name the alternative, so the guidance remains implicit rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses the data source (performance_schema) and that it avoids application tables, which implies a read-only, non-intrusive operation. However, it does not explicitly state whether it modifies anything, how much data it returns, or any performance implications. The disclosure is partial, leaving some behavioral ambiguity.

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

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

The description is a single, concise sentence that front-loads the core purpose ('Top statement digests by wait time') and immediately clarifies the source and exclusion. There is zero verbosity; every word contributes to the tool's semantics.

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

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

Given the tool has no parameters and an output schema exists, the description covers the essential context: what data it returns (top digests by wait time) and where it comes from (performance_schema). The explicit note about not reading application tables addresses a likely concern. Nothing critical is missing for an agent to call this tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (trivially). The baseline for 0 parameters is 4, and the description adds no parameter-specific information because none exists. This is appropriate; there is nothing for the description to explain.

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: it retrieves top statement digests ranked by wait time from performance_schema. It explicitly differentiates itself by noting 'no application table reads,' which distinguishes it from tools that might query application data. The verb+resource pattern is strong and 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 clear context: when you need top statement digests by wait time from performance_schema. It also signals a boundary by stating it avoids application table reads, which helps an agent avoid using it for app-data queries. However, it does not name any alternative tools explicitly, so the guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses that only single SELECT/SHOW statements are accepted and that stacked queries/DML are rejected, which is meaningful. However, it does not address side effects, error behavior, or any execution constraints beyond acceptance rules.

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

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

The description is two short sentences with zero wasted words. The core purpose is front-loaded, and the rejection behavior is stated in a compact second sentence.

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

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

For a single-parameter tool with an output schema, the description adequately covers accepted input and rejection behavior. A concrete example or a note on expected error handling would improve completeness, but nothing essential is missing for correct selection and 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%, so the description must compensate. It adds real value by constraining the statement parameter to a single SELECT or SHOW and explicitly rejecting DML and stacked queries. Still, it lacks syntax details, examples, or clarification of trailing semicolons, so the gap is not fully closed.

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 specific verb 'EXPLAIN' and the exact resource scope: a single SELECT or SHOW statement. It also explicitly rejects stacked queries and DML, making the tool's purpose unambiguous and clearly distinct from the diagnostic read-only siblings.

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

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

The description implies when to use the tool: when an execution plan for a single SELECT or SHOW statement is needed. It provides exclusions by rejecting stacked queries and DML, but it does not name alternative tools or explicitly state when to prefer them.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only snapshot by saying 'curated keys', but it doesn't explicitly state that it performs a read, whether it is instant, or if any special privileges are required. The lack of explicit safety or side-effect information is a notable gap.

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

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

A single, front-loaded sentence with no filler. It states the purpose and gives concrete examples immediately. Every word earns its place; it is appropriately concise.

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

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

Given the tool has an output schema (though not shown) and no parameters, the description is moderately complete. It explains the subset of status keys but doesn't clarify the output format (e.g., single row vs. multiple rows) or whether the values are current snapshots. It also doesn't mention any rate limits or performance implications, which could matter for frequent monitoring calls.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by indicating the categories of keys returned, which helps the agent understand what kind of data to expect. It doesn't need to explain parameter syntax, but it could list the exact keys; however, the examples suffice.

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 'Curated SHOW GLOBAL STATUS keys' and gives examples (threads, tmp tables, InnoDB locks, QPS counters). This conveys a specific resource (global status) and a filtered scope. It distinguishes from a full SHOW GLOBAL STATUS but doesn't explicitly contrast with siblings like mysql_status_delta, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that mysql_status_delta is for changes over time or that mysql_variables covers settings. An agent has to infer usage from the name and sibling list, which is insufficient.

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 does disclose that the tool parses SHOW ENGINE INNODB STATUS and which sections are included, which is useful behavioral context. However, it does not mention read-only behavior, potential performance impact, or that it returns a structured, parsed representation rather than the raw command output.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes: it names the command, states the parsing behavior, and lists the meaningful output categories.

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 zero parameters, an output schema, and a very simple tool shape, the description is nearly complete. It briefly lists what the result covers, and the output schema handles return-value details. It could add a sentence about when not to use it, but the core context is adequately covered.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter meaning, and the empty input schema combined with the description is fully 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 specifies the resource ('SHOW ENGINE INNODB STATUS') and the transformation applied ('Parsed'), then enumerates the key content areas: history list, deadlocks, semaphores, buffer pool. This makes it immediately distinguishable from sibling tools like mysql_global_status or mysql_variables without needing to inspect schemas.

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

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

No guidance is given about when to choose this tool over related siblings such as mysql_innodb_trx, mysql_lock_waits, or mysql_global_status. The description implies that it is for InnoDB status internals, but it does not state explicit conditions or exclusions.

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

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

With no annotations, the description carries the full burden. It communicates useful diagnostic context and the consequence of long transactions, but it never explicitly says the operation is read-only, what privileges are needed, or whether it only lists currently open transactions. The phrasing 'Open InnoDB transactions' is slightly ambiguous and could be misread as an action verb.

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

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

Two tight sentences with no filler. The first sentence front-loads the resource and key fields; the second adds a practical diagnostic insight. Every word earns its place.

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

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

For a no-parameter monitoring tool with an output schema, the description adequately covers what the tool exposes and why it matters. It could be more complete with an explicit read-only statement and direct comparison to related diagnostic tools, but the core invocation context is sufficiently provided.

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

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

The tool has zero parameters, so there are no parameter meanings for the description to clarify. The baseline score of 4 is appropriate because no schema coverage gap exists.

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

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

The description names a specific resource (InnoDB transactions) and lists the reported dimensions (age, thread, query), making its purpose fairly clear. It does not explicitly contrast with sibling tools like mysql_processlist or mysql_lock_waits, so it misses the strongest form of 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 warning that long trx_age_sec pins locks/history implies this tool is useful for investigating long-running transactions, but there is no explicit statement about when to choose it over siblings or when not to use it. Usage guidance is only 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, the description carries the full burden. It discloses version-specific data sources (8.0+ vs <8.0.18) and the empty result when nobody is waiting, which is useful. However, it does not mention that the tool is read-only or any side effects, and the output format is left to the output 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 a single, concise sentence that leads with the key concept ('Blocking chains') and includes essential technical details. It is not verbose, but the phrasing is slightly cryptic and could be more explicit about the action.

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 that there are no parameters and an output schema exists, the description is reasonably complete. It provides version-specific context and the empty-result behavior. It does not explain the output structure, but that is covered by the output schema. It lacks mention of read-only nature, but that is minor.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema coverage is 100% (trivially). No additional parameter information is required.

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

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

The description mentions 'Blocking chains' and the underlying tables, but does not explicitly state the action (e.g., 'lists', 'shows'). It is not a tautology, but the purpose is implied rather than clearly stated. It distinguishes from siblings by topic, but lacks a clear verb-resource structure.

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

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

No guidance is provided on when to use this tool versus alternatives like mysql_innodb_trx or mysql_wait_events. The description does not mention any conditions that would select this tool over others, nor any exclusions. Usage context is solely implied by the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a grouped processlist, which implies a read-only query, but it does not explicitly say it is non-destructive, does not require special permissions, or will not block. For a monitoring tool, this is a minor gap, but without annotations the transparency is only partial.

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

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

The description is two concise sentences. The main purpose is front-loaded, and the usage scenario is stated in the second sentence. There is zero waste; every word contributes to the agent's understanding of what the tool does and when to use it.

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

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

Given the tool has no parameters and an output schema is provided, the description covers everything essential: what it returns (grouped processlist) and a specific use case. It does not need to explain return values because the output schema covers that. For a simple monitoring tool, this is complete and sufficient.

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

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

The tool has zero parameters, so the description has nothing to explain beyond the schema. According to the rubric, when there are 0 params, the baseline is 4. The description does not add parameter-related meaning, but none is needed. The schema already covers the empty parameter set.

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 returns: a processlist grouped by user/host/command. This is a specific, differentiating statement that clearly distinguishes it from the sibling mysql_processlist, which presumably returns a raw processlist. The phrase also implies a specific resource (MySQL processlist) and a specific scope (grouping).

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

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

The description gives clear context for when to use the tool: 'Use to spot monitoring-agent connection storms.' This tells the agent a concrete scenario, though it does not explicitly name an alternative or state when *not* to use it. Since it doesn't exclude other tools or name a sibling, it falls slightly short of a 5, but the use case is clear and actionable.

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

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

With no annotations provided, the description carries the full burden. It discloses that this is a reachability check and what it returns, which implicitly signals a non-destructive, read-only operation. It doesn't elaborate on failure modes or authentication needs, but for a simple ping tool this is reasonable 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?

A single, front-loaded sentence communicates the action, target, and return values with no filler. Every word is informative and the structure makes it easy for an agent to quickly understand the tool's purpose.

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

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

For a zero-parameter utility with an output schema, the description is complete: it states the connectivity check and the specific return fields. The sibling context makes it clear this is part of a MySQL diagnostic family, and nothing critical is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter-specific detail because there are none, but it does provide useful context about what the tool returns, which goes slightly beyond the empty schema.

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

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

Description states a specific verb 'Check' and a clear resource 'SSH + MySQL reachability', then explicitly lists the returned information: version, hostname, and server time. This clearly distinguishes it from sibling tools that inspect process lists, queries, status variables, and other MySQL diagnostics.

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 implies the tool is for verifying SSH and MySQL connectivity, which is a natural precursor to deeper diagnostics. It doesn't explicitly name alternatives or exclusion conditions, but the intended usage context is obvious from the wording and the sibling tool set.

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 disclosure burden. It does reveal one behavioral trait—'Truncates Info'—which is genuinely useful. But it omits other relevant behaviors such as the read-only nature of SHOW, potential privilege requirements, or whether it has performance implications. The disclosure is minimal but not absent.

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 three short sentences with zero wasted words. The core command is front-loaded, followed by a behavior note and a use case. Every sentence earns its place.

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

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

Given zero parameters and an existing output schema (which obviates explaining return values), the description covers the essential invocation context: what the tool does and when to use it. It could be slightly more explicit about the read-only nature, but the command name implies it, and the description is otherwise complete for a tool of this simplicity.

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

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

The tool has zero parameters, so the schema is trivially fully described and there is nothing to explain. Per the rubric, a 0-parameter tool earns a baseline of 4; the description adds no parameter details because none are needed.

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

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

The description names the exact SQL command 'SHOW FULL PROCESSLIST', making it clear the tool retrieves the MySQL process list. It also notes 'Truncates Info', adding a useful display detail. It doesn't explicitly distinguish itself from sibling mysql_active_queries, but the command name is self-explanatory and the intent is clear.

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

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

'Use during a user-facing slowdown' provides a specific, actionable scenario for when to invoke this tool. However, it offers no guidance on when not to use it or mentions alternatives among the many sibling tools, so it stops short of an explicit exclusion.

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 the SQL version differences (SHOW REPLICA STATUS vs SHOW SLAVE STATUS), what is returned (replica lag, thread state, errors), and the normal result for non-replicas. It implies a read-only operation without explicitly stating so, but that's a minor omission.

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

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

Three concise sentences, each earning its place: the first lists the core output, the second notes implementation details and version handling, and the third clarifies the normal empty result. No waste, front-loaded with 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?

Given an output schema exists, the description need not enumerate return fields. It explains the purpose, the version-specific SQL, and the typical result on non-replicas, covering everything an agent needs to decide when to call it and interpret the response.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description correctly adds no parameter information since there are none. Baseline for 0 params is 4.

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 specific resource (replica status) and the key data it returns (lag, thread state, errors). It clearly distinguishes itself from siblings by noting it returns replication channel metadata only, not binlog row contents, and by defining the normal empty result on standalone/primary servers.

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 clarifies when this tool is relevant by stating it only covers replication channel metadata and that empty rows are normal on a standalone/primary server, effectively guiding an agent to avoid using it when not monitoring a replica. It doesn't explicitly name alternative tools, but the context is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a behavioral nuance about version compatibility (8.0.22+ vs older), which is useful. However, it does not explicitly state that the operation is read-only or describe the output format, though these are somewhat implied. For a simple query tool, this is adequate but not rich.

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

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

The description is a single, concise sentence that front-loads the key purpose and includes an implementation note. Every word earns its place; there is 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?

Given that an output schema exists (per context), the description does not need to detail return values. It covers the essential purpose and version handling. It does not mention error conditions or prerequisites, but for a simple list query, these are likely low-risk. It is sufficiently complete for an agent to call it 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 tool has zero parameters, and the schema coverage is effectively 100%. The description adds no parameter information, but since there are none, the baseline of 4 applies. No compensation needed.

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

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

The description clearly states what the tool does: it shows replicas connected to this server, and even mentions the underlying SQL commands. It distinguishes from siblings like mysql_replica_status (which likely reports replication status rather than topology), though not explicitly. It is specific about the resource and action.

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

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

There is no guidance on when to use this tool versus alternatives like mysql_replica_status. The description only states the function, not the context or conditions that would make this the preferred choice. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the output format (counters as rates, gauges as t0/t1) but does not disclose that the tool takes two samples, how long sampling takes, whether it blocks, or what happens if the server is busy. The description is a terse summary, not a transparent behavioral contract.

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

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

The description is a single sentence with no wasted words. It front-loads the core behavior (two samples) and the output transformation. However, it is so terse that it sacrifices necessary detail, so it earns a 4 rather than 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 the tool has one parameter, no annotations, and a rich set of siblings, the description is incomplete. It does not explain the meaning of sample_seconds, does not differentiate from mysql_global_status, and does not state any side effects or prerequisites. An agent would likely need to open the schema and guess at the parameter's 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. It mentions 'sample_seconds' implicitly by saying 'Two GLOBAL STATUS samples' but does not explain that sample_seconds controls the interval between the two samples, nor does it give a recommended value or range. The parameter is left almost entirely to inference.

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

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

The description states that the tool samples GLOBAL STATUS twice and reports counters as per-second rates and gauges as t0/t1. This is a specific verb-resource pairing, but it does not explicitly say what the tool is for (e.g., monitoring deltas over an interval) or how it differs from mysql_global_status, which is a sibling. It is clear enough to identify the operation but not fully differentiated.

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

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

The description gives no guidance on when to use this tool versus mysql_global_status or other siblings. It does not state that this is for observing changes over time or that mysql_global_status is for a single snapshot. The only hint is the word 'delta' in the name, which is not enough for an agent to choose correctly.

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?

There are no annotations, so the description carries the full burden. It states that the tool returns a list of tables, but does not disclose whether it is a read-only query, any performance impact, or required permissions. This lack of behavioral context could mislead an agent about potential side effects.

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

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

The description is a single, well-structured sentence that immediately conveys the core functionality. It avoids redundancy and is appropriately front-loaded with the key outcome.

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 no-parameter tool with an output schema, the description is mostly complete. It specifies the data scope and exclusions, but could add when to use it relative to siblings and any potential caveats about query cost or privileges. Still, the essential information for calling the tool 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 tool has zero parameters, and the schema is empty with 100% coverage (trivially). The description correctly focuses on the output and filtering behavior, which is sufficient given there are no input parameters to document.

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 the tool returns the hottest application tables by IO wait and excludes internal schemas (mysql/performance_schema/sys). This clearly distinguishes it from sibling tools like mysql_processlist or mysql_global_status, making its 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 no guidance on when to use this tool versus alternatives such as mysql_wait_events or mysql_digest_top. It does not mention any conditions or exclusions beyond the schema exclusions, leaving the agent to infer when this is the appropriate choice.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the result is curated and conditionally includes the query cache 'if present,' which is useful context. Still, it does not state that this is a read-only operation, what filtering criteria apply, or how the tool behaves if variables are unavailable.

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

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

A single sentence conveys the command, the selection strategy, and the categories included, with no filler or redundancy. The phrase 'if present' adds precision without extra length.

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

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

For a zero-parameter, read-oriented diagnostic tool with an output schema, the description is nearly complete: it tells the agent what the tool returns and what is included. It could be slightly stronger by naming the exact variables or stating the read-only nature, but nothing essential is missing for calling it 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 tool has zero parameters and the schema coverage is 100%, so there is no parameter information the description needs to add. Per the baseline for parameterless tools, this is adequate.

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

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

The description identifies a specific resource (SHOW GLOBAL VARIABLES) with a clear verb-frame ('Curated') and names the exact categories it covers (buffer pool, connections, slow log, query cache). This makes the tool's purpose immediately recognizable and distinguishes it from status-only siblings like mysql_global_status.

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

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

The description implies the tool should be used when the agent wants a focused view of server variables, thanks to 'Curated SHOW GLOBAL VARIABLES.' However, it does not explicitly state when to prefer it over closely related siblings such as mysql_global_status or mysql_status_delta, nor does it provide any exclusion conditions.

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 of behavioral disclosure. It does disclose one relevant trait: the result may be empty if wait instruments are disabled. However, it does not explicitly state that the operation is read-only, whether it requires special privileges, or what the output shape is (though an output schema exists). This is partial transparency but not comprehensive.

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

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

The description is a single sentence that is immediately informative and front-loaded with the main purpose, followed by a useful caveat. There is no fluff, and every word earns its place. It is appropriately concise for a tool with no parameters.

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

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

For a zero-parameter tool with an output schema, the description provides the essential behavior and an important caveat about instrumentation. It could explicitly mention that it is a read-only operation, but that is often implied by the nature of the tool. Overall, the agent can call it correctly without further information, so it 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?

The input schema is empty with zero parameters, so the baseline is 4. The description does not need to add parameter information, and it does not attempt to. There is no ambiguity in parameters.

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

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

The description 'Top wait events' clearly identifies the resource (wait events) and indicates it returns the top ones. It is specific enough to distinguish from sibling tools like mysql_processlist or mysql_global_status, though it uses a noun phrase rather than an explicit verb+resource construction. It adds a useful caveat about instrumentation, so it is 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?

No guidance is given on when to use this tool versus alternatives. The caveat about wait instruments being disabled is a condition that affects results, but it does not tell the agent when to choose this tool or when to avoid it. There is no mention of alternatives or exclusions.

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