verify_emailVerify one email. Cached repeats within 30 days are free. If credits are 0, returns payment_required with a checkout_url. Never invent results. unknown means the check did not finish.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to verify | ||
| workspace_token | No | Workspace token from checkout. Or send Authorization: Bearer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses 30-day cached free repeats, the payment_required/checkout_url behavior when credits are 0, the 'never invent results' reliability rule, and the meaning of 'unknown.' This goes well beyond a bare definition.
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 four short sentences with no filler. The core action is front-loaded, and each subsequent sentence provides a distinct and relevant behavioral detail.
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 two-parameter tool with no output schema, the description covers the main invocation and edge-case concerns: caching, credit exhaustion, unknown outcomes, and reliability expectations. It does not specify the success response format, but this is a minor gap given the tool's 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 description coverage is 100% for both parameters, so the baseline applies. The description adds no parameter-specific meaning beyond what the schema already provides, although it does add broader billing and result context.
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 opens with 'Verify one email,' which states a specific verb and resource and distinguishes the tool from the sibling tools balance and receipts. The purpose is immediately clear without requiring schema inspection.
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 implies this is the tool for single-email verification, and it provides useful operational context such as caching and credit-exhaustion behavior. However, it does not explicitly discuss when to use this tool versus alternatives, though the siblings are unrelated in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: balance checks credits, receipts lists past proofs, and verify_email performs email verification. No overlap exists, making tool selection unambiguous.
balance and receipts are noun-style names, while verify_email follows verb_noun convention. While each name is clear, the mixed style is slightly inconsistent, though not confusing.
Three tools are minimal but appropriate for a server focused on email verification and billing queries. The scope is narrow, so the low count is well-suited.
The tools cover the core lifecycle: checking balance, viewing receipts, and verifying emails. Minor gaps exist (e.g., purchasing credits) but these are likely handled externally, so the surface is adequate.