search_examples

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the detail '~470 reference circuits' and clarifies search criteria ('by name or domain'), but it does not disclose limit behavior, sorting, pagination, or whether the operation is read-only. For a search tool, these are notable gaps.

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 that is front-loaded with the core action and scope. No filler words. Every term ('search', '~470 reference circuits', 'by name or domain') contributes meaningful information. It is appropriately concise for a search tool with a simple interface.

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 an output schema, so return values are presumably defined, but the description lacks contextual integration. It does not mention related tools like list_domains (which could provide valid domain values) or describe_example/get_example (which might be the next step after searching). The description is too isolated to fully orient the agent, especially given the many sibling tools.

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 explains that 'query' is a name or domain, adding meaning beyond the schema's bare 'Query' label. However, the 'limit' parameter is not mentioned at all; the schema only shows its type and default, leaving its purpose implicit. Partial compensation is achieved.

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 'Search the ~470 reference circuits by name or domain' clearly states the verb (search), resource (reference circuits), and scope (~470 circuits, by name or domain). This distinguishes it from siblings like get_example, describe_example, and generate_* 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?

The description provides no guidance on when to use this tool versus alternatives such as get_example, describe_example, or list_domains. It does not mention use cases, prerequisites, or exclusions, leaving the agent without clear direction on tool selection.

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