agent-cold-email

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action. For example, activity vs inbox differentiate broad events vs replies, and campaign_results vs metrics vs list_campaigns each serve unique query scopes. No two tools overlap in purpose.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., list_campaigns, configure_webhook), but a few are noun-only (activity, inbox, thread, metrics). The overall pattern is clear and readable, with only minor deviations.
Tool Count4/5
25 tools is slightly above the typical 3-15 range, but the complexity of cold email infrastructure (campaigns, inbox, leads, infrastructure, webhooks) warrants a larger set. Each tool feels justified.
Completeness3/5
Core workflows (campaign creation, inbox triage, lead management, infrastructure) are covered, but notable gaps exist: no update or delete campaign, and no resume after pause. These missing operations could hinder agent workflows.
Average 4.6/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 465 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 failing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds behavioral context: cursor-pagination, merged feed, response structure { items[], nextCursor }, and item fields. No contradictions. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph front-loaded with purpose, then details on pagination, item structure, and filters. Every sentence earns its place. Slightly dense but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies the return structure, pagination, filters, and default/max values. Covers all needed context for a read-only feed tool with simple parameters.
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 0%. Description mentions filters (kind, limit) and defaults/max (50, 200) already in schema. Adds meaning for kind enum values ('event' vs 'deliverability') and cursor usage. Does not fully compensate for missing schema descriptions but adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Unified activity feed' merging campaign events and deliverability actions, and distinguishes itself from sibling 'inbox' tool by noting 'Use inbox for replies only.' The specificity of verb and resource is high.
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?
Explicitly instructs when to use this tool vs inbox for replies. Provides filter guidance (kind, limit, cursor). Does not mention other sibling tools like get_dashboard, but the context is sufficient for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description confirms this by stating 'Create and activate.' It adds behavioral details: steps are scheduled upfront, suppressed leads are skipped, returns campaignId, and supports idempotency for retry. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, front-loaded with the main purpose. Every sentence adds value, and there is 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?
Given the tool's complexity (8 parameters, nested objects) and lack of output schema, the description covers essential purpose, parameters, and key behaviors (suppressed leads, idempotency). It mentions the return value. Missing some details like default for timezone or sendWindow but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (13%), but the description enumerates all key parameters (name, offer, leads, sequence, sendWindow, timezone, stopOnReply, idempotencyKey) and explains the structure of sequence and sendWindow. It adds meaning beyond the schema, especially for idempotency and lead object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create and activate a campaign on a lead list,' specifying the verb and resource. It distinguishes from sibling tools like list_campaigns (listing) and campaign_results (results) by focusing on the creation and activation process.
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 launching campaigns but does not explicitly state when to use this tool vs alternatives or provide when-not-to-use guidance. The context of sibling tools is not leveraged for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation, such as running a 'pre-flight live-infra scan + abuse gate + reputation ladder' and returning billing projections. It does not contradict the annotation and enriches understanding of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with action identifiers and clear sentences. It is as concise as possible given the tool's complexity, front-loading the overall purpose before detailing each action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all actions, parameter dependencies, billing projection behavior, and special flags like quoteOnly. With no output schema, it provides sufficient context for an AI agent to invoke the tool correctly across all scenarios.
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?
With 90% schema description coverage, the baseline is 3. The description adds meaning by explaining each parameter's role per action (e.g., 'acknowledge_consent needs id + acknowledged:true — REQUIRED before a primary domain can proceed past pending_consent'), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for registering or advancing BYO domain/mailbox intake, referencing SPEC.md §20. It lists five distinct actions with specific verbs and resources, effectively distinguishing each sub-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?
The description provides detailed guidance on when to use each action, including required parameters and context (e.g., 'register needs domain + domainRelationship', 'poll_dns needs id'). It implies a logical order but does not explicitly compare against sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that secrets are never returned on reads, a behavioral trait beyond the 'readOnlyHint' annotation. This is consistent with the annotation and adds important context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, covering both use cases and a critical note about secrets without unnecessary verbosity. It is well-structured with front-loaded main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description details return shapes for both cases, compensating for the lack of an output schema. It lacks information on pagination or limits, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the parameter description already explains the id behavior. The tool description does not add additional meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists webhook subscriptions, with distinct behaviors for omitting or providing an id. It specifies the return format for each case, 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 explains when to use the id parameter versus omitting it, providing clear usage patterns. It does not explicitly mention when not to use this tool or alternatives among siblings, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by detailing pagination behavior and the structure of return data (threads[], nextCursor, fields). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a filter list and an alternative tip. Every sentence adds value, and the most important information (purpose, pagination, key filters) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by specifying return structure and fields. It covers all major filters and provides a usage pointer to a sibling. Missing details like error handling or ordering, but still adequate for a read-only paginated list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the meaning of 6 out of 8 parameters (mailbox, campaign, label, read, includeNonreply, archived) including the enum options for archived and default for includeNonreply. Two parameters (limit, cursor) are only implicitly mentioned via pagination context, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a unified reply inbox across mailboxes, specifies cursor-paginated output with fields, and distinguishes from sibling 'thread' by telling to use that for one thread's history.
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 lists available filters and explicitly mentions an alternative tool ('Use thread for one thread's history'), providing clear context on when to use this tool. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true, and the description adds context about the status change, unaffected sent mail, no resume capability, and a 404 error. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, no redundancy, and front-loaded important information. Slightly more structured formatting could improve readability, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, effect, irreversibility, error handling (404), alternative tool, and output format, making it fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes campaignId as 'The campaign id returned by launch_campaign.' The description mentions 'Input: campaignId' but does not add significant new semantics beyond the schema's 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 pauses one campaign, changes status to 'paused', and stops tick scheduling. It distinguishes itself from the sibling tool 'pause_all' by specifying it affects a single campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use this tool (for a single campaign), provides an alternative ('Use pause_all to pause every active campaign at once'), and notes that there is no resume tool, giving clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, but the description adds crucial behavioral details beyond that: idempotency behavior (with idempotencyKey or body hash), the fact it sends from the mailbox that sent the thread, and the 404 error scenario. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loading the primary purpose, then inputs/output, idempotency details, and error case. Every sentence 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return format ({ messageId }), covers idempotency and error. For a 3-parameter tool with no nested objects, it provides sufficient context for an agent to use correctly, though it omits rate limits or auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (threadId and idempotencyKey described, body not). The description adds context by stating 'from the mailbox that sent it' (implied parameter) and explains idempotencyKey fallback to body hash. This adds semantic value beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a reply on an existing thread', specifying the verb (send), resource (reply on thread), and context (from the mailbox that sent it). It distinguishes from siblings like 'thread' (retrieve thread) and 'mark' (mark status) by focusing on reply action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details when to use this tool (to reply to an existing thread) and notes a critical error condition (404 if no sending mailbox on record). However, it does not provide explicit when-not-to-use guidance or compare against specific sibling alternatives like 'thread' or 'mark'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. Description adds specifics: return shape with nullable mailboxEmail, oldest-first order, and error behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph covering purpose, input, output, error, and sibling hints. No redundancy; efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and high schema coverage, the description provides complete context: purpose, input, output shape, error, and usage alternatives.
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 has 100% coverage with clear description for threadId. Description mentions it but adds no new semantic detail 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?
Explicitly states 'Full message history for ONE thread' with specific verb and resource. Distinguishes from siblings by naming inbox, reply, and label_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: 'Use inbox to LIST threads; reply to respond; mark/label_thread to triage.' Also notes 404 error for unknown threads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the 'destructiveHint' annotation, the description discloses the compare-and-swap behavior for update: a stale rev returns '{ currentRev, currentLayout }' to rebase and retry. Does not mention rate limits or auth, but the conflict resolution is a key behavioral trait.
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?
Efficiently written in one paragraph with no filler. Front-loaded with the main purpose. Could be improved with bullet points for the actions, but is very compact and informative.
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 absence of an output schema, the description explains the conflict response for stale revisions, which is critical. No description of success return values, but the tool's complexity and the CAS behavior are well-covered.
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?
Adds action-specific required parameters (e.g., create needs name+layout, update needs id+rev+layout) and explains the rev parameter's CAS semantics. The schema covers 83% of parameters, but the description reinforces and provides context beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with 'Write a saved dashboard view,' clearly identifying the verb and resource. Lists four specific actions (create, update, promote, delete), and distinguishes from sibling 'get_dashboard' which is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Read the current rev+layout via get_dashboard first' before update. Explains when each action is appropriate (create needs name+layout, update needs id+rev+layout, etc.) and details the CAS conflict handling for update.
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?
Describes the mutation behavior (set or clear, with null to clear) and is consistent with destructiveHint=false. Adds value beyond annotations by explaining how to clear a label.
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 purpose, no wasted words. Efficiently conveys all necessary information.
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 (2 params, no output schema), the description provides enough context: it links to dashboard chips, explains clearing, and notes filterability. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description adds meaning for the 'label' parameter by explaining how to clear it. The 'threadId' parameter is already 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 verb 'set or clear' and the resource 'triage LABEL on an inbox thread', and distinguishes it from the sibling tool 'mark' by explaining that a label is a free-form category, not a read flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit differentiation from 'mark' and mentions filterability via inbox's label param. Does not list all alternative tools but gives clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently explains async behavior (returns jobId, poll infrastructure_status), billing details (per-mailbox costing, minimum 5, formula), and the quoteOnly preview. Annotations only provide destructiveHint: false, so the description adds significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the core purpose. It covers billing, async behavior, and idempotency without redundancy. While lengthy, every sentence contributes value, making it appropriately concise for the complexity.
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?
Considering the tool's complexity (async, billing, many parameters), the description covers the main aspects: what it does, billing preview, async polling, idempotency. It lacks explicit detail on warmup or mailbox creation, but the response format is described. Overall, complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 9 parameters with only 11% description coverage. The description adds meaning by summarizing key inputs (brand, domains, inboxesEach) and explaining the role of quoteOnly and idempotencyKey. It doesn't detail every parameter, but compensates adequately for the low 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 starts with a clear verb+resource: 'Provision sending infrastructure: buy branded lookalike domains, create mailboxes, start warmup.' It distinguishes itself from sibling tools like get_dashboard or list_campaigns, which are about retrieval or management, not provisioning.
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 advises using quoteOnly:true to preview billing before committing, and mentions idempotencyKey for retries. While it doesn't explicitly state when not to use the tool, the context makes it clear it's for initial setup or capacity addition. Sibling tools are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the destructiveHint annotation: secret returned only once, HTTPS requirement, rejection of private IPs, HMAC signing, and re-enable/pause semantics for active flag. This is comprehensive.
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, dense paragraph that front-loads the purpose and then details actions. While effective, it could be broken into bullet points for easier scanning, but no unnecessary sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 actions, 7 parameters, no output schema), the description covers all actions, parameter dependencies, constraints (URLs, event types), and return behavior (secret once). It is fully informative.
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?
Despite high schema coverage (86%), the description adds context like 'secret rotates', 'active:true re-enables an auto-disabled one', and 'ignored placeholder' for note, enriching the schema definitions.
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 'Manage an outbound webhook subscription' and enumerates the three actions (create, update, delete), making the tool's purpose specific and distinct from sibling tools like get_webhooks.
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 detailed usage patterns for each action, including required and optional parameters. However, it does not explicitly contrast with sibling tools or state when not to use this tool, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by specifying cursor-pagination, return structure (leads[], nextCursor), and available filters. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, each providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema, the description covers purpose, response structure, pagination, and sibling alternatives. It lacks detailed parameter explanations but is otherwise comprehensive for a list tool. Minor gap: no explicit mention of default limit value.
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?
With 0% schema description coverage, the description partially compensates by listing four filter parameters (campaign, interestStatus, suppressed, replied). However, it does not explain the pagination parameters (limit, cursor) beyond mentioning cursor-pagination. Enums are only in schema, not described. Adequate but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List/export leads' with specific verb and resource, and mentions cursor-pagination, making the purpose immediately obvious. It also differentiates from siblings by referencing update_lead and suppress_lead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'This IS the export surface — paginate to dump the full book of business as JSON (no separate CSV endpoint).' It also points to alternatives: 'Use update_lead to write disposition, suppress_lead to opt an address out.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds context on the data shape (fields), scope (tenant-wide), and exclusions (bounce = hard only, opens not tracked), without contradiction.
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 with a clear list and alternative references. No superfluous information; well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return fields, scope, and tracking exclusions. Sufficient for understanding tool behavior, though could hint at data types.
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?
No parameters exist (schema has zero properties, 100% coverage). Baseline of 4 for zero-parameter tools is appropriate; description adds no parameter info but clarifies return semantics.
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 specifies 'Account-wide outcome totals across ALL campaigns' with a clear list of fields, and explicitly distinguishes from sibling tools (campaign_results, list_campaigns, account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives: 'Use campaign_results for one campaign, list_campaigns per-campaign, or account for billing/quota.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond readOnlyHint annotation: clarifies bounce is HARD only, opens not tracked, and 404 response. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences covering purpose, input/output format, and explicit usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes a simple read operation: input, output fields, error case, and relationship to sibling tools. No output schema needed.
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 description for campaignId. Description restates that input comes from launch_campaign but adds no new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Outcome counts for ONE campaign' - specific verb and resource. Clearly distinguishes from sibling tools by naming 'metrics' and 'list_campaigns' as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (single campaign results) and alternatives (metrics for account-wide, list_campaigns for all). Also specifies input source and 404 handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description's reading behavior is consistent. It adds value by explaining the rev role and that views are both agent- and human-editable, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three concise sentences: core purpose, mode behavior, and additional context. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and no output schema, the description fully explains return structures for both modes and connects to sibling tool, providing complete context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes id parameter well, but description adds meaning by specifying the exact fields returned in each mode and how rev connects to configure_dashboard, enhancing 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?
Description clearly states 'Read saved dashboard views' and distinguishes between two modes: listing all with no id, and retrieving full layout with id. It contrasts with sibling tool configure_dashboard, making 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use each mode ('No id → list all', 'With id → that view's full layout + rev') and advises to write views with configure_dashboard, providing clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=true. The description adds significant transparency: it explains the data structure, notes that vendorReputationScore and vendorPlacementRate are VENDOR-REPORTED approximations (not first-party), and clarifies that the control loop uses local signals only. This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with front-loaded key purpose. Every sentence adds value: purpose, return structure, and usage alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains return values with caveats about data sources. Also mentions sibling for account-wide rollups. No missing context for a zero-parameter read-only 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 tool has zero parameters, and schema coverage is 100%. Baseline is 3. The description does not add parameter semantics because none exist, but it does describe the return structure, which indirectly helps.
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 that the tool returns warmup and provisioning progress per mailbox, using a specific verb 'Returns'. It distinguishes from siblings like 'account/metrics' for account-wide rollups, and the name 'infrastructure_status' aligns with 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (per-mailbox status) and when to use alternatives ('Use account/metrics for account-wide rollups'). No ambiguity about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context (returns list with specific fields, newest first, bulk operation). Could mention limitations like pagination, but not necessary given no 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?
Two concise sentences, front-loaded with purpose, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers what the tool returns, ordering, and provides sibling guidance.
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?
No parameters exist, and schema coverage is 100% (trivially). Baseline is 4; description does not add parameter info but provides output structure, which is helpful but not required for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List every campaign at once' and provides the output structure, clearly distinguishing it from siblings like campaign_results and metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use (when you need all campaigns) and when not to, offering alternatives: 'Use campaign_results for one campaign's counts, metrics for account-wide totals.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return value ({marked: true}), error handling (404 for unknown thread), and the effect of 'archived' status (hides from default inbox, refetching behavior). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences plus a front-loaded purpose). Every sentence adds necessary information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two parameters, no output schema, and available sibling tools, the description provides complete context: input details, output, errors, and usage boundaries.
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?
While schema coverage is 50%, the description adds meaning by listing the valid status values and explaining the archival behavior. It also provides context for threadId ('e.g. from inbox() or campaign events'). This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'a thread's READ-STATE' for inbox triage. It also explicitly distinguishes from sibling tools 'label_thread' and 'reply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for read/unread/archived flags) and provides alternatives for other actions (label_thread for labels, reply for responses). However, it does not explicitly state when not to use it beyond those comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive intent, and description adds specific behavioral details (status change, stops sends, return value). No mention of reversibility or prerequisites, but sufficient for the simple 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?
Extremely concise with two sentences plus a note. Front-loaded with purpose and effect.
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?
All necessary context provided: purpose, effect, return value, no inputs, and relationship to sibling tool. No gaps.
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?
No parameters, schema fully covers it. Description explicitly states 'No inputs', adding confirmation beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it pauses every active campaign for the tenant, with specific effect on status and scheduling. Distinguishes from sibling tool 'pause' for single campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'pause' for single campaign, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: it states it's a partial patch (only passed fields changed), requires at least one of interestStatus/notes/tags, and mentions server-enforced enum validation. Annotations only provide destructiveHint=false, so the description adds useful context. However, it does not mention authorization needs or rate limits, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence followed by a parameter list. It is relatively long but each sentence adds value. Minor redundancy: 'Inputs: ' could be integrated. Overall, it's concise for the amount of detail provided.
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 4 parameters, no output schema, and low schema coverage, the description thoroughly covers inputs, behavior (partial patch), and relationships to sibling tools (suppress_lead, list_leads). It also notes the contact-level scope and cross-campaign visibility. No missing aspects for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries the burden. It explains each parameter's role: email as key, interestStatus with explicit enum values and the note that it's server-enforced, notes and tags with constraints (maxLength, maxItems). It also clarifies that at least one optional param is required, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recording contact-level disposition keyed by email. It uses specific verbs ('record what you learned') and resource ('contact-level disposition'), and distinguishes itself from sibling tool 'suppress_lead' by explicitly noting that 'do not contact' is not a valid interestStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it notes that 'do not contact' should be handled via suppress_lead. It also mentions that the tool is filterable via list_leads, offering context for integration. No when-not-to-use scenarios are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description doesn't need to restate that. However, it adds substantial behavioral context, such as billing details (per-provisioned-mailbox pricing), the meaning of activationState as the 'HONEST send state', and conditions for teardown. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, using a concise introductory sentence listing key fields, then brief elaborations on billing and activationState. Every sentence serves a purpose, and the structure is clear with no 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?
With no output schema, the description fully covers the return data, including fields like recentActions[], teardown, and detailed activationState interpretations. It is complete for a read-only account overview, leaving no ambiguity about what the tool provides.
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 no parameters, so description is not needed for parameter semantics. According to guidelines, 0 parameters earns a baseline of 4. The description does not add anything about parameters because none exist, which 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 it provides an 'Account overview' and lists specific fields (brand, plan, status, etc.). It also differentiates from sibling tools by noting that 'metrics' should be used for counts and 'infrastructure_status' for per-mailbox health, making the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool: it advises trusting activationState over 'sent' counts and directs users to other tools for specific needs ('Use metrics for counts, infrastructure_status for per-mailbox health'). It also explains the meanings of activationState values, providing clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' destructiveHint, the description explains the irreversible nature, immediate release but no mid-cycle credit, and that the lower price takes effect next renewal. It explicitly states the return values: releasedCount and quote.
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 relatively concise and front-loaded with the main action, but the parenthetical about alternatives and the return values could be separated for better scanning. Still, it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what is returned. It covers prerequisites (acknowledgment), side effects (no partial credit), billing impact, and alternatives. Completeness is high for a downgrade tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: 'count' is the number of mailboxes to release (1-60), and 'acknowledged' must be true as irreversible consent. It adds billing context not 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 it is a downgrade tool to release N newest live mailboxes and lower billed quantity. It distinguishes from the sibling 'setup_infrastructure' and 'configure_byo_domain' tools which are for adding mailboxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (to lower billing) and contrasts with adding mailboxes via sibling tools. It also provides constraints like minimum 5 mailboxes / $99 and that no mid-cycle credit is given, and requires the 'acknowledged' consent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the `destructiveHint` annotation by detailing side effects: cancels pending sends, marks rows suppressed, last-write-wins relabeling, and the fact that notes are accepted but not persisted. This provides complete transparency beyond what annotations offer.
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 but packs in all critical details. The structure is front-loaded with the core purpose, then details. Minor improvement: could break into bullet-style for even quicker scanning, but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully covers input semantics, side effects, behavioral traits (last-write-wins), and caveats (no un-suppress). It leaves no ambiguity about what the tool does or its consequences for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates: it explains that `reason` is fixed to 'manual' (const), `note` is accepted but not persisted, and `email` is required. This adds significant meaning beyond the bare 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 specifies a clear verb ('suppress') and resource ('email address tenant-wide'), and distinguishes its purpose as the manual opt-out path for cases the typed-unsubscribe matcher misses. It names the exact inputs and effects, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('manual opt-out path') and implicitly when not to use (bounce/complaint/unsubscribe are handled automatically elsewhere). It also warns there is no un-suppress tool and explains the last-write-wins behavior, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds rich behavioral details: lists output fields per mode, explains status progression, and notes that configure_byo_domain is for mutation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with main action, then specifics. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema, the description fully covers behavior, output structure, status progression, and sibling tool linkage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for 'id' parameter; description goes beyond schema by explaining the effect of omitting vs providing id, and enumerates additional returned fields when id 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?
Clearly states it lists BYO domains or gets full intake detail for a specific domain. Distinguishes between two modes and differentiates from sibling tool 'configure_byo_domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to omit 'id' vs pass it, and directs users to 'configure_byo_domain' for registration or advancement. No ambiguity.
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:

[![agent-cold-email MCP server](https://glama.ai/mcp/servers/YS-projectcalc/agent-cold-email/badges/card.svg)](https://glama.ai/mcp/servers/YS-projectcalc/agent-cold-email)

Score Badge

Copy to your README.md:

[![agent-cold-email MCP server](https://glama.ai/mcp/servers/YS-projectcalc/agent-cold-email/badges/score.svg)](https://glama.ai/mcp/servers/YS-projectcalc/agent-cold-email)

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/YS-projectcalc/agent-cold-email'

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