find_search_backlog

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

With no annotations, the description carries the full burden and does provide useful behavioral context: it cross-references a live EDSM sphere with bodyCount against the journal ledger, orders unvisited systems first, and warns to confirm in-game. It does not explicitly declare read-only safety, network/API dependency, rate limits, or what happens when journal data is unavailable. The disclosure is helpful but incomplete for a tool with zero annotation coverage.

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 short and front-loaded with the main purpose before the data-source and ordering details. It avoids unnecessary repetition and keeps the in-game confirmation caveat concise. Minor clarity loss comes from the unexplained 'Raxxla grid backlog' phrasing and line-break formatting.

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 four parameters with 0% schema description coverage, but an output schema exists so return-value explanation is not required. The description supplies purpose, data sources, and ordering, which is useful context. It remains incomplete for correct invocation because parameter meanings and journal-directory behavior are not described.

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 the four undocumented parameters, but it largely does not. 'Near a reference' hints at system_name and radius_ly, and 'your journal ledger' hints at journal_dir, while max_results is not addressed at all. Default values, optionality, and the meaning of journal_dir are left entirely to the schema.

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 purpose: find systems near a reference that the commander has not fully scanned, using EDSM sphere data and the journal ledger. It also specifies result ordering (UNVISITED first, then VISITED-but-incomplete). It does not explicitly differentiate itself from close siblings like system_scan_status or edsm_sphere_systems, and the phrase 'Raxxla grid backlog' is unexplained jargon.

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 intended use is implied by 'Systems near a reference YOU have not fully scanned', so an agent can infer this is for exploration backlog discovery. However, there is no explicit when-to-use guidance versus alternatives such as system_scan_status, get_exploration_log, or edsm_sphere_systems, and no exclusions or prerequisites are stated. The note 'Confirm in-game' is a caveat, not routing guidance.

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