ForwardEmail MCP Server

by junxit

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation2/5
Several tools have overlapping purposes, most notably the domain_sieve_* and sieve_script_* groups, which both manage Sieve scripts for an alias with nearly identical descriptions. Other resources like email vs message also blur the line between outbound SMTP and IMAP messages, though descriptions help somewhat.
Naming Consistency2/5
Naming is inconsistent: list endpoints use plural resource names (domains_list, aliases_list, contacts_list), while other actions use singular (domain_create, alias_get, contact_update). Prefixes vary as well, with domain_sieve_* and sieve_script_* both used for the same underlying resource.
Tool Count2/5
With 71 tools, the server is far beyond the typical 3-15 well-scoped range and even exceeds the 25+ threshold that indicates too many. While the API covers a broad feature set, the sheer number makes it unwieldy for an agent to navigate efficiently.
Completeness4/5
The tool surface is remarkably comprehensive, covering CRUD for accounts, domains, aliases, contacts, calendars, events, messages, folders, and Sieve scripts, plus email sending and domain verification. Minor gaps exist, such as no getter for allowlist/denylist (only replace) and duplication between Sieve tool groups, but most workflows have no dead ends.
Average 3.5/5 across 71 of 71 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- 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 disclosing behavior. It merely says 'update' without mentioning permissions, reversibility, effects on existing fields, or return values. This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and appropriately concise, though it could be slightly more informative without sacrificing brevity.
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 tool with no annotations, no output schema, and five optional parameters, the description is too thin. It doesn't mention return values, confirm the update affects existing values, or provide any caveats (e.g., clearing default_forwarding_address). The schema partially compensates, but overall the documentation is incomplete 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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself adds no additional meaning beyond the schema; it simply refers generically to 'account information' without elaborating on any parameter syntax or relationships.
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 clearly states the action ('Update') and the resource ('your ForwardEmail account information'). It is specific enough to distinguish from account_get and account_create, though it doesn't explicitly name these alternatives.
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 provided on when to use this tool versus alternatives like account_create or account_get. The context is implied only by the name and sibling list, but the description offers no explicit usage context 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?
With no annotations, the description carries the full burden of disclosing side effects. It merely says 'Generate a password' without mentioning override behavior, auto-generation versus provided passwords, or whether instructions will be emailed. For a state-changing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant content. It front-loads the key action and target, making it easy to scan.
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?
Despite having 5 parameters and no output schema, the description does not explain what the tool returns (e.g., the generated password) or the effects of is_override and emailed_instructions. The absence of behavioral context makes it incomplete for understanding the full tool workflow.
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 descriptions for all 5 parameters (100% coverage), so the description doesn't need to explain them individually. The description adds context about the password's intended use (IMAP/SMTP/CalDAV/CardDAV) but no additional parameter-level meaning, making baseline 3 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 clearly states the action (generate a password) and the target resource (an alias), adding the protocol context (IMAP/SMTP/CalDAV/CardDAV). It is specific enough to distinguish from generic alias tools, but doesn't explicitly differentiate from sibling tools like alias_update or catchall password creation.
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 sibling tools such as alias_update or domain_catchall_password_create. The description implies it's for alias passwords but provides no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update an existing alias' without indicating partial vs. full update, required permissions, or side effects. This is insufficient for a mutating tool with 14 parameters.
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, direct sentence with no redundancy. It is appropriately concise for a simple update operation and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the one-line description is severely incomplete. It omits guidance on behavior, permissions, and return values, making it inadequate for an agent to use 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% description coverage for all 14 parameters. The tool description adds no additional parameter context, 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 'Update an existing alias' clearly states the action (update) and resource (alias). It distinguishes itself from sibling tools like alias_create and alias_delete, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus creating or deleting an alias, nor does it mention any prerequisites or alternatives. This is a clear gap.
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, the description carries full burden for behavioral disclosure, but it only states creation. It does not mention validation, default values for priority/is_active, idempotency, authentication needs, or return behavior.
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 clear sentence with no wasted words and is front-loaded with the verb. It is slightly undersized given the tool's context and sibling ambiguity, but it remains concise and well-structured.
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?
The tool has 6 parameters, no output schema, no annotations, and is surrounded by many similar sibling tools. The one-sentence description does not clarify return values, default behavior, or the relationship between domain and alias, leaving significant 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 has 100% parameter coverage with descriptions for all 6 fields, so the description does not need to add much. The description itself adds no parameter details beyond what the schema already provides, so 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 clearly states the verb 'Create' with the resource 'Sieve filtering script' and the scope 'for an alias'. However, it does not explicitly differentiate this tool from the sibling 'sieve_script_create', which could be ambiguous.
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 provided about when to use this tool versus the many sibling sieve/script tools. There are no exclusions, prerequisites, or alternatives 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update', without indicating whether the script is fully replaced, whether activation is implied, whether validation occurs, or what permissions are needed.
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 immediately states the verb and object. It contains no filler or redundant phrasing.
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?
This is a mutation tool with six parameters and no output schema, but the description is only one clause. It does not mention the activate parameter, the distinction from generic sieve_script_update, or any outcome/return behavior, making it insufficient for confident invocation in complex scenarios.
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 descriptions for all six parameters, giving 100% coverage. The description adds no parameter-level semantics beyond the schema, but the schema itself is sufficient, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies the resource ('Sieve filtering script') scoped to 'an alias', which makes the core purpose clear. However, it does not explicitly distinguish this from sibling tools like sieve_script_update or domain_sieve_activate, and it omits the 'domain' context from the name.
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 provided about when to use this tool versus alternatives. There are no exclusions, prerequisites, or explicit comparisons to sibling tools such as domain_sieve_create or sieve_script_update.
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, the description carries the full burden for behavioral disclosure. It merely says 'Update domain settings' without explaining whether the update is partial or full, what permissions are needed, or what side effects or response to expect. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. However, it is under-specified, sacrificing necessary context for brevity, which slightly reduces its efficiency score.
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 (10 parameters, no output schema, no annotations), a single generic sentence is inadequate. The description does not address partial vs. full updates, validation behavior, or response details, leaving significant gaps for an 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?
The input schema has 100% description coverage for all 10 parameters, so the schema already documents parameter meanings. The description adds no additional semantic context beyond what the schema provides, meeting the baseline expectation.
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 clearly states the verb 'Update' and the resource 'domain settings', distinguishing it from sibling tools like domain_create and domain_get. However, it is generic and does not specify which settings are updatable, relying on the schema for that detail.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or situations where other domain tools (e.g., domain_create) would be more appropriate.
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 available, the description carries full responsibility for behavioral disclosure. It mentions the need for credentials and the IMAP/Nodemailer format, but it does not describe side effects (e.g., whether the message is actually sent or only stored), return values, or potential constraints. The ambiguous 'Create/append' leaves room for misinterpretation.
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, short sentence that is front-loaded with the primary verb ('Create/append') and resource. It is efficient and avoids redundancy with the schema. However, it is arguably too sparse given the tool's complexity, but the schema compensates for this.
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 13-parameter create tool with no output schema and no annotations, the description is notably incomplete. It does not explain what 'append' means operationally (e.g., where the message goes, whether it is sent), what the return value looks like, or how this tool relates to other message/email tools. The description alone would leave a user uncertain about the tool's real-world effect.
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 with descriptions for all 13 parameters, so the baseline of 3 is appropriate. The description adds no additional semantic meaning beyond what the schema already offers, such as clarifying the relationship between alias_username/alias_password and the message content.
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 uses a specific verb ('Create/append') and resource ('a message for an alias'), which clearly conveys the core action. It also hints at the technical context ('IMAP, Nodemailer format'). However, it does not explicitly distinguish this from sibling tools like email_create or message_update, leaving some ambiguity about when to choose this tool over them.
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 states one prerequisite ('Requires alias credentials') but provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or which sibling tools should be preferred for other message operations (e.g., sending vs. appending).
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 is the sole source of behavioral information. 'Delete an alias' indicates a destructive operation but does not disclose permanence, side effects on related data, or required permissions, leaving significant ambiguity.
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 redundant words. It is front-loaded and efficient, using the minimal text to convey the core action.
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 two required parameters, both well-documented in the schema, and no output schema. The one-line description is nearly sufficient for such a simple operation, but the lack of behavioral context (e.g., irreversibility) and any usage guidance leaves a minor gap in 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 already provides clear descriptions for both parameters, covering 100% of them. The description adds no additional meaning beyond the schema, so the baseline score of 3 for high schema coverage applies.
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 uses the specific verb 'delete' and the resource 'alias', clearly indicating the tool's action. It distinguishes itself from sibling delete tools by naming the resource type. However, it lacks additional context or scope that would further differentiate it, so it does not earn a 5.
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, prerequisites, or alternatives. The agent must infer usage entirely from the tool name and sibling context, which is minimal support.
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 the action and does not mention read-only nature, return format, pagination, permissions, or any other behavioral traits.
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 is appropriately sized for a simple list operation. It is front-loaded with the action and contains no wasted words.
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?
For a simple tool with two documented parameters, the description is adequate but leaves gaps. It does not explain what the return value looks like, nor does it clarify when to use this tool over the similar sieve_scripts_list 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 already provides descriptions for both parameters (domain: 'Domain name or ID', alias_id: 'Alias ID or name'), covering 100% of the parameters. The description adds no additional parameter semantics beyond the schema.
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 clearly states the action (List) and resource (Sieve filtering scripts) with a specific scope (for an alias). It is clear and specific, but it does not explicitly differentiate from sibling tools like sieve_scripts_list or domain_sieve_get.
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. Given the existence of many sibling sieve tools, the lack of usage context or exclusions is a notable gap.
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?
Since no annotations are provided, the description must disclose behavioral traits. It states the action but does not mention side effects (e.g., sending an email), required permissions, irreversibility, or the return value, leaving the agent without critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, though it sacrifices detail for brevity, which is why it does not receive a perfect 5.
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 an invite creation tool, the description is sparse. It does not explain the invite lifecycle (e.g., that invite_accept exists), whether it returns an invite object, or any side effects, making it incomplete for an agent to fully understand the context despite complete parameter documentation.
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 descriptions for all three parameters, achieving 100% coverage. The description's mention of 'admin or user' mirrors the group enum but adds no additional semantic value beyond what the schema already documents, 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 purpose with a specific verb ('Invite') and resource ('a user to join your domain'), and distinguishes it from sibling tools like invite_accept and invite_delete by mentioning the admin/user role option. The action 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as invite_accept or member_update, nor are prerequisites or conditions mentioned. The usage is only implied by the verb, making it insufficient for differentiating usage scenarios.
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, the description carries the full burden. It only discloses the need for alias credentials, but does not explain side effects, whether updates are overwrites, activation behavior, or response format. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or repetition. It fronts the core purpose, but it is so terse that it omits necessary behavioral and usage context. Efficient but not optimally sized for the tool's complexity.
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 has 6 parameters, 3 required, no annotations, and no output schema, the description is notably incomplete. It does not explain return values, behaviors, or edge cases. This is a moderate-complexity tool that needs more context than a one-liner.
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 all 6 parameters with descriptions (coverage 100%). The description adds no param-specific information beyond the credential prerequisite, which is already implied by the schema fields. 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 identifies the action ('Update'), the resource ('Sieve script for an alias'), and scopes it to aliases, distinguishing it from sibling tools like domain_sieve_update. The specific verb+resource+scope meets the highest bar.
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 when-to-use guidance or exclusions. The credential requirement is a prerequisite, not usage context. It does not mention when to prefer this over domain_sieve_update or other Sieve tools, leaving the agent without clear selection criteria.
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 that an account is created, without mentioning side effects (e.g., verification email), authentication requirements, or what happens if the email already exists. This is minimal 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 a single, direct sentence that conveys the purpose with no unnecessary words. It is appropriately sized for the simplicity of the tool.
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 no output schema and no annotations, the description is too sparse. It does not explain the expected outcome, any side effects, or constraints. For a creation tool, this lack of context leaves the agent uncertain about post-conditions and error 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?
Schema coverage for parameters is 100%, with basic descriptions for 'email' and 'password' already provided. The tool description adds no additional semantic meaning beyond what the schema already includes, 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 action ('Create') and the specific resource ('a new ForwardEmail account'), distinguishing it from sibling tools like account_get and account_update. 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 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, no prerequisites, and no exclusions. It simply states the action, leaving the agent without explicit context for when this tool is appropriate compared to account_update or domain_create.
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?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. However, it only states the action without noting permissions, side effects, or what happens on creation (e.g., immediate activation, required admin rights). The schema covers parameters but not behavioral consequences.
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?
Single sentence, direct, and front-loaded. It avoids any fluff or redundant information.
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?
The tool has 13 parameters and no output schema or annotations. The description is too brief to cover important context such as required fields (domain, name), what the response contains, or any special considerations like the smtp_limit permission requirement. The schema helps but the description does not compensate for missing annotations and 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information, but the schema already provides detailed descriptions for all 13 parameters, including constraints like smtp_limit requires domain-admin permission and is capped by domain limit.
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') and resource ('email alias') and clearly distinguishes from sibling tools like alias_update, alias_delete, and alias_get. It is concise 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 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. It does not mention prerequisites, typical scenarios, or when to use sibling tools like alias_update or alias_generate_password.
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 adds the useful fact that alias credentials are required and mentions CalDAV, but it does not disclose the read-only nature, potential side effects, error behavior, or return format. This leaves significant behavioral ambiguity for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using just two short sentences that front-load the action and key constraint. Every word earns its place, with no redundancies or filler.
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?
The tool has 8 parameters, no output schema, and no annotations, yet the description only states the basic action and credential requirement. It fails to mention what the response looks like, pagination behavior, default filters, or how to interpret the available filter parameters. The description is incomplete for a tool of this 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%, with every parameter having its own description, so the baseline is 3. The tool description adds no parameter-specific meaning beyond the credential context (already present in schema). It neither detracts from nor enhances the schema 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 the tool's action with a specific verb ("List"), a resource ("calendar events"), and scope ("for an alias (CalDAV)"). This distinguishes it from sibling tools like calendar_event_get (single event) or calendars_list (calendar metadata), even without naming alternatives.
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 minimal usage context, only noting "Requires alias credentials." It does not explain when this tool should be preferred over alternatives, nor does it specify exclusions or conditions. The prerequisite is helpful but does not constitute real usage 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 full responsibility for behavioral disclosure. It reveals a key requirement (alias credentials) and provides the CardDAV context, but it does not clarify side effects, permission needs beyond credentials, error behavior, or how the created contact relates to the alias. This is insufficient 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 a single, clear sentence with two meaningful clauses. It conveys both the purpose and an essential prerequisite without redundancy, earning its place in the description.
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 (10 parameters, no output schema) and the richness of the schema descriptions, the description offers only a minimal overview. It does not explain relationships between fields (e.g., when content is generated vs. provided), any expected response, or how this operation integrates with the alias's CardDAV context, leaving gaps for an 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 the schema fully documents all 10 parameters. The description adds minimal semantic value beyond stating that credentials are required, which is already present in the schema. This aligns with 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 is explicit: 'Create a contact for an alias (CardDAV).' It identifies a specific verb (create), a resource (contact), and a context (alias, CardDAV), distinguishing it clearly from sibling tools like contact_update and contact_delete.
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 explicit guidance on when to use this tool versus alternatives. It states a prerequisite ('Requires alias credentials') but does not mention when to prefer contact_create over contact_update or how to interact with associated operations. The usage is implied only by the tool's name.
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 merely says 'Delete' without disclosing the permanence of the action, impact on catch-all email routing, required permissions, or any side effects. This is a significant gap for a destructive 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 a single, focused sentence with no unnecessary words. It is appropriately concise for a simple delete operation.
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 lack of annotations, the description is too sparse. It doesn't mention the destructive nature, reversibility, or downstream effects on catch-all functionality, leaving the agent without essential context for a delete 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 covers both parameters with descriptions (domain, token_id), so the description doesn't need to elaborate. It adds no additional meaning but meets the baseline 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 action (delete) and the specific resource (domain-wide catch-all password). It distinguishes this from sibling tools like domain_catchall_password_create and domain_catchall_passwords_list by naming the delete operation explicitly.
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, nor any prerequisites or context. It simply states what the tool does without explaining when deletion should be performed or what conditions apply.
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 are absent, so the description carries the full burden of behavioral disclosure. It only states 'Create a new domain' without mentioning side effects, verification requirements, or that the domain may not be active immediately. 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 a single concise sentence with no fluff. It front-loads the action and resource, making it easy to scan.
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 11 parameters and no output schema or annotations, this tool is complex, yet the description is only one sentence. It does not explain return values, verification flow, or behavioral implications, leaving significant gaps for an agent to understand the full 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?
Schema description coverage is 100%, and each parameter has a clear schema description. The tool description adds no extra meaning beyond the schema, so 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's action ('Create a new domain') and identifies the resource (domain in ForwardEmail account). It distinguishes from sibling tools like domain_update and domain_delete by explicitly focusing on creation.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, prerequisites (e.g., domain ownership verification), or exclusions. It simply states the action without 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?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Delete' implies a destructive operation, but the description does not state whether the action is permanent, reversible, or what effects it may have on mail filtering. No associated side effects or authentication requirements are mentioned.
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, clear sentence with no filler or redundant information. It is concise and front-loaded, stating the action and target immediately. Every word is meaningful.
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?
Despite having a simple parameter set and no output schema, the tool is a destructive operation with no annotations. The description does not specify that deletion is permanent, whether there are any cascading effects, or any error conditions. For a delete tool, this is insufficient context for an agent to safely invoke 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 input schema fully describes all three parameters (domain, alias_id, script_id) with 100% coverage, so the schema carries the main load. The description does not add any additional semantic details beyond what is already in the schema, such as accepted formats or relationships between parameters. 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 'Delete a Sieve filtering script for an alias' uses a specific verb and resource, clearly indicating what the tool does. It includes the qualifier 'for an alias,' which helps distinguish this from the sibling tool 'sieve_script_delete' by implying an alias-scoped deletion, though it does not explicitly name the alternative.
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. There is no mention of exclusions, prerequisites, or that this is the alias-scoped counterpart to the general 'sieve_script_delete'. It is merely a statement of function without 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?
With no annotations available, the description carries the full burden of behavioral disclosure. It mentions 'send' and 'SMTP API', which implies immediate delivery, but it does not disclose side effects, failure modes, authentication requirements, or irreversibility. The description adds minimal context beyond the basic 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 a single, front-loaded sentence that conveys the core purpose without unnecessary words. Every word earns its place, making it appropriately concise and well-structured.
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 (9 parameters, 2 required, no output schema, no annotations), the description is severely underspecified. It lacks information about success/failure responses, prerequisites (e.g., from_addr must be a controlled alias), or any behavioral nuances. This is a minimal summary rather than a complete guide.
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 all parameters with 100% description coverage, so the tool description doesn't need to repeat parameter details. The description adds no extra meaning beyond the schema, but the schema itself is clear and self-sufficient, 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 a specific action ('Create and send') on a specific resource ('outbound email') with a transport method ('via SMTP API'). This distinguishes it from sibling tools like email_get or email_delete. It's unambiguous and informative.
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 provided on when to use this tool versus alternatives such as message_create or other email-related tools. The description gives no context for prioritization or exclusions, leaving the agent to infer usage from the name alone.
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 does not mention whether the deletion is irreversible, what permissions are required, or potential side effects on related data. As a destructive operation, this is a significant omission.
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: 'Remove a member from a domain.' It is front-loaded, direct, and contains no unnecessary words or filler, making it highly concise.
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?
The tool is simple with two well-described parameters, but the absence of annotations and the minimal description leave gaps: no return value explanation, no error handling, no clarification of soft vs. hard delete, and no usage context. This falls short for a destructive operation in a domain management 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?
Schema description coverage is 100%, with both parameters described ('Domain name' and 'Member ID to remove'). The tool description adds no additional meaning beyond restating the action, 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 uses a specific verb 'Remove' with a clear resource 'member' and scope 'from a domain'. It is concise and distinguishes this from sibling delete tools (e.g., contact_delete, email_delete) by specifying the domain-member context.
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, nor any prerequisites or exclusions. It simply states the action, leaving the agent to infer usage from the name and sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action ('Update') but does not mention any side effects, required permissions, reversibility, or behavior regarding existing sessions or privileges. 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, clear sentence with no wasted words. It is appropriately sized for a simple update tool, though slightly under-specified in terms of context. The structure is front-loaded and readable.
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, and the schema covers all parameters. However, with no output schema and no annotations, the description does not explain return values, side effects, or any preconditions. It is minimally viable but lacks contextual details that would fully inform the 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 the schema already documents all three parameters clearly. The description adds the word 'role' which aligns with the 'group' parameter, but does not provide additional syntax or format details 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 uses a specific verb ('Update') and identifies the resource ('domain member's role'), clearly distinguishing it from sibling member_delete. The action is unambiguous and directly reflects the tool's purpose.
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 explicit guidance on when to use this tool or when to use an alternative. It does not mention that this is for role changes only, nor does it reference sibling tools like member_delete for removal. Usage is only implicitly conveyed by the verb.
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 the credential requirement, which is already evident from the schema. It does not disclose the default response format, what the boolean parameters (eml, raw, nodemailer, attachments) do collectively, or whether the operation is read-only. The word 'Get' implies read-only but this is not made explicit.
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 directly states the action and a key requirement. It contains no filler or redundant information, earning a high score for conciseness.
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?
There is no output schema, so the description should explain what the response looks like. It does not mention that the return format is controlled by boolean flags like eml, raw, or attachments. It also lacks any indication of error behavior or how this tool relates to sibling message/email tools, leaving the agent under-informed for a 7-parameter 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% coverage with descriptions for all seven parameters, including notes like 'Alias password from the alias_generate_password tool'. The description adds no parameter-specific meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Get a specific message for an alias (IMAP).' This specifies the verb (get), the resource (message), and the scope (alias, IMAP). It distinguishes from siblings like email_get by targeting alias mailboxes, though it does not explicitly name alternatives.
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 it (for retrieving a specific message from an alias via IMAP) and includes a prerequisite ('Requires alias credentials'). However, it offers no explicit guidance on when not to use it or which alternative tools might be more appropriate, such as email_get or messages_list.
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 adds useful context: the requirement for alias credentials and the IMAP protocol. However, it does not explicitly state that the operation is read-only, nor does it describe any side effects, performance implications, or return behavior. The credential requirement is a positive disclosure, but the overall behavioral 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 exceptionally concise: two short sentences that immediately convey the core purpose and a key prerequisite. Every word earns its place, with no filler or redundancy. It is front-loaded with the action and scope, making it easy to scan.
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?
The tool is complex (16 parameters, nested objects) and has no output schema, yet the description provides only a terse overview. It fails to explain return values, pagination behavior, the lightweight mode, or how the many filters interact. The absence of these details leaves the agent with insufficient information to fully understand the tool's capabilities and response format.
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 input schema already documents all 16 parameters in detail. The description itself adds no parameter-specific semantics beyond the general 'list/search' verb. As per the baseline for high schema coverage, a score of 3 is appropriate; the description neither enhances nor detracts from the schema.
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 clearly states the tool's function: 'List and search messages for an alias (IMAP).' This identifies a specific verb ('list/search'), a resource ('messages'), and a scope ('for an alias'). It distinguishes itself from sibling tools like emails_list by specifying the alias context and IMAP protocol, though it does not explicitly name alternatives.
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 a prerequisite ('Requires alias credentials') but no direct guidance on when to use this tool versus siblings. It does not mention alternatives like emails_list or explain scenarios where this tool is preferred. The usage context is only implied by the phrase 'for an alias,' which is insufficient for choosing among sibling 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?
No annotations are provided, so the description carries the full burden. It discloses the need for alias credentials but does not mention other behavioral traits such as expected return value, validation, or side effects. The write nature of the operation is only implied by the verb 'create'.
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 concise with a single sentence that communicates the core purpose and a key prerequisite. It is appropriately sized for a create operation, though it could have used an extra sentence for guidance or return value.
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?
The tool has no output schema, so the description should explain the return value or success criteria, but it does not. It also lacks context about CalDAV-specific behavior or the relationship to calendars_list/calendar_get. The description is minimal and leaves the agent to infer too much.
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, but the 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 uses a specific verb and resource ('Create a calendar event') and distinguishes from sibling tools like calendar_event_update and calendar_event_delete. The mention of 'for an alias (CalDAV)' clarifies the target context.
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 creating a new calendar event and explicitly states a prerequisite ('Requires alias credentials'). However, it does not provide explicit alternatives or exclusionary guidance, such as pointing to calendar_event_update for existing events.
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, the description carries the full burden of behavioral disclosure. It mentions the credential requirement and the CalDAV protocol, but does not indicate whether the operation is read-only, what the return format is, or how errors like 'not found' are handled. This is a significant gap for a get 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 two concise sentences with no filler. It immediately states the action and resource, then adds the key prerequisite. 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?
For a simple 3-parameter get tool, the description is minimally adequate. It covers the core purpose and a critical requirement, but lacks information about response format, error behavior, or any side effects. Since there is no output schema and no annotations, slightly more detail 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?
Schema coverage is 100% for all three parameters, so the description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate, as the description does not compromise on parameter clarity but also does not enrich 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 clearly states the verb ('Get') and the resource ('a specific calendar event'), effectively distinguishing it from sibling tools like calendar_events_list, calendar_event_create, and calendar_event_delete. Mentioning 'for an alias (CalDAV)' adds useful context about the domain.
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 only a prerequisite ('Requires alias credentials') but no explicit guidance on when to use this tool instead of alternatives like calendar_events_list (when listing) or calendar_event_update (when modifying). It implies the need for an event_id but does not state it as a usage condition.
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 only states 'Get' without explicitly confirming the operation is read-only, mentioning any required permissions, or describing potential errors or side effects. While 'Get' implies retrieval, it does not disclose enough behavioral context for safe and complete understanding.
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, direct sentence that immediately conveys the tool's purpose. It contains no redundant words or information, making it highly concise and well-structured for quick agent comprehension.
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 description is adequate for a simple retrieval tool, but it lacks contextual guidance regarding when to use it, how it relates to sibling tools, or any prerequisites. The schema covers parameters, but the absence of annotations and usage notes leaves some gaps in completeness, earning a mid-level score.
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 (domain, alias_id, script_id), so the schema already provides the necessary semantics. The tool description adds no additional parameter information, aligning with the baseline score of 3 when schema coverage is high.
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 specific resource ('a specific Sieve filtering script for an alias'). It is unambiguous and distinguishes itself from siblings like domain_sieve_list (list) and sieve_script_get by specifying the alias scope, making the purpose immediately clear.
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 such as domain_sieve_list or sieve_script_get. There are no explicit when-to-use or when-not-to-use instructions, and no exclusion criteria are mentioned, leaving the agent to infer usage purely from the name and schema.
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 full burden for behavioral disclosure. 'Verify' implies a read-only operation, but it does not state what happens (e.g., whether records are checked for existence, correctness, or ownership) or what the response looks like. No details about permissions or side effects are 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 concise sentence, front-loaded with the verb 'Verify' and immediately stating the resource. Every word earns its place with no waste.
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 (one parameter, no output schema), but the description still lacks detail about what 'verify' entails or what the return value indicates. It names record types (MX, TXT) but does not explain the verification criteria or expected response, leaving moderate ambiguity for an 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?
The schema covers 100% of parameters with a description for 'domain' ('Domain name to verify'). The tool description adds little beyond restating 'for a domain,' so it does not provide extra format details (e.g., FQDN, no protocol). Baseline 3 is appropriate given full 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 ('Verify') and identifies the exact resource ('DNS records (MX, TXT)') for a domain. This clearly differentiates it from the sibling tool domain_verify_smtp, which verifies SMTP instead.
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. It does not mention domain_verify_smtp or any other related tools, nor does it state prerequisites 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 are provided, and the description only states 'Requires alias credentials,' which is already documented in the schema. It does not disclose return format, error behavior, or side effects. For a read-only operation, the read-only nature is implied but not 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 short sentences, with the purpose front-loaded. There is no redundant or unnecessary text.
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 there is no output schema and no annotations, the description should at least mention what the tool returns (e.g., the Sieve script content) or clarify when to use it. It simply states the action and credential requirement, leaving gaps in context. However, for a simple get operation, it is 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?
All three parameters have detailed descriptions in the schema (including an example for alias_username and a cross-reference for alias_password). The description adds no additional parameter-specific information beyond what the schema already provides, so the score is 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 clearly states a specific verb ('Get') and resource ('a specific Sieve script for an alias'), distinguishing it from sibling tools like sieve_scripts_list (list all) and sieve_script_delete. It is unambiguous about the action and target.
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. It mentions that alias credentials are required but does not specify scenarios when to use it or when to prefer e.g., domain_sieve_get. The scope is implied by the name and 'for an alias' but 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 of behavioral disclosure. It only mentions that alias credentials are required, which is already captured by the schema parameter descriptions. It does not explain the effect of updating (e.g., whether ical is required, what happens when omitted, or whether calendar_id moves the event), nor any other runtime 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 exceptionally concise: two short sentences with no filler. It front-loads the core purpose ('Update a calendar event') and includes the key prerequisite ('Requires alias credentials'). Every word earns its place.
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 no output schema and no annotations, the description is too thin. It does not clarify what aspects of an event can be updated (only ical and calendar_id are in the schema, but this is not mentioned), the semantics of updating without ical, or any success/failure indicators. The agent is left to infer behavior from the schema, which is incomplete 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?
The input schema has 100% parameter description coverage, with clear explanations for ical, calendar_id, alias_password, and alias_username. The description adds no additional parameter-level meaning 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 action ('Update') and the resource ('calendar event'), and scopes it to 'for an alias (CalDAV)'. This distinguishes it from sibling tools like calendar_event_create, calendar_event_get, and calendar_event_delete, as well as calendar_update (which updates a calendar, not an event).
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 gives context ('for an alias (CalDAV)') and notes the authentication requirement, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The name and sibling set make the primary use case obvious, but no explicit guidance is given.
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 disclose behavioral traits. It only says 'Requires alias credentials,' which is redundant with the schema's required fields. It does not explicitly state read-only behavior, side effects, or return format.
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 filler. It efficiently conveys purpose and a key requirement.
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?
There is no output schema, so the description should explain what the tool returns and any pagination or ordering behavior. It only states 'List contacts for an alias' and the credential requirement, leaving the agent to infer response shape and 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?
Schema description coverage is 100%, with each parameter already described in the schema. The description adds no additional parameter semantics, 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 verb 'List' with the resource 'contacts' and scopes it to 'an alias', which distinguishes it from siblings like contact_get, contact_create, and aliases_list. Mentioning CardDAV adds useful protocol context.
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: use this to list contacts for an alias. It provides a prerequisite ('Requires alias credentials') but does not explicitly differentiate it from contact_get or other listing tools. No alternatives or exclusions 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?
With no annotations, the description carries the full burden of behavioral disclosure. 'Create' implies mutation, but nothing is said about whether an existing catch-all password is overwritten, what permissions are required, or what the response contains. This is a significant gap for a create 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 a single, concise sentence that communicates the core purpose efficiently. It earns its place with no superfluous wording.
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?
The tool has no output schema and no annotations, so the description should compensate by explaining return values and side effects. It does not mention what the tool returns (e.g., the created password) or whether it replaces an existing catch-all password, leaving the agent under-informed.
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. The description adds no extra semantic meaning beyond the schema; it simply restates the context of the password. 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 and resource: 'Create a domain-wide catch-all password' and even clarifies its purpose 'for IMAP/SMTP access.' This clearly distinguishes it from sibling tools like delete or list.
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 (for domain-wide catch-all access) but does not explicitly state exclusions or alternatives. It does not mention that alias_generate_password might be an alternative for generating passwords for specific aliases, leaving the agent to infer from the name.
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 says 'List', which implies a read-only operation, but there is no mention of return format, pagination, permissions, or any side effects. Minimal behavioral context is disclosed.
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: 'List domain-wide catch-all passwords.' It is concise, front-loaded with the action verb, and contains no unnecessary 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?
The tool is simple (one parameter, no output schema, no nested objects), and the description covers the core purpose. However, with no annotations, it could further explain that this is a read-only operation and what data is returned, though for a list tool this is fairly self-evident.
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 has 100% coverage for the single parameter 'domain' with description 'Domain name', so the baseline is 3. The tool description adds no additional meaning beyond the schema, but the schema itself is sufficient for understanding the parameter.
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 ('List') and the resource ('domain-wide catch-all passwords'), which precisely identifies what the tool does. This distinguishes it from sibling tools that create or delete catch-all passwords.
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 usage context or guidance is provided. The description does not indicate when to use this tool vs alternatives, nor any prerequisites or conditions. The one-line description implies a simple read operation, but no explicit guidance is given.
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 for behavioral disclosure. It merely states the action (delete) without revealing that deletion is likely irreversible, what happens to associated data (mailboxes, aliases), or any permission requirements. This is a significant gap for a destructive 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 a single, well-structured sentence that is front-loaded with the action and object. It contains no redundant words and earns its place without verbosity.
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 one fully documented parameter and no output schema, but the description is minimal. It states the basic action but lacks details about the deletion's permanence or cascading effects, which are important for a destructive tool. Annotations or more context 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 has full coverage for the single parameter 'domain' with its description ('Domain name or ID to delete'), so the schema already provides necessary semantics. The description adds no extra param detail, which is acceptable per the baseline 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 (Delete) and resource (domain) with clear scope ('from your account'). It distinguishes the tool from siblings like domain_create, domain_get, and domain_update by stating the delete action explicitly.
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 removing a domain but provides no explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or consequences. The purpose is self-evident, but no exclusions or alternative recommendations are given.
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 full behavioral burden. It only says 'Get details', which implies a read operation, but does not disclose whether permissions are required, what response format to expect, how errors like missing domains are handled, or any rate limits or side effects. This is minimal behavioral 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?
A single, concise sentence that is front-loaded with the key action and object. No filler or redundancy, 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 one well-schemaed parameter, so a minimal description might suffice. However, without an output schema, 'details' is vague—it does not specify what fields or information will be returned, nor what happens if the domain is not found. This leaves a meaningful gap in understanding the tool's complete 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 already describes the only parameter 'domain' as 'Domain name or ID' with 100% coverage. The description's phrase 'specific domain' adds no additional semantic detail beyond the schema, so the schema-driven 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?
Description clearly states the action (Get) and resource (specific domain), distinguishing it from sibling tools like domains_list (which lists domains) and domain_create/update/delete (which modify domains). The singular 'specific domain' reinforces its one-object retrieval 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?
No explicit usage guidance is given. The intended use is implied by the name and singular parameter: to fetch details for one domain. However, it does not mention alternatives such as domains_list for listing all domains or domain_update for modifying, so guidance is only 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?
With no annotations provided, the description carries the burden. 'Get' clearly indicates a read-only operation, but it does not disclose potential errors, authentication needs, or response format. For a simple get operation this is adequate, if minimal.
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 front-loaded with the key action and target. Perfectly concise with 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?
Given the simplicity of a get-alias operation, the description is sufficient. It does not describe the return value in detail since there is no output schema, but 'details' reasonably implies the response. Enough for a straightforward CRUD read.
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 'domain' and 'alias_id' described. The description adds no extra meaning beyond the schema, 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 details of a specific alias' uses a specific verb and resource, clearly indicating a read operation for one alias. It distinguishes from siblings like aliases_list (which lists all) and alias_create/update/delete (mutations).
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. It does not explicitly mention aliases_list for listing all aliases or any other context, leaving usage entirely implied.
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 the essential mutating behavior (delete) and an auth requirement, which is useful. However, it does not explain permanence, side effects, or result behavior, leaving the agent without a full picture.
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 sentences, each earning its place. It is front-loaded with the action and resource, making it easy to scan. No filler or redundant wording.
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 delete operation with a fully described schema, the description provides adequate context: what is deleted, for whom, and what credentials are needed. It omits details about return values or error cases, but these are less critical for a delete 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 baseline is 3. The description adds no extra meaning beyond restating that alias credentials are required; contact_id and alias_username are already well-described 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 action (Delete) and resource (a contact for an alias), with additional protocol context (CardDAV). This distinguishes it from sibling tools like contact_update, contact_get, and alias_delete, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that contact_update should be used for modifications, or that deletion is irreversible. The only context added is the credential requirement, which is a prerequisite rather than a usage guideline.
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, the description carries the full burden. It only discloses the credential requirement and CardDAV protocol, but fails to mention whether the update is partial or full replacement, side effects, or return behavior. 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 concise sentences, front-loaded with purpose and followed by the key prerequisite. 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 has 9 parameters, an output schema is absent, and no annotations are provided, the description is too minimal. It does not explain how updates are applied (e.g., field merging) or what the response contains, leaving the agent uncertain about 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?
Schema coverage is 100%, so the baseline is 3. The description adds minimal context (alias, CardDAV) but does not explain parameter semantics 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 states a specific verb ('Update'), resource ('contact'), and scope ('for an alias (CardDAV)'). This clearly distinguishes it from sibling tools like contact_create, contact_delete, and alias_update.
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 by indicating this tool operates on contacts within an alias and requires alias credentials. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer appropriate use.
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 transparency burden. It does disclose key behavior via 'Replace' and 'clear', implying a destructive overwrite. However, it omits permissions, reversibility, and side effects beyond the basic replace 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 two short sentences with no redundant information. It front-loads the core action and adds a clear usage tip, making every word earn 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 replace tool with complete parameter schema, the description covers the essential behavior. It does not include alternative guidance or prerequisites, but this is partly mitigated by the explicit name and sibling list. A small gap remains regarding when to prefer this over denylist update.
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 both 'domain' and 'allowlist' already documented in the input schema. The description adds no new parameter meaning beyond reinforcing the empty-list-clears behavior already stated in the allowlist parameter 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 'Replace a domain's sender allowlist' with a specific verb and resource. It distinguishes itself from sibling tools like domain_denylist_update and domain_update by explicitly naming the 'sender allowlist' as the target.
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. The phrase 'Pass an empty list to clear it' is a usage tip but does not help an agent decide between this and domain_denylist_update or other domain update 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?
No annotations are provided, so the description must disclose side effects. It only states the test involves credentials and bucket access, but doesn't indicate whether the operation is read-only, what success/failure looks like, or any prerequisites. This is insufficient for a testing 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 a single, front-loaded sentence that directly conveys the tool's purpose. 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?
The tool has no output schema and no annotations, so the description should explain return behavior or side effects. It only covers the purpose, leaving the agent guessing about test results. For a simple tool, this is a significant 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?
The single parameter 'domain' is fully documented in the schema with 'Domain name or ID'. The description adds no additional parameter meaning, meeting the baseline 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 tests a domain's custom S3 storage connection, specifying 'credentials and bucket access'. This distinguishes it from sibling tools like domain_verify_smtp and domain_verify_records.
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 clear context for when to use this tool – to test S3 connectivity – but doesn't explicitly mention alternatives or exclusions. The purpose itself implies the appropriate use case, so it's not misleading.
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 disclosing behavioral traits. It only notes a prerequisite (credentials) and the protocol (IMAP), but does not describe side effects, idempotency, error behavior, or what happens if the folder already exists. 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 two short sentences, front-loaded with the core purpose and immediately followed by the key requirement. Every word earns its place; no 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?
Given the tool's low complexity, the rich schema for parameters, and the absence of an output schema, the description covers the essential purpose and a key prerequisite. It falls short of explaining return values or edge-case behavior, but it is adequate for a straightforward create 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 (path, alias_username, alias_password) having a clear description in the schema. The tool description itself adds no parameter-level semantics, 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 a specific action ('Create a folder') and a resource ('for an alias (IMAP)'), which distinguishes it from sibling folder tools like folder_update, folder_delete, and folders_list. The inclusion of 'IMAP' further clarifies the 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 mentions a prerequisite ('Requires alias credentials') but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The usage context is implied rather than explicit, with no reference to sibling operations like folder_update or folder_delete.
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, the description carries full burden for behavioral disclosure. It only mentions the need for alias credentials, but does not disclose potential side effects of renaming (e.g., whether it overwrites existing paths, impacts email delivery, or is reversible). 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 a single, well-structured sentence that front-loads the purpose and includes a critical prerequisite. Every word earns its place with no filler.
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?
Despite having all parameters documented, the description is too brief for a mutation tool with no annotations or output schema. It fails to explain what happens on success, any error conditions, or the implications of renaming a folder, leaving the agent under-informed.
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 each parameter is well-documented in the schema. The description adds no additional meaning beyond the schema; it simply restates the tool's purpose. 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 clearly states the action (rename) and the resource (folder for an alias, IMAP). It distinguishes from sibling tools like folder_create and folder_delete by specifying the rename operation.
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 clear context that this tool is for renaming folders on an alias, which implicitly differentiates from other folder operations. It also mentions the credential requirement, but does not explicitly state when not to use it or mention alternatives.
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 only states the action without revealing side effects, whether the invite is consumed, reversibility, or any required auth context. This is a significant gap for a tool that performs a state-changing 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 a single sentence, front-loaded with the verb, and contains no extraneous words. It is optimally concise while conveying the core purpose.
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 (two simple parameters with full schema descriptions, no output schema), the description is mostly adequate. However, the absence of annotations and any mention of post-acceptance effects leaves a small gap, but not enough to significantly impair an agent's ability to use 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?
Schema description coverage is 100%: both 'domain' and 'token' have clear descriptions in the schema. The tool description itself adds no additional parameter semantics, but the schema already covers the meaning adequately, warranting a 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 the action: 'Accept a domain invite that was sent to you.' It uses a specific verb (accept) and resource (domain invite), which distinguishes it from sibling tools like invite_create and invite_delete. The purpose is immediately understandable.
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 phrase 'that was sent to you' implies the tool is for when the agent has received an invite, providing some usage context. However, it does not explicitly state when to use this tool over alternatives, nor any exclusions or prerequisites.
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 and does well by disclosing that logs are emailed as a gzip-compressed CSV attachment and that there is a daily limit. It communicates the asynchronous, non-immediate delivery and rate-limiting, which are important behavioral traits. It doesn't mention any other side effects, but the main constraints are disclosed.
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 short sentences, each providing distinct useful information: the action, the delivery format, and the rate limit. It is front-loaded with the core purpose and has no filler 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 request-style tool with no output schema, the description covers the essential behavior and constraints. The only notable gap is the lack of specificity about which logs are covered, which is left to the tool name and context. Overall, it is sufficiently complete for an agent to understand the outcome.
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 both parameters, so the schema already explains 'query' and 'domain' clearly. The tool description adds no additional parameter details or examples beyond what the schema provides, meeting the baseline but not exceeding it.
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 'Request a log download' with a clear verb and resource, and describes the delivery format (gzip-compressed CSV). However, it doesn't specify which logs are being downloaded (e.g., email logs, domain logs), leaving some ambiguity in scope. There are no direct sibling log tools to distinguish from, but more specificity would improve clarity.
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 explicit guidance on when to use this tool over alternatives, nor any prerequisites or exclusions. It only states the action and constraints (e.g., 'Limited to 10 requests per day'), so the usage context is not addressed.
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 adds useful context about auth requirements and the CalDAV protocol, but doesn't disclose other traits such as return values, error behavior, or idempotency. This leaves significant behavioral aspects undocumented.
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 communicates the core purpose and a key prerequisite with zero wasted words. It is appropriately sized for the tool's simplicity.
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 has 8 parameters and no output schema, the description is minimal. It omits any mention of return values or expected response format, and doesn't clarify whether the optional parameters affect behavior. The schema covers parameter meanings, but the description doesn't fill the gap for post-creation behavior or outcomes.
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 every parameter having a description. The tool description adds no extra parameter details beyond what the schema already 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 uses a specific verb ('Create') with a clear resource ('calendar'), target ('alias'), and protocol ('CalDAV'). This distinguishes it from sibling tools like calendar_get, calendar_update, and calendar_delete, making 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an alias' provides context on the intended scope, and 'Requires alias credentials' identifies a prerequisite. However, it doesn't explicitly state when to use this versus alternatives (e.g., calendar_update) or mention any exclusions, so usage guidance is implied rather than directly stated.
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 discloses the authentication requirement and protocol (CardDAV), but lacks details on return format, error behavior, or explicitly confirming it's a read-only operation. Some context is added, 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 short sentences, front-loaded with the core action. Every word is purposeful, and there is no filler or redundancy.
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?
For a simple get operation, the description covers the essentials but omits expected response structure and failure conditions. Since no output schema exists and no annotations are provided, a bit more detail would improve completeness, but the tool is 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%, with each parameter already clearly described (e.g., alias_password sourced from alias_generate_password). The description adds no parameter-specific meaning beyond the schema, 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 uses the specific verb 'Get' with the resource 'specific contact' and scopes it to an alias, clearly distinguishing it from contacts_list and mutation tools like contact_create/update/delete. The mention of CardDAV adds further specification.
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 provides a prerequisite ('Requires alias credentials') but does not explicitly mention when to use this tool versus contacts_list or other alternatives. Usage is implied by 'specific contact' but not elaborated.
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 the authentication requirement and IMAP scope, which is useful. However, it does not explicitly state that the operation is read-only, describe the response format, or mention pagination behavior. The schema already defines credential fields, so the added behavioral insight 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 a single, front-loaded sentence that states the core purpose and a key requirement. Every word earns its place; there is no redundancy or fluff.
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 simplicity and the schema covering parameters, the description is minimally adequate. However, since there is no output schema, the description does not mention what the list returns or details like default pagination or subscription filtering, which could be important for the agent to understand the full 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?
Schema coverage is 100% with clear descriptions for all 5 parameters, so the baseline is 3. The description does not add any additional meaning beyond the schema, but it doesn't need to since the schema is self-sufficient.
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 ('folders for an alias (IMAP)'), clearly distinguishing it from sibling folder operations like folder_create, folder_get, and folder_update. The alias scope and IMAP protocol add precision.
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 usage context is implied: use this when you need to list folders for an alias. However, it does not explicitly state when not to use it or mention alternatives such as folder_get or folders_list with different filters. The credential requirement is a prerequisite but not a usage guideline.
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 mentions the action and the 'pending' constraint, but omits consequences (e.g., irreversibility), required permissions, or behavior for non-pending invites. 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 a single, front-loaded sentence that is immediately clear. Every word earns its place—no fluff or redundancy.
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?
For a simple delete tool, the description is minimally adequate: it states the action and the pending restriction, and the schema covers parameters. However, without an output schema or annotations, it lacks details about return values, errors, or side effects, making it incomplete for full autonomous use.
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 both 'email' and 'domain' fully described in the schema. The description adds no additional semantic 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 clearly states the verb 'Remove/cancel' with a specific resource ('pending domain invite'). It also distinguishes from sibling tools like invite_create and invite_accept by explicitly scoping to pending invites.
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 by specifying 'pending' invites, implying it should be used only for invites not yet accepted. However, it does not explicitly mention alternatives or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that alias credentials are required and that only one script can be active, but it does not explain what happens if another script is already active (e.g., auto-deactivation vs error) or the effects of activation. This is partial 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 two sentences, front-loaded with the core action, and every word adds value. There is no redundancy or filler.
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?
For a simple activation tool with three required parameters and no output schema, the description covers the basic purpose and a key constraint. However, it misses important context such as return value expectations, error behavior when another script is active, and whether the activation is reversible, which would be helpful given the absence of annotations.
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 additional parameter-specific meaning; it simply refers to 'alias credentials' and 'script' without elaborating on the exact parameter usage beyond what the schema already documents.
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 ('Activate') with a clear resource ('a Sieve script for an alias') and adds a distinguishing constraint ('only one can be active'). This clearly differentiates it from sibling tools like sieve_script_create or domain_sieve_activate.
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?
It implies usage context by requiring alias credentials and noting the exclusivity constraint, but it does not explicitly state when to use this over alternatives (e.g., domain_sieve_activate) or mention any preconditions beyond credentials. Some guidance is present, but exclusions are absent.
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, the description carries full burden. It only mentions the credential requirement, but does not disclose what happens on success, whether it overwrites existing scripts, any side effects, or the response format. This is a meaningful gap for a creation 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 concise sentences, front-loaded with the primary action and resource. Every word earns its place, with no redundancy.
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?
For a create tool, the description is minimally adequate but would benefit from clarifying the distinction from domain_sieve_create and the dependency on alias_generate_password. The schema fills in parameter details, but the lack of any note about interaction with other tools (e.g., activation) leaves some context incomplete.
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 only the context that alias_username and alias_password are 'credentials,' but this is already implied by the schema's required fields and descriptions (e.g., 'Alias password from the alias_generate_password tool'). No extra meaning is provided.
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 verb and resource: 'Create a Sieve script for an alias.' This distinguishes it from sibling tools like domain_sieve_create (which targets domain-level scripts) and other sieve_script_* tools (update/delete/activate).
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 'for an alias' clearly indicates the intended use case, and 'Requires alias credentials' provides a necessary prerequisite. While no alternatives are explicitly named, the context is unambiguous enough to differentiate from domain-level operations.
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, the description bears full responsibility for behavioral disclosure. It only mentions the auth prerequisite (Requires alias credentials) and does not describe side effects (though listing is likely read-only), error behavior, pagination, or return format. The description is too superficial for full 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 two sentences, front-loaded with the purpose and followed by the prerequisite. Every word is necessary and there is no redundant information.
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?
For a simple list operation, the description states the action and the authentication requirement. However, it omits details about the output (e.g., script names) and does not clarify the relationship to domain_sieve_list or sieve_script_get. Given no output schema, the description could be more informative, but it is minimally acceptable for a straightforward list 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 parameters are fully documented in the schema. The description adds no additional parameter semantics beyond stating that credentials are required, which is already evident from the schema. The baseline of 3 applies because 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 uses the specific verb 'List' and identifies the resource as 'Sieve scripts' with the scope 'for an alias'. This clearly distinguishes it from sibling tools like domain_sieve_list (domain scope) and sieve_script_get (single script retrieval).
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 'for an alias' provides clear context for when to use this tool, implying alias-level script listing. However, it does not explicitly mention alternatives or exclusions (e.g., domain-level scripts should use domain_sieve_list), which would push it to 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. 'List all aliases' clearly indicates a read-only operation, but it does not mention return format, error handling, or edge cases. The description adds no details beyond the basic purpose.
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 sentences, front-loaded with the core purpose and followed by the key feature support. Every word earns its place, with no redundancy 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 simple list tool with 5 documented parameters, the description conveys the essential purpose, pagination, and search support. It does not have an output schema, but the return value is implicitly a list of aliases. The description is adequate for the tool's complexity, though it could mention the domain-scoped nature more explicitly.
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 mentions pagination and search, which map to page, limit, and query parameters, but it adds no additional meaning beyond what the schema already documents. No compensation needed.
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 a specific resource 'all aliases for a domain', clearly distinguishing it from sibling tools like alias_get (single alias) and alias_create/update/delete. It also highlights pagination and search capabilities, which further define the tool'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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing all aliases for a domain, but it does not explicitly state when to use it versus alternatives (e.g., alias_get for a single alias). There is no when-not guidance or comparison with sibling list tools.
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 disclosure. It does disclose that the tool supports pagination and search, and it scopes the operation to the user's account. However, it omits details like the return format, sorting behavior (despite the sort parameter), or any explicit read-only intent beyond the verb 'list'. Some key behavioral aspects are left to inference.
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 sentences with no filler or redundancy. It front-loads the core purpose and adds the most notable capability (pagination and search) efficiently. Every word contributes value.
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 list operation with well-defined optional parameters and no output schema, the description is mostly sufficient. However, it omits mentioning the sort parameter, does not describe the response structure, and does not reference sibling tools for alternative use cases. A slightly richer description would make 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 schema already documents all four parameters. The description only vaguely mentions 'pagination and search' which corresponds to page/limit/query but adds no new detail beyond what the schema provides, and it does not mention sorting. This matches the baseline score of 3 for full 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 action ('List') and resource ('domains in your ForwardEmail account'), which distinguishes it from sibling tools like domain_get (for a single domain) or domain_create/update/delete. The scope is precise 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 for retrieving all domains in the account, but it does not explicitly mention when to use this tool over alternatives like domain_get, nor does it state any exclusions or limitations (e.g., when not to use). The context is clear but lacks explicit guidance beyond the obvious list-vs-single distinction.
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 behavioral disclosure. It mentions that the return includes body and headers, but does not elaborate on error handling, permissions, or any potential side effects. For a simple read operation, 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 a single sentence that is front-loaded with the main verb and resource. Every word earns its place, and there is 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?
For a tool with one parameter and no output schema, the description provides a reasonable overview. It explicitly mentions body and headers, and 'full details' implies comprehensive coverage. However, it could be slightly more specific about other returned fields or possible errors, but given the simplicity, it is 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%, so the baseline is 3. The tool description adds minimal context by specifying 'outbound email', which clarifies that email_id refers to an outbound email, but does not add further semantic 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 uses a specific verb ('Get') and a specific resource ('outbound email'), and states the scope ('full details including message body and headers'). This clearly distinguishes it from sibling tools like emails_list or email_delete.
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 (to retrieve full email details), but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over similar tools like messages_get or emails_list.
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 behavior. It does add the auth requirement and the IMAP protocol, which are useful. However, it does not explicitly state that the operation is read-only or describe error behavior (e.g., what happens if the folder ID is invalid). The 'Get' verb implies non-destructive behavior but this is not stated outright.
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. It includes only essential information (purpose, protocol, and credential requirement) with no fluff or redundant 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?
Given the tool's simplicity (3 params, no output schema) and the schema's thorough parameter documentation, the description covers the main purpose, protocol, and a key prerequisite. It could be slightly improved by explicitly stating what is returned (e.g., the folder object) or how errors are surfaced, but it is mostly complete for a straightforward fetch 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 has 100% description coverage, with each parameter already well-documented: folder_id, alias_username, and alias_password have clear descriptions. The description's mention of 'alias credentials' adds no new meaning beyond what the schema provides, so it simply meets the baseline for a fully documented 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 specific folder for an alias'), with the qualifier '(IMAP)' adding protocol context. It distinguishes itself from sibling tools like folders_list (which lists all folders) and folder_create/update/delete (mutations) by focusing on a single fetch 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 when to use the tool (when you need a specific folder by ID) and states a prerequisite ('Requires alias credentials'). However, it does not explicitly exclude alternatives or mention related tools such as folders_list or folder_get variants, so guidance is more implicit than direct.
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 of disclosing behavioral traits. It does mention the need for alias credentials, which is a key auth requirement, but it does not disclose other behavioral aspects such as idempotency, partial vs full update, or potential side effects. This is adequate but leaves 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 extremely concise at two sentences, front-loaded with the action and resource. Every word adds value: the verb, the resource, the protocol note, and the credential requirement. No filler or redundancy.
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?
For a mutation tool with 8 parameters and no annotations or output schema, the description provides the essential context (update calendar for alias, needs credentials) but does not elaborate on update semantics, field applicability, or error conditions. The schema covers parameter details, so the description is minimally sufficient but not comprehensive.
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 the baseline is 3. The description adds no parameter-specific meanings beyond what the schema already provides, though it does reinforce that alias_username and alias_password are required for authentication. No extra semantics are introduced.
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 specifies the action 'Update' and the resource 'calendar for an alias (CalDAV)', distinguishing it from sibling calendar tools like calendar_create, calendar_get, and calendar_delete. The scope is precise 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?
It provides clear context: the tool updates a calendar for an alias and explicitly requires alias credentials. However, it does not mention when to prefer this over alternatives or exclude cases, so it stops short of full usage guidance.
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 behavioral disclosure. It does specify that the tool checks DKIM, Return-Path, and DMARC records, which is a useful behavioral detail. However, it does not disclose the mechanism (e.g., DNS lookup vs. sending a test email), whether it is read-only, or what the output format looks like, leaving some ambiguity.
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 any redundancy. It is concise and easy to scan.
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 one parameter and no output schema or annotations. The description covers the core purpose but omits details about the result format or success criteria. For a verification tool, knowing the output structure (e.g., per-record pass/fail status) would improve completeness, but given the simplicity, the current description is minimally viable.
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 description for the only parameter 'domain' is 100% covered, so the baseline is 3. The tool description does not add any extra meaning about the parameter format, validation, or examples, but it does contextualize what verification is performed on the domain.
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 verifies SMTP records (DKIM, Return-Path, DMARC) for outbound email. It uses a specific verb ('verify') and resource ('SMTP records'), and explicitly lists the record types, which distinguishes it from the sibling tool domain_verify_records that likely handles general DNS records.
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 clear context for when to use this tool: when you need to verify SMTP-related DNS records for outbound email. However, it does not explicitly mention alternatives or when not to use it, such as pointing to domain_verify_records for general DNS verification, but the scope is sufficiently clear.
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, the description must disclose behavioral traits on its own. It only says 'encrypt' and gives the purpose, but does not mention the encryption algorithm, whether it is reversible, what the output format is, or any potential side effects. This is a significant gap for a tool that takes an input and returns a value.
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 that front-load the primary action and purpose. It contains no filler or repetition, making it easy to parse.
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?
For a simple one-parameter tool, the description explains the purpose adequately, but the lack of any information about the return value is a notable omission, especially since there is no output schema. The agent knows what it encrypts but not what it receives in return.
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 'input' parameter as 'The value to encrypt (e.g., an email address)'. The tool description adds context by connecting it to TXT records and forwarding addresses, enriching the parameter's 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 ('Encrypt'), the resource ('TXT record value'), and the domain ('for use in DNS'). It also implies a specific use case ('forwarding addresses in DNS records'), distinguishing it from sibling tools that manage domains, aliases, or email records.
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 context: encoding forwarding addresses for DNS TXT records. Although it does not explicitly list exclusions or alternatives, the tool is unique among siblings, and the intended use case is evident.
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 for behavioral disclosure. It does reveal that the operation deletes both the calendar and its events, and that credentials are required. However, it does not state that deletion is permanent, whether there are any safety checks, or any other side effects beyond events.
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 of 14 words, front-loaded with the action and essential scope. Every word 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with three clearly defined parameters, the description is reasonably complete. It explains the destructive scope (calendar + events), the required credential context, and the protocol (CalDAV). It lacks explicit mention of response behavior or error cases, but no output schema exists and the operation is straightforward.
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 the schema already fully describes the parameters. The description adds a general note about requiring alias credentials but does not provide additional detail per parameter beyond what the schema offers, keeping the baseline at 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 ('Delete') with a resource ('a calendar and its events') and scope ('for an alias'), clearly distinguishing it from calendar_get, calendar_update, and other calendar 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 clearly implies use when a calendar and its associated events should be removed, and notes the prerequisite of alias credentials. It does not explicitly mention alternatives or exclusions, but the context is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds non-obvious context by stating 'CalDAV, soft delete' and 'Requires alias credentials', which informs the agent about the deletion mechanism and authentication requirements. However, it does not explain the implications of soft delete (e.g., recoverability) or the response format.
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 action, scope, protocol, and authentication requirement without unnecessary words. Every word adds value, 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 delete operation, the description provides the core necessary information: what it does, scope, protocol, soft-delete behavior, and auth requirements. While it could mention return values or the consequences of soft delete, the absence is not a major gap given the tool's simplicity and the presence of sibling tool descriptions for 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?
Schema description coverage is 100%, with all three parameters (alias_username, alias_password, event_id) already described in the schema. The description does not add significant semantic detail beyond the schema, and the mention of 'alias credentials' aligns with the schema fields. Baseline 3 is appropriate given 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 'Delete a calendar event for an alias', using a specific verb and resource. It also specifies the scope ('for an alias') and distinguishes itself from sibling tools like calendar_event_update and calendar_event_create by indicating the delete 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 provides a prerequisite ('Requires alias credentials') and implies the tool is used for deleting calendar events. However, it does not explicitly contrast it with alternatives or specify when not to use it. The context is clear but exclusions and alternative selection guidance are missing.
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 must carry the transparency burden. It discloses authentication requirements (alias credentials) and protocol (CalDAV). However, it does not explicitly state that this is a read-only operation, the return format, or any side effects; the verb 'Get' implies read-only, but the description could add more 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, focused sentence that immediately conveys the tool's purpose and a key prerequisite. No filler or redundant 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 get tool, the description covers the essential purpose and authentication. However, it omits what the response contains (e.g., the calendar object details) and does not explicitly contrast with calendars_list. Given the simplicity of the operation, this is adequate but not 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 coverage is 100%, so baseline is 3. The description adds only minimal context beyond schema: it mentions alias credentials, which maps to alias_username and alias_password, but does not elaborate on calendar_id or parameter formats. The schema already describes the parameters adequately.
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'), the resource ('specific calendar'), and the scope ('for an alias (CalDAV)'). It distinguishes itself from sibling tools like calendars_list (list all) and calendar_create/update/delete (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 implies when to use this tool (when retrieving a specific calendar) and notes the prerequisite of alias credentials. It does not explicitly name alternative tools like calendars_list for listing, but the phrase 'specific calendar' gives clear contextual guidance.
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 behavioral disclosure. It does mention the auth requirement ('Requires alias credentials') and protocol (CalDAV), which is useful. However, it does not explicitly state that this is a read-only operation or describe pagination behavior, though 'list' implies read-only. Some context is provided but not exhaustive.
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, short sentence that front-loads the purpose and then states the prerequisite. Every word earns its place with no redundancy 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 simple list tool with minimal parameters and no output schema, the description covers the essential context: what it lists and the required credentials. The schema handles parameter details, so the description is sufficiently complete, though it could optionally mention pagination or response format in text.
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 all parameters (page, limit, alias_username, alias_password) described. The description adds no additional parameter semantics 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 clearly states the tool's function: 'List calendars for an alias (CalDAV)'. It uses a specific verb 'list', a resource 'calendars', and a scope 'for an alias', making it distinct from sibling calendar tools like calendar_get or calendar_events_list.
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 usage by specifying that it lists calendars for an alias and explicitly requires alias credentials. This gives the agent a prerequisite and clear context, though it does not mention alternatives (likely unnecessary as this is the only calendar-list tool among 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the important behavioral trait that only one script can be active, which implies activating a new one may deactivate the previous. However, it does not explain the exact consequences (e.g., error vs. replacement), permissions required, or return behavior, leaving room for ambiguity.
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, efficient sentence that front-loads the action and object. It contains no filler and every word adds value, making it highly concise and appropriately 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?
This is a simple activation tool with three parameters and no output schema. The description covers the core action and the key constraint, which is sufficient for basic understanding. It omits details like return values or error cases, but for a straightforward operation, the level of completeness is 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 input schema already covers all three parameters with clear descriptions (domain, alias_id, script_id), achieving 100% coverage. The description does not add additional semantic meaning beyond what the schema provides, so it meets 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 (Activate) and clearly identifies the resource (Sieve filtering script for an alias) and a key constraint (only one can be active). This distinguishes it from sibling tools like domain_sieve_get/update/delete and sieve_script_activate, which operate on different scopes or actions.
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 clear context by specifying the tool is for an alias and notes the exclusivity constraint, which implies the use case of activating a script where only one may be active. However, it does not explicitly state when to use this over alternatives like sieve_script_activate or domain_sieve_create, 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, the description carries the full burden of behavioral disclosure. It does add the key constraint that only certain statuses are eligible, which is useful. However, it does not state whether the deletion is permanent, whether special permissions are required, or what happens if the email is not in the supported statuses. This is a modest but incomplete disclosure for a mutating 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 two short sentences, with the primary action front-loaded. Every phrase earns its place, including the crucial status constraint. No filler or redundant information is present.
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 delete tool, the description covers the essential 'what' and 'when' context. It lacks mention of return values or error behavior, but since there is no output schema, that is a minor gap. The status constraint adds valuable context that makes the tool's usage clear.
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 a description for the only parameter (email_id: 'Email ID to delete'), yielding 100% schema coverage. The tool description itself adds no additional parameter semantics, 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 uses the specific verb 'Delete/cancel' with the resource 'outbound email', clearly distinguishing it from sibling delete tools like message_delete or alias_delete. It also adds a scope condition ('Only works for emails with status pending, queued, or deferred'), which further clarifies the exact purpose.
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 when-to-use condition by specifying which statuses qualify ('pending', 'queued', 'deferred'), effectively excluding other states. However, it does not explicitly name alternatives for emails in other states, such as email_get or email_create, so it falls short of fully explicit when-not/alternatives guidance.
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 partially discloses behavior by noting the tool does not include message body. It does not clarify whether it is read-only (implied by 'List') or describe pagination/return format, but the disclosed limitation is significant and helpful.
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 no filler. The second sentence efficiently communicates a critical limitation and points to the correct alternative, earning 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 list tool with a rich schema (5 documented parameters) and no output schema, the description adequately covers the core purpose and the most important output characteristic (no body). It could mention that it returns a list of summaries, but the pointer to email_get covers the main follow-up need.
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 no additional parameter meaning beyond what the schema already provides. It does not clarify parameter interactions, but the baseline of 3 is appropriate since the schema fully documents each parameter.
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') and resource ('outbound SMTP emails'), immediately distinguishing this from other tools like email_get (which retrieves full details). It also specifies the scope (outbound) and the key omission (no body), 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?
The description explicitly points to email_get as the alternative for full message body details, providing a clear when-not-to-use signal. It lacks broader context on when to prefer this over messages_list, but the core alternative is addressed.
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 of behavioral disclosure. It explicitly states the deletion is permanent and irreversible, and that alias credentials are required. This conveys key behavioral traits, although it does not describe error handling or return 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 a single, focused sentence that front-loads the action and includes only essential information. There is no redundancy or unnecessary detail, making it concise and easy to parse.
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 three-parameter delete tool with the schema fully describing inputs, the description covers the core purpose, permanence, and authentication requirement. It is reasonably complete, though it omits potential error conditions or success response specifics, which could be valuable in some contexts.
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 with clear descriptions for all three parameters (message_id, alias_password, alias_username). The description adds no additional parameter-level detail, so it meets the baseline expected for full 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 with a specific verb ('Permanently delete') and a specific resource ('a message for an alias (IMAP)'). This distinguishes it from sibling tools like email_delete or message_update, and the IMAP context adds further clarity.
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 for permanently deleting messages via IMAP and mentions the prerequisite of alias credentials, but it does not explicitly provide alternatives or when-not-to-use scenarios compared to sibling tools. Usage guidance is present but not fully explicit.
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 must carry the behavioral burden. It mentions the auth requirement and the operation scope, but does not disclose whether flags/labels are replaced or merged, what happens when the message does not exist, or any error/return behavior. This is a reasonable but not deep disclosure 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 a single, focused sentence that front-loads the verb and resource, immediately conveys the scope, and includes an essential prerequisite without any filler. Every word contributes to understanding.
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 no output schema, the description covers the essential context: what it does, its domain (IMAP alias), and an authentication requirement. It does not describe expected return values or error scenarios, but these are less critical given the straightforward nature of the operation. It is almost 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?
The schema has 100% parameter description coverage, so the schema carries the semantic details. The description's mention of 'flags/labels/folder move' loosely maps to parameters, but adds no additional meaning beyond what the schema already states. 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: 'Update a message' with specific sub-operations (flags/labels/folder move) and the scope ('for an alias (IMAP)'). This distinguishes it from sibling tools like message_create, message_get, and message_delete.
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 on when to use the tool (updating an existing message) and a prerequisite ('Requires alias credentials'). It does not explicitly name alternatives or exclusions, but the specific sub-operations make the intended use obvious relative to 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?
With no annotations, the description must disclose behavior. It mentions the active-script limitation and credential requirement, but omits details on irreversibility, error handling, or post-deletion effects.
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, immediately stating the action and adding only relevant constraints. 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 simple delete operation with schema-documented parameters, the description covers purpose, key constraint, and authentication requirement. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for all three parameters (100% coverage). The description's mention of credentials reinforces the alias_username/password fields but adds no new semantic 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 begins with 'Delete a Sieve script for an alias', which clearly identifies the action and target. It also notes the active-script restriction, distinguishing it from other sieve_script_* tools such as update or activate.
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 explicitly states 'cannot delete the active script', providing a condition for when deletion is not possible. 'Requires alias credentials' signals prerequisites, though it does not explicitly compare against sibling update/activate tools.
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. The term 'retrieve' clearly signals a read-only operation, and it details the scope of returned data (email, plan, settings), but it does not disclose behavior like authentication requirements, error handling, or side effects.
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 with specific content (email, plan, settings) and 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 simple, parameterless getter, the description provides enough detail about the expected return content. However, since there is no output schema, it could have been slightly more explicit about the response structure or that it returns the authenticated user's account.
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, which is the baseline for a perfect score. The description adds no irrelevant parameter details, staying clean.
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 (retrieve), the resource (your ForwardEmail account), and specific content (email, plan, settings). It is easily distinguished from sibling tools like account_create and account_update, which imply different actions.
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 tool is for reading the current account's data, and siblings include create/update alternatives, giving clear context. However, it lacks an explicit 'when not to use' statement or mention of 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?
The description implies a read-only operation but does not add context beyond that, such as authentication requirements, rate limits, or reset behavior of the count. Since no annotations are provided, the description carries the full burden, and this is a relatively simple read operation, so a neutral score 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 a single, front-loaded sentence with no filler words, earning a high score.
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 no-parameter tool with no output schema, the description gives the essential information: it returns the daily limit and current count. It could benefit from explaining the return format or whether the count resets, but the core usage is clear.
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 has no properties. The baseline for zero parameters is 4, and the description appropriately adds no parameter details since none are needed.
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 daily outbound SMTP email limit and current count, using a specific verb ('Get') and resource, distinguishing it from siblings like emails_list or email_get.
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?
While no explicit alternatives are named, the description provides clear context that this tool is for querying daily email sending limits/counts, which differentiates its use case from other email-related tools. However, it lacks explicit when-not-to-use or alternative recommendations.
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 must carry the safety/behavioral transparency burden. It explicitly states 'Replace' and 'Pass an empty list to clear it,' which makes the destructive/overwrite behavior evident. It does not mention permissions or other side effects, but for this simple mutation tool, the core behavioral disclosure is present.
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 short sentences, each serving a purpose: the first states the action and resource, the second explains a critical usage variant. No wasted words, information is front-loaded.
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 simplicity of the tool (two required params, no output schema, no nested objects), the description combined with the comprehensive schema fully covers the tool's behavior. The replace and clear semantics are explicitly stated, and the description is sufficient for an agent to 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?
Schema description coverage is 100%, with the 'denylist' parameter already explaining the allowed item types and the empty-list clearing behavior. The description adds no additional parameter semantics beyond the schema; the clearing note merely restates what is already 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 uses the precise verb 'Replace' with the specific resource 'a domain's sender denylist,' clearly distinguishing this from sibling tools like domain_allowlist_update or domain_update. The additional note about passing an empty list to clear reinforces the purpose.
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 clear usage context: the tool replaces the entire sender denylist, and an empty list serves to clear it. However, it does not explicitly mention when to choose this over domain_allowlist_update or other domain-level updates, so it stops short of full alternatives/exclusion 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 full behavioral disclosure. It explicitly states that both the folder and its messages are deleted, and it calls out the authentication requirement. This is sufficient for an agent to understand the destructive and privileged nature of the operation, though it does not mention irreversibility (implied by 'delete').
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 conveys purpose, scope, and prerequisites without any filler. Every word earns its place, making it highly efficient and easy to parse.
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 straightforward delete tool with three fully described parameters and no output schema, the description is complete. It covers what is deleted, the target (alias), and the required credentials, giving an agent 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 covers 100% of parameters with clear descriptions (folder_id as path, alias_username format, alias_password source). The description adds no additional parameter-level detail, but the high schema coverage means the 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 ('Delete') and identifies the exact resource (folder and its messages) plus the target context (an alias via IMAP). This clearly distinguishes it from sibling tools like folder_create, folder_get, and folder_update, which have different purposes.
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 states the key prerequisite ('Requires alias credentials'), making clear when the tool can be used. It does not explicitly mention alternatives or when-not scenarios, but the tool's name and destructive scope provide strong contextual guidance, especially alongside sibling folder tools.
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:

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

Score Badge

Copy to your README.md:

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

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/junxit/mcp-forwardemail'

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