Email Sending MCP

by resend

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.15.0
Disambiguation4/5
Most tools have clearly distinct purposes, with CRUD operations separated cleanly by resource (contacts, segments, domains, etc.). Some overlap exists between send-email, send-batch-emails, and send-broadcast, and between update-email/cancel-email for scheduled sends, but the descriptions are detailed enough to disambiguate these cases.
Naming Consistency4/5
Tool names largely follow a consistent verb_noun pattern using hyphens and lowercase (e.g., create-contact, list-broadcasts, remove-domain). Minor exceptions like manage-events (a multi-action tool), get-tiptap-json-content, and connect/disconnect-from-editor deviate slightly, but the overall style remains predictable and uniform.
Tool Count1/5
With 91 tools, this is far beyond the 50+ threshold for severe over-scoping. While the email platform covers many subdomains, exposing all of them as individual tools creates a massive, overwhelming surface that hinders agent navigation and selection.
Completeness5/5
The toolset is exceptionally comprehensive, providing full CRUD/lifecycle coverage for contacts, segments, domains, templates, broadcasts, automations, suppressions, webhooks, topics, API keys, and more. It also includes received email handling, attachments, logs, and OAuth grant management, leaving very few functional gaps for an email platform.
Average 4.2/5 across 91 of 91 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 10 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 fails to mention idempotency, duplicate handling, side effects (e.g., welcome emails), permission requirements, or what happens if a segment ID or topic subscription is invalid. Only the basic creation action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes the most important optional capabilities. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema) and absence of annotations, the description is too sparse. It omits behavior around duplicates, error handling, response format, and usage context relative to sibling tools, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds a high-level hint about optional segment assignment and topic subscriptions, but does not add detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new contact in Resend' with a specific verb and resource, and mentions optional segment assignment and topic subscriptions. It is clear, but it does not explicitly distinguish from sibling 'create-contact-import', which also creates contacts (albeit in bulk).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'update-contact', 'add-contact-to-segment', or 'update-contact-topics'. The description implies segment assignment and topic subscriptions are possible here, but does not clarify when to use this tool vs. the dedicated segment/topic mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'Update a contact.' It does not reveal whether updates are partial/merge, whether authentication is required, what happens when conflicting identifiers are provided, or the response format. The schema descriptions add some parameter-level behavior (e.g., null to remove), but the overall operational behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded and easy to scan. However, it is extremely brief—almost under-specified—but the conciseness dimension rewards efficiency, and the sentence earns its place by stating the core action and identifier options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, nested objects, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain return values, partial update behavior, how 'properties' interact with existing data, or any side effects. The schema provides field-level detail, but the overall operation remains incomplete for an agent to select and invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, only restating that updates happen by ID or email. Since the schema already documents each parameter's meaning (including null-to-remove semantics), the description does not need to compensate, but it also does not clarify the need for at least one identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a contact'), and specifies identification methods ('by ID or email'). It distinguishes itself from sibling tools like create-contact or update-contact-property by focusing on updating an existing contact's fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., update-contact-property, create-contact). It only states the action but does not mention exclusions, prerequisites, or preferred scenarios. The 'by ID or email' hint is more about identification than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning prerequisites, side effects, duplicate handling, or idempotency. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the purpose. It is concise and easy to parse, though it omits important context. It is not overly verbose, so it earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a very short description, the tool is under-specified. It does not explain return values, error conditions, or whether the contact and segment must already exist. For a simple mutation tool, more context is needed to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds the 'by contact ID or email' hint, which clarifies alternative identifiers but does not explain their relationship to the required-only segmentId, adding only marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a contact to a segment' with a specific verb and resource, and adds 'by contact ID or email' to clarify the two identification methods. It distinguishes from the sibling tool 'remove-contact-from-segment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by indicating the contact can be specified by ID or email, but it does not explicitly compare this tool to alternatives or state when not to use it. Sibling tools are not referenced, so the agent gets only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Create a new contact property' without explaining potential side effects such as duplicate key errors, immutability of the property type after creation, or any permission requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no filler. The first sentence states what the tool does; the second defines the domain concept with examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-documented parameters, but the description lacks important context such as what happens when a property with the same key already exists, whether the type is immutable after creation, or what the successful response contains. The schema covers parameter details, but the absence of annotations and output schema leaves behavioral gaps that the description does not fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minor value by giving examples of property keys and explaining what a contact property is, but it does not provide additional semantics for the 'fallbackValue' parameter beyond what the schema offers. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new contact property in Resend' with a specific verb and resource, and provides illustrative examples (e.g., company_name, plan_tier) that clarify what a contact property is. This distinguishes it from sibling CRUD tools like update-contact-property or list-contact-properties by focusing on the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention that for modifying an existing property one should use update-contact-property, nor does it address scenarios like checking for existing keys before creation. The only implied usage is 'create a new property,' which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for disclosing side effects. It mentions the types of changes allowed (tracking, TLS, capabilities) but does not disclose potential consequences such as delivery impact, DNS requirements for tracking subdomain, or the rule that at least one capability must remain enabled. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 14 words, front-loaded with the verb and resource, and lists key modification areas without wasted words. It earns a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, nested object, enums) and rich schema, the description provides a basic overview but lacks context on side effects, permissions, or return behavior. Since there is no output schema, the description should offer more guidance, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all 6 parameters, including detailed descriptions for tls, capabilities, openTracking, clickTracking, and trackingSubdomain. The description's mention of 'tracking settings, TLS mode, and capabilities' adds no new semantics beyond the schema, so a baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing domain in Resend' with a specific verb ('update') and resource ('domain'), and further specifies the areas it can modify (tracking settings, TLS mode, capabilities), distinguishing it from sibling tools like create-domain or verify-domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use on existing domains but does not provide explicit guidance on when to use this tool versus alternatives such as verify-domain or get-domain. No exclusions or prerequisites (e.g., domain must exist and be verified) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the concept of topics but does not disclose what happens on creation, such as response format, duplicate handling, required permissions, or side effects. The immutability of 'defaultSubscription' is noted in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the action and scope; the second provides useful domain context. There is no wasted information, and the key point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with full schema coverage, the description is largely complete: it states the action, scope, and explains the domain relevance of topics. The main gap is the lack of return value or post-creation behavior, but this is minor for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (name, description, defaultSubscription) with clear explanations. The description adds no additional parameter-level meaning, but the baseline of 3 applies because the schema carries the burden effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create'), names the resource ('topic'), scopes it to 'Resend', and adds value by explaining the purpose of topics (managing subscription preferences). This clearly distinguishes it from sibling tools like 'update-topic' and 'remove-topic'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (create a topic when you need a new subscription preference group) and provides domain context, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when-not-to-use scenarios. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description does not need to restate read-only behavior. However, the description adds no extra behavioral context beyond the basic operation, such as what happens if the ID is invalid, authentication requirements, or response format. It adds no value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one parameter and no output schema. The description adequately conveys the tool's purpose and operation. While it does not mention the return value explicitly, it is obvious for a 'get by ID' tool. The completeness is sufficient for the low complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter 'id' with description 'Topic ID'. The tool description does not add additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a topic by ID from Resend' uses a specific verb ('Get'), names the resource ('topic'), and provides scope ('by ID from Resend'). It clearly distinguishes from sibling tools like list-topics, create-topic, and update-topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single topic by its ID, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. There is no guidance about not using it when list-topics would suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and does not disclose side effects, response content, required permissions, or whether a rename overrides the previous name. The mutation is implied but no further behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant wording or filler. It states the action, target, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter update operation, and the schema already provides full parameter descriptions. The description is complete enough for the agent to decide to call the tool; only output or side-effect details are absent, which is minor for this low-complexity operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both required parameters (id and name) with clear descriptions. Since schema description coverage is 100%, the description does not need to add much; it does not, but that is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Rename') tied to a specific resource ('an existing API key') and narrows it to 'in Resend.' This clearly differentiates it from the sibling tools that create, list, or remove API keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage because it says to rename an existing key, so the context is reasonably clear. However, it does not explicitly state when not to use it or mention alternatives like create-api-key or remove-api-key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 explains what a webhook is but does not disclose the behavior of the create operation itself—such as whether the webhook becomes active immediately, whether a secret or ID is returned, or any side effects or requirements beyond the URL and events. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the direct statement of purpose. The second sentence adds context about webhook behavior without unnecessary fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required parameters and clear schema descriptions. However, there is no output schema and the description does not mention what the response contains (e.g., webhook ID or signing secret) or any prerequisites like authentication or endpoint validation. It is adequately complete for a simple creation tool but has clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds example events (email.sent, email.delivered, email.bounced) that reinforce the enum values, but it does not provide any additional detail beyond what the schema already documents for endpoint and events. The contribution is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new webhook in Resend,' which is a specific verb and resource. It clearly identifies the tool's function and naturally distinguishes it from sibling tools like list-webhooks, get-webhook, update-webhook, and remove-webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case by stating that webhooks receive notifications at a URL when events occur, giving context for when this tool would be used. However, it does not explicitly mention alternatives or exclusions (e.g., using update-webhook for existing webhooks), so it lacks a clear when-not-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose whether the topics array replaces the contact's existing subscriptions or merges, whether id/email must be provided (the schema only requires topics), or what the response contains. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action, resource, and identifier options. It contains no filler and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 parameters and the schema covers all of them, so the description need not re-explain fields. However, for a mutation with no output schema and no annotations, it should ideally clarify whether topics are incrementally updated or fully replaced, and whether id or email is mandatory in practice. These gaps keep it at a middling score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly indicating that id and email are alternative ways to identify the contact, which is not clear from the schema alone (neither is required). It reinforces that topics are the subscription preferences to update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update'), names the precise resource ('topic subscriptions for a contact'), and notes the product context ('in Resend'). It also distinguishes this tool from siblings like list-contact-topics and update-contact by focusing on the topic subscription operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to change a contact's topic subscriptions and mentions that the contact can be identified by ID or email. However, it does not explicitly say when NOT to use it or mention alternatives like list-contact-topics for viewing current subscriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of behavioral disclosure and does so well by warning that the token is only shown once and MUST be displayed to the user. This is a critical, non-obvious behavior that an agent needs to handle correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and immediately follow with the critical security behavior. Every word earns its place, and the must-display note is actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with three optional/required parameters and a detailed schema, the description is largely complete: it says what is created, and the token-display warning addresses the only truly hidden part of the response. It could mention response shape beyond the token, but this is only a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter details live entirely in the schema. The description adds no additional parameter-level meaning, but per the baseline for high schema coverage, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('a new API key in Resend') and immediately distinguishes this from sibling tools like list-api-keys or remove-api-key. The one-time-token warning further clarifies what makes this operation unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives like update-api-key or list-api-keys. While 'Create' strongly implies its own use case, there is no explicit guidance on prerequisites, decisions between full_access and sending_access, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states the action without disclosing operational details like uniqueness, persistence, permissions, or return value. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being simple, the description explains the concept and the action. It lacks return value details, but given the one-parameter scope, it's reasonably complete for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the only parameter fully. Description adds context about what a segment is but doesn't add specific parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new segment in Resend, and defines a segment as a group of contacts for targeting broadcasts, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about segments being used to target broadcasts, implying when to use this tool. It doesn't explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation creates a new draft copy with a new ID, giving some behavioral insight. However, it does not mention permissions, side effects on the original template, or reversibility, which would be expected for a mutation tool without annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, and every sentence provides essential information. The description is concise with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema or annotations, the description adequately explains the action and accepted input. It lacks some detail like the resulting template content, but the phrase 'new draft copy' gives sufficient context for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter description fully explaining 'ID, alias, or Resend dashboard URL.' The tool description repeats this same information without adding meaningful new semantics, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states 'Duplicate an existing email template in Resend' with a clear verb and resource, and adds the outcome 'Creates a new draft copy of the template with a new ID.' This distinguishes it from sibling tools like update-template, publish-template, or create-template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for duplicating an existing template, but it does not explicitly mention when to use it instead of alternatives or any exclusions. It lacks direct comparison like 'use search_calls_extensive instead' which would justify a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Get' is consistent. No additional behavioral traits (e.g., error handling, pagination, response shape) are disclosed, so the description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the core action. Every word earns its place, with no redundancy (aside from the minor 'from Resend' modifier).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and clear annotations, the description is sufficient. It does not explain return values, but the nature of 'get' implies returning the property, and no output schema is expected for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter contactPropertyId is already described. The description only says 'by ID,' which adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a contact property by ID'), distinguishing it from list/create/update/remove contact property tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need a single contact property by its ID. It does not explicitly mention alternatives or exclusions, though the purpose is fairly obvious given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes the read-only nature. The description adds no further behavioral context such as response format, error behavior, or authentication requirements, but it does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, front-loading the verb and resource. It is appropriately concise for a simple retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a one-parameter read-only getter, but it does not describe the return value or behavior when the webhook is not found. Since no output schema exists, a brief mention of the expected response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter webhookId as 'Webhook ID' with a minLength constraint, achieving 100% coverage. The description's 'by ID' adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'webhook' and a scope 'by ID', making it distinct from sibling tools like list-webhooks, create-webhook, update-webhook, and remove-webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided for when to use this tool versus alternatives, though the 'by ID' scope implies retrieval of a single webhook when the ID is known. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds return value details and an instruction about handling IDs. However, the claim to 'List all' may be misleading given pagination parameters (limit, after, before) are present, implying single-page retrieval. It doesn't disclose pagination behavior or rate limits, so additional transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no fluff. It immediately states the action and resource, then adds useful return field info and a practical tip. Every word earns its place, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema and no required params. The description covers the main purpose and return fields, which is helpful given no output schema. However, it doesn't mention pagination behavior or that 'all' might require multiple calls, relying on the schema's pagination parameters. This is a minor gap for a list tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (after, limit, before) with clear descriptions, achieving 100% coverage. The tool description adds no extra parameter details beyond what the schema provides, so it doesn't compensate or enhance the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists email templates from Resend, specifying a specific verb and resource. It distinguishes itself from sibling tools like get-template (single) and create/update/remove by focusing on listing all templates. The mention of return fields (names, statuses, aliases) further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of enumerating all templates but provides no explicit guidance on when to choose this over alternatives like get-template. It doesn't mention exclusions or alternative tools. The phrase 'List all' gives context, but there's no direct 'use this when' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It adds a key constraint (key/type immutable) beyond schema, but lacks information on error behavior, authorization requirements, or effects of nonexistent IDs. Some transparency, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence clearly states the action and resource; the second adds a critical limitation. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter update tool with no output schema or nested objects, the description covers the essential purpose and the most important behavioral constraint. Missing details like return format or error cases are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with meaningful descriptions for both parameters. The tool description reinforces that only fallbackValue is mutable, but adds no new parameter-level insight beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action (update) on a specific resource (contact property in Resend) and explicitly clarifies the scope (only fallback value can be changed). This clearly distinguishes it from sibling tools like create-contact-property or update-contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when updating a contact property's fallback value) and what cannot be done (key/type change), but does not explicitly name alternatives like create-contact-property for new properties or remove-contact-property for deletion. Context is clear but no direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states that removing an event requires user confirmation and clarifies that update only changes the schema. However, it omits side effects (e.g., impact on existing automations), error conditions, or response format, which are important for a mutation-capable tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Purpose, Actions, Workflow, Schema types) and uses concise bullets. It is slightly longer than strictly necessary but every section contributes useful context. It is front-loaded with the core purpose, making scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with 7 parameters and no output schema or annotations, the description delivers a solid understanding: what events are, what each action does, when to use the tool, and possible schema types. It lacks some details like error handling or return values, but overall it is sufficiently complete for an agent to select and use the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minor value by mapping actions to the parameters they use (e.g., create uses name and schema; list uses after, before, limit), but it does not provide new semantic details beyond the schema. Thus the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create, list, get, update, or remove event definitions in Resend,' which uses specific verbs and clearly identifies the resource. It further distinguishes the tool by explaining events are named triggers that start automations, setting it apart from sibling tools like create-automation or send-event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow ('manage-events (create) → create-automation → send-event') that indicates when this tool is used relative to other tools. It also explains each action's purpose. However, it does not explicitly state exclusions or alternative tools to use instead, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the readOnlyHint annotation, noting that either an ID or email can be used. It does not disclose details like what happens if both are provided, error behavior, or return format, but with annotations already signaling a safe read operation, this is acceptable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no extraneous words. It is concise and appropriately structured for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the essential purpose and context (from Resend). However, it does not specify that at least one of id or email is required, nor the precedence if both are supplied, which is a minor gap given the optional parameters in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (ID and email), and the description merely restates 'by ID or email' without adding new semantic detail. With 100% schema coverage, the baseline is 3, and no additional meaning is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a contact', specifying that lookup is by ID or email. This distinguishes it from sibling tools like list-contacts, create-contact, and update-contact, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: retrieving a single contact when you have an ID or email. It does not explicitly mention alternatives or exclusions, but the scope is clear enough that an agent can infer when to use this tool over list-contacts or other contact operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a read-only operation. The description adds minimal context beyond the annotation: it specifies the source ('from Resend') and the lookup constraint ('by ID'), both of which are also reflected in the schema. No additional behavioral details such as return format or error scenarios are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without unnecessary words. Every word earns its place, making it highly concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only, no output schema), the description is sufficient to understand its purpose and usage. It could optionally mention what the response contains, but this is largely implied for a get-by-ID operation, so only minor completeness gap exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'id' parameter is described as 'Segment ID'. The description does not add any further semantics beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a segment by ID from Resend' uses a specific verb ('get') and resource ('segment') and explicitly identifies the lookup key (ID). It clearly distinguishes from sibling tools like list-segments, which retrieves multiple segments, and create-segment, which creates a new one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single segment when its ID is known, which is clear context for use. However, it does not explicitly state when to prefer this over alternatives like list-segments, nor does it mention any preconditions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include readOnlyHint=true, which already communicates the read-only safety. The description adds a note about optional status filtering and the purpose of discovering IDs, but it does not describe pagination behavior or return format. Given the annotation coverage, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The primary action is front-loaded ('List contact imports from Resend'), and the optional filter and use cases are succinctly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, the description conveys purpose, filtering, and use cases. The mention of 'discover import IDs' hints at the return contents. Pagination details are covered in the schema, making the description adequately complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including detailed explanations for pagination and status filtering. The description only repeats 'Optionally filter by status' and adds no new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List contact imports from Resend' with a specific verb and resource. It distinguishes the tool from siblings like list-contacts or get-contact-import by explicitly referring to 'contact imports' and the use case of discovering import IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use to discover import IDs or review past imports.' This tells when to use the tool, though it does not explicitly mention alternatives (e.g., get-contact-import) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds value by disclosing the return contents (domain names, statuses, regions, capabilities) and a user-interface guideline ('Don't bother telling the user the IDs unless they ask'), which are not present in the annotations. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds information. The informal instruction about IDs is concise and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description covers what the tool does and what it returns, which is adequate given there is no output schema. It does not explain pagination behavior beyond the schema descriptions, but that is already documented. The extra user-facing guidance adds completeness without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for each parameter (after, limit, before). The description does not add extra parameter semantics, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('domains from Resend'), clearly distinguishing it from sibling tools like get-domain or create-domain. It also specifies the returned fields (names, statuses, regions, capabilities), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for listing all domains) but does not explicitly state when to use this over get-domain or when not to use it. There is no mention of alternatives or exclusions, leaving usage guidance to be inferred from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the key precondition (only for unsent scheduled emails) but does not mention permissions, reversibility, or the error behavior if the email has already been sent. This is adequate but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose and a usage constraint. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, a simple purpose, and no output schema. The description covers the essential purpose and the key limitation. It does not explain return values, but for a low-complexity mutation tool, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'scheduledAt' already described in the schema. The description adds no additional meaning beyond reinforcing that the update involves the scheduled send time, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Reschedule a scheduled email by updating its scheduled send time." This specifies a concrete verb ('reschedule') and resource ('scheduled email'), distinguishing it from siblings like cancel-email or send-email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage constraint: "Only works for emails that were scheduled and have not yet been sent." This tells the agent when the tool is applicable, though it does not explicitly name alternatives or exclusion scenarios beyond the unsent/scheduled condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what can be changed but does not disclose details such as validation of webhook ID, whether changes take effect immediately, or any permissions required. The description is truthful but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and key modifiable aspects without any filler. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 4 parameters and no annotations or output schema. The description covers the core functionality and parameter roles adequately, though it could mention edge cases like whether events replaces the full list or how status interacts. Overall, it is sufficiently complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The tool description adds a summary of which parameters map to the listed use cases (endpoint, events, status) but does not provide additional semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing webhook in Resend and lists the specific aspects that can be changed (endpoint URL, subscribed events, enable/disable). This directly distinguishes it from sibling tools like create-webhook, get-webhook, and remove-webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing webhooks and mentions the specific modifiable attributes. It does not explicitly exclude create/remove or name alternatives, but the context is clear enough for an agent to infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that removal is irreversible and mandates user confirmation, which is critical behavioral context. It doesn't cover post-removal effects, but the core safety traits are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each contributing: the action, the mandatory double-check, and the irreversibility warning. Slightly verbose but justified by the destructive nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a one-parameter destructive tool with no output schema and no annotations, the description covers identification, irreversibility, and confirmation requirement. It doesn't describe success/error responses, but the essential context for safe invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully documented in the schema, including the example URL format. The description reiterates the identification methods but adds no additional semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove an email template by ID, alias, or Resend dashboard URL'. It names the specific resource (email template) and distinguishes it from sibling remove tools like remove-automation or remove-broadcast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit safety protocol: must double-check with the user, reference the template name, warn that removal is irreversible, and only proceed after explicit confirmation. This is strong when-to-use guidance for a destructive operation, though it doesn't compare against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It conveys the key effect (suppressed addresses never receive emails) and the automatic nature of hard bounces/spam complaints. However, it does not mention eventual consistency, idempotency, partial failures, or permissions required, leaving some transparency gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each subsequent sentence adds meaningful context about behavior, usage, and an alternative. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, when to use it, and how it relates to alternatives. It lacks explicit information about return values or error behavior, but these are less critical for a straightforward batch add operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage: the only parameter 'emails' is described as 'Email addresses to suppress' with format/pattern. The description adds minimal extra semantic value beyond restating 'multiple email addresses,' so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add multiple email addresses to the suppression list in Resend in a single call,' clearly specifying the verb, resource, and scope. It distinguishes itself from the sibling 'add-suppression' by explicitly noting the single-address alternative and from batch-remove operations by focusing on adding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool: to manually suppress addresses when needed (e.g., do-not-contact requests), and contrasts this with automatic suppression from hard bounces and spam complaints. It also explicitly directs users to 'add-suppression' for a single address, providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 reveals a key limitation (only works for scheduledAt emails) but does not mention what happens if the email has already been sent, whether cancellation is reversible, or error handling. This is a moderate gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core action and immediately followed by a critical condition. Every word is essential, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and no output schema, the description covers the purpose, the main precondition, and the parameter's role. It does not specify failure behavior (e.g., already-sent emails), but this is a minor omission given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes 'id' as 'The ID of the scheduled email to cancel', and the description adds a meaningful semantic constraint: the email must have been scheduled using scheduledAt. This helps the agent understand which IDs are valid, going slightly beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Cancel a scheduled email' and the resource (scheduled email) with a scope condition ('that has not yet been sent'). This distinguishes it from sibling tools like update-email or send-email, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (for canceling scheduled emails) and provides an explicit exclusion: 'Only works for emails that were scheduled using the scheduledAt parameter.' It does not name alternative tools like update-email, but the condition clearly implies when this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral context. It discloses that users see an avatar while connected, that compose tools disconnect when done, and that returns a token and room ID. However, it does not state whether the connection persists until disconnect-from-editor is called, any limits on concurrent connections, or what happens if the agent connects while another is already connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with bold section labels (Purpose, When to use, Returns). Every sentence adds value, and the key information is front-loaded in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage, exclusions, and return values. Minor gap: it does not explicitly mention the need to call disconnect-from-editor when the agent is done outside compose workflows, but the sibling tool name implies this. Overall complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 3 parameters, so the schema already provides full parameter documentation. The description does not add meaningful semantics beyond returning a token/room ID, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose ('Show agent presence in the Resend dashboard editor') with a clear verb-resource pairing. It distinguishes this tool from siblings by explaining when it is not needed (before compose-broadcast/compose-template) and that get-tiptap-json-content connects automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: signal agent presence outside compose workflows. Also explicitly lists exclusions ('Not needed before compose-broadcast or compose-template') and names an alternative (get-tiptap-json-content), which is exactly the kind of guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It goes beyond a simple 'creates' statement by disclosing the critical behavioral requirement: 'You MUST display the DNS records to the user so they can set them up.' This is a concrete, actionable side effect that the agent must handle. However, it does not disclose other potential behaviors (e.g., rate limits, irreversibility), so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word earns its place. It efficiently communicates purpose, output, and a critical mandatory action without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (one required, nested objects) and no output schema, the description provides a complete enough picture: it explains what the tool does, what it returns (DNS records), and what the agent must do with them. It does not explain the exact structure of the DNS records, but that is beyond the necessary remit and the key usage context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including details about defaults and meanings (e.g., TLS modes, region enums). The description adds no parameter-specific information beyond what the schema already provides. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Create a new domain in Resend.' It also mentions the unique output (DNS records for verification), which distinguishes it from sibling tools like get-domain, update-domain, or verify-domain. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when creating a new domain and needing DNS records for verification. It implies a workflow (create domain → configure DNS → verify), but does not explicitly name alternatives or state when not to use it. The mandatory instruction to display DNS records gives practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key side effects: domain is recreated, brand-new DKIM keys are generated, previous DNS records become invalid, and a TXT record is returned that must be displayed and added to DNS. It also details the follow-up workflow. It doesn't cover failure modes or auth requirements, but the core behavioral impact is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, side effects, required action, and workflow. It is front-loaded with the core purpose and uses concise, imperative language. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that initiates a multi-step workflow, the description gives a complete flow: returns a TXT record, user must add it, then verify-domain-claim, then poll get-domain-claim until status is 'completed'. It also explains the DKIM key reset, which is crucial context. It doesn't elaborate on failure cases or output structure, but the essential workflow is well covered given the schema handles parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all six parameters having meaningful descriptions. The tool description adds no extra parameter-level detail beyond the schema, so the baseline of 3 is appropriate. It doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific purpose: 'Start a claim for a domain another Resend account has already verified.' This distinguishes it from create-domain (for new domains) and aligns with the claim workflow. The verb 'start' plus the resource 'domain claim' is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use when a domain is already verified by another Resend account. It also gives explicit next steps: 'use verify-domain-claim, then poll get-domain-claim'. It doesn't explicitly say 'use instead of create-domain', but the scenario is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already annotation, the description adds valuable context by explaining the two modes and the detail level: step-by-step execution status, outputs, and errors. It also lists run and step statuses, which goes beyond the schema and annotations. However, it does not address rate limits or pagination defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers, bullet points, and distinct sections for purpose, modes, when to use, and statuses. It is efficient, front-loaded with purpose, and every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two modes and no output schema, the description explains both modes and what is returned (run info, step-by-step status, outputs, errors), and lists statuses. It lacks explicit mention of default pagination behavior, but the schema covers cursor parameters, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-described (e.g., status is 'for list mode only', runId says 'If omitted, lists all runs'). The description reinforces these mode distinctions but does not add substantive meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List runs for an automation, or get details of a specific run.' It uses specific verbs and a distinct resource, and explicitly differentiates the two modes, making it easy to distinguish from sibling tools like get-automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section provides concrete scenarios such as checking if an automation is working or debugging a failed run, and explicitly answers common user questions like 'why did this automation fail?'. However, it does not mention when not to use the tool or name alternative tools, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a read operation; the description adds value by specifying that the response includes DNS records needed for verification. It does not cover error behavior or authentication, but the annotation lightens the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and return content without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description adequately covers what it returns (full domain details plus DNS records). Without an output schema, it still gives sufficient guidance, though it could mention possible response fields or not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with a description. The tool description adds no further semantics beyond what the schema provides, aligning with the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a domain by ID from Resend, with a specific verb ('Get') and resource. The mention of DNS records helps differentiate from domain-related siblings like list-domains or get-domain-claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single domain's details are needed, as opposed to listing all domains. However, it does not explicitly name alternative tools or exclusion conditions, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Retrieve' aligns without contradiction. The description adds value by specifying the included fields (message_id, HTML, plain text) beyond the annotation, which is useful for setting agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then lists the return contents. Every word contributes value; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with annotations, the description covers the core behavior and return contents. It does not detail error handling or authentication, but that is not critical given the annotations and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the 'id' parameter is described in the schema as 'The email ID to retrieve.' The description adds the context that the ID refers to a sent transactional email, but this is marginal given the schema already covers the parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and clearly identifies the resource as a specific sent transactional email by ID. It enumerates the returned content (message_id, HTML, plain text), which distinguishes it from siblings like get-received-email or list-emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this when you need full details of a specific sent transactional email by ID. It does not explicitly mention alternatives or exclusions, but the specificity is clear enough for an agent to select it over list-emails or get-received-email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds the behavioral detail that the download URL is time-limited, which is valuable context for agents. This goes beyond the basic safe-read indication and informs expectations about URL expiry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and includes a key detail about the output. Every word adds value, with no redundancy or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter retrieval operation with readOnlyHint and no output schema, the description sufficiently covers what it does and the nature of the response (details + time-limited URL). It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, and they are clearly named. The description adds minimal parameter-specific meaning beyond mapping emailId to 'received email' and id to 'attachment', so it does not significantly elevate the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve details') and clearly identifies the resource ('a specific attachment from a received email'), including a notable output trait ('time-limited download URL'). This distinguishes it from siblings like get-sent-email-attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from a received email' provides clear context for when to use this tool, implicitly differentiating it from sent-email attachment tools. No explicit exclusions or alternatives are named, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds the time-limited download URL behavior, which is a meaningful behavioral trait not covered by annotations. This goes beyond the minimal bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool with full schema coverage and a readOnly annotation, the description covers the essential aspects: what it does, the scope (sent email), and the notable behavior (time-limited URL). It lacks explicit references to alternatives, but the tool is simple enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides; it merely ties 'specific attachment' and 'sent email' to the id and emailId parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('attachment from a sent email'), clearly distinguishing it from sibling tools like list-sent-email-attachments (list vs. get specific) and get-received-email-attachment (sent vs. received).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets clear context: this tool is for retrieving a specific attachment from a sent email, implying you already have an attachment ID and email ID. It doesn't explicitly name alternatives or exclusions, but the sent-email scope is clear from both name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful context by specifying the returned fields (names, IDs, creation dates) and advising on user communication. It does not disclose pagination behavior or rate limits, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, then adds a concise, actionable instruction about presenting results. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description is largely sufficient. It covers the return fields and usage context. However, it does not mention pagination behavior, which is relevant since the schema includes pagination parameters; this would have made it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no additional parameter-level context, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('API keys from Resend'), clearly distinguishing it from sibling tools like create-api-key and remove-api-key. It also previews the returned fields, which removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving API keys, which differentiates it from create/remove operations. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as a read operation, and the description reinforces that by saying 'List all topic subscriptions.' It adds extra behavioral context by instructing the agent to avoid surfacing IDs unless the user requests them, which isn't captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. The second sentence is a useful, non-redundant behavioral tip. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the core purpose and scope. It doesn't explain pagination beyond what the schema already documents, and doesn't detail ambiguous parameter interactions (e.g., using both id and email), but it provides enough context for typical use. Given the rich schema and annotation, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, so baseline is 3. The description adds meaning by stating the tool operates 'by contact ID or email,' clarifying that one of these identifiers is needed even though the schema marks them optional. This helps the agent decide which parameters to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List all topic subscriptions') on a specific resource ('for a contact in Resend'), and distinguishes itself from sibling tools like list-topics by specifying the contact scope. It also mentions the alternate lookup methods (ID or email), making the purpose unequivocal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (for a contact's topics) but does not explicitly compare with alternatives or state when not to use it. The only additional usage hint is about not telling IDs unless asked, which is a response-formatting guideline rather than a tool-selection guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral context: it returns metadata (filename, size, content type) and a time-limited download URL, which is significant because the URL expires and requires handling. This goes beyond the annotation and is helpful for the agent to anticipate the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every element is useful: what it lists, how to identify the email, and what the output contains. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 params and no output schema, the description covers the main purpose and return shape, including the time-limited URL. The schema covers parameter details, and the read-only annotation covers safety. It lacks explicit mention of pagination behavior, but the schema provides that. Overall, it's complete for typical use, with a minor gap in not indicating that attachments might be paginated or how to consume the URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (emailId, after, before, limit), so the baseline is 3. The description adds marginal value by noting that the emailId comes from send-email or list-emails, clarifying the expected source. However, it doesn't add meaning to pagination params or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all attachments from a specific sent email' – a specific verb and resource. It also differentiates from siblings by specifying sent emails (not received) and listing all attachments, distinguishing it from get-sent-email-attachment (singular). The mention of source tools (send-email or list-emails) provides useful context for where the emailId comes from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use it: for attachments from sent emails, specifically those created via send-email or list-emails. It doesn't explicitly mention when not to use it or alternatives, but the clear reference to sent emails versus the sibling list-received-email-attachments implies the appropriate usage. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'List all topics' is consistent. It adds context about returning topic IDs for downstream use but does not disclose behavior like pagination or response format. With annotations covering the safety profile, the additional context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. It front-loads the action and resource, then adds a brief use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description covers what it does and why it's useful. It doesn't describe the output shape, but no output schema exists and the 'topic IDs' hint provides some guidance. Given the low complexity, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to detail parameter semantics. It mentions 'all topics' implying no filtering, which adds slight value over the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with the specific resource 'topics from Resend', clearly distinguishing this tool from list-contact-topics in the siblings. It also states the purpose of retrieving topic IDs for use by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'useful for getting topic IDs to use with other tools like send-email.' This provides clear context for when to use it, though it doesn't mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It discloses a key behavioral trait: re-publishing a previously published template makes the latest changes live, indicating the action updates the live version. It also implies idempotency (re-publishing is possible) and the prerequisite for sending. Still, it could have mentioned permissions or what happens to unpublished changes, but overall it communicates the essential state change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences, each serving a purpose: first states the action, second explains the prerequisite, third describes re-publishing behavior and accepted input forms. There is no wasted content, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema or annotations, the description covers the core purpose, usage context, and behavioral effects. It does not mention error conditions or return values, but given the low complexity and clear sibling differentiation, it is sufficiently complete. A more exhaustive description might include idempotency or error scenarios, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter comprehensively, including the ability to use a template ID, alias, or Resend dashboard URL. The description repeats this same information without adding new details or examples. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Publish an email template in Resend.' The verb-resource combination is specific and distinct from sibling tools like create-template or update-template, which do not cover publishing. The additional context about templates needing to be published before sending further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool, stating that templates must be published before they can be used for sending emails, and that re-publishing makes latest changes live. However, it does not explicitly mention alternatives or when not to use it, though this is implied by the workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does add one important behavioral note: the need for explicit user confirmation before acting, implying destructive potential. However, it does not describe other behavioral aspects such as idempotency (what happens if the contact is not in the segment) or effects on segment membership statistics. Some context is provided, but it's not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first stating the core action and the second giving a critical safety instruction. There is no redundancy or filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with a well-defined schema and no output schema, the description is nearly complete: it states the action, identifies the identification method, and includes an important safety confirmation. The only minor gap is lack of explicit guidance on the consequences (e.g., whether removal is permanent or what happens if the contact doesn't exist in the segment), but this is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that removal can be done 'by contact ID or email', explicitly indicating an either/or relationship between the 'contactId' and 'email' parameters. This is not fully spelled out in the schema, which only lists them as separate optional properties. That semantic connection earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove a contact from a segment in Resend (by contact ID or email).' It uses a specific verb ('remove') and identifies the resource ('contact from a segment'), which distinguishes it from sibling tools like 'remove-contact' (removes entire contact) and 'add-contact-to-segment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it removes a contact from a segment, not a full contact removal. It also gives an explicit conditional guideline: 'Before using this tool, you MUST double-check with the user that they want to remove the contact from the segment.' However, it does not explicitly mention alternative tools for related operations, though the scope is clear from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 critical behavioral traits: the action is irreversible and removes the property from all contacts. It also emphasizes the need for user confirmation. However, it doesn't describe return values, error conditions, or potential restrictions beyond irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with the purpose stated first, followed by focused safety instructions. Every sentence earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no annotations or output schema, the description covers key context: irreversible impact, all-contacts scope, and confirmation workflow. It could mention error cases (e.g., property not found) or whether some properties are protected, but overall it is quite complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter contactPropertyId, so the baseline is 3. The description adds a useful nuance by instructing to reference the property KEY during double-checking, implying a distinction between ID and key, but it doesn't elaborate on parameter format or validation beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('contact property'), and the method ('by ID'). It distinguishes from sibling tools like update-contact-property, get-contact-property, and create-contact-property by specifying removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites: double-check with the user, reference the property KEY, warn about irreversibility and impact, and only proceed with explicit confirmation. This defines when not to use the tool, but it doesn't name alternatives or contrast with update/delete operations, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool sends up to 100 transactional emails and implies batch behavior, but does not disclose potential side effects, partial failure handling, idempotency details, or rate limits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized into three labeled sections (Purpose, NOT for, When to use) with no redundant words. Every sentence contributes to understanding the tool's purpose and usage boundaries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's rich parameter descriptions and lack of output schema, the description adequately covers purpose, usage, and exclusions. It could be improved by mentioning idempotency or error behavior, but it is largely complete for a batch-email tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a useful pointer that each item has the same fields as send-email, but it does not provide additional semantic detail beyond the schema for the idempotencyKey or email object fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send up to 100 transactional emails in one API call,' with a specific verb, resource, and scope. It also distinguishes itself from siblings by noting that individual emails should use send-email and broadcasts should use create-broadcast + send-broadcast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'NOT for' and 'When to use' sections, providing clear guidance on when to use this tool versus send-email or create-broadcast + send-broadcast. Examples (50 password resets, 100 receipts) further clarify appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral constraint (defaultSubscription cannot be modified) but omits other behavioral details such as error handling, permissions, idempotency, or response format. The provided note adds value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action in the first sentence and a concise note in the second. No redundant information or filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three parameters and no output schema, the description covers the essential purpose and a critical constraint. It does not mention return values or error behavior, but given the simplicity and schema availability, it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters, covering 100% of them. The description adds meaningful constraint information about a field not present in the schema (defaultSubscription), clarifying that this field is not updatable. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('existing topic'), making it immediately identifiable among sibling update tools. The specific mention of 'in Resend' adds context, and the note about defaultSubscription further defines the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It is clear this tool is for updating an existing topic, not creating one. The note about defaultSubscription provides a meaningful 'when not to' guideline for a specific field, though it does not explicitly name alternatives or broader usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals that the process is asynchronous and that the domain status temporarily becomes 'pending', which is useful behavioral context. However, it does not mention failure outcomes, permissions, or how to check the final status, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with the primary action front-loaded ('Trigger domain verification in Resend'), and it includes only relevant details about the asynchronous process and pending status. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter signature, lack of output schema, and absence of annotations, the description sufficiently covers what the tool does and its immediate effect. It could be enhanced by mentioning how to verify the final result or differentiating from verify-domain-claim, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'id' as 'Domain ID' (100% coverage). The description adds no additional parameter-specific meaning, so it provides no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Trigger domain verification in Resend' and explains the verification process, checking DNS records. This distinguishes it from sibling tools like create-domain or verify-domain-claim by focusing on the specific action of triggering verification and its effect on domain status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it starts an asynchronous verification process to check DNS configuration, implying it should be used when the user wants to initiate verification. However, it does not explicitly mention when not to use it or name alternatives like verify-domain-claim, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the effect ('addresses will start receiving emails again'), warns about deliverability risks, and mandates user confirmation. It does not cover all aspects like permissions or error handling, but it provides substantial context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with three sentences covering purpose, effect, and safety. The final sentence is somewhat long but contains essential warnings. It is organized and each sentence contributes, though it could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema or annotations, the description is fairly complete. It covers the key behavioral and safety aspects, parameter constraints, and the user-confirmation requirement. Missing details like return format or partial failure behavior are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds crucial meaning by stating 'provide exactly one of the two' and clarifying the purpose of each parameter (emails vs IDs), which goes beyond the schema's 'Cannot be used with' notes by emphasizing the exclusivity and necessity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove multiple entries from the suppression list in Resend in a single call' and specifies the two modes (by email or by ID). This distinguishes it from siblings like remove-suppression (single removal) and batch-add-suppressions (adding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including the requirement to double-check with the user and obtain explicit confirmation before using. However, it does not explicitly name alternative tools for single removals, so it stops short of fully clarifying when-not-to-use compared to specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the state change (removing presence) but does not disclose potential side effects like whether unsaved edits are preserved or if the session is fully terminated. For a simple tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, followed by a clear call-to-action. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description fully covers purpose and usage. It tells the agent exactly when to invoke it and what it does, making it complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter info because none are needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Remove agent presence from the Resend dashboard editor.' It clearly distinguishes from siblings like 'connect-to-editor' and 'update-email' by naming the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage timing ('Call this when done editing'), giving clear context. It doesn't name alternatives or exclusions, but the instruction is unambiguous and sufficient for a simple disconnect operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context: it can accept either a bare ID or a Resend dashboard URL, and it returns both HTML and plain text content. This exceeds the schema and annotations, providing meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and resource, followed by the input format and output content. Every clause earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, a read-only annotation, and no output schema, the description adequately covers what the tool does, how to specify the target, and what is returned (HTML and plain text). This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter broadcastId, which already explains it accepts an ID or Resend dashboard URL. The description repeats this, adding no new meaning beyond the schema. Baseline 3 is appropriate when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' and resource 'broadcast', and clarifies it's for a specific broadcast by ID or dashboard URL, including content types. This clearly distinguishes it from siblings like list-broadcasts (which lists) and create/update/remove-broadcast (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when needing full details of one specific broadcast, but does not explicitly name alternatives or state when not to use. This is clear context without exclusions, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint: true, so the description adds value by revealing that contact imports are asynchronous and can be in queued, in_progress, completed, or failed states. This is useful behavioral context beyond the read-only safety hint, though it doesn't describe return format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose and immediately providing workflow context. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, a read-only annotation, and no output schema, the description covers the purpose, usage context, and expected statuses sufficiently. It provides complete guidance for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'id' parameter with the description 'Contact import ID' (100% coverage). The description does not add any further parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the status and counts of a contact import by ID, using a specific verb and resource. It distinguishes itself from siblings like create-contact-import and list-contact-imports by focusing on a single import's status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to use this tool after create-contact-import to track progress, naming the allowed statuses. It provides clear context but does not mention when not to use it or suggest alternatives like list-contact-imports for viewing all imports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, and the description adds valuable behavioral context by enumerating exactly what the log details include (id, created_at, endpoint, method, etc.). It does not over-explain, and the return fields provide transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Purpose, Returns, and When to use. It is compact, front-loads the essential purpose, and every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get tool, the description is complete: it states the purpose, lists the return fields, and gives usage scenarios. Despite no output schema, the return field list compensates, making the tool's behavior fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter logId as 'The Log ID to retrieve' with 100% coverage. The description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a specific API request log, including full request and response bodies. It uses a specific verb ('get'), identifies the resource ('API request log'), and distinguishes itself from list-logs by focusing on a single log's detailed contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear 'When to use' section with concrete user intents and phrasings, such as debugging a specific API call or inspecting a request. However, it does not explicitly name alternatives or state when not to use it, such as mentioning list-logs for listing logs, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by specifying exactly what content is returned (HTML, plain text, headers, raw email download URL). This goes beyond the annotation but does not cover potential side effects or rate limits, which are less relevant for a read-only retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded, naming the action, resource, and key return components without any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description sufficiently explains the return value (full details including content and headers). It is complete for the tool's complexity and works well with the readOnlyHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the 'id' parameter is described as 'The received email ID to retrieve'. The description adds minimal extra meaning beyond restating that it retrieves by ID, so it stays at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' with the resource 'a specific received email by ID', clearly stating what is included (HTML, plain text, headers, raw email download URL). It distinguishes itself from sibling tools like list-received-emails, which lists emails, and get-received-email-attachment, which gets attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving full details of a single received email when you have its ID. It provides clear context but does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds value by disclosing that the result includes the suppression origin (bounce, complaint, or manual), giving the agent expectations about the response content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the primary action and then adds the usage rationale, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one documented parameter and a read-only annotation, the description fully covers purpose, usage, and expected return context (suppression status and origin). No output schema is present, but the description gives enough detail for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is described as 'Suppression ID or email address.' The description reinforces the same semantics ('by ID or email address') but does not add additional formatting or constraint details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a suppression list entry'), the resource ('suppression list entry'), and the identifier types ('ID or email address'). It also explains the purpose ('check whether a specific address is suppressed and why'), which distinguishes it from list-suppressions or mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check whether a specific address is suppressed and why,' providing a clear when-to-use scenario. It does not name alternative tools explicitly, but the sibling context (list-suppressions, remove-suppression) makes the differentiation clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context beyond that by specifying what the response includes ('HTML content, variables, and publish status'). This discloses the output shape even without an output schema, but it stops short of discussing error handling or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and wastes no words. The example URL is redundant with the schema but harmless. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and read-only annotation, the description is complete. It explains the input format and explicitly names the return contents, compensating for the lack of an output schema. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single 'id' parameter already covers the allowed formats (ID, alias, or dashboard URL) and even the same example. The tool description essentially restates this, adding no extra semantic meaning beyond what the schema provides. With 100% schema coverage, this is baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('email template'), and clearly states the input can be an ID, alias, or dashboard URL. This distinguishes it from list/update/delete operations among the sibling tools, making the tool's function immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve a single template's full details by ID/alias/URL. However, it does not explicitly mention when not to use it or point to alternatives like list-templates, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing that removal is irreversible and stops all future runs. It also outlines necessary pre-checks. It could further specify any side effects (e.g., impact on logs or active runs), but the critical behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action. The safety instructions are necessary and each sentence adds value, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is remarkably complete. It covers what the tool does, the input format, and the critical safety protocol, leaving no major gaps for an agent to misuse it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter with 100% coverage, including the format and example URL. The description adds no new parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove an automation') and specifies the resource and input format ('by ID or Resend dashboard URL'). It unambiguously distinguishes this from sibling tools like create-automation or get-automation by focusing on deletion, and it emphasizes irreversibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use the tool by mandating user confirmation, referencing the automation name, and warning about irreversibility. It could be improved by explicitly naming alternatives (e.g., update-automation for modifications), but the prerequisites are very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses async processing, immediate ID return, polling via a sibling tool, a 100MB size limit, and mutual exclusivity of CSV sources. This meaningfully informs the agent beyond what the schema provides, though it omits error/rate-limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then key constraints and async behavior. Every sentence contributes actionable information with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the import lifecycle by naming the polling tool and explaining the immediate return value. The complex nested columnMap schema is fully documented in the input schema, so the description doesn't need to repeat it. Lacking error handling details, but for an initiation tool with no output schema, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly stating 'exactly one of filePath, content, or url' and the max file size – constraints not obvious from individual property descriptions. It also references the polling parameter implicitly (the returned import ID), reinforcing the schema's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Bulk-import contacts from a CSV file into Resend' – a specific verb, resource, and method. It clearly distinguishes from single-contact creation (create-contact) and positions itself as the bulk import initiation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: the async workflow ('returns an import ID... then use get-contact-import to poll') and a hard constraint on CSV source ('exactly one of filePath, content, or url'). It stops short of explicitly saying when not to use it relative to single-contact tools, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses draft status, the recommended workflow, and the lossy nature of switching between compose and html/text modes. This goes beyond typical create-tool descriptions, though it does not mention return values or potential validation failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear title, bold headers, and bullet points. Every sentence provides useful information: purpose, draft status, workflow, and content options. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full lifecycle, including next steps and caveats. It does not describe the response shape, but no output schema is provided. For a create tool with a complex domain, this is reasonably complete given the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The tool description adds the triple-brace variable convention (already present in the schema) and workflow context, but does not explain individual parameters beyond what the schema provides. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new email template in Resend,' a specific verb+resource statement. It immediately adds that templates are created in draft status, distinguishing this from publish-template. This clearly scopes the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit workflow (create-template → get-tiptap-json-content → compose-template → publish-template) and contrasts compose-template (recommended) vs update-template with html/text, including when each is appropriate. It also tells the user to ask before switching modes, giving clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the core behavior: creates a copy with its own ID and preserves steps/connections. It doesn't explicitly state side effects like whether the original remains untouched, but that is strongly implied by 'creating a copy' and there is no destructive behavior implied. It could add more detail about response or failures, but for this simple operation it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences without unnecessary detail. It front-loads the action, then explains the result and the appropriate usage context, followed by the follow-up action on the new ID. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description covers the main usage, creation behavior, and next-step with update-automation. A minor gap is that it never explicitly states what the response returns, though it implies the new ID is accessible since it says 'Use update-automation on the new ID.' Overall, it's sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter documentation, including the type, required status, and a clear description with an example URL format. The tool description reinforces this by mentioning 'by ID or Resend dashboard URL' but does not add new semantics beyond what the schema already communicates. This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Duplicate an existing automation by ID or Resend dashboard URL.' It clarifies that the result is a copy with its own ID and includes the original's steps and connections, distinguishing itself from create-automation, which builds work from scratch. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use this when the user wants a new automation based on one they already have, instead of rebuilding from scratch.' It also points to a concrete alternative: 'Use update-automation on the new ID to rename it or change its workflow.' This gives clear direction for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the read-only nature is already covered. The description adds behavioral context by explaining the two modes (with id returns workflow, without id lists with filtering/pagination) and mentions pagination parameters. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headings (Purpose, Modes, When to use), front-loads the purpose, and every sentence provides necessary information. It is concise with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description compensates by stating what is returned in each mode ('full automation details including the workflow definition'). It covers modes, parameters, and usage context well. It omits error handling or authentication details, but for a read-only tool with simple parameters, this is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 5 parameters. The description adds the meaning of omitting vs providing 'id' (list vs detail mode), which is not explicitly stated in the schema but is critical for correct invocation. This semantic clarification exceeds the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific automation (with its workflow) or list all automations.' It distinguishes two modes (with/without id) and explicitly mentions the dual functionality, differentiating it from sibling tools like get-automation-runs. The purpose is specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section provides explicit scenarios: user asks to show automations, inspect a specific workflow, or before update-automation to see current workflow. This gives clear context and implies an alternative (update-automation) but does not explicitly mention when not to use this tool versus other list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral details: it returns claim status and the TXT record, and it indicates the polling behavior. It does not contradict the annotation and provides context beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded, immediately stating what the tool retrieves and how. It includes the essential information (input, output, usage pattern) without any waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description explains the return value (claim status and TXT record) and the intended polling loop. It does not enumerate possible statuses or error conditions, but given the tool's simplicity and the readOnlyHint annotation, this level of completeness is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'id' as 'The placeholder Domain ID created by the claim'. The description adds the exact provenance ('the domain_id from create-domain-claim') and calls it a 'placeholder Domain ID', reinforcing the semantic meaning. With 100% schema coverage, this additional clarification earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and names the resource ('latest claim for a domain'), clearly distinguishing it from sibling tools like create-domain-claim and verify-domain-claim. It also specifies the input identifier ('placeholder Domain ID') and the output (status and TXT record), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it tells the agent to poll until status is 'completed' and identifies that the input comes from create-domain-claim. It does not explicitly mention when not to use this tool (e.g., versus verify-domain-claim), but the context is strong enough to infer its role in the claim verification flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds behavioral context beyond this: it reveals that the tool is for obtaining property IDs and understanding configured custom attributes, and it instructs the agent to request user selection rather than presenting all IDs upfront, and to omit IDs and creation dates unless explicitly requested. This adds useful behavioral nuance without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the function, explaining usefulness, and providing usage directives. It is front-loaded with the core action and avoids redundant wording. No unnecessary details or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with optional pagination parameters and no output schema, the description adequately covers the core purpose and usage. It explains what the tool is good for (getting IDs, seeing custom attributes) and gives an explicit workflow. It does not describe the return format or pagination behavior, but the schema covers the latter, and the tool's low complexity reduces the need for further detail. Overall, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (after, limit, before), meaning the schema already explains their meaning and constraints. The description does not add further parameter-level details, but the schema is sufficient. Since the schema carries the burden, a baseline score of 3 is appropriate; the description's mention of 'all contact properties' could imply pagination behavior but the schema parameters already handle that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all contact properties from Resend.' It specifies the resource (contact properties) and the action (list), and distinguishes it from more targeted tools like get-contact-property by emphasizing that it retrieves all available properties. The phrase 'This tool is useful for getting property IDs and seeing which custom attributes are configured' further clarifies its intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'If you need a contact property ID, you MUST use this tool to get all available properties and then ask the user to select the one they want.' This clearly states when to use the tool and how to proceed. It also provides behavioral instructions ('Don't bother telling the user the IDs or creation dates unless they ask for them'), helping the agent know how to handle the results. No alternative tools are mentioned, but the conditional usage is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares safe read behavior. The description adds value by instructing the agent not to surface IDs or creation dates unless specifically asked, which is a useful behavioral guideline beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first states purpose, the second provides a concise behavioral instruction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list operation with full parameter documentation. The description supplements the missing output schema by telling the agent what not to return. It's sufficiently complete for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage, so baseline is 3. The description adds meaning by highlighting that contactId or email are the two ways to specify the contact, which clarifies parameter relationships not explicitly stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and the resource 'all segments a contact belongs to in Resend', with the methods 'by contact ID or email'. This is specific and clearly distinguishes from sibling tools like list-segments, which lists all segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for listing segments of a specific contact, which differentiates it from more general segment listers. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint annotation already declaring safety, the description adds return field details and pagination instructions (limit, after/before), which are behavioral traits not in the annotation. This provides meaningful context beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with bold headers and bullets, it conveys purpose, return fields, and usage in a compact, scannable format with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, return fields, pagination, and use cases, which is sufficient for a read-only list tool with a fully documented schema. It lacks error handling details, but those are not essential for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters at 100%, and the description reinforces their combined use for pagination ('Use pagination (limit, after/before) for large lists'), adding a strategic layer beyond individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List API request logs for the account' with a clear verb and resource, and differentiates itself from the singular 'get-log' sibling by describing the list operation. It also specifies use cases like review and audit, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists concrete scenarios (reviewing activity, debugging, user phrases) and explicitly covers pagination for large lists. It doesn't name alternative tools like 'get-log', but the usage context is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It explicitly warns that 'removing a broadcast is irreversible' and instructs the agent to warn the user. This is a critical behavioral disclosure for a destructive operation, going well beyond a simple 'removes' and covering the consequence and required pre-action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then adds necessary safety instructions. However, there is slight redundancy: 'you MUST double-check' and 'You may only use this tool if the user explicitly confirms' express similar requirements. While the content is valuable, it could be tightened without losing meaning. Still, every sentence contributes to the safe usage of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema or annotations, this description is fully sufficient. It covers the action, input format, irreversible nature, and the required confirmation workflow. There are no missing pieces that would prevent an agent from using the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage: 'Broadcast ID or Resend dashboard URL (e.g. https://resend.com/broadcasts/<id>)'. The tool description repeats 'by ID or Resend dashboard URL' without adding new semantic detail. The mention of referencing the 'NAME of the broadcast' is about the confirmation process, not the parameter meaning itself. Therefore, the description does not add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a broadcast by ID or Resend dashboard URL.' This uses a specific verb and resource, and differentiates from siblings like update-broadcast or get-broadcast. It also specifies the input format, which removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a strong procedural requirement: 'Before using this tool, you MUST double-check with the user' and 'You may only use this tool if the user explicitly confirms.' This gives clear context on when the tool is appropriate. However, it does not explicitly mention alternatives or when NOT to use this tool beyond the confirmation requirement, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 reveals that removal is irreversible and mandates a confirmation step, which is critical for a delete operation. However, it does not mention potential side effects on related data (e.g., contacts, segments) or the response format, though irreversibility is the most important trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the purpose, and the next two provide essential safety instructions. Every sentence earns its place, and the purpose is front-loaded. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool (1 parameter, no output schema, no annotations), the description covers the key risks (irreversibility, user confirmation) and provides clear operational guidance. It does not explain cascading effects or return values, but these are less critical given the tool's simplicity and the strong safety focus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'id' has description 'Topic ID'), so the schema already documents the parameter. The description merely repeats 'by ID' without adding format, source, or usage details beyond the schema, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a topic by ID from Resend,' providing a specific verb (remove), resource (topic), and scope (by ID). This distinguishes it from sibling remove-* tools which target other resources, and from other topic tools (create/update/get/list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Before using this tool, you MUST double-check with the user' and 'You may only use this tool if the user explicitly confirms.' This clearly states when the tool may and may not be used, effectively serving as a usage gate for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the immediate/scheduled sending behavior, return value ('Send confirmation and email ID'), and post-send follow-up (use list-emails or get-email). However, it does not mention edge cases like failures, retries, or rate limits, which could be important for a send operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers and bullet lists, and the purpose is front-loaded. It is longer than strictly necessary ('Key trigger phrases' overlap somewhat with 'When to use'), but every section adds value for a tool with 14 parameters and many sibling alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the tool's complexity (14 params, nested objects), the description covers the essential context: return value, workflow after sending, alternatives, trigger phrases, and scheduling. It tells the agent what to do with the result (check status via list-emails/get-email) and when not to use it, providing a complete operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself does not elaborate on individual parameters, but the schema provides detailed descriptions for all 14 parameters, including examples and constraints. The description adds no extra parameter-level meaning beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Send a single transactional email to one or more recipients immediately (or schedule it)' with a specific verb and resource, and distinguishes from siblings by noting 'NOT for: Sending the same email to a whole list/audience (use create-broadcast + send-broadcast).' This makes the tool's scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('When to use' bullet list) and exclusions ('NOT for' section) naming alternative tools. Also includes workflow and trigger phrases, making it clear when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing key constraints: event name must match trigger, contactId/email mutual exclusion, and payload semantics via event.* variables. It does not cover return values or error behavior, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded headers and concise bullet points. Every sentence adds value, covering purpose, usage, workflow, and important caveats without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a nested object, and no output schema, the description covers purpose, usage, workflow, and critical constraints. It misses return value details, but that is not required given the absence of an output schema. Overall, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% parameter description coverage, so the baseline is 3. The description adds extra meaning beyond the schema by explaining the mutual exclusion requirement and how the payload is used in automations, pushing it to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Fire an event to trigger automations for a specific contact.' It uses a specific verb and resource, distinguishing it from sibling tools like send-email or send-broadcast, which send messages rather than trigger automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' bullets and a workflow (create-event → create-automation → send-event) give clear usage context. However, it does not explicitly mention when not to use or name alternative tools, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: suppressed addresses 'never receive emails from the account, even when included as recipients,' and it clarifies the manual vs. automatic nature of suppression. It does not cover edge cases like duplicate suppression or reversibility, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. Every sentence earns its place: the action, the behavioral implication, and the alternative for bulk operations. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and lack of annotations or output schema, the description is complete enough for an agent to select and invoke the tool. It covers purpose, usage guidance, and the key behavioral consequence, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter ('email') with a format and description. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add an email address to the suppression list in Resend.' It uses a specific verb and resource, and explicitly distinguishes itself from batch-add-suppressions by mentioning that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, noting that hard bounces and spam complaints are added automatically and this tool is for manual suppression 'e.g., to honor a do-not-contact request.' It also directs users to batch-add-suppressions for multiple addresses, giving a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing that the tool automatically connects the agent to the editor and that subsequent compose calls disconnect. This side-effect is significant and not observable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, bullets, and a tip. Every sentence contributes to understanding the tool's purpose, usage, and side-effects, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains the return value and how to use it as a base for modifications. It also covers the editor connection side-effect and parameter defaults, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters, so the baseline is 3. The description adds minimal extra value, such as the tip about include_schema, but largely repeats parameter behavior already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves TipTap JSON content of a broadcast or template, optionally including the schema reference. It also differentiates from siblings by instructing 'Always call this before compose-broadcast or compose-template', making its specific role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section provides explicit contexts: always before compose-broadcast/compose-template, for edits/modifications, and for inspection. It lacks explicit when-not-to-use or alternative tool names, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds useful context about the scope (all broadcasts, no filtering) and included return fields, but does not mention pagination or potential large result sizes. This is comparable to the get_calls calibration example, receiving a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded section headers and front-loaded purpose. Each sentence earns its place, covering purpose, exclusions, return fields, and usage triggers without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool, the description includes all essential context: what it lists, what fields return, when to use, and when not to use. There is no output schema, so the return field list compensates. The tool's complexity is low, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for zero params is 4, and the description doesn't need to add parameter details. It does add context about return fields, which indirectly clarifies output but not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all broadcast campaigns (newsletters/bulk emails) with specific fields. It explicitly distinguishes from sibling tools like list-emails, list-segments, and list-contacts, and points to get-broadcast for single details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios ('show my broadcasts', 'what newsletters did I send?') and explicit exclusions ('NOT for: listing transactional emails...'). It also names alternative tools, making the selection decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds value by specifying the return fields, pagination behavior, and its role as the first step in a workflow, going beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers and is appropriately concise. Every sentence provides useful information: purpose, exclusions, return details, usage scenarios, and workflow. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers purpose, return fields, pagination hints, usage scenarios, and workflow integration. It gives the agent enough context to invoke correctly and know what to expect, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters. The description adds little beyond mentioning pagination in the returns section, not explaining parameter syntax or edge cases. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recently sent transactional emails with metadata, using a specific verb and resource. It explicitly distinguishes itself from list-broadcasts, making it easy for the agent to select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'NOT for' section naming list-broadcasts, plus a 'When to use' list with concrete user intents and a workflow (list-emails → get-email). This gives complete guidance on when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: it explains that revoked grants are included and how to detect them via a non-null revoked_at field. It also lists the key output fields (client name, scopes, creation date), providing richer context than the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the main action in the first sentence and then providing necessary behavioral and output details. Every sentence earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with a comprehensive schema and a read-only annotation, this description is complete. It covers the important aspects: what the tool lists, the active/revoked distinction, the fields returned, and guidance for the agent's response. No output schema is present, so the description appropriately covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with clear descriptions, including constraints and mutual exclusivity for 'after' and 'before.' The description adds no parameter-specific information, so the baseline score of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List OAuth grants for the team — the apps authorized to act on the team's behalf.' This is a specific verb+resource+scope that distinguishes it from sibling tools like revoke-oauth-grant, which performs a different mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by noting that all grants (active and revoked) are returned, implying the agent may need to filter for active ones. It also gives a direct interaction guideline: 'Don't bother telling the user the IDs unless they ask for them.' However, it does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the `readOnlyHint` annotation, the description discloses that the download URL is time-limited and specifies the return metadata (filename, size, content type), adding valuable behavioral context. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with the primary purpose, then return details and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the return value (attachment metadata), the time-limited download URL, and the intended source of emails. Pagination is documented in the schema, so the description is complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters. The description does not add further parameter-level meaning, matching the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('attachments from a specific received (inbox) email'), clearly distinguishing it from siblings like `get-received-email-attachment` (singular) and `list-sent-email-attachments` (sent instead of received). It also mentions the return type, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use for emails listed by list-received-emails' provides clear context for when to use the tool, but it does not explicitly name alternatives or state when not to use it. This is clear guidance without explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable context by stating the return scope ('Paginated metadata: from, to, subject, message_id, received time') and that full content requires a different tool. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured into three sections (Purpose, NOT for, Returns) with no redundant wording. Every sentence earns its place, and the most critical information is front-loaded. It is concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and readOnly annotation, the description covers all essential aspects: purpose, exclusions with alternatives, return content, and a pointer to the content-retrieval tool. No output schema exists, so the description compensates by listing the returned fields. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all three parameters (after, limit, before) are fully described in the input schema, including constraints and mutual exclusivity. The description adds no extra parameter semantics, but the schema already does the heavy lifting, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource combination: 'List emails received (inbox) by your Resend receiving address.' It clearly distinguishes from sibling tools by explicitly stating what it is NOT for (sent emails and broadcasts) and names the correct alternatives (list-emails, list-broadcasts). This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use-case examples ('show my inbox', 'what emails did I get?') and explicit exclusions with alternative tools ('NOT for: Listing emails you sent (use list-emails)...'). It also mentions using get-received-email for full content, giving a clear path for follow-up actions. This is model usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that removal is irreversible, stops all email sending/receiving for the domain, and requires a specific confirmation protocol. This goes well beyond a generic 'Removes a domain' and gives the agent essential safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the action. Every subsequent sentence adds crucial safety information, and there is no redundant wording. It is appropriately detailed for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers the action, prerequisites, consequences, and the exact consent requirement, providing all necessary guidance for an agent to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'id', with description 'Domain ID' providing 100% coverage. The description merely echoes 'by ID' without adding further semantic detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a domain by ID from Resend.' This is a specific verb (Remove) plus resource (domain) and method (by ID). It distinguishes itself from sibling tools like create-domain, update-domain, and verify-domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit preconditions: double-check with the user, warn about irreversibility, and only proceed with explicit confirmation. It states when-not-to-use (without confirmation) but does not mention any alternative tools or methods, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses prerequisites (broadcast must be created first), return value (send confirmation and broadcast ID), scheduling behavior (natural language or ISO 8601, sent immediately if not provided), and workflow. It does not detail potential side effects (e.g., status change or irreversibility), but provides substantial behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Purpose, NOT for, Returns, When to use, Workflow). Each section adds value, and the content is front-loaded with the core purpose. No redundant or wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description is thorough. It explains what the tool does, when to use it, the prerequisite workflow, return value, and scheduling semantics. Sibling differentiation is strong, and the missing output schema is partially compensated by the explicit 'Returns' note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema already states. It reinforces the workflow relationship between broadcastId and create-broadcast, but does not introduce new parameter-level details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send (or schedule) an existing broadcast by ID.' It specifies the verb (send), resource (broadcast), and explicitly distinguishes from create-broadcast (creation) and send-email (one-off email). The 'NOT for' section reinforces differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists concrete scenarios (e.g., 'user says send it', 'schedule this for tomorrow') and explicitly states what the tool is NOT for (sending one-off emails, creating content). It also provides a workflow (create-broadcast → send-broadcast) and mentions list-broadcasts as an alternative for finding existing broadcasts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: setting html/text replaces compose-template content and is lossy, and published templates require re-publishing. It does not cover permissions or response format, but the main risk is well-communicated, so this exceeds baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the action, then provides workflow and cautionary notes. Every sentence contributes value, and the lossy-content warning and compose-template alternative are clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter update tool with no output schema, the description covers the important context: the need to republish, the content overwrite risk, and the alternative for TipTap content. It gives the agent enough to decide when to invoke this tool and what to watch for.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds the warning about html/text being lossy, which is useful, but it does not add new semantic info beyond the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates template metadata by ID, alias, or dashboard URL, listing the fields (name, subject, from, html, variables, etc.). It explicitly distinguishes from compose-template ('To edit TipTap content, use compose-template instead') and mentions publish-template, making it unambiguous among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and alternatives: after updating a published template, use publish-template to make changes live; prefer compose-template for content changes. Also instructs to ask the user before overwriting TipTap content with raw HTML, which is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals the asynchronous nature ('Trigger asynchronous DNS verification'), the pending state ('claim stays 'pending''), and the post-verification side effect (NEW DKIM records). It could also mention failure handling or idempotency, but the core behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence contributes necessary workflow context. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full lifecycle: triggering verification, polling for status, and subsequent steps (fetch DKIM records, add to DNS, run verify-domain). It's complete for an asynchronous tool with no output schema, as it directs the agent to the appropriate follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'id' fully as 'The placeholder Domain ID created by the claim', and schema coverage is 100%. The description repeats 'using the placeholder Domain ID' but adds no new semantic detail. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Trigger asynchronous DNS verification and ownership transfer for a domain claim'. It specifies the resource (domain claim) and the unique input (placeholder Domain ID). This distinguishes it from siblings like get-domain-claim (poll status) and verify-domain (final verification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: use after creating a claim, poll get-domain-claim for status, then fetch DKIM records with get-domain, add them to DNS, and run verify-domain. It names alternative tools and describes the workflow sequence, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the entire behavioral burden. It fully discloses the nuanced effects: queued broadcasts stop mid-send, already-sent emails are unaffected, scheduled broadcasts revert to draft, and sent broadcasts are immutable. This goes well beyond minimal requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with purpose, exclusions, and when-to-use sections, and every sentence earns its place. It is front-loaded with the core purpose and avoids filler while still covering edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description provides strong contextual completeness: purpose, target states, exclusions, and a sibling pointer. The only minor gap is not describing the cancellation response or confirming idempotency, but this is not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already includes the broadcast ID/URL meaning and example. The tool description adds no extra detail about the parameter beyond what the input schema provides, so the baseline applicable score is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: cancel a queued or scheduled broadcast by ID or dashboard URL, with the explicit scope that it removes no broadcast. It distinguishes itself from remove-broadcast by name, so an agent can tell this tool apart from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit 'NOT for' guidance, excludes drafts and sent broadcasts, and tells the agent to use remove-broadcast instead when removal is intended. It also defines a concise 'When to use' trigger matching common user phrasing like 'stop', 'cancel', or 'pause'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool 'Automatically connects and disconnects from the editor,' warns that skipping get-tiptap-json-content will 'overwrite all existing content,' and explicitly notes that switching between compose and update modes is 'lossy' and that HTML content may be lost. These side effects are critical for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with bold section headers (Purpose, Workflow, When to use, Important, Note). Each section adds value, though there is some redundancy with the schema's parameter descriptions (e.g., the 'Important' note repeats the content parameter's description). It earns a high score for clarity and organization, but loses a point for minor repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool involving TipTap JSON, dashboard editor connectivity, and potential data loss, the description is remarkably complete. It explains the full workflow, prerequisites, side effects, and when to defer to the user. It also addresses the nuance of switching from HTML to compose mode, which is essential for avoiding destructive actions. No output schema is present, but for a mutation tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already provides detailed descriptions for each parameter (e.g., content param says 'Call get-tiptap-json-content (with include_schema: true) first...'). The tool description repeats this advice but doesn't add significant new semantics beyond the schema. It reinforces the workflow but does not go beyond what structured fields already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the TipTap JSON content of a template, enabling it to be edited visually in the Resend dashboard editor.' It also distinguishes itself from siblings by noting it can 'also update metadata (subject, name) in the same call' and by highlighting that it is 'the recommended way to set email content' compared to raw HTML updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: a 'When to use' list (after create-template, when user wants to write/edit/style email content, when collaborating in dashboard), a recommended workflow (get-tiptap-json-content → compose-template), and a caution about not using it when template already has HTML content without asking. It also implies an alternative (update/raw HTML mode) by referring to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It states that removing an API key is 'irreversible and any services using it will lose access', and requires user double-check and explicit confirmation. This transparently communicates the destructive nature and the need for consent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded: it states the core action first, then provides necessary safety instructions. Every sentence serves a purpose—setting the action, requiring double-check, warning about irreversibility, and conditioning on explicit confirmation. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the destructive nature, user confirmation requirement, and the need to reference the API key name. While it omits details like error handling or permissions, the safety-critical aspects are thoroughly addressed. Given no annotations or output schema, this is a complete enough description for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'id' parameter with description 'API key ID'. The tool description adds minimal extra meaning, only reinforcing 'by ID' and referencing the name for double-checking. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove an API key by ID from Resend.' This specifies the verb (remove), resource (API key), and scope (by ID). It distinguishes from sibling tools like create-api-key and list-api-keys. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage protocol: 'Before using this tool, you MUST double-check with the user...' and 'You may only use this tool if the user explicitly confirms...'. It gives clear instructions on when to use the tool and the required confirmation steps, effectively guiding the agent on safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully carries the burden of disclosing behavioral traits. It explicitly states the operation is irreversible, requires user confirmation, and should reference the endpoint. This goes beyond the basic delete semantics and provides critical safety context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the purpose. However, the confirmation requirement is repeated twice ('double-check' and 'explicitly confirms'), adding slight redundancy. It remains compact and mostly every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description is sufficiently complete. It explains the action, the safety protocol, the irreversibility, and the condition for invocation. The agent has all necessary context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter (webhookId) with a type and description, giving 100% schema coverage. The description's 'by ID' adds no additional meaning beyond the schema, so a baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Remove a webhook by ID from Resend', which clearly identifies the action (remove), the resource (webhook), and the scope (by ID). This distinguishes it from sibling webhook tools like create-webhook, list-webhooks, get-webhook, and update-webhook, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit preconditions for use: 'you MUST double-check with the user', 'You may only use this tool if the user explicitly confirms'. It also gives guidance on what to reference (ENDPOINT) and what to warn about (irreversible), making when-to-use and when-not-to-use exceptionally clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the exact return fields (id, email, first_name, last_name, unsubscribed, created_at) and optional segment filtering behavior. This provides useful behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with four labeled sections (Purpose, NOT for, Returns, When to use) and bold headers. Every sentence serves a purpose, with no redundant or filler content, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description specifies the return structure and gives practical usage guidance. Combined with the schema's thorough parameter documentation, the description fully equips an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for all four parameters (pagination constraints, defaults, segmentId behavior). The tool description adds only a brief mention of 'Optionally filter by segment', which adds little beyond the schema's existing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List contacts from Resend' with a specific verb and resource, and immediately differentiates itself from sibling tools like list-segments, list-emails, and list-broadcasts. It also clarifies the primary use case: discovering contact IDs or emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'NOT for' section naming alternatives (list-segments, list-emails, list-broadcasts) and a 'When to use' section with concrete user queries like 'who's in this list?'. This gives clear guidance on when to select this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by detailing return fields ('name, id, created_at') and pagination behavior ('Use pagination (limit, after/before) for large lists'). It also states 'List all segments in the account,' which clarifies scope. This adds meaningful context about what the tool does and how results are returned, complementing the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded section headers ('Purpose', 'NOT for', 'Returns', 'When to use'), making it scannable and front-loaded. Every sentence provides actionable information with no redundancy or filler. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers all necessary aspects: purpose, alternatives, return fields, pagination, and trigger phrases. No output schema exists, but the description explicitly states what is returned. It is complete enough for an agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all three parameters (after, before, limit), including constraints and defaults. The description only mentions pagination generically without adding new semantic details. With high schema coverage, a baseline of 3 is appropriate; the description adds no significant parameter-level information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all segments in the account.' It uses a specific verb and resource, and explicitly distinguishes from related tools with 'NOT for: Listing contacts inside a segment (use list-contacts with segmentId). Not for listing broadcasts (use list-broadcasts).' This fully clarifies scope and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'When to use: User says "show my segments", "what lists do I have?", or before create-contact/create-broadcast when segmentId is unknown.' It also includes clear alternatives in the 'NOT for' section, naming specific sibling tools. This gives an agent definitive criteria for when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint: true already annotating the safe read nature, the description adds useful behavioral context by specifying the output content (webhook IDs, endpoints, events). It does not contradict the annotation and provides meaningful detail about what the tool returns, which is especially helpful given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every phrase adds value. It is concise with no redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (no params, read-only annotation), the description fully covers the context: what it lists, what info it returns, and what it does not cover. The absence of an output schema is compensated by stating the key output fields (IDs, endpoints, events).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information needed. The baseline for 0 params is 4, and the description appropriately focuses on the tool's purpose rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List all webhooks from Resend.' It clearly distinguishes from sibling tools by explicitly saying 'Not for listing emails, segments, or broadcasts,' making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the user when to use this tool: 'Use to get webhook IDs and see which endpoints and events are configured.' It also provides exclusions ('Not for listing emails, segments, or broadcasts') which differentiates from alternative list tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 discloses the consequence (the address will receive emails again), the risk of deliverability harm if suppressed due to bounce/complaint, and the required user consent step. This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core action. Each safety sentence provides essential operational guidance without redundancy, earning its place in the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is complete. It covers the action, consequences, and user interaction requirements, making it fully self-contained for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes idOrEmail as 'Suppression ID or email address' with 100% coverage. The description reiterates this and adds minor context about referencing the email address during double-check, but does not significantly enrich parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes an entry from the suppression list by ID or email address and explains the effect (allowing the address to receive emails again). This distinguishes it from sibling tools like add-suppression, list-suppressions, get-suppression, and batch-remove-suppressions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit mandatory usage guidance: double-check with the user that they want to remove the suppression, reference the email address when doing so, warn about deliverability risks, and only proceed after explicit user confirmation. This clearly defines when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 thoroughly discloses the destructive nature of the operation: 'revocation is immediate and irreversible,' all access and refresh tokens stop working, and the app must be re-authorized. This goes well beyond the schema's parameter information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though the description is longer than average, every sentence adds necessary safety-critical context for an irreversible operation. It front-loads the core purpose, then clearly enumerates warnings and the confirmation requirement, without any redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with no output schema. The description completely covers the operation's purpose, precondition, consequences, and user-confirmation protocol, leaving no critical gaps for the agent to invoke the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the single parameter 'id' with a clear description ('OAuth grant ID'). The description does not add extra parameter-level details (such as format or examples), but none are needed given the schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource combination: 'Revoke an OAuth grant by ID.' It cleanly distinguishes itself from the sibling 'list-oauth-grants' tool, which is a read operation, while this one performs a destructive revocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, actionable usage guidance: it mandates double-checking with the user, tells the agent to reference the app name, warns about immediate irreversibility, and states the exact condition under which the tool may be used ('only if the user explicitly confirms'). This clearly delineates when to use the tool versus when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and delivers thoroughly. It specifies behavior for each step type, fallback semantics for 'from'/'subject', error modes (silent failure, run error), structural rules (tree-shaped, reachability), and return value (Automation ID and dashboard link). This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, the description is meticulously structured with headers, bullet points, and examples. It front-loads purpose and usage, and every section serves a functional need given the tool's complexity. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (nested steps, multiple step types, branching rules), the description fully equips the agent to construct valid workflows. It covers all step types, config schemas, constraints, and return values, with multiple examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage, but the tool description goes far beyond schema definitions. It explains the exact structure of workflow steps, config objects, operator semantics, dynamic variables, and provides three complete examples. This adds immense meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'create an automation workflow that triggers on events and executes a sequence of steps.' This is a specific verb and resource, and it differentiates from sibling tools that update, remove, or get automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a dedicated 'When to use' section listing two concrete scenarios (automated email sequences, event-based actions). It also references a workflow with prerequisite tools, but does not explicitly mention when not to use or alternatives like update-automation, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure. It reveals important behaviors such as disabled status not stopping existing runs, workflow replacement semantics, potential silent email failures, and constraints like reachability and tree-shaped workflows. This is far beyond generic mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, when-to-use, important notes, step-type reference, rules, and three illustrative examples. It is front-loaded with action and use-case context before diving into detailed reference material, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool managing automation workflows, the description covers all necessary context: step types, configs, branching semantics, constraints, examples, and potential failure modes. No output schema exists, but the operational guidance is so thorough that the lack of return-value documentation is not a meaningful gap in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema's basic parameter definitions. It provides a comprehensive guide to the workflow parameter, including every step type, config structure, branching rules, and worked examples. It also clarifies id/status/name usage in context, making parameter interpretation much richer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update an automation's name, status, or workflow,' clearly specifying the verb and the modifiable resources. It distinguishes itself from siblings like create-automation and remove-automation by enumerating the exact update operations it supports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists precise scenarios: renaming, toggling status, and modifying workflow steps. It also advises calling get-automation first to inspect the current workflow. However, it does not explicitly name alternative tools for create/delete or state 'do not use' conditions, so full when/when-not guidance is slightly lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: discloses automatic connect/disconnect from editor, warns that skipping get-tiptap-json-content will overwrite existing content, and notes that switching between compose and update modes is lossy. These are meaningful behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold headers, bullet lists, and a clear flow. Each sentence earns its place—purpose, recommendation, workflow, when-to-use, important warning, and note. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description covers purpose, usage workflow, prerequisites, warnings, and limitations. It is sufficiently complete for a tool with 5 parameters (1 required) and no return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that content is TipTap JSON and that metadata (subject, preview text, name) can be updated in the same call, reinforcing the schema's parameter descriptions and the combined-use capability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Set the TipTap JSON content of a broadcast, enabling it to be edited visually in the Resend dashboard editor.' It clearly distinguishes from siblings by labeling it 'the recommended way to set email content' and contrasting with 'update (raw HTML)' mode in the note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' bullets (after create-broadcast, for writing/editing/styling content, for dashboard collaboration) and a workflow: get-tiptap-json-content → compose-broadcast. It also gives an exclusion: if broadcast already has HTML content, ask the user before switching to compose mode due to lossy conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 key behavioral traits: 'does NOT send yet', requires a segment ('There is no all contacts option'), personalization placeholders, and that switching between compose and html/text modes is lossy. This is substantial context beyond a simple create action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured with bold headers, bullet points, and sections. Every sentence serves a purpose: purpose, exclusions, return value, when-to-use, workflow, content options. Front-loaded with the most critical information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is exceptionally complete. It covers returns, workflow, personalization, segment requirements, alternatives, and content-authoring modes. This provides a full operating context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter context by explaining when to use html/text vs compose-broadcast, and clarifies that the name can be auto-generated. It also notes the 'all contacts' limitation relevant to segmentId. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the purpose: 'create a broadcast campaign (one email sent to an entire segment)'. It clearly distinguishes from send-broadcast, send-email, and create-contact with specific 'NOT for' examples. The verb+resource+scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: user intents like 'email my list', 'send a newsletter', 'broadcast to my segment'. Also includes 'NOT for' exclusions and a clear workflow (list-segments → create-broadcast → get-tiptap-json-content → compose-broadcast → send-broadcast). Names alternatives such as send-email and create-contact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, but the description adds rich behavioral context: explains that suppressed addresses never receive emails, describes automatic origin sources (bounce, complaint), and discloses return fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than minimal, every section serves a purpose: Purpose, NOT for, Returns, When to use. Proper use of bold headings and concise bullet-like phrases makes it scannable and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 optional parameters and no output schema, the description is complete: it covers what it returns, pagination, origin filtering, and disambiguation from related tools. No significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description enhances this by explaining how origin values map to real-world events and elaborating on pagination usage (after/before), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource ('List email addresses on the suppression list') and clearly distinguishes itself from siblings by explicitly naming get-suppression and list-contacts as alternatives. This goes beyond a bare statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'NOT for' section explicitly lists what the tool is not for and names the correct alternative tools. The 'When to use' section provides concrete example user requests, making usage context unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive, irreversible nature of the operation and the required confirmation workflow. It also explains how to identify the contact (name and email) during the double-check, adding behavioral context beyond the basic 'remove' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the action, and the next two provide critical safety instructions. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers all essential context: what it removes, how to identify the contact, the irreversible nature, and the required confirmation. It is complete for an agent to invoke safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (id and email) with 100% coverage, so baseline is 3. The description adds that the contact can be removed by either ID or email, and that the double-check references the email, providing mild additional context for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a contact from Resend (by ID or email)', with a specific verb and resource. It distinguishes from sibling tools like update-contact or get-contact by explicitly focusing on removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage prerequisites: 'you MUST double-check with the user', 'warn the user that removing a contact is irreversible', and 'You may only use this tool if the user explicitly confirms'. This clearly frames when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the irreversible nature of the action and the necessity of a confirmation step. It warns that removal cannot be undone, which is critical behavioral information beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence serves a purpose: the action, the mandatory double-check, the irreversibility warning, and the explicit confirmation requirement. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers all necessary context: what it does, how it must be used safely, and the irreversible consequence. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter as 'Segment ID', so baseline is 3. The description adds the instruction to reference the segment NAME during double-checking, implying the need to map id to a human-readable name. This enriches the id parameter's meaning beyond the schema, though not extensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Remove a segment by ID from Resend,' which clearly states the action (remove), the target resource (segment), and the identifier (ID). It unambiguously distinguishes this tool from sibling remove tools like remove-contact or remove-broadcast by specifying the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance: it must only be used after the user explicitly confirms. It also mandates a specific pre-operation workflow (double-check, reference the segment name, warn about irreversibility), leaving no ambiguity about the required confirmation process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully carries the burden. It discloses the API requirement for 'from' and 'segmentId', notes that these may be empty for dashboard-created broadcasts, and warns that setting html/text is lossy, replacing content from compose-broadcast. It even instructs asking user before overwriting TipTap content, which is strong side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headings and front-loaded purpose. It is not overly verbose; each sentence adds crucial information, including the important caveats, without redundancy. The format is easily scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema or annotations, the description covers essential preconditions, alternative tools, and risks. It mentions the need to call get-broadcast first, use list-domains/list-segments, and clarifies content loss issues. This is complete for guiding correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema. It explains that 'from' and 'segmentId' are often required and provides guidance on finding verified domains and segment IDs. The note about html/text replacing TipTap content adds semantic depth not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states precisely what the tool does: 'Update broadcast metadata by ID or Resend dashboard URL' and lists the specific fields (name, subject, from, html, text, segment, preview text, reply-to). It clearly differentiates from sibling 'compose-broadcast' by stating 'To edit TipTap content, use compose-broadcast instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use this tool versus the alternative, with a direct reference to compose-broadcast for TipTap content. It also gives step-by-step usage prerequisites: 'Always call get-broadcast first to check, and include from and segmentId in your update if they are not already set' plus references to list-domains and list-segments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![resend-mcp MCP server](https://glama.ai/mcp/servers/resend/resend-mcp/badges/card.svg)](https://glama.ai/mcp/servers/resend/resend-mcp)

Score Badge

Copy to your README.md:

[![resend-mcp MCP server](https://glama.ai/mcp/servers/resend/resend-mcp/badges/score.svg)](https://glama.ai/mcp/servers/resend/resend-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/resend/resend-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server