leitos_enviar_notificacao

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

The description adds valuable context beyond annotations by specifying authentication requirements (GMAIL_USER and GMAIL_APP_PASSWORD in .env), pointing to app password creation, and mentioning it's equivalent to a specific node. Annotations already indicate it's not read-only, not destructive, not idempotent, and open-world, but the description provides practical implementation details.

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 well-structured with clear sections (overview, requirements, parameters, examples) and appropriately sized. Every sentence adds value, though the equivalence statement could be slightly more concise. The information is front-loaded with the core purpose first.

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 the tool's complexity (email sending with authentication requirements), the description provides complete context including purpose, requirements, parameters with examples, and practical usage guidance. With an output schema present, the description appropriately focuses on input and behavioral aspects rather than return values.

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?

With 0% schema description coverage, the description fully compensates by clearly documenting all three parameters (destinatario, assunto, mensagem) with their purposes and providing concrete examples. The description adds essential meaning that the bare schema lacks, making parameter usage clear.

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 specific action ('Envia notificação por e-mail via Gmail SMTP') and distinguishes it from sibling tools like 'leitos_enviar_sms' by specifying the email transport method. It identifies the exact resource (email notifications) and mechanism (Gmail SMTP).

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 about when to use this tool (sending email notifications via Gmail SMTP) and mentions it's equivalent to a node available to all agents. It doesn't explicitly state when NOT to use it or name specific alternatives, though the sibling tool 'leitos_enviar_sms' suggests an alternative notification channel.

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