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

No annotations are provided, so the description carries the full disclosure burden. 'Get' implies a read-only metadata operation and it lists the kind of content returned (columns, constraints, size statistics), but it says nothing about permissions, cost/latency of statistics collection, or behavior for a non-existent table.

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 efficient sentence with the resource and return contents front-loaded and no filler. It is compact, though the brevity comes partly at the cost of the missing parameter and usage detail.

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

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

For a two-parameter read-only introspection tool with no output schema, the description gives an adequate picture of what comes back. It leaves uncovered the interplay of the two required parameters and error behavior, which matters given zero schema coverage.

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% for both required parameters, and the description adds no detail about them. It never explains what 'schema' and 'table' mean here, whether the table name must be schema-qualified, or how defaults are handled.

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 ('Get') and resource ('table structure') and enumerates what the structure contains (columns, constraints, size statistics). This clearly separates it from siblings like list_indexes and list_objects, though it does not explicitly name an alternative to route against.

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 indication of when to use this versus list_objects, search_objects, or list_indexes, and no prerequisites stated. The agent must infer usage context entirely from the 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?

With no annotations, the description carries the full behavioral burden, and it does disclose scope by enumerating the five health areas checked. However, it says nothing about whether the check is read-only, whether it is heavy/slow (implied by 'composite'), or what it returns, so key behavioral traits remain undisclosed.

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

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

It is a single front-loaded line with no wasted words, which is good, but the noun-fragment style leaves it under-specified rather than genuinely concise for a tool with parameters and no output schema.

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-required-parameter diagnostic tool with no output schema, the description covers the broad 'what' but omits the parameters, the return shape, and any usage decision criteria. It is adequate as a label but incomplete as agent guidance.

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 never mentions include_queries or include_connections. The boolean names are somewhat self-explanatory, but the description adds no meaning about what including them changes or when each is useful.

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

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

The description names a specific diagnostic operation ('Composite database health check') and enumerates the areas covered (cache, connections, vacuum, indexes, sequences), which clearly separates it from read-oriented siblings like describe_table or explain_query. It lacks a true verb and never explicitly contrasts itself with get_connections or list_indexes, which overlap its scope.

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

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

There is no when-to-use guidance at all. Because it is a 'composite' tool that overlaps several siblings (get_connections, list_indexes, get_slow_queries), an agent has no basis for choosing it over those narrower tools or understanding its cost relative to 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Get' which implies a read operation, but doesn't specify if it's safe, requires permissions, has side effects, or details output format. For a tool with 5 parameters and no annotations, this is a significant gap in 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 single, front-loaded sentence that directly states the tool's purpose. There is no wasted text, making it efficient and easy to parse.

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

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

Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain parameter meanings, return values, or behavioral traits, leaving the agent with insufficient information for effective tool 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%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'sql', 'analyze', 'buffers', 'costs', or 'format', failing to compensate for the lack of schema documentation.

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

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

The description clearly states the verb 'Get' and the resource 'query execution plan (EXPLAIN)', making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'query' tool, which might also involve query execution, so it doesn't reach the highest score of 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 like the 'query' tool or other siblings. It lacks context on use cases, prerequisites, or exclusions, leaving the agent without direction for 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. It usefully discloses that idle-in-transaction warnings are surfaced, implying a read/display operation with diagnostic content, but says nothing about permissions, whether it is read-only, cost, or result shape.

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 or redundancy. It is appropriately lean for a lightweight inspection tool, though it is terse enough that nothing is spent on disambiguation.

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

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

For a tool with no annotations, no output schema, and zero schema description coverage, one sentence is only partially sufficient. It sketches the return content but does not explain how grouping or query inclusion alters results, nor any operational prerequisites.

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 neither parameter (group_by, include_queries) is mentioned in the description. The group_by enum values are somewhat self-explanatory in the schema, but the description fails to explain grouping behavior or what include_queries changes in the output.

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-plus-resource ('Show active database connections') and enumerates the substance returned (utilization, idle-in-transaction warnings). It is clearly distinguishable from siblings like get_slow_queries or list_objects, though it never explicitly names a sibling to contrast against.

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 purpose implies when it applies (inspecting live connection state), but there is no explicit when-to-use, when-not-to-use, or alternative named. An agent must infer it is for connection monitoring versus diagnose_database or get_slow_queries.

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 behavioral burden, yet it discloses almost nothing: not whether this is read-only, not whether the pg_stat_statements extension must be installed, and not what include_query_text implies for query text exposure or privacy. It only reveals the backing view.

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?

It is a single compact sentence with no filler, front-loading the resource and the data source. It is efficient, though it is arguably too terse for the breadth of undocumented options it must cover.

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 five undocumented parameters, no output schema, and no annotations, the description is far too thin for the tool's complexity. An agent cannot tell what the results look like, how they are ordered by default, or whether the call requires prior diagnostics.

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% across five parameters, including a sort_by enum and numeric thresholds. The description's 'filtering and sorting' adds no meaning beyond the parameter names themselves, leaving min_calls, min_duration_ms, limit, and include_query_text entirely unexplained.

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 (slow queries) and the data source (pg_stat_statements) plus activities (filtering and sorting), which is more than a tautology. However, it does not distinguish itself from sibling diagnostics tools like explain_query or diagnose_database, so an agent must infer the boundary.

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 'with filtering and sorting' gestures at capability but gives no when-to-use context, no exclusions, and no mention of alternatives like explain_query for a specific statement. The agent gets no routing guidance among the nine sibling 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 of behavioral disclosure. It states what the tool does but doesn't describe behavioral traits such as whether it's read-only, what permissions are required, how results are formatted, or if there are rate limits. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero waste—every word contributes to understanding the tool's purpose. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 complexity (2 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter usage, output format, and differentiation from siblings. For a database tool that likely returns structured data, this is inadequate to guide an agent effectively.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'table or schema' which hints at the two parameters, but doesn't explain their semantics, relationships, or usage (e.g., that 'schema' is required and 'table' is optional for listing all indexes in a schema). This adds minimal value beyond the schema.

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

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

