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

No annotations are provided, so the description carries the full burden and it does disclose a key behavioral constraint: the query must return a single summary row, implying rejection of multi-row results. It does not cover permissions, what happens on violation, or rate/access behavior, so the disclosure is 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?

Purpose and constraint come first, followed by a compact illustrative example; every element earns its place. The example sentence is long but directly encodes the required shape of the input rather than padding.

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, return values need not be described, and the description covers purpose, input shape, and the aggregate-only constraint. The main remaining gap is the lack of explicit routing versus query/export_query, but for a one-parameter tool this is close to 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% for the single sql parameter, so the description must compensate, and it does by giving concrete example syntax (count(*), count(distinct gvkey), min/max fyear, FROM comp.g_funda WHERE ...) plus the single-summary-row constraint on the input. This meaningfully clarifies what belongs in the parameter.

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 an aggregate-only availability check') and pins the scope ('on any accessible library, including ones where row-level data is not AI-allowed'). This distinguishes it reasonably from the generic query sibling, though it never names the alternative explicitly.

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 'aggregate-only' framing and the note about libraries where row-level data is not AI-allowed, which hints this is the way to probe restricted libraries. However, there is no explicit when-not or named alternative (e.g., use query for row-level retrieval), leaving the agent to infer the boundary with query/export_query.

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. 'Show' implies a read-only metadata lookup with no side effects, and it discloses that column descriptions are returned only 'where available', but it says nothing about permissions, cost, or behavior for missing/invalid tables.

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, tightly written sentence with the key output contents front-loaded and no filler. Nothing needs trimming and nothing is buried.

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-value detail is not required, and the one-liner adequately conveys the tool's intent. However, with 0% parameter coverage and no annotations, the unresolved 'library' semantics leave a real gap for an agent trying to invoke 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?

Schema description coverage is 0% and neither parameter is documented. The description only implies 'table'; the required 'library' parameter is never explained, nor is the expected naming format (e.g., whether it takes a library code like 'comp').

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 gives a specific verb ('Show') and resource ('columns, types and column descriptions for a table'), which is a clear describe/schema-inspection operation. It is naturally differentiated from siblings like list_tables and query, though it never names them explicitly.

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 versus list_tables, search_catalog, or query, nor any mention of prerequisites. Usage is only weakly implied — an agent must infer it is for inspecting a known table's schema before querying.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses read-only semantics, that no row limit is applied, the default output location, accepted formats, and that a 5-row preview is granted only for AI-allowed sources. It omits overwrite behavior, permission requirements, and whether the filename needs an extension.

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 compact sentences, front-loaded with the core action. The 'fmt: csv, parquet or xlsx' fragment is terse but slightly choppy against the prose around 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?

An output schema exists, so return values need not be described, yet the description still summarizes them (path, row count, columns) without harm. Remaining gaps are minor operational details such as overwrite behavior and filename format conventions.

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 value for `fmt` by enumerating csv, parquet, and xlsx, and clarifies `sql` is a read-only SELECT, but `filename` gets no guidance (path vs. name, extension handling) beyond the default folder mention.

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 gives a specific verb and resource: run a read-only SELECT and save the result to a file. It implies the distinction from the sibling `query` tool by emphasizing persistence to the output folder and no row limit, but it never names `query` explicitly, so the differentiation is inferred rather than stated.

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 ('no row limit', 'save it to the output folder') which suggests this is for large result sets the agent wants persisted, but it never states when to use this over `query` or `check_availability`. No exclusions or prerequisites are given.

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

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

With no annotations, the description must carry behavioral weight; it discloses that results are account-scoped and include vendor plus an AI data-return policy flag, which is useful context. However, it says nothing about pagination, whether the operation is read-only (implied by 'list'), or rate/auth constraints.

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 front-loaded sentence that names the resource, scope, return fields, and the filter in minimal words. Nothing is redundant or padded.

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?

An output schema exists, so return-value structure is documented elsewhere, and the description still summarizes the notable return fields. The only gap is lack of routing guidance among the six sibling catalog/query tools, which is minor for a simple enumerate operation.

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

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

