find_keywords

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

With no annotations, the description carries the behavioral burden. The detailed strategy parameter documentation discloses important behavior: semantic search has an optional dependency and falls back to pattern matching when not installed, catalog strategy is a literal substring filter that returns 0 for multi-word natural-language queries, and session strategy requires a session_id. It does not explicitly state read-only/no-side-effects, but 'Discover' plus the described search mechanics make the behavior clear.

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 front-loaded with the core purpose, immediately followed by actionable usage guidance. The long parameter documentation is dense but each part earns its place given the tool's complexity, and no redundant or filler text is present.

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 8 parameters and an output schema, but the description covers all necessary context: when to call it, how each strategy behaves, library filtering, strict mode, and session requirements. An agent can correctly invoke this tool without needing to infer missing information.

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 100%, so the baseline is 3, but the parameter descriptions go far beyond names. Each strategy is explained with its intended use and limitations, library_name semantics clarify sibling compatibility and precedence, and strict_library is described with a concrete example. This gives the agent everything needed to choose parameter values correctly.

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: 'Discover Robot Framework keywords using multiple strategies.' It clearly distinguishes this discovery/search tool from execution tools like execute_step and detail tools like get_keyword_info by framing the tool as the way to find keywords before executing them.

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 an explicit 'WHEN TO USE THIS TOOL' section with concrete triggers such as 'ALWAYS before calling execute_step with an unfamiliar keyword' and when an error says keyword not found. It does not explicitly name alternative tools for cases like retrieving details for a known keyword, so it stops short of full when-not guidance.

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