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 return content (columns, primary key) and implies a read operation, but does not mention error behavior, permissions, or 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?

One concise sentence that front-loads the key purpose. No redundant words or filler.

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

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

The description covers the main output columns and primary key but omits potential other details (e.g., foreign keys, indexes, constraints). With an output schema present (though not shown), the description is adequate but not exhaustive.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does not explicitly state that 'table' is the table name and 'schema' is the schema name (with default 'public'). The meaning is somewhat inferable but not explicit.

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 it provides a 'full description' of a table/view including columns (with details) and primary key. This is specific and distinguishes from siblings like list_tables (listing names) or get_relations.

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

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

No guidance on when to use this tool versus alternatives like list_tables, list_views, or get_relations. The description does not mention prerequisites, context, 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?

No annotations are provided, so the description must carry the full burden. It only mentions retrieving source code, but does not explicitly state that the operation is read-only (non-destructive), what happens on missing function, or any permission requirements.

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

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

The description is two concise sentences with critical information front-loaded. The first sentence states the purpose, the second provides disambiguation guidance. No redundant or unnecessary 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 that an output schema exists (not shown), the description need not explain return values. It covers the core behavior (full source retrieval and disambiguation). Minor gap: no mention of error conditions or system source (e.g., PostgreSQL).

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 meaning for the `arguments` parameter (disambiguation example) but does not elaborate on `name` or `schema` (default 'public') beyond what the schema provides.

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

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

The description clearly states 'Full source (CREATE OR REPLACE ...) of a function or procedure', specifying the verb (retrieve), resource (function or procedure), and output (full source). This distinguishes it from sibling tools like list_functions which only list names.

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 a clear usage guideline for overloaded names: 'If the name is overloaded, pass `arguments` (e.g. "integer, text") to disambiguate.' However, it does not explicitly state when not to use this tool or suggest alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns two categories (outgoing and incoming) and implies read-only safety, but doesn't elaborate on side effects, auth needs, or rate limits. Adequate 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?

Two sentences with no filler. The first sentence states the purpose and output structure, the second gives usage context. Every word is earned, and the information 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?

The output schema exists, so return values are covered. However, the description does not explain the schema parameter or note the default, and parameter coverage is 0%. For a two-parameter tool with an output schema, the description is 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 coverage is 0%, yet the description adds little beyond the schema: it mentions the table but not the optional schema parameter. The schema itself is simple, but the description fails to elaborate on parameter roles or constraints, leaving a gap for the agent.

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 foreign-key relationships (outgoing and incoming) for a given table, with a specific verb and resource. It distinguishes itself from siblings like list_constraints or describe_table by focusing specifically on FK data flow.

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

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

The description explicitly advises using this tool to understand data-flow impact before any write, providing clear context. It does not list exclusions or alternatives, but the guidance is sufficient for deciding when to invoke it.

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

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

With no annotations, the description carries the full burden. It states the tool returns 'all constraints' and 'their full definitions,' which is accurate but lacks details on permissions, performance implications, or side effects. The mention of constraint types adds some value, but behavioral context is minimal.

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 of 16 words. It efficiently conveys the tool's purpose and scope with no wasted words.

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

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

Given the tool's simplicity, the description covers the basic purpose but omits usage context and parameter details. The output schema exists, reducing the need to describe return values, but the lack of guidance on when to use the tool and the missing schema parameter explanation make it only partially 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%, yet the description does not explain the parameters. It implies the 'table' parameter by saying 'on a table,' but the 'schema' parameter (with a default) is not mentioned. The description adds little beyond parameter names from 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 explicitly states the tool lists all constraints on a table, enumerating the constraint types (primary key, unique, foreign key, check, exclusion) and specifying that full definitions are included. This clearly distinguishes it from sibling tools like list_indexes or list_triggers.

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 does not mention prerequisites, context, or when not to use it. For a tool with many siblings, this is a significant gap.

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 should disclose behavioral traits. It only mentions 'ordered labels' but omits whether the operation is read-only, what authentication is needed, or any output format details. Essential behavioral context is missing.

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 action and resource. It is efficient with no redundant words, though it could be slightly more structured with a bullet list of 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?

