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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavior: results are de-duplicated by CIK (one record per filer), date filters restrict to recently updated prospectuses, and no API key is required. It also names the underlying source API. The only unexploited gap is that openWorldHint=false sits oddly against a live external EDGAR call, but the description does not actually contradict the annotation.

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 purpose, then use case, then examples, then behavioral notes — a clean hierarchy. The four example queries occupy real space but each maps a distinct keyword/type combination, so they earn their place; the only redundancy is restating return fields that the output schema already covers.

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 read-only search tool with an output schema, the essentials are present: what is searched, which forms, what comes back, how results are de-duplicated, and what to do with the CIKs next. The remaining shortfall is the unexplained auxiliary parameters (max_results, source_resource_id, wholesaler_ids) that an agent would have to guess at from the schema alone.

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 reported at 0%, so the description carries the burden and it only partially discharges it: it demonstrates keywords, fund_type, and date-range filtering through examples and prose. It says nothing about max_results (though the workflow implies one may need many results), source_resource_id caching, wholesaler_ids, or the miscellaneous filler/filter params, leaving several inputs unexplained in both places.

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 first sentence names a specific verb and resource ('Search SEC EDGAR for mutual fund and ETF filers by investment category or keyword') and then enumerates the exact form types scoped (N-1A, 485BPOS, N-2 for closed-end). That precision separates it from generic sibling searchers like GetEdgarCompanyFilings or SearchEdgar13F without the agent needing to open a 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?

It states a PRIMARY USE ('Step 1 of fee comparison') and explicitly routes the output to a named sibling, 'Feed the returned CIKs directly into GetFundFees'. Four worked example queries show how keywords and fund_type combine in practice. What is missing is any exclusion guidance — nothing says when to prefer GetFundProfile or GetEdgarCompanyFilings instead — so it stops short of a full when/when-not treatment.

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