olist_nota_fiscal_obter_xml

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, but it only states that the tool obtains XML and gives the endpoint. It does not describe what the XML contains, whether authentication is required, what errors may occur, or whether this is a safe read-only operation beyond the implied 'obter' (get).

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 concise, with two short sentences that state the purpose and provide the endpoint and documentation link. No unnecessary words are used, and the structure front-loads the core 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?

For a simple single-parameter retrieval tool with no output schema, the description gives the essential purpose and a documentation URL. However, it lacks information about the return format or any behavioral details, which would have made it more complete given the absence of an output schema.

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 only parameter 'id' is described as 'Número de identificação da nota fiscal na Olist'. The tool description adds no further semantic detail about the parameter, so it relies entirely on the schema, which is adequate for a single simple identifier.

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 tool's function: 'Obter XML da Nota Fiscal API 2.0' (Get the Nota Fiscal XML from API 2.0), which specifies the verb and resource. It distinguishes itself from sibling tools like olist_nota_fiscal_obter and olist_nota_fiscal_obter_link by explicitly targeting XML retrieval, though it does not explicitly compare itself to those alternatives.

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 provides no guidance on when to use this tool versus alternatives such as olist_nota_fiscal_obter or olist_nota_fiscal_obter_link. It only mentions the endpoint and documentation URL, leaving the agent to infer usage context from the tool name and schema.

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