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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: it discloses that EXPLAIN ANALYZE is actually executed against top SELECTs (implying real DB load, not just catalog reads) and that results come from pg_stat_statements. It stops short of noting cost/overhead or that it is non-idempotent despite idempotentHint=false.

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 compact sentences with zero filler, and the core action (find/analyze slow queries) plus mechanism are front-loaded. Every clause earns its place by naming the source table and the detection patterns.

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

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

With no output schema, the description should clarify what the analysis returns, but it only gestures at 'performance patterns.' Combined with three fully undocumented parameters and no guidance against siblings, the definition is workable but leaves real gaps for an agent choosing and invoking it.

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

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

All three parameters (limit, min_calls, schema_name) have 0% schema description coverage and are completely unexplained in the description. It is unclear whether 'limit' caps rows returned, queries analyzed, or EXPLAIN targets, and min_calls has no stated meaning, so the description fails to compensate for the 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?

States a specific verb pair (find/analyze) plus the exact resource and data source ('slow queries from pg_stat_statements'), and names the detection targets (sequential scans, missing indexes). It is clearly distinct from check_config and full_audit, though the 'missing indexes' overlap with the sibling check_index_health is left unresolved.

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

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

Usage is only implied: an agent can infer this is for diagnosing query performance, but the description never says when to prefer it over check_index_health or full_audit, nor any prerequisites or exclusions. No explicit when/when-not guidance is present.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it compares values against some notion of 'suboptimal,' but does not say whether it only reports or also suggests fixes, nor how thresholds are determined. 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?

A single front-loaded sentence naming the action and the inspected settings with zero filler. Every clause earns its place and the resource is stated before the detail.

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

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

With no parameters and no output schema, the description carries the burden of describing results. Saying it 'flags suboptimal values' implies a findings-oriented return, which is likely sufficient for a trivial read-only check, though the exact shape of the flag output is left implicit.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The settings named in the description are internal targets of the check, not inputs.

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

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

States a specific verb (review/flag) and resource (PostgreSQL configuration settings), and enumerates the concrete settings examined (shared_buffers, work_mem, max_connections, autovacuum). It does not explicitly distinguish itself from the overlapping full_audit sibling, so it stops short of a 5.

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

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

No guidance on when to use this versus alternatives. The sibling set includes full_audit, which plausibly subsumes config review, yet the description neither mentions it nor states any trigger condition or exclusion. Usage is only inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the analysis basis ('sequential scan patterns'), which is useful, but says nothing about scope (whole database vs. one schema), whether statistics collection is required, or the cost of the analysis.

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 is efficient, though the terseness contributes to the unaddressed parameter and scope questions.

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 read-only diagnostic with annotations covering safety, this is close to adequate, but it omits the scope of the scan and the meaning of the one parameter, and there is no output schema to fall back on for expected results.

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

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

The single parameter schema_name has 0% schema description coverage and the description does not mention it at all, so there is no way to know whether it filters the analysis or defaults to all schemas. The description fails to compensate for the 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?

Names a specific verb ('Find') and three concrete resources (unused, duplicate, missing indexes), which is far more informative than the tool name alone. What's missing is any explicit differentiation from siblings like check_table_health or full_audit, which could plausibly overlap.

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 never states when to reach for this tool versus check_table_health, analyze_slow_queries, or full_audit, nor does it give prerequisites. Usage can only be inferred from the index-related subject matter.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description contributes the useful detail of which health dimensions are measured, but says nothing about thresholds, severity interpretation, or cost of running across a whole database.

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: the purpose and the metrics come first, and the optional filter behavior follows. Every clause carries information and nothing is repeated from the schema or annotations.

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

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

With no output schema, the description does the work of naming the returned metrics, which is the key thing an agent needs. It is a read-only, zero-required-parameter tool, so little else is mandatory, though a note on how to interpret or when to prefer full_audit would close the remaining gap.

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

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

Schema description coverage is 0%, so the schema supplies only titles and defaults. The description compensates partially by stating both parameters are optional filters and that one narrows to a user schema and the other to a table name, but it adds no format or matching details beyond that.

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

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

The description states a specific verb and resource ('Check table health') and enumerates the dimensions inspected (dead tuples, bloat, vacuum stats, scan ratios), so the agent knows exactly what this tool reports. It does not explicitly distinguish itself from siblings like check_index_health or full_audit, but the table scope is clear from the name and text.

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 second sentence explains that the schema/table arguments act as optional narrowing filters, which implies you can run it database-wide or focus on one table. However, there is no explicit when-to-use guidance versus check_index_health or full_audit, and no stated prerequisites, so usage must be 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?

Annotations cover the safety profile (readOnly, non-destructive), and the description adds real value beyond them: the return shape is a unified report sorted by severity, and there is a notable asymmetric scoping rule where configuration findings stay database-wide even when schema_name is set. It does not mention cost/runtime (a full audit is likely expensive) or what audit_run_id does behaviorally, which is the main 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?

Front-loads the purpose, then the return value, then the scoping caveat — the most surprising fact (config stays database-wide) is stated before the default case. No filler 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?

With no output schema, the description correctly summarizes the return ('unified report... sorted by severity') and explains default scoping, so an agent can call it and interpret results. Remaining gap is the undocumented audit_run_id and its relationship to get_audit_run.

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

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

Schema description coverage is 0%, so the description must carry semantics; it does a good job on schema_name (partial scoping, default = all non-system schemas), but audit_run_id is entirely unmentioned and slow_query_limit is never explained. Two of three parameters lack added meaning, so only partial compensation.

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

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

States a specific verb+resource ('Run a comprehensive performance audit') and enumerates the four dimensions covered: table health, slow queries, index health, configuration. This immediately distinguishes it from the four sibling check_* tools, which each cover one dimension.

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?

By enumerating exactly the domains the siblings cover individually, it effectively signals 'use this for the combined view', and it adds scoping guidance ('omitting schema_name audits all non-system schemas'). It stops short of an explicit routing statement such as 'prefer this over calling check_table_health/analyze_slow_queries separately', which keeps it at 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real value on top: it guarantees the call will not trigger or re-trigger diagnostic work (important for retry behavior) and signals that status is 'durable', i.e. persisted. It does not say what happens with an unknown or expired audit_run_id.

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

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

Two short sentences, front-loaded with the core action, and the second sentence is a targeted negative constraint rather than filler. Nothing is redundant with the name or annotations.

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

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

With no output schema, the description's promise of 'status and evidence' leaves the agent guessing what fields come back or how to interpret them. For a single-parameter read tool with annotations covering safety, this is adequate but has a clear gap around return shape and unknown-ID behavior.

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

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

Schema description coverage is 0%, so the description must carry the single audit_run_id parameter, and it only implicitly signals that the ID belongs to a prior full-audit operation. It gives no format hint (opaque string vs. UUID) or guidance on where the agent obtains the value.

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

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

States a specific verb and resource ('Retrieve durable status and evidence') scoped to a known full-audit operation, and the second sentence explicitly separates it from the auditing action itself. An agent can tell this is a read-back tool distinct from full_audit without opening the schema.

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?

'for a known full-audit operation' plus 'never starts or repeats database diagnostic work' clearly establishes the use case (polling an already-started run) and the exclusion (do not call this to kick off an audit). It stops short of naming full_audit as the alternative to use for starting a run.

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