Despite having a single parameter and an output schema, the description does not explain what 'ordered labels' means, what the output contains, or how the schema parameter affects results. This leaves the agent underinformed 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%, yet the description fails to clarify the 'schema' parameter beyond implying its purpose. It does not specify valid formats, constraints, or how to leave it default. Minimal value is added over the schema itself.

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 'List enum types in a schema with their ordered labels', specifying the verb ('list'), resource ('enum types'), and scope ('in a schema'). It distinctly separates this tool from siblings like list_tables and list_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 provided on when to use this tool versus alternatives such as list_tables or list_constraints. The description lacks context for selecting this tool over others.

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 bears the full burden. It only lists what it returns without disclosing behavioral traits like authentication needs, performance impact, or whether it's read-only (implied by 'list'). This gap leaves the agent uninformed about side effects or restrictions.

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 immediately states the core action and included fields, then succinctly points to a sibling tool. No wasted words.

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

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

With an output schema present, the description only needs to provide a quick summary, which it does. It adequately distinguishes from sibling tools, though it could add more detail on any limitations or ordering.

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' has no description in the input schema (0% coverage). The description mentions 'in a schema' but does not elaborate on the parameter's meaning, format, or constraints beyond the default.

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

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

The description clearly states it lists functions and procedures in a schema, specifying the fields (signature, return type, language, kind). It also explicitly mentions an alternative tool (get_function_definition) for full source, distinguishing it from 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?

It directs the agent to use get_function_definition for full source, providing clear context on when to use an alternative. However, it doesn't explicitly state when not to use this tool or mention prerequisites.

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

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

No annotations provided, so description carries full burden. It discloses that the tool returns CREATE INDEX definitions and flags, which implies a safe read operation. However, it omits any mention of authentication, rate limits, or error conditions, which is minimal but not misleading.

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?

Single sentence, no wasted words, and front-loaded with key information. Could be slightly more structured, but remains concise and efficient.

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

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

Output schema exists, so return format is covered. The description adds value by specifying 'full CREATE INDEX definitions and flags'. However, lack of parameter explanation is a gap, making it only moderately 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%; the description does not explain the parameters (table, schema) at all. With low coverage, the description must compensate, but it fails to add any meaning beyond the schema's names and types.

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

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

Description clearly states the tool lists indexes on a table with full CREATE INDEX definitions and flags. It uses a specific verb 'list' and specifies the resource 'indexes on a table', distinguishing it from sibling tools like list_constraints and list_tables.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving index definitions, but lacks when-not-to-use or explicit references to siblings.

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

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

The description discloses the important behavioral detail that system schemas are excluded, which is critical for proper use. No annotations are present, so the description effectively carries the burden.

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, front-loaded with the core purpose, and contains no extraneous information.

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

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

For a tool with no parameters and an output schema, the description fully covers what the user needs to know: what is listed and what is excluded.

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

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

The input schema has no parameters, so the baseline is 4. The description correctly implies no parameters 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 clearly states the tool lists user schemas and specifies exclusions (pg_catalog, information_schema, temp), making it distinct from sibling list tools.

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 implied by the context of sibling tools (which list other database objects), but there is no explicit guidance on when to use or avoid this tool.

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 full burden. It discloses that the operation is a read (list) and mentions the output fields (comment, row count, size), but does not address potential behavior like filtering by schema (defaults to 'public'), performance implications, or permission requirements.

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

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

The description is a single, well-framed sentence of about 20 words. It immediately states the action and the object types, then adds output details. No wasted words.

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

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

For a simple list tool with one parameter and an output schema, the description covers the basic purpose and return info. However, given the number of siblings, more explicit differentiation or behavioral notes (e.g., 'does not include system schemas') would improve completeness. The output schema likely covers return fields, so that part is adequate.

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 parameter has no description in the input schema (0% coverage). The tool description adds context by saying 'in a schema', implying the parameter specifies the namespace, but it does not explain the default value 'public' or what happens if omitted. More detail is needed to fully compensate for the missing schema description.

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

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

The description clearly states the verb 'List' and specifies the exact resource set: tables, partitioned tables, views, and materialized views within a schema. It also mentions the output includes comment, estimated row count, and on-disk size, which distinguishes it from siblings like 'list_views' (only views) or 'describe_table' (single table details).

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

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

No explicit guidance on when to use this tool versus its siblings (e.g., 'list_views' for only views, 'describe_table' for detailed schema). The description only states what it does, not when or 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?

Without annotations, the description discloses that internal/constraint triggers are excluded and that triggers may cascade side effects, providing useful behavioral context beyond the schema.

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

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

The description is concise (two sentences), front-loaded with the main action, and each sentence adds value. No fluff.

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

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

Given the low complexity (2 simple parameters, output schema exists), the description covers the essential: what the tool does, its scope, and an important behavioral note. No gaps.

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

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

