find_module

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

No annotations are supplied, so the description carries the full load. It does well on data-quality behavior (live Spansh, sparse snapshots, acquisition semantics for pre-engineered/tech-broker/Powerplay stock) and on the effect of standard_only. It is silent on how the search center is resolved (x/y/z vs system_name vs journal_dir), on rate limits, and on whether results are cached — gaps that matter for a read tool with no annotation cover.

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?

Front-loaded with the capability in the first line, then behavior and caveats in short follow-on sentences. The line breaks fragment the prose slightly, but no sentence is filler.

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?

An output schema exists, so return-value description is not required, and the acquisition caveat is genuinely valuable. For a 9-parameter tool with 0% schema coverage and no annotations, though, the missing location-resolution story (how 'near you' is determined when coordinates, system_name, and journal_dir are all optional) leaves a real decision undocumented.

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 for all 9 parameters. It explains module_query (name or ed_symbol), pages (default 1, max 10), and standard_only, but says nothing about x/y/z, system_name, journal_dir, or max_results — four of the nine parameters are documented in neither structured field nor prose.

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?

States a specific verb and resource ('Stations selling a module near you'), plus the matching semantics (name or ed_symbol) and the data source (live Spansh). It is distinguishable from find_ship and get_stored_modules by implication, but never explicitly contrasts itself with get_station_outfitting, which queries one known station.

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?

Usage is implied by the geography-based framing ('near you'), and there is real operational guidance on tuning `pages` because Spansh snapshots are sparse. However, there is no explicit when-to-use vs. get_station_outfitting / inara_search_nearest, and no statement of prerequisites such as needing a location context.

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