anaf_delete_token

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

With no annotations provided, the description carries the full burden. It discloses the destructive consequence (revokes synchronization access for the CIF) and names the source of the token ID. It conveys that this is an irreversible/impactful action by describing the effect on e-Factura sync. This is good disclosure for a single-param delete operation.

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?

Two sentences, zero waste. Each sentence earns its place: the first states the action and consequence, the second clarifies the parameter origin. Excellent front-loading and brevity.

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 single-param delete tool with full schema coverage and no output schema, the description is appropriately complete. It explains the impact (revokes sync access), the consequence (irreversible), and where the ID comes from. Multiple related anaf_* siblings exist, but the destructive nature of this operation is sufficiently conveyed. No significant gaps for a tool of this simplicity.

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% and there is one parameter, which is fully described in the schema itself ('The ANAF token ID to delete'). The description restates the schema's parameter info ('token ID is an integer obtained from anaf_tokens'), which adds modest value by clarifying the source. With full schema coverage and no additional complexity, a baseline 3 is appropriate — the description doesn't need to add much.

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 (Delete), resource (ANAF OAuth token), and consequence (revokes e-Factura synchronization access for the associated CIF). It also specifies that the token ID is an integer from anaf_tokens, which distinguishes it from related tools like anaf_create_token_link and anaf_sync_trigger. This is a specific, actionable purpose statement.

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 explains what the deletion accomplishes (revokes synchronization access), which implies when to use it (when you need to revoke access). However, it does not explicitly state when NOT to use it versus alternatives, nor does it mention prerequisites like the token being obtainable from anaf_tokens (though it does reference where the token comes from). No alternative filtering or exclusion guidance is provided despite the many anaf_* sibling tools.

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