etf_nav

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. Beyond that the description adds nothing behavioral: it does not say whether non-ETF symbols error or return empty, whether values are real-time or end-of-day, or what units the premium/discount is expressed in. With the conceptual framing being the only contribution, transparency is thin.

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?

A single short clause with no filler and the key concept (premium/discount, NAV vs market price) front-loaded. It loses a point only because the fragment form omits a verb, making it less immediately actionable than a full sentence would be.

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?

The tool is simple (one required parameter, no nesting), but there is no output schema, so the description carries the burden of saying what comes back — NAV value, market price, premium percentage, timestamps — and it does not. It also doesn't note the ETF-only applicability, which is the most likely source of misuse given the many non-ETF symbol siblings in the toolset.

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% and the single symbol parameter is already documented with a Persian example ('فولاد') plus the insCode alternative. The description adds no parameter meaning and does not repeat that restriction, which is fine, but it also does not clarify whether sym/insCode typed input behaves identically. Baseline 3 applies when the schema does all the work.

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 names a distinct resource — fund/ETF NAV versus market price, expressed as premium/discount with the Persian terms صدور و ابطال — which clearly separates it from quote, order_book, and other pricing siblings. However, there is no verb: it reads as a topic label rather than a statement of what the tool returns or computes, so the agent must infer that calling it yields NAV and premium/discount figures.

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?

There is no when-to-use guidance, no statement that this only applies to ETF/fund symbols rather than ordinary equities, and no mention of alternatives. The parenthetical 'صدور و ابطال' hints at the issuance/redemption use case but is left implicit rather than spelled out as a selection condition.

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