indices_b3

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches quotes but doesn't disclose return format, whether data is real-time or delayed, pagination/limits, or whether the optional indices parameter is mutually exclusive. For a data-fetching tool, the behavioral contract 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?

Single, compact Portuguese sentence that communicates the core function and gives concrete examples. No wasted words or redundant restatement of the name 'indices_b3'. Efficient and front-loaded with the essential purpose.

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 has a single optional parameter with full enum coverage, and the description names examples. However, with no output schema and no annotations, the agent doesn't know what the response shape looks like, whether quotes are current or delayed, or what units (points, percent change). For a simple one-parameter fetch tool, this is minimally adequate but leaves open questions.

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% - the single parameter 'indices' has a clear description ('Lista de índices para consultar') and a complete enum of valid values with a sensible default. The description adds the example list but the enum in the schema already fully defines acceptable values. Baseline 3 is appropriate when the schema does the heavy lifting.

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 clearly states the verb ('Obtém cotações') and resource ('principais índices da B3'), listing example indices (Ibovespa, IFIX, IDIV, SMLL). It's in Portuguese, consistent with the tool naming and sibling tools which are also Brazilian market tools. It distinguishes from siblings since no other tool mentions indices explicitly.

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 implies this is for getting index quotes as opposed to individual asset quotes (cotacao_ativo) or fund-specific data (fiis_lista, fii_detalhes). However, it doesn't explicitly state when to use this vs alternatives, nor does it mention when NOT to use it. The implied usage context is clear but no exclusion guidance is provided.

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