Search Funds and ETFs

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

Beyond the readOnlyHint annotation, it discloses result shape (one canonical profile per series), ranking behavior ('exact stored tickers outrank verified share-class aliases'), and a coverage boundary (NPORT-P filers only, misses are coverage artifacts). These are exactly the behavioral traits an agent needs and that annotations cannot convey.

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?

Three compact sentences plus the coverage caveat, front-loaded with the core action before the ranking and coverage details. No padding, though the enumeration of return fields is dense enough that it verges on a run-on.

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?

With no output schema, the description compensates by naming the returned fields (ticker, registration type, latest report date, assets, holding counts), stating the ranking rule, the coverage scope, and the follow-up tool. Nothing material for a correct call is missing.

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 baseline is 3 and the schema already documents both parameters. The description largely mirrors the schema's query enumeration, and it even diverges slightly by citing 'SEC series ID' while omitting the 'verified share-class alias' the schema lists; it adds little new parameter syntax or format detail.

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 and resource ('Search the tracked SEC Form NPORT-P fund directory') and enumerates the four accepted lookup keys. It distinguishes itself from adjacent tools such as GetFundProfile by explicitly routing the returned profile ID forward, so an agent can tell which tool to call first without opening 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?

Gives a clear workflow cue ('Use the profile ID with GetFundProfile') and an important interpretive caveat that empty results reflect dataset coverage rather than fund existence. It does not, however, contrast this tool against textual siblings like SearchDocument or SearchInstitutions, so the 'when not to use' side is left implicit.

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