Share Email

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the security-relevant outcome that anyone possessing the link can view the email, and that both sent and received IDs are valid inputs. It does not, however, describe what the tool returns (there is no output schema) or whether a link can be revoked after being created.

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 short sentences, around 30 words, with the action and the access context front-loaded. The only redundancy is repeating 'sent or received' in both sentences, a minor duplication that does not harm readability.

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 simple tool (2 parameters, 1 required, no nested objects, full schema coverage), the description covers purpose, scope, and the key access caveat. The single notable gap is that the return value — the actual shareable URL — is not stated, and with no output schema the agent cannot determine the exact response format from structured data.

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%, so both parameters are fully documented: id identifies the email to share and expiresIn specifies the human-readable duration, the format, the default of 48 hours, and the ≥ 48-hour cap. The description adds no additional meaning beyond this, so the baseline score of 3 for fully documented schemas is appropriate.

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 ('Create a shareable link for a sent or received email') and adds the purpose: anyone with the link can view it without Resend dashboard access. The closing scope statement ('Works for any email ID, sent or received') makes clear it is distinct from retrieval siblings like get-email and get-received-email.

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 communicates exactly when this tool is appropriate: when an email needs to be viewable by someone without Resend dashboard access. However, it does not name excluded alternatives or state when not to use it, leaving alternative routing implicit.

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