find_code_examples

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

Annotations already declare readOnlyHint=true. The description adds behavioral details: the search algorithm (BM25), filtering before scoring, and return fields. It discloses the INDEX_VERSION dependency, which is beyond what annotations provide.

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 with three sentences: purpose and return fields in the first, optional filters and scope in the second, and usage context in the third. It is front-loaded and every sentence adds value without 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?

Given the complexity (6 parameters, no output schema), the description covers purpose, return fields, optional filters, and preconditions. It references sibling contract for clarity. It does not explain default max_results or provide examples, but those are covered in the schema.

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 83%, so the schema already documents most parameters. The description adds minimal meaning beyond the schema, except mentioning that filters are applied before scoring and referencing the search_sections contract for scope filters. This adds some value but not enough to raise the score above baseline.

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 searches fenced code blocks using BM25, lists return fields, and distinguishes from sibling 'search_sections' by focusing on code blocks. It is specific about the resource and operation.

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 clear prerequisites (use after index_local, requires INDEX_VERSION>=3) and mentions optional lang and scope filters. It references the same contract as search_sections, giving implicit guidance on when to use this vs. alternatives, though no explicit when-not-to-use.

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