redcon_structural_search

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses a critical dependency (ast-grep availability) and the resulting fallback behavior ('returns backend=unavailable'), which is valuable transparency. It also implies read-only semantics via 'Search', but does not explicitly mention side effects or other behavioral traits like rate limits. Still, key behavior is disclosed.

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 two sentences, front-loaded with the primary action, and every phrase adds value: AST pattern, difference from regex, behavioral consequences, dependency, and fallback. No wasted words.

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 that this is a search tool with a dependency and fallback, the description covers the essentials: what it does, how it differs, prerequisites, and failure behavior. There is no output schema, so return format is not described, but given the context of a search operation and sibling tools, the description is sufficient for correct selection and 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 coverage is only 25% (only 'language' has a description). The description adds crucial meaning to 'pattern' by explaining it is an AST pattern (not regex), which is essential for correct usage. However, 'scope', 'max_results', and 'language' are not elaborated, and the low schema coverage means the description should do more to compensate for those parameters.

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 by AST pattern ('Search by AST pattern'), differentiates from regex-based search ('not regex'), and specifies a key behavioral consequence ('matches skip comments and strings'). This distinguishes it from sibling redcon_search.

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 explicitly contrasts with regex search, implies when to use it (when AST-aware matching is needed), and provides a clear fallback mechanism ('callers fall back to redcon_search') plus a prerequisite ('Needs ast-grep on PATH or redcon[ast_grep]'). This gives strong guidance on when and how to use the tool.

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