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

Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds useful context: the source is the SEC EDGAR full-text search API, no API key is required, and searches are by institution name with date-range filtering. It doesn't disclose possible search-result limitations or pagination, but the annotation coverage lowers the bar.

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 well-organized and front-loaded: purpose, return fields, regulatory context, usage bullets, date format, and source/auth are each given one short section. Every sentence adds information and there is no filler.

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 the core use case the description is complete: it explains what the tool does, what it returns, when to use it, the input format for dates, and the data source. An output schema exists, so return values don't need to be enumerated. It doesn't address advanced cached-result or internal-filter behavior, but those are documented in the schema and are not essential to primary usage.

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?

With schema description coverage reported at 0%, the description must compensate. It adds meaning for the core parameters by explaining the query is an institution name and that start_date/end_date use YYYY-MM-DD. However, it leaves the many fin-specific parameters (wholesaler_ids, source_resource_id, exclude_fillers, additional_display_fields, etc.) entirely to the schema, so the compensation is only partial.

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 opens with a specific verb+resource: 'Search SEC EDGAR for 13F-HR institutional holdings filings by institution name.' It also names the exact return fields (filing date, entity name, period of report, accession number), which sharply distinguishes it from siblings like Get13FHoldings or GetEdgarCompanyFilings.

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 description provides an explicit 'Use this tool when' list with concrete scenarios such as researching an institution's investment strategy or getting a list of 13F filings for a manager over a date range. It does not name sibling alternatives or give when-not-to-use guidance, so it stops just short of a 5.

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