Index Membership As-Of a Date

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

Annotations only declare readOnly/idempotent/non-destructive, which the description matches — no contradiction. The description adds substantial behavioral context beyond annotations: the four-state answer semantics where 'uncertain' and 'out_of_coverage' must not be collapsed into 'absent', the requirement to report uncertainty honestly, and the disclosure that answers are only trustworthy up to meta.coverage.answerable_through with a freshness lag. This is exactly the kind of behavioral nuance structured fields cannot express.

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 long but densely informative, front-loading the core question and the four-state contract before usage guidance and meta-field caveats. Every block earns its place for a tool this behaviorally complex; however, there is mild redundancy — 'never a bare yes/no' restates what the four-state list already implies, and the 'REPORT UNCERTAINTY HONESTLY' paragraph partially repeats the 'do not collapse' rule from the state definitions.

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?

Despite having no output schema, the description fully compensates by explaining the answer domain (four states), the return metadata (meta.coverage and meta.freshness.lag_days), and the trust boundary (answerable_through). For a complex point-in-time query tool with an open-world-ish answer space, this covers everything an agent needs to call it correctly and interpret results safely. The only nuance not stated — that index and symbol are semantically required despite a formal required count of 0 — is already in the schema descriptions.

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 100%, so the schema already documents all five parameters (date format/default, required index and symbol, ticker and identifier aliases), establishing the baseline of 3. The description does not add parameter-specific semantics beyond the schema — the as-of concept is conveyed by the tool name and title rather than per-parameter detail. The description is not required to compensate, so a 3 is appropriate.

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?

Opens with a specific verb+resource question ('Was a stock a constituent of an index on a specific historical date?') and immediately differentiates scope by defining the four-state answer domain. The tool is clearly distinguished from siblings like get_index_history (index values, not membership) and resolve_identifier_asof / get_identifiers_asof (identifier resolution, not membership).

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?

Explicitly states when to use it ('USE THIS for any "was X in the Nifty 50/500 on <date>" question, and for point-in-time universe construction or survivorship-bias-aware backtests') and gives a clear when-not with the exact failure mode it prevents ('Do NOT infer historical membership from today's constituent list — that is exactly the survivorship bias this tool exists to avoid'). An agent needs no inference to decide routing.

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