With 0% schema description coverage, the description adds limited meaning: it clarifies the 'schema' parameter as the target schema and 'table' as an optional filter. More detail on parameter constraints or defaults would improve it.

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

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

The description clearly states the tool lists triggers in a schema, optionally filtered by table, and includes full CREATE TRIGGER definitions. It also mentions exclusions, distinguishing it from sibling tools like list_constraints.

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 a usage hint to review before writes due to possible side effects, but does not specify when to use this tool over alternatives or provide exclusion criteria.

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

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

No annotations are provided, so the description must carry the burden. It indicates that the tool returns SQL definitions, which is a read-only operation. However, it does not disclose potential failure modes (e.g., invalid schema) or any performance considerations.

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, concise and front-loaded. Every word is purposeful, no redundancy.

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

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

For a simple listing tool with an output schema, the description is mostly complete. It specifies the return content (SQL definitions). Given the tool's simplicity, it covers the essential context, though it could mention the schema parameter's role more explicitly.

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?

Only one parameter 'schema' with a default. The description does not add meaning beyond the schema's title and default value. Since schema coverage is 0%, the description should compensate but fails to do so. It merely repeats the concept of schema without context.

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), the resource (views and materialized views), and the additional detail (with SQL definitions). It distinguishes itself from sibling tools like list_tables or list_functions.

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 it is used to retrieve views in a schema but does not provide explicit guidance on when to use it over alternatives or mention prerequisites like schema existence. The usage is implied but not elaborated.

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 provided, so description carries full burden. It discloses that the tool is read-only, rejects non-read and multi-statement SQL, caps returned rows, and notes that the DB session is read-only. This covers core behavioral traits without contradictions.

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 sentences, no unnecessary words. The main action is front-loaded, and the second sentence adds crucial constraints. 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?

The tool has 2 parameters, no nested objects, and an output schema (not shown but present). The description covers core behavior, restrictions, and one parameter's semantics. Missing details about error handling or edge cases, but for a simple tool it is reasonably complete.

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

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

Schema description coverage is 0%, so description must compensate. It adds value for the 'sql' parameter by specifying allowed statement types but does not describe the 'limit' parameter explicitly (its role in capping rows is implied). The description partially compensates but leaves the limit parameter under-specified.

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

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

The description clearly states the tool runs a single read-only SELECT/WITH/EXPLAIN/SHOW statement and returns rows. It distinguishes itself from sibling tools, which are all metadata listing tools, by specifying the exact SQL statement types it executes.

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

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

The description explicitly lists allowed statement types and mentions restrictions: rejects non-read and multi-statement SQL, caps rows. It provides clear context for when to use this tool (read-only queries) but does not offer explicit exclusions or mention alternative tools beyond what is implied by sibling context.

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

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

Description states it reports configuration but does not explicitly disclose that it is a read-only, non-destructive operation. Without annotations, the description carries full burden; it is minimally adequate but lacks explicit behavioral 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?

Single sentence, no wasted words. Front-loaded with purpose and 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?

With zero parameters and a simple read operation, the description adequately covers purpose and usage. Output schema handles return details, so description is complete enough for this complexity.

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

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

No parameters (100% schema coverage). Description adds meaning about the output (access mode, safety configuration) and its purpose (knowing permitted write operations).

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

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

Description clearly states verb 'Report' and resource 'server's current access mode and safety configuration'. It distinguishes from sibling listing tools by focusing on server permissions and safety, which is unique among 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?

Explicitly says to use before write operations to check permissions. Implicit when-to-use is clear. No explicit when-not or alternatives, but no sibling serves the same 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?

Description discloses types of statistics returned (live/dead rows, sizes, last vacuum/analyze, scans). No mention of it being read-only or side-effect-free, but output schema exists. Good behavioral context beyond what schema provides.

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

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

Single sentence with examples in parentheses, no wasted words. Front-loaded with 'Size and activity statistics'.

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?

Output schema exists so return values need not be described. Description complements by listing statistics categories. Parameters are simple; no missing context for normal usage.

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

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

Schema coverage is 0% but parameters are self-explanatory (table, schema). Description does not add parameter details; baseline of 3 is appropriate as schema names carry meaning.

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

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

Description clearly states the tool returns size and activity statistics for a specific table, listing examples. It distinguishes from siblings which are about listing schema objects or running queries.

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

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

No explicit guidance on when to use or alternatives, but the purpose is clear enough that an agent can infer usage from the context of database tools.

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