Read the sector lens

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

Annotations already establish this as a safe, idempotent, non-open-world read, so the description's job is to add context — and it does by outlining the substantive sections of the response (rules and their dates, starting entries, sector-specific placements with reasons, hold-backs, priorities). That is genuine behavioral value in the absence of an output schema, though it stays conceptual and never mentions length limits, formatting, or what happens with an unknown sector value.

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?

Two sentences, the first front-loading the payload and the second delivering the no-argument fallback mode; nothing is redundant. The parallel clause list is dense but scannable, with only mild loss from abstract nouns like "what binds there" that could have been stated as "binding rules".

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?

For a single optional-string read tool with no output schema, the description covers purpose, the return content categories, and the no-argument mode — enough for an agent to call it correctly. The remaining gap is error and edge-case behavior for invalid sector values, which is a minor omission given full schema coverage.

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% and the schema already lists the six supported sector values, so the baseline is 3. The description does add one meaningful behavioral detail the schema lacks — that omitting the parameter switches the tool into a sector-listing mode — but it does not clarify matching behavior (exact string, case sensitivity) or what an unrecognized sector returns.

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 names a specific resource (the sector lens) and enumerates what it returns: binding rules with dates, starter entries, entries placed differently and why, hold-backs, and top entries. The verb is implicit ("How the Radar reads for one sector" rather than "Get the sector lens"), and the metaphorical phrasing ("what binds there", "what to hold back") makes the payload slightly harder to grasp, but the tool is still clearly distinguishable from siblings like get_entry or search_radar.

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?

It gives one useful usage rule: omit the sector to list the sectors the lens covers, which explains the optional parameter. However, it never says when to use this versus get_entry, get_dimension, or search_radar, nor does it state prerequisites or suggest a workflow (list sectors first, then query one).

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