find_examples

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal useful behavioral traits: the corpus size (770 examples), the no-argument behavior of returning available types, and the list of valid pattern values. However, it does not describe the return format, how limit affects results, or whether the search is read-only, leaving meaningful 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?

The description is compact: two sentences, with the main action front-loaded and the pattern list in a single terse line. It avoids filler and is easy to scan. It sacrifices some completeness, but it remains well-structured and appropriately short for a search tool.

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 five parameters, no output schema, and no annotations, yet the description only covers the 'patron' values and the no-args return behavior. It does not explain how parameters interact, what a typical result looks like, or the role of 'libreria' and 'query'. Given the sibling context and parameter count, this is incomplete for confident 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%, so the description must compensate. It explains the 'patron' parameter by listing suggested values and mentions the no-argument behavior, but it does not clarify 'query', 'limit', 'tipo', or 'libreria'. With five parameters, the agent has insufficient meaning for most of them.

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 action and resource: 'Busca entre los 770 ejemplos oficiales de jgraph', identifying it as a search tool over the official JGraph example corpus. It also adds a distinctive behavioral note that with no arguments it returns available types. However, it does not explicitly differentiate it from siblings like get_example or build_from_example, so it falls just short of a 5.

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 when-to-use or when-not-to-use guidance is provided relative to sibling tools. The description only implies a possible workflow: call without arguments to discover types, then use 'patron' to filter. It never states that get_example should be used for retrieving a specific known example or that build_from_example is for building from an example, leaving the selection to agent inference.

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