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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context: data is ~30-60 days delayed, only US-registered funds covered, and funds like UITs are excluded. It doesn't contradict annotations—readOnly is consistent with a read-only query. The description goes beyond annotations to set expectations about data freshness and coverage limitations.

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 longer than typical but every sentence serves a purpose: purpose, usage, examples, distinction, coverage, and exclusions. The essential info (what it does, how to use) is front-loaded, with edge cases at the end. It's not overly verbose given the complexity (fund vs manager distinction). It loses a point for being a bit longer than ideal, but it's well-organized and each sentence earns its place.

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 tool with 3 parameters and no output schema, the description is nearly complete. It explains the output will include net assets, holdings count, and top positions with name, CUSIP, value, and % of fund. It also covers common failure modes (non-US funds, UITs, CIK misuse) and provides alternatives. It doesn't specify pagination or error details, but those are less critical. Given the tool's moderate complexity, this is near-complete.

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% since both parameters have descriptions, providing a baseline of 3. The description adds value by clarifying the ticker parameter is REQUIRED (despite schema showing required: []), and warns that `ticker_or_cik` is an alias but must be a fund ticker, not a CIK. It also explains that 'limit' is a preference (1-100, default 25) implicitly. This elevates from baseline to a 4 because it clears up the ambiguity around the alias and the required nature of ticker.

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 clear verb ('Pass'), resource (US ETF/mutual fund portfolio holdings from SEC Form N-PORT), and specific scope (latest monthly portfolio with net assets, holdings count, top positions). It explicitly differentiates from edgar_institutional_holdings by naming the sibling and defining what it covers (13F managers vs. fund's own N-PORT). The phrase 'AUTHORITATIVE' adds confidence, and the list of example queries makes the purpose unmistakable.

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 gives explicit usage instructions: pass the fund's ticker (not company tickers), provides example tickers, mentions the alias `ticker_or_cik` and warns that a CIK won't resolve. It explicitly contrasts with edgar_institutional_holdings and explains the N-PORT vs 13F distinction. It also provides negative guidance: funds structured as UITs (SPY, DIA) won't work, with a suggested alternative (IVV, VOO) for S&P 500 exposure. This is exactly what the dimension asks for.

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