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

Annotations only declare readOnly/openWorld/non-destructive; the description carries far more: null flow semantics (N-MFP2/N-MFP don't file monthly), flows_basis discriminator, per-class reporting coverage counts vs total_share_classes, the explicit caveat that absent coverage fields do NOT imply completeness, the pre-2026-09-11 no-backfill boundary, verbatim fraction-of-1 units, and the 'pure-publisher, no derived scores' posture.

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 core purpose before the caveats, and nearly every sentence earns its place given the multi-generation data quirks. It is very dense and leans on repeated ⚠/caps warnings, which is scannable but bordering on noisy for a description of this length.

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 an 11-param, no-output-schema tool spanning three form generations, the description supplies the era-by-era cadence differences, null/coverage semantics, join keys, and filtering recipes an agent needs to call it correctly. No output schema exists, yet the returned fields and their caveats are explained where it matters.

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 schema already documents all 11 params and baseline is 3. The description adds real usage semantics beyond the schema: series_id is framed as 'one fund's monthly history', report_date filters as cross-fund month snapshots, cik/adviser_file_number as join keys, and sort combinations as patterns — genuinely useful invocation context.

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+resource: returns Form N-MFP3 monthly money-market fund reports, one record per (fund series, month), and enumerates the fields delivered (net assets, WAM/WAL, daily/weekly liquid-asset percentages, flows, stable-NAV posture). It also distinguishes itself from sibling datasets (N-MFP2/N-MFP generations, get_investment_advisers joins, get_nport_filings-adjacent XML) so an agent can place it without opening the schema.

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 explicit when-to-use triggers ('money-market fund assets or flows, fund liquidity levels, WAM positioning as a rates signal, prime-vs-government fund dynamics, or a specific fund family's money funds') plus concrete filtering recipes (series_id + sort report_date asc for one fund's history; report_date for a cross-fund snapshot). It does not name a sibling to use instead for portfolio-level data beyond pointing at source_url, so it falls just short of full when-not guidance.

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