Fund Operations (Form N-CEN)

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

Beyond the readOnlyHint annotation, it discloses non-obvious behavior an agent cannot infer: N-CEN is filed at registrant level rather than series level, ingestion runs through tracked issuer feeds, and a resolvable series can still yield zero reports. That is exactly the kind of caveat that prevents a false 'no data means not a fund' conclusion.

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?

Four sentences, front-loaded with purpose, then identifiers, then returned content, then coverage caveats — no filler. The coverage-caveat sentence is long and could be tightened, which keeps it just shy of a 5.

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?

There is no output schema, so the description carries the return-value burden and does: registrant classification, Investment Company Act file number, reporting period, first/last-filing flags, latest service providers, and filed-name provider history. Combined with the coverage caveats, an agent has everything needed to call this correctly and interpret empty results.

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 `fund` and `maxResults` parameters are fully documented in structured form (including accepted identifier forms and the default/max on maxResults). The description restates the identifier types but adds no syntax, resolution-order, or format detail beyond the schema, so the baseline of 3 applies.

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: retrieve operational data for a registered investment company from SEC Form N-CEN annual reports. The scope is narrow enough (N-CEN only, registered funds only) to distinguish it from the broad sibling GetFundProfile without opening either 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?

Points the agent at SearchFunds as the source of valid identifiers and states the exclusion cases explicitly (non-registered/operating companies return no data; untracked multi-series trusts may resolve but have no report). It never names a concrete alternative tool to call instead for those cases, so it stops short of a full 5.

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