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

Annotations already indicate a write operation (readOnlyHint=false) and non-idempotent behavior. The description adds 'ATO FISCAL REAL' to convey the legal gravity and mentions required permissions, providing context beyond the annotations. However, it does not detail potential side effects or what happens after transmission, so it stops short of 5.

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 a single, compact sentence that front-loads the key information ('ATO FISCAL REAL') and clearly states the action and requirements. Every word earns its place, with no fluff or repetition of schema details.

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?

Given that this is a fiscal transmission (write operation, non-idempotent, no output schema), the description is quite brief. It covers the action and prerequisites but omits any mention of return values, error behavior, or post-transmission status. Annotations help, but for a tool with real fiscal consequences, more context would be expected.

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 0%, so the description must compensate. It only clarifies the 'ids' parameter via 'por id', but leaves 'account' and 'empresa_id' unexplained. For a tool with three parameters, this is insufficient, as the agent must infer the meaning of these fields from context or external knowledge.

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: transmitting one or more MDF-e to SEFAZ by id. It uses a specific verb ('transmite') and resource ('MDF-e'), and the addition of 'ATO FISCAL REAL' emphasizes the real fiscal nature. This distinguishes it from sibling tools like hivecloud_mdfe_cancelar or hivecloud_mdfe_encerrar.

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 clear context for use: it is for sending MDF-e to SEFAZ and explicitly states prerequisites ('allow_writes + mdfe_tenant_id'). While it does not name alternative tools or explicitly say 'use when...', the purpose and requirements imply when it should be used, which is sufficient for a 4.

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