The description clearly states the verb ('List') and resource ('indexes') with scope ('for a table or schema'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'get_constraints' which might also provide index information, so it doesn't reach the highest score.

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 'describe_table' or 'get_constraints', nor does it mention prerequisites or context for usage. The phrase 'for a table or schema' gives minimal context but no explicit usage rules.

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 behavioral burden. It implies a read-only list and names the object types, but omits permissions, pagination, default schema behavior, and any return format details.

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 zero waste. It names the verb and resources immediately, which is appropriate for a simple list tool.

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

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

For a low-complexity list tool, the description covers the basic operation but leaves a key invocation detail unstated: whether schema is optional and what happens if omitted. With no annotations and no output schema, it is minimally adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It names the enum values for type and indicates that schema scopes the listing, which adds useful meaning, but it does not clarify schema optionality or default behavior.

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

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

States a specific verb 'List' and clear resource set 'tables, views, or functions in a schema'. It distinguishes from list_schemas and list_indexes by naming the object types, though it does not explicitly route away from search_objects or describe_table.

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 when-to-use guidance, prerequisites, or alternatives are given. The description implies it lists database objects in a schema, but does not say when to choose it over siblings such as search_objects or list_indexes.

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 burden but offers minimal behavioral insight. It implies a read-only operation by using 'List', but doesn't disclose permissions needed, pagination behavior, rate limits, or what 'all schemas' entails (e.g., scope or limitations). This is inadequate for a tool with potential complexity.

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

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

The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool, making it easy to parse quickly.

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, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what a 'schema' entails in this context, how results are returned, or handle the parameter, leaving significant gaps for the agent to operate effectively.

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 1 parameter with 0% description coverage, so the description must compensate but doesn't mention the parameter at all. It adds no meaning beyond the schema, but since there's only one parameter and the baseline for low coverage is higher with fewer params, a score of 3 reflects minimal adequacy without added 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?

The description clearly states the action ('List all') and resource ('schemas in the database'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_tables' or 'list_views', which would require specifying what distinguishes schemas from those resources, so it falls short of a perfect score.

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 doesn't mention prerequisites, context for usage, or comparisons to siblings like 'list_tables' or 'list_functions', leaving the agent to infer usage based on tool names alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions pagination and parameterization, but says nothing about read/write semantics, transaction behavior, permissions, multiple-statement handling, or side effects. For an arbitrary SQL execution tool, these are significant undisclosed traits.

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 single sentence is front-loaded and contains no filler. It is efficient, though arguably too sparse for a tool with four parameters and no annotations. There is no wasted 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?

Given the complexity of arbitrary SQL execution, four parameters, no annotations, and no output schema, the description is materially incomplete. It omits result format, error behavior, pagination defaults, parameter binding rules, and whether writes or DDL are permitted. It leaves an agent guessing on important invocation details.

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

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

Schema description coverage is 0%, so the description must compensate, but it only loosely references pagination and parameterization. It does not explain parameter binding order, how sql relates to parameters, default or maximum page sizes, or whether offset and pageSize interact. The required sql parameter is only implicitly covered by 'Execute SQL'.

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: 'Execute SQL'. This is clearer than a generic name like 'query' and distinguishes it from read-only siblings such as describe_table and list_schemas. It does not explicitly contrast with explain_query or list_objects, so sibling differentiation is not fully achieved.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It implies that the tool runs SQL, but an agent gets no help deciding between this and explain_query, describe_table, or other sibling tools. There are also no exclusions or warnings about 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only the search scope ('across schemas') and says nothing about case sensitivity, default search breadth, pagination/limit behavior, ordering, or result shape for a multi-parameter search 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?

A single dense sentence with the verb and resource front-loaded and no filler or redundancy. Every token contributes to the reader's understanding of what is searched and how.

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 4 parameters, no annotations, no output schema, and 0% schema coverage, the agent has almost nothing to work with beyond one sentence. Defaults (does it search all schemas? what is the default limit?), matching semantics, and result format are all unaddressed, leaving real gaps 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%, so the description is the only source of parameter meaning. It loosely covers three of four parameters — 'pattern' (name pattern), 'object_types' (tables/columns/functions/views), and 'schemas' (across schemas) — but omits the 'limit' parameter entirely and never mentions the additional enum values (index, constraint) the schema allows.

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 ('Find') and concrete resources ('tables, columns, functions, views') plus the matching mechanism ('by name pattern across schemas'). An agent understands this is a name-pattern search rather than a full listing. It stops short of naming the sibling list_objects, so the boundary between the two is left to inference.

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 'by name pattern' implies the usage condition (you have a partial/known name and want to locate matching objects), which is a reasonable implied-use signal. However, there is no explicit statement of when to prefer this over list_objects or describe_table, and no exclusions or prerequisites.

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