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

Adds substantial behavior beyond the annotations: access is read-only until the account grants more in Ajustes, the recipient's flow differs depending on whether it already has a contix account, and the same generic reply is returned in all cases by design for privacy. This privacy-preserving return contract is exactly the kind of thing an agent cannot infer from the schema.

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?

Front-loads purpose and access level, then explains the two recipient paths and the generic reply. Dense and nearly waste-free, though the final sentence partly restates the 'same generic reply' point already made.

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 one-parameter mutation with no output schema, the description covers the access granted, the recipient-side flow, the privacy-motivated return value, and the account scope. Nothing an agent needs to invoke it correctly is missing.

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?

Only one parameter (email) with 0% schema description coverage. The description confirms the invite is sent 'by email' and discusses what happens based on account existence, but adds no format, validation, or constraint details for the email value itself.

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?

States a specific verb and resource ('Invite the accounting firm (gestoría) ... by email') and what the invite grants (read-only visibility and export of invoices/expenses). It scopes itself with 'Only for the own account', which helps distinguish it from the gestoria_*_mandante siblings, though it never names them.

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?

Gives clear context: invite the firm that keeps this account's books, and explicitly restricts to the own account, implying the mandante sibling is for other cases. It doesn't explicitly name the alternative tool or state when not to use it beyond that scoping sentence.

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