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

Well beyond the readOnly/idempotent annotations, it discloses that no docking is required, explains data-freshness semantics (last-seen snapshots vs. live readings where an online member is present), defines read_at_tick and its absence on unverified hand-submitted readings, and names live_systems. These are exactly the operational traits an agent cannot infer from annotations.

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?

Purpose is front-loaded and every clause carries information (tier gating, freshness, pagination, ally rules). It is dense with nested parentheses and reads as one long paragraph, which costs a point on structure but not on wastefulness.

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?

With no output schema, the description adequately covers the return shape (read_at_tick per POI, live_systems, snapshot vs. live resources) and all invocation constraints for an 8-parameter tool. Nothing material is left unspecified.

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 description adds cross-parameter meaning: it groups filters by intel tier (L1 vs L2) and explains the alliance/opt-out condition governing source_faction_id beyond the schema's own text. Pagination defaults are repeated from the schema rather than extended, keeping it at 4.

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 ('query your faction's intel database, or an allied faction's') and defines the scope clearly enough to separate it from faction_query_trade_intel and faction_intel_status by subject matter. It never names a sibling explicitly, but the intel-DB focus is unambiguous.

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?

Gives concrete prerequisites: L1 Intel Terminal allows only system_id/system_name filtering while L2 Intel Center unlocks resource_type/poi_type/empire, and source_faction_id is allowed only when allied and the ally has not set ally_intel_opt_out. It stops short of naming an alternative tool to use instead for trade intel or ownership status, so it is context-rich but not a full routing guide.

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