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

With no annotations provided, the description carries the behavioral burden. It adds useful details: case-insensitive matching and a 50-row cap. However, it does not disclose what happens with no matches, whether results are ordered, or the exact return format.

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

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

A single sentence conveys the core behavior with no filler. Every element—row selection, cell matching, case-insensitivity, and result cap—is packed efficiently.

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 two-parameter search tool with no output schema, the description explains input behavior and the maximum result count. It could note what a result row looks like or empty-result behavior, but the basics are sufficiently covered.

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

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

Schema description coverage is 50%: the query parameter has a description while limit does not. The tool description adds the case-insensitive matching behavior for query, which is meaningful. However, the relationship between the limit parameter and the 'up to 50' behavior is only implicit, so the description partially compensates but does not fully clarify parameter semantics.

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 clear verb ('search') and resource ('dataset'), and precisely defines the behavior: returns rows whose cells contain the query, case-insensitively, up to 50 results. This distinguishes it from sibling tools like dataset_row or dataset_stats, which clearly have different purposes.

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

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

The description gives clear context for when to use the tool: when an agent needs to find dataset rows matching a query in any cell. It does not explicitly mention alternatives or exclusion criteria, but the search semantics are specific enough that an agent can infer the appropriate use case.

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