lookup_command

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

No annotations exist, so the description carries the full burden. It does add genuine behavioral value by disclosing case-insensitive matching and enumerating the returned YAML fields, but it says nothing about what happens for an unknown/near-miss command name (error vs empty result), whether the name must be an exact command identifier or can include a prefix, or whether the full wiki is returned unfiltered.

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?

One sentence, front-loaded with the return payload and closed with the behavioral caveat. Every clause (return format, fields covered, case handling) earns its place; nothing is redundant.

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 output schema exists, so the field enumeration in the description is a bonus rather than a necessity, and return-value explanation is not required. However, with zero annotations on a lookup that can silently fail on a bad name, the description should say more about input format and miss behavior to be considered complete.

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% for the single "name" parameter, and the description adds only the case-insensitivity trait. It never clarifies whether "name" means a bare command name, a prefixed identifier, or whether the term must match exactly — meaning the agent is left guessing at the one input it must supply.

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?

"Full wiki YAML for an SQF script command" names a specific verb-equivalent (lookup/return) and a precise resource (an SQF command entry), and the parenthetical enumerates exactly what the payload contains (syntax, params, return, locality, examples). It implicitly separates itself from lookup_event by naming "command," but never names a sibling explicitly, so it stops 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 when-to-use or when-not-to-use guidance is given; the agent must infer that this is for a known command name while keyword exploration belongs to search. The "case-insensitive" note implies the key is a literal command identifier rather than a query string, which is a useful but implicit usage cue.

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