Schema coverage is 0% and the single 'contains' parameter is undocumented in the schema, but the description rescues it by explaining it as an optional substring filter. That adds the matching semantics ('substring', 'optional') the schema lacks, though no case-sensitivity or field-matched details are given.

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 (list WRDS libraries) plus scope (those this account can access) and the fields returned (vendor, AI data-return policy). It is distinguishable from list_tables/describe_table by resource, but does not explicitly name or contrast with any sibling.

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, prerequisites, or alternative is given. The mention of an optional substring filter hints at usage but does not explain when to prefer this over search_catalog or when to enumerate libraries before calling list_tables.

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 usefully discloses that row counts are 'approximate' rather than exact, and 'List' implies a read-only operation, but permissions, result size, or pagination behavior are not addressed.

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

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

A single tight sentence with no wasted words, and the resource and scope are front-loaded. Every clause 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?

An output schema exists, so return values need not be explained, and the description covers the core purpose plus the approximation caveat. It could say more about how libraries relate to the sibling list_libraries tool, but nothing critical for a simple read 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 single parameter, library, has 0% schema description coverage, and the description only alludes to it via 'in a WRDS library'. It adds minimal semantic meaning beyond the bare parameter name.

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 resource (tables) with the scope qualifier 'in a WRDS library'. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like describe_table or search_catalog.

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, no exclusions, and no mention of alternatives such as search_catalog or describe_table. Usage is only weakly implied by the verb 'List'.

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

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

With no annotations, the description carries the full burden and does disclose key traits: read-only, a hard 500-row ceiling, CSV output, and a policy gate on referenced libraries. It omits error behavior (e.g. whether exceeding 500 errors or clamps) and any rate-limit or permission detail.

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, zero filler, and the operational facts (read-only, row cap, CSV) are front-loaded ahead of the policy caveat. Every clause 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?

An output schema exists, so return values need not be explained further, and the description already covers the essentials for a query tool. The remaining gap is the undocumented sql parameter contract and ambiguous overflow behavior past the 500-row cap.

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 both parameters are undocumented in the schema. The description rescues 'limit' by supplying the 500 max that the schema lacks, but says nothing about the required 'sql' parameter's dialect, allowed statements, or format. Partial compensation only.

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 ('Run a read-only SELECT'), the return shape ('up to limit rows as CSV'), and the scope constraint (max 500). It is distinguishable from export_query and list_tables at a glance, though it never names a sibling to sharpen 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?

It gives one hard precondition ('only allowed when every referenced library is AI-allowed under the WRDS policy'), which is genuine usage guidance. However, it never says when to prefer this over export_query, or what to do for larger result sets, leaving the main routing decision to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose the access scope ('all accessible libraries') and that three distinct field types are matched, which is meaningful behavioral context for a read tool. It omits anything about result limits, ordering, or how hits are returned, and there is no explicit read-only statement.

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, front-loaded with the core purpose and followed by a directive on when to reach for it. Every clause carries information; there is no 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 existence of an output schema means return values need not be described, lowering the bar. Still, for a three-parameter tool with zero schema coverage and no annotations, the description leaves library_contains and max_results unexplained and gives no guidance versus the overlapping check_availability sibling.

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, and it only partially does: the example keywords ('revenue', 'nace', 'sic', 'orbis') clarify what 'keyword' should contain. The other two parameters, library_contains and max_results (default 200), receive no explanation at all, leaving their meaning and effect undocumented.

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 (Search) and precisely enumerates the searched resource fields (table names, column names, column descriptions) plus the scope (all accessible libraries), which is far more informative than the bare name. It does not, however, differentiate itself from the sibling check_availability, which the phrasing 'is X available?' arguably overlaps with.

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 this first to answer "is X available?" questions' gives an implied entry-point role and usage context. But it never mentions the sibling check_availability or when that tool should be preferred instead, leaving the agent to guess at overlap between the two.

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