share_request_email

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

With no annotations, the description carries the burden of disclosing side effects. It does state that this tool sends an email and that authentication is required. However, it does not mention idempotency, duplicate-send behavior, or what happens if the verification request ID is invalid or unauthorized.

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 brief and front-loads the core purpose before the access note. The access block is useful but includes environment-specific instructions like 'restart this server' that could be considered outside the essential tool description; overall, there is no wasted filler.

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 tool with no output schema, the description covers the core operation and the necessary authentication precondition. It does not describe the email content or post-send behavior, but those are not required to invoke the tool correctly.

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?

The only parameter, id, is already described in the schema as 'Verification request ID' with 100% coverage, so the description adds little semantic value. The phrase 'subject of a verification request' contextualizes the ID but provides no additional format or usage details.

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 states a clear action ('Send an email notification') and a specific resource ('subject of a verification request'), so an agent can infer the operation. It does not explicitly contrast with sibling tools like resend_verification or send_account_email, but the resource and action are specific enough to avoid major ambiguity.

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 access prerequisites (Proof account, API key, or start_login) but does not say when this tool should be chosen over alternatives. No sibling comparison, exclusions, or conditions are given, so the agent must infer usage solely from the name and purpose.

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