sendcraft-mcp

Official

by sendcraftlabs

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct resource/action, with clear differentiation between transactional and campaign sending, and between list/get operations for different entities. Potential overlaps are resolved by specific descriptions.
Naming Consistency4/5
All tools follow the sendcraft_ prefix and mostly use verb_noun structure. Minor deviations like 'unsubscribe' (verb-only) and 'batch_send' (verb at end) are still understandable and do not break the overall pattern.
Tool Count2/5
With 26 tools, the server exceeds the 25-tool threshold and feels overly heavy. Many list/get tools could be consolidated, and the count makes the toolset harder to navigate.
Completeness3/5
Core operations for sending, scheduling, and tracking are covered, but update/delete operations are missing for campaigns, templates, domains, and subscribers. Subscriber management relies on add/unsubscribe only, and there is no way to modify or remove certain resources, leading to notable gaps.
Average 3.9/5 across 26 of 26 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations are present, so the description carries the burden. It says 'List' but doesn't disclose response format, pagination, or whether it returns all segments. For a simple list tool, this is minimal but acceptable, yet lacks depth.
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 action and resource, then a helpful definition. 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?
The tool is simple (no params, no output schema), and the definition of segments adds context. However, the description doesn't mention what fields are returned (e.g., IDs, names) or any limitations like pagination, so it's slightly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain any parameter semantics; there are none to explain.
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 it lists subscriber segments and defines what segments are (dynamic groups matching criteria). This differentiates it from list_subscribers, though it doesn't explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like list_subscribers. The description implies it's for segment listing but doesn't state exclusions or 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, but it only states that the tool lists subscribers with status and tags. It does not mention pagination behavior, default limits, filtering semantics, or any access requirements, which are relevant for a listing 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 short sentence that immediately conveys the core purpose with no filler words or redundant information. It is appropriately sized and front-loaded.
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 low complexity and 100% schema coverage, the description is passable but leaves gaps: there is no output schema, and pagination/response shape are not mentioned. It is sufficient for a basic tool but not comprehensively specified.
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 four parameters, covering 100% of them, so the baseline is 3. The description adds minimal value beyond the schema, and 'tags' is not a parameter even though it is mentioned in the 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 'List subscribers/contacts' with a specific verb and resource, and it specifies the included fields (status and tags). This distinguishes it from sibling tools that send emails or manage campaigns, making its 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 beyond the basic listing function. There are no when/when-not criteria, no mention of filters like status or list_id, and no reference to alternative tools like list_segments for more targeted subscriber views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions {{variable}} placeholders, which is helpful, but does not disclose whether saving an existing template name overwrites it, what permissions are needed, or what the operation returns. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediately clarifies the key feature (variable placeholders). There is no redundant information, and it is appropriately sized for the tool's complexity.
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 create tool with a 100% schema coverage, the description is almost sufficient, but it lacks any info on the return value, behavior on duplicate names, or how the saved template is later referenced. Given no output schema, a bit more context would be beneficial.
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's mention of {{variable}} placeholders aligns with the schema's parameter descriptions but adds no new semantic meaning beyond that. The parameters are self-explanatory from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Save' and the resource 'email template', with the purpose 'for reuse'. This distinguishes it from sending or listing templates, and 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 purpose implies when to use this tool (when you need a reusable email template), but there is no explicit guidance on when not to use it or alternatives. The sibling tools are mostly for sending, so the context is somewhat clear, but no exclusions are 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. The verb 'Get' and the explanation of opt-in/out status imply a read-only operation, but it does not explicitly state side effects, permissions, or error 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, front-loaded sentence that conveys the essential information without any 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?
With no output schema, the description adequately explains what the tool returns (opted-in/out topics). For a simple getter with one parameter, this is nearly complete, though it does not mention behavior when the subscriber does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter (subscriber_id) with 100% coverage. The description adds no additional semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific subscriber's topic preferences, including opt-in/out status. This directly differentiates it from siblings like list_topics (which likely lists all topics) and list_subscribers.
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 explicit guidance is given on when to use this tool versus alternatives. The phrase 'for a specific subscriber' implies a use case, but there is no mention of when not to use it or reference to sibling 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 behavioral disclosure. It clearly implies a read-only operation ('List') and gives a hint of the content (status, performance metrics), but it omits details such as pagination behavior, default limits, whether it returns only the user's own campaigns, or any authorization requirements. This is a modest disclosure, adequate for a simple list but not rich in 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 concise sentence that is front-loaded with the verb 'List'. It conveys the essential purpose without any redundant words or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with only two optional parameters, both well-documented in the schema. No output schema exists, so the description's mention of 'status and performance metrics' provides a reasonable, albeit basic, expectation of the return. However, it could be more thorough by noting the availability of the status filter or the difference from listing individual emails, but given the low complexity, this is mostly sufficient.
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 both parameters (limit and status) with clear descriptions, so the baseline is 3. The description adds no additional meaning about how the parameters behave or interact; it only states the output content (status and performance metrics), which is not directly tied to the parameters. Thus, the description does not elevate beyond the 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 specific action verb 'List' and clearly identifies the resource as 'email marketing campaigns'. It also specifies the output includes 'status and performance metrics', which differentiates it from sibling tools like sendcraft_list_emails (which likely lists individual emails) and sendcraft_get_campaign_analytics (which likely focuses on detailed analytics for one campaign).
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 exclusions, prerequisites, or explicitly name any sibling tools. For instance, an agent could not tell from the description whether to use this tool or sendcraft_get_campaign_analytics for obtaining detailed performance data, since 'performance metrics' is vague and no comparison is made.
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 fully disclose behavioral traits. It only states the basic action and timing, but omits important details such as whether cancellation is irreversible, idempotent, what happens if the email has already been sent, or required permissions. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action verb 'Cancel,' and every word earns its place. It is highly efficient and well-structured.
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 with no output schema, the description covers purpose and usage scenarios. However, it lacks behavioral edge-case details such as error handling, idempotency, or feedback on already-sent emails, leaving some context 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 schema covers the single parameter email_id with a clear description, so the baseline is 3. The tool description adds no additional meaning beyond the schema, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Cancel a scheduled email' and adds the temporal condition 'before it is sent.' This distinguishes it from sibling tools like sendcraft_send_email and sendcraft_schedule_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit scenarios for when to use: 'when a user cancels an order, changes their preferences, or the scheduled action is no longer needed.' However, it does not mention when not to use or contrast with alternatives beyond implication.
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 responsibility for disclosing behavior. It mentions immediate vs scheduled sending, but omits critical traits such as the irreversibility of sending, any state changes to the campaign (e.g., marked as sent), or prerequisites beyond 'draft' status. This is a significant gap for a mutation-like 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 verb, resource, and two modes with zero wasted words. It is appropriately concise for a simple tool.
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 tool with two parameters and no output schema, the description is minimally viable. It correctly identifies the target resource and scheduling option, but misses behavioral caveats (e.g., draft requirement, sending irreversibility) that would make it fully complete for an agent without additional context. Slightly below the ideal for a send operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds 'existing draft campaign' and 'immediately or schedule' but essentially restates the schema's 'Campaign ID to send' and 'ISO 8601 datetime to schedule' without adding deeper meaning. 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 ('Send') and resource ('existing draft campaign'), and clearly states two modes: immediate send or schedule for future time. This distinguishes it from sibling tools like sendcraft_send_email (emails vs campaigns) and sendcraft_create_campaign (creation vs sending).
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 when to use this tool: when you have an existing draft campaign to send. It does not explicitly name alternatives or exclusions, but the 'existing draft campaign' wording and the two modes provide clear context for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does list the returned metrics, which is helpful, but it does not explicitly state that this is a read-only operation, mention any side effects, or describe behavior for invalid campaign IDs. Since it's a 'get' operation, the read-only nature is implied but not stated, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource, then enumerates the delivered metrics. No filler words or redundant content; every word adds 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?
Given the tool's low complexity (one parameter, no output schema), the description adequately covers the essentials by specifying the exact data categories returned. It doesn't detail response format or error conditions, but for a get-analytics tool, this is sufficient. The sibling context further clarifies its niche.
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 only parameter, campaign_id, with a basic description ('Campaign ID'). The tool description adds only that it is 'for a specific campaign,' which barely enhances the schema. Baseline 3 is appropriate since the schema already documents the parameter 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 tool's function: retrieving detailed analytics for a specific campaign, enumerating the metrics included (opens, clicks, bounces, unsubscribes, click heatmap). This differentiates it from siblings like sendcraft_get_stats (likely account-wide) and sendcraft_list_campaigns (listing campaigns). It uses a specific verb ('get') and resource ('campaign analytics').
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 a specific campaign' implies the tool is used when analytics for a single campaign are needed, but it does not explicitly provide when-not-to-use guidance or mention alternative tools (e.g., 'for overall account stats use sendcraft_get_stats'). All context is implicit, 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?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, return format, pagination, or other behaviors. The spam warning is about email delivery consequences, not the tool's behavior itself.
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 function in the first sentence and a relevant warning in the second. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers the key output (domains and DNS status) and adds a useful warning about unverified domains. It lacks explicit mention of read-only nature or output structure, but given its simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to add. The description's mention of domains and DNS status aligns with the schema's emptiness. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sender domains and their DNS verification status (SPF, DKIM, DMARC). This is a specific verb+resource combination that distinguishes it from sibling tools like sendcraft_add_domain, sendcraft_verify_domain, and sendcraft_analyze_dmarc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (checking verification status before sending, given the spam warning) but does not explicitly state when to use this tool versus alternatives like sendcraft_verify_domain or sendcraft_get_stats. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral details such as pagination, rate limits, or whether it returns all topics at once. The term 'List' implies read-only, but no further operational context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences long, front-loaded with the operation ('List email topics/categories'), and the second sentence adds useful domain context without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description is adequate: it states what is listed and explains the domain. The absence of an output schema is compensated by the natural expectation that a list operation returns the available topics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed since the schema is empty and there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and explicitly names the resource 'email topics/categories', clearly distinguishing it as a catalog operation. It also defines what topics are, which reinforces the purpose and provides domain 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 context by explaining that topics let subscribers choose email types, indicating this tool is for browsing available categories. However, it does not explicitly state when to use this over sibling tools like get_subscriber_topics, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states the core action and scope but omits whether the action is reversible, what happens to scheduled emails, or whether it affects transactional email. Additionally, conflating unsubscribe with GDPR deletion is misleading. The description lacks the behavioral detail expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no redundant or tangential information. It is efficiently structured and highly scannable.
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 a single parameter and no output schema, the description covers purpose and usage well. The slight GDPR inaccuracy and lack of side-effect details prevent a perfect score, but the description is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'email' is clearly described as the target address. The tool description adds no extra parameter detail beyond the schema, 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 uses a specific verb ('Unsubscribe') and clearly identifies the resource ('a contact') and scope ('from all marketing emails'). This effectively distinguishes the tool from email-sending and campaign tools, and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' guidance is provided with two concrete scenarios. However, the mention of 'GDPR deletion requests' is potentially misleading because unsubscribing is not equivalent to data deletion; this prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key behavioral trait: if double opt-in is enabled, a confirmation email is sent. However, it does not mention duplicate handling, permission requirements, or whether the subscriber becomes active immediately, leaving significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and every sentence earns its place. It is concise and 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 tool with 5 parameters, no output schema, and no annotations, the description is somewhat incomplete. It mentions double opt-in but does not explain the resulting subscriber state (e.g., pending vs. active) or what happens on duplicate email. Schema covers parameters, but behavioral outcomes are under-specified.
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 does not add additional meaning to the parameters beyond what the schema already provides; it only describes the overall action. No extra insight about tags, names, or list_id is given.
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 ('Add a new subscriber/contact to a list') with a specific verb and resource. It distinguishes itself from sibling tools like sendcraft_unsubscribe and sendcraft_list_subscribers by focusing on the add operation, and it adds the double opt-in nuance.
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 clear usage: use this when you want to add a new subscriber to a list. It doesn't explicitly mention alternatives or exclusions, but the sibling context makes it obvious this is the creation tool vs. listing or unsubscribing. The double opt-in note provides situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool returns a value and references historical open patterns, implying a read-only operation. However, it does not mention potential failure modes (e.g., insufficient data), side effects, or any special constraints, leaving the agent with incomplete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with two sentences: the first introduces the action, and the second provides the precise output details (best day, hour, UTC, and basis). Every word is meaningful and no filler is present.
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?
While the tool has no parameters or output schema, the description conveys the semantic output but not the exact data structure (e.g., JSON keys, text format). It also omits important contextual details like behavior with insufficient historical data, making it less complete for an agent to fully rely on the return value without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly avoids parameter details. Per the rubric, zero-parameter tools receive a baseline of 4, and the description adds no unnecessary parameter information.
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: it returns the best day of week and hour of day (UTC) to send campaigns for maximum open rate based on historical open patterns. This distinctly identifies the tool's purpose and differentiates it from sibling tools like send_campaign or schedule_email.
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 (before sending campaigns to optimize timing) but does not explicitly state this or provide alternatives. It also lacks any mention of prerequisites, such as sufficient historical data, or cases where the tool might not be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' implies a read-only operation, and listing the specific output metrics adds useful context. However, it doesn't disclose potential behavioral details such as time range, data latency, or account-wide vs. sub-account scope, which could be relevant for interpreting the stats.
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 tight sentences: the first states what the tool does and lists the return metrics; the second gives usage guidance. No filler, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is reasonably complete. It tells the agent what data comes back and when to use it. It could mention any limitations (e.g., available time range, whether it's real-time), but the simplicity of the tool keeps the need for additional detail low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain input semantics, and it adds value by enumerating the exact metrics returned, which helps the agent understand the output.
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 gets aggregate email statistics with specific metrics: total sent, open rate, click rate, bounce rate, and complaint rate. The verb 'Get' plus the resource 'aggregate email statistics' is specific, though it doesn't explicitly distinguish from sibling 'get_campaign_analytics' other than by focusing on overall (aggregate) stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to understand overall sending health' provides clear context for when to use this tool. It doesn't mention alternatives or exclusions, but it gives a straightforward use case that differs from campaign-specific analytics.
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 burden. It discloses the core behavioral trait (scheduling for future delivery) and adds use-case context. However, it omits operational details like return values, timezone handling, prerequisites, or cancellation, which are relevant for a write-style tool without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scheduling tool with schema covering all parameters, the description is adequate for selection. It does not mention return values or how to cancel a scheduled email, and there is no output schema or annotations to fill that gap, leaving moderate 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 description coverage is 100%, so the schema already documents every parameter clearly. The description adds no parameter-specific semantics 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 clearly states the tool schedules an email for future delivery, with a specific verb ('schedule') and resource ('email'). It distinguishes itself from the sibling sendcraft_send_email by emphasizing 'future delivery' rather than immediate sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: reminders, follow-ups, drip messages, and any email that should go out at a specific time. It does not name alternatives or state exclusions, but the sibling list and 'future delivery' make the primary context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the main action (adding a domain) and the return value (DNS records), but does not mention side effects, prerequisites, uniqueness requirements, or whether verification is automatically triggered. This is a moderate disclosure, not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and outcome. It contains no filler and every phrase adds 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 one-parameter add operation with no output schema, the description adequately explains what the tool does and what it returns. It could mention the follow-up verification step with sibling tools, but that may be considered extra context; the core operation is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the single 'domain' parameter with a format example, providing 100% coverage. The description adds no additional parameter details, 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 a specific verb ('Add') and resource ('sender domain'), and clearly states the outcome (getting DNS records for SPF, DKIM, DMARC, BIMI). This distinguishes it from sibling tools like sendcraft_verify_domain or sendcraft_analyze_dmarc, which operate on existing domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for setting up a new sender domain, as opposed to verifying or analyzing existing ones. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose this tool when adding a domain.
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 present, so the description must carry the burden. It discloses the 100-email limit and that emails can have different fields, but does not mention partial failure behavior, rate limits, or response format, leaving behavioral uncertainty.
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 core capability, no redundant information. Every sentence adds 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 batch-send tool, the description covers the essential capability and limit. However, with no output schema and no mention of return values or failure semantics, it leaves some gaps 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 the 'emails' array described. The description adds minimal meaning beyond the schema, only clarifying that each email can have different recipient, subject, and body, which is already implicit in the schema structure.
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 tool 'Send up to 100 distinct emails in a single API call', uses the verb 'Send' with resource 'emails', and explicitly contrasts with send_email, distinguishing it from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes this is more efficient than calling send_email 100 times, implying use for batch sending distinct emails. However, it does not mention cases where it should not be used (e.g., sending the same email to many recipients) or provide alternatives like campaigns.
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 discloses that the campaign is not sent automatically, which is key, but it omits other important behaviors such as persistence, idempotency, validation, or what the return value is. This is a minimum viable 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 with zero filler. The first sentence states the core purpose; the second provides a necessary workflow pointer. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a rich schema, the description covers the essential create-then-send workflow and distinguishes from related tools. However, it lacks any mention of what happens on success (e.g., returned campaign ID) or error/failure behavior, which would improve completeness given there is no 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 parameters are already well-documented in the input schema. The description adds no additional parameter semantics or usage hints, 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 begins with 'Create a new email marketing campaign,' which is a specific verb and resource. It clearly distinguishes from sibling send tools by noting that after creation, one must call sendcraft_send_campaign to send it, establishing a two-step workflow.
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 instructs to call sendcraft_send_campaign after creation, giving clear context for when to use this tool. However, it does not explicitly mention exclusions or alternatives like sendcraft_send_email for one-off sends, though the workflow implication is sufficient.
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 implies a read-only operation via 'Retrieve', but does not disclose error behavior, auth requirements, or rate limits. Minimal but not misleading, hence a mid-range score.
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 and purpose, no filler. Every word adds value, making it highly concise and easily scannable.
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 with one parameter and no output schema. The description covers what it does, the use case, and the parameter source. However, 'details' is slightly vague and the return/error behavior isn't addressed, though this is borderline acceptable for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'email_id' with a helpful source note ('returned from send or list calls'). The tool description adds context about checking a specific email but does not add new syntax or format details beyond the schema, which is already 100% covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and clearly targets 'a single email by its ID', explicitly distinguishing from list operations. The phrase 'delivery status' adds precision and communicates exactly what the tool returns.
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 an explicit use case: 'check whether a specific email was delivered, opened, or bounced.' While it doesn't explicitly name alternative tools like sendcraft_list_emails, the context is clear for single-email status checks, which is sufficient for a simple retrieval tool.
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 behavioral disclosure burden. It implies a read-only operation (list) and mentions 'delivery status' as part of the result, which is useful. However, the phrase 'recently sent' is ambiguous—it could imply a default filter or ordering, and it may conflict with the schema's ability to list scheduled/cancelled emails. It does not explicitly state that the operation is safe/non-mutating, though that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage context. Every sentence contributes value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 optional parameters, good schema descriptions, and no output schema, the description is mostly complete. It provides use cases and result highlights (delivery status). However, it could be more precise about what 'recently sent' means and could mention that the tool supports pagination and filtering via parameters, which are already in the schema. Overall, it's sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description does not add much parameter-specific meaning beyond what the schema already documents. It obliquely references use cases (e.g., find a specific email) that could map to status/campaign filters, but it does not explain parameter behavior directly.
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 with a specific verb and resource: 'List recently sent emails with delivery status.' This distinguishes it from siblings like get_email (single email) and list_campaigns (campaigns). The qualifier 'with delivery status' adds specificity.
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 three clear use cases: 'audit what was sent, find a specific email, or monitor deliverability.' This gives the agent context for when to use this tool, but it does not explicitly mention alternatives (e.g., get_email for a specific email or get_stats for deliverability metrics) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation via 'List' but doesn't mention details like pagination, sorting, or output format. The behavioral context is minimal beyond the obvious.
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 two-sentence description is succinct and front-loaded with the primary action. Every word earns its place, with no unnecessary 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 listing tool with one optional parameter and no output schema, the description provides enough context about the tool's purpose and use case. It doesn't explain return values, but the tool name and description make the basic behavior 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 input schema fully describes the only parameter (limit with default 20), and the description adds no additional meaning beyond what the schema already provides. This 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 uses the specific verb 'List' and clearly identifies the resource as 'saved email templates.' This distinguishes it from sibling tools like sendcraft_send_email and sendcraft_create_template by focusing solely on the listing 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 second sentence provides context that templates can be reused across campaigns and transactional emails, implying this tool is useful when selecting a template for those purposes. However, it doesn't explicitly state when to use this over other list tools or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that sending is immediate and transactional, but it does not mention side effects, delivery guarantees, error handling, or the purpose of the idempotency key.
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 core action, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-email send tool, the description covers the core purpose and typical use cases. It could be more explicit about exclusions (e.g., scheduled or batch), but the schema fully documents 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 description coverage is 100%, so all 10 parameters are already documented. The description adds no additional parameter-level 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 sends a single transactional email immediately, and lists concrete use cases (order confirmations, password resets, notifications) that distinguish it from batch or campaign 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?
It specifies when to use this tool (one-off, user-triggered emails) and implies it is not for batch or scheduled sends, but it does not explicitly name alternative 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 burden of disclosing behavior. The word 'Check' implies a non-destructive read operation, but it doesn't explain what the response contains or what happens if DNS is misconfigured. Some behavioral detail is present but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides the core purpose and usage guidance. It lacks explicit return-value details, but the phrase 'confirm verification' implies a status result. Given the simplicity, this is reasonably 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%: the parameter 'domain_id' is adequately described as 'Domain ID from list_domains'. The tool description adds no extra meaning beyond the schema, so baseline 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 a specific verb ('Check') and resource ('DNS records for a domain'), clearly distinguishing this from siblings like add_domain or analyze_dmarc. It also states the expected outcome ('confirm verification').
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 tells the agent when to call this tool ('after updating DNS records'), which provides clear usage context. It doesn't explicitly list exclusions or alternatives, but the instruction is concise and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that keys are masked and never the full value, which is a critical safety-related behavior, and also discloses the information fields returned. It stops short of mentioning pagination, ordering, or any potential errors, but for a simple list tool, the given details are valuable and non-obvious.
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, compact sentence of about 17 words. It front-loads the main action ('List API keys'), then adds the most important behavioral note (masking) and the return fields. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers the essentials: what it does, the scope, and what the response includes. It could go further by noting the response structure (e.g., a list/array) or any authentication requirements, but the core information an agent needs to select and invoke the tool correctly is present. Slight gap in not mentioning how many API keys or whether the list is paginated, but this is acceptable for a simple resource list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so there is nothing to add about parameter semantics. The description instead clarifies what the output contains, which supports parameter understanding indirectly. The baseline for zero parameters is 4, and there is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List API keys for the account.' It uses a specific verb (list), identifies the resource (API keys), and scopes it to the account. This distinguishes it from sibling list tools like list_emails or list_campaigns, and even previews the response contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to view API keys for the account, and the mention of 'masked keys, permissions scope, and last-used date' gives context on what you can learn from it. However, it does not provide explicit when-to-use vs. when-not-to-use guidance, nor does it name any alternative tools, leaving the agent to infer based on the resource type.
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 must carry the full burden of behavioral disclosure. It does disclose return values (score, policy strength, issues to fix), but it does not explicitly state whether the operation is read-only, has side effects, or requires special permissions. The word 'Analyze' implies read-only, but this is 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 a single concise sentence (18 words) that front-loads the action and includes the key output summary. There is zero wasted content.
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, this description is sufficient: it explains the purpose, the prerequisite, and the return values (score 0-100, policy strength, issues) in enough detail for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has full coverage for domain_id, describing it as 'Domain ID from list_domains'. The description adds the constraint 'for a verified domain,' which gives extra semantic context beyond the schema, reinforcing which domain_ids are valid.
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 ('Analyze') and resource ('DMARC record for a verified domain'), clearly distinguishing this tool from the many sibling tools focused on sending, campaigns, and subscribers. The purpose is unambiguous and immediately actionable.
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 a verified domain' provides a clear prerequisite: the domain must already be verified. This gives context on when the tool is appropriate, though it does not explicitly exclude alternatives or mention 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?
With no annotations provided, the description carries the full burden. It clearly discloses that the tool is a status check and lists the exact return fields. The phrasing 'Check' implies a read-only operation, and the 'before sending large batches' note adds practical context. It does not explicitly state 'does not modify anything,' but for a zero-parameter status endpoint, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding meaningful value: what the tool checks, what it returns, and when to use it. It is front-loaded and contains 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, zero-parameter read tool, the description is complete. It explains the purpose, the return values, and the recommended usage context. No output schema exists, but the description directly covers what an agent needs to know, including how this fits into sending workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to compensate for schema coverage, and it adds no parameter information because none exist. This 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 the specific verb 'Check' and clearly names the resource: 'IP warmup status for the self-hosted SMTP server.' It distinguishes this tool from siblings by listing the specific data returned (current day, daily send limit, emails sent today, remaining quota) and the usage context (before large batches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Important to check before sending large batches.' It provides a clear use case, but does not mention alternatives or when not to use it beyond that context, which is a minor gap.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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