postmark-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes. The main ambiguity is among statistics tools: get_delivery_stats and get_outbound_overview both provide aggregate overviews, and get_bounce_counts overlaps with the bounce breakdown in get_delivery_stats.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case. Retrieval operations consistently use get_ for single items and list_ for collections, while action verbs like send, create, edit, delete, activate, validate, and search are used appropriately throughout.
Tool Count2/5
At 28 tools, this server exceeds the recommended range, feeling heavy and somewhat redundant. The statistics surface alone accounts for 7 tools with overlapping functionalities, which could be consolidated.
Completeness5/5
The tool set provides comprehensive coverage of Postmark's email capabilities, including sending, templates, suppressions, bounces, and outbound message tracking. CRUD operations are present where applicable, and the inclusion of search and validation tools ensures agents can fully manage the email lifecycle.
Average 4/5 across 28 of 28 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, establishing the tool as a safe, non-mutating operation. The description adds only that it returns a brief overview, which is a minor addition and does not disclose behavioral specifics like pagination or aggregation behavior. This is consistent with annotations, and the sparse extra context aligns with the lower burden set by the 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 a single, focused sentence that immediately states the action and resource. It contains no filler or repetition, and the key verb 'Get' is front-loaded, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of an output schema, and strong annotations, the description is minimally adequate. However, it lacks contextual guidance on how this overview relates to the many sibling statistics tools, and it does not explain what statistics are actually included, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage, with 'tag' and 'messagestream' lacking any description. The tool description does not add clarifying information about these parameters or the meaning of the date range filters, leaving potential ambiguity for the agent regarding what each parameter does.
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 retrieves a brief overview of statistics for outbound email, with a specific verb and resource. However, it does not explicitly differentiate itself from sibling tools like get_delivery_stats or get_sent_counts, which also deal with outbound statistics, so it lacks full distinction.
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 any exclusions, prerequisites, or suggest using other tools for more detailed data, leaving the agent without clear decision-making 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?
Annotations already declare readOnlyHint and idempotentHint true, so the safety profile is covered. The description adds the detail that results are broken down by bounce type, but it does not disclose other behavioral aspects such as date filtering behavior, handling of null parameters, or any potential rate limits. This is consistent with annotations, no 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?
The description is a single, front-loaded sentence that directly states the purpose. It contains no filler, repetition, or extraneous details. 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?
Given that an output schema exists, return values are presumably documented elsewhere. The description is adequate for a simple read-only tool, but it omits context around key parameters (tag, messagestream) and does not explain whether 'bounce type' refers to a fixed enumeration or custom categories. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (todate and fromdate have descriptions, while tag and messagestream do not). The description does not clarify the meaning of tag or messagestream, nor does it explain their role in filtering results. Since the description adds no parameter-level information beyond what the schema already provides, it fails to compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get counts of bounced emails, broken down by bounce type.' It distinguishes itself from siblings like list_bounces or get_bounce by focusing on aggregated counts rather than individual records, and the breakdown by bounce type adds further specificity.
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 compared to alternatives. It does not mention that this should be used for aggregate counts while list_bounces is for retrieving raw bounce records, nor does it suggest any exclusions or alternative scenarios. The intended use must be inferred from the name and 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds no additional behavioral context such as rate limits, auth requirements, or data scope (e.g., date range semantics). It does not contradict the annotations, but it also provides no extra value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function. There is no redundant information or filler, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are presumably documented elsewhere, and annotations cover safety. However, the description is minimal and does not address parameter semantics or usage context, leaving gaps for the undocumented 'tag' and 'messagestream' parameters. For a simple count tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; the parameters 'tag' and 'messagestream' lack descriptions in the schema, and the tool description does not explain them. The description adds no parameter-level meaning, failing to compensate for the undocumented fields. This leaves the agent uncertain about how to filter by tag or message stream.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('count of recipients who marked email as spam'), clearly distinguishing this tool from sibling count tools like get_click_counts or get_open_counts. It precisely identifies the metric (spam complaints) and the action (retrieving the count), leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_bounce_counts or get_sent_counts. It does not mention any prerequisites, exclusions, or explicit context for selection, leaving the agent to infer usage solely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description carries a lighter burden. It adds value by specifying 'unique' counts and the requirement for link tracking, which are behavioral notes not present in annotations. However, it omits further details like aggregation behavior, rate limits, or impact of suppressions.
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, fully front-loaded with the core action, and contains 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity, the description covers the core purpose but lacks usage guidelines and parameter explanations for tag and messagestream. The presence of an output schema reduces the need to explain return values, but the gaps in guidance and parameter semantics make it merely adequate, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, leaving tag and messagestream undocumented. The description does not explain these parameters or how they affect the counts. It only describes the result, not the input semantics, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets counts of unique link clicks, which is a specific verb+resource. It distinguishes from sibling tools like get_open_counts or get_sent_counts by focusing on clicks. The mention of 'requires link tracking' adds a condition without obscuring 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 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 unique link click counts and adds the prerequisite that link tracking is enabled. However, it does not explicitly mention alternatives or when not to use this tool. Siblings like search_message_clicks and get_open_counts exist, but no guidance is given to differentiate them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds the 'optionally bucketed over time' behavior, which is useful, but it does not disclose return format, default time ranges, or how bucketing works. With annotations lowering the bar, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core purpose and an optional behavior. No wasted words, appropriately concise for a simple read-only stats 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?
With an output schema and strong annotations, the description covers the basic purpose and optional bucketing. However, it omits the meaning of tag and messagestream parameters and provides no usage guidance, leaving meaningful gaps for an agent to understand full functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (todate/fromdate have descriptions; tag/messagestream do not). The description does not mention any parameters or explain how 'tag' or 'messagestream' affect results, failing to compensate for the missing schema descriptions. The phrase 'optionally bucketed over time' only hints at date parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the total count of sent emails' with an optional 'bucketed over time' qualifier. This distinguishes it from sibling tools like get_click_counts or get_open_counts by specifying 'sent emails' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving sent email counts and optionally grouping by time, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Sibling names are self-explanatory, yet the description provides no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds little beyond the fact that it returns a 'full detail record,' which is modestly useful context. No additional behavioral traits such as error handling, permissions, or rate limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the key action ('Get') and resource ('full detail record'). Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, rich annotations, and an output schema, so the description does not need to explain return values. It provides enough context for an agent to understand the core purpose. Though usage guidance is limited, the overall definition is adequate for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter bounce_id as a 'Numeric bounce ID,' giving 100% schema description coverage. The description's mention of 'single bounce' only implies that the ID identifies which bounce, but it does not add meaningful detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: 'Get the full detail record for a single bounce.' It uses a precise verb ('Get'), identifies the resource ('bounce'), and clarifies scope ('single bounce'), which distinguishes it from sibling tools like list_bounces or get_bounce_dump.
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 'single bounce' implies this tool is for retrieving one specific bounce when you have its ID, which provides some usage context. However, it does not explicitly state when to prefer this over list_bounces, get_bounce_dump, or activate_bounce, nor does it mention any exclusions or alternatives.
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 valuable behavioral context beyond the annotations: 'paginated; up to 10,000 results' discloses a result limit and pagination behavior. It does not describe sorting or default filter semantics, but the read-only/idempotent hints already cover safety, and this extra detail is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action, optionality, and a key behavioral constraint (pagination and limit).
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 an output schema, read-only/hints, and a clear purpose, the description covers the essential aspects for a search tool. The mention of pagination and the 10,000-result limit is crucial, though it doesn't address potential edge cases like sorting or default filter combinations, which are minor gaps given the schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 70%, leaving 3 parameters undocumented (tag, subject, messagestream). The description only says 'optional filters' and does not compensate for these gaps or add any per-parameter context, falling short of the baseline expected at this coverage level.
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 'Search outbound messages' with 'optional filters' and pagination, identifying the action and resource. It does not explicitly contrast with sibling search tools like search_message_opens or search_message_clicks, but the focus on 'outbound messages' provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when searching outbound messages, with optional filters and pagination controlling result size. It offers clear context but does not explicitly mention when not to use it or point to alternatives, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the specific detail that the tool returns the raw SMTP dump, which goes slightly beyond the annotations. However, it does not disclose other behavioral traits such as output size, encoding, or whether the dump includes full headers. With readOnlyHint and idempotentHint already declared, the description does not need to restate these, but it adds limited extra 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, clearly worded sentence that is front-loaded with the key action and resource. There is no filler or unnecessary repetition, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one well-documented parameter), strong annotations, and the existence of an output schema, the description is complete. It fully communicates what the tool returns (raw SMTP dump) without needing to explain return values, since the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter bounce_id ('Numeric bounce ID'). The description adds no additional meaning about this parameter, so the baseline score of 3 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as the 'raw SMTP source/dump' of a single bounce. This distinguishes it from sibling tools like get_bounce (likely parsed bounce data) and list_bounces (multiple bounces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies usage when raw SMTP is needed, but it does not state how this relates to get_bounce or when to prefer one over the other. This is implied but not clearly stated.
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 and idempotentHint, so the description need not restate those. It adds the key behavioral prerequisite that open tracking must be enabled, and clarifies that the count refers to recipients (implying unique recipients), which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the core action and resource, and immediately states the key requirement. Every word earns its place; no wasted text or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only count tool with an output schema and annotations, the description covers the essential purpose and prerequisite. It does not elaborate on filtering or return details, but the output schema can handle that, so the description is sufficiently complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (fromdate and todate have descriptions, but tag and messagestream do not). The description provides no additional parameter meaning, failing to compensate for the undocumented parameters or explain how filters like tag or messagestream affect the counts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get counts' and a clear resource 'recipients who opened emails', which precisely identifies the tool's function. It distinguishes from sibling tools like get_click_counts and get_sent_counts by specifying 'opened emails'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving open counts and mentions the prerequisite 'requires open tracking', but it does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks direct comparison with sibling count tools such as get_click_counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds pagination behavior and the dual scope of templates and layouts, but this is minimal additional context. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. Every word adds value, making it concise and well-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?
The description, combined with full schema coverage, comprehensive annotations, and an output schema, provides everything an agent needs to select and invoke this tool correctly. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description, defaults, and constraints. The description adds no further parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'templates and layouts' on the server, clearly distinguishing it from sibling tools like get_template (single entity) and create/edit/delete mutations. The mention of pagination further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear listing purpose but does not explicitly state when to prefer this over alternatives or when not to use it. No sibling comparisons or exclusions are mentioned, leaving usage context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds the important precondition that open tracking must be enabled, which is not covered by the readOnly/idempotent/openWorld annotations. This is a useful behavioral insight, though it does not detail what happens if tracking is disabled or how pagination behaves beyond schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes a key prerequisite in parentheses. 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?
The output schema and annotations cover return values and safety profile, while the description adds the open-tracking requirement. The main gap is the lack of parameter guidance for three filters, but overall the tool is simple enough that a capable agent can infer most usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% of parameters described in the schema (count and offset), the description should compensate by explaining tag, recipient, and messagestream. It does not, leaving these filters ambiguous beyond their names.
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 searches email open events across outbound messages, using a specific verb and resource. It distinguishes itself from siblings like search_message_clicks by focusing on opens rather than clicks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires open tracking) but does not explicitly discuss when to use this tool versus similar alternatives like search_message_clicks or get_open_counts. Usage is implied by the tool's purpose rather than explicitly guided.
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 context beyond annotations by noting the tool is blocked in read-only mode and by clarifying that it reactivates a deactivated address tied to a bounce. This complements the readOnlyHint=false annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a short operational note. Every word contributes to understanding the purpose and a key constraint, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is complete enough: it states the action, the target resource, and an important operational limitation. The output schema covers return values, so those do not need description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter bounce_id is fully described in the schema as 'Numeric bounce ID to reactivate.' The description adds no additional semantic context about the parameter, so with 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'reactivate' and clearly identifies the resource: a deactivated address tied to a bounce. This distinguishes it from sibling tools like list_bounces or get_bounce, which are read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an address tied to a bounce needs to be reactivated, but it does not explicitly state when to use this tool versus alternatives or give exclusions beyond the read-only mode block. The 'BLOCKED in read-only mode' note provides some context but not full 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 that the operation is blocked in read-only mode, which is a behavioral trait beyond annotations' readOnlyHint:false. It also specifies the validation requirement for html_body/text_body, adding useful operational context. No contradiction with annotations; readOnlyHint:false aligns with a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with purpose first, no filler. The first sentence states the action, the second gives a key constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and low schema coverage, the description leaves significant gaps: it doesn't clarify template_type vs layout_template relationship, the subject requirement for Standard templates, or alias uniqueness. The presence of an output schema does not compensate for missing parameter semantics and conditional rules.
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 only 43%, so the description must compensate. It adds the critical rule 'Provide at least one of html_body or text_body' and mentions 'template or layout' hinting at template_type, but does not explain html_body, text_body, layout_template, or the conditional subject requirement for Standard templates. Partial compensation but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with the resource 'template or layout', clearly distinguishing it from sibling tools like edit_template, delete_template, or send_email_with_template. It also states a key requirement (at least one body) that clarifies the action further.
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 mentions the tool is blocked in read-only mode and requires at least one of html_body or text_body, giving clear operational context. However, it does not explicitly contrast with alternatives like edit_template or validate_template, only implying when to use via the word 'new'.
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 significant context beyond the annotations: it reveals that deletion actually means reactivation, that SpamComplaint suppressions are excluded, and that the operation is blocked in read-only mode. These details complement the destructiveHint and readOnlyHint annotations without contradicting them. The 50-address limit is also disclosed. This is useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, with the main action and limit in the first, and two key exceptions in the second. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple tool with 2 parameters and an output schema, the description covers the core action, a key exception, a usage restriction, and a limit. It could explicitly mention the inverse relationship with create_suppressions or describe error/return behavior, but the presence of an output schema reduces that need. Overall, it is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already fully described in the input schema (100% coverage): stream_id includes a default and 'Message stream ID', while email_addresses says 'Up to 50 addresses to remove/reactivate.' The tool description mostly repeats this information and adds only a small context clue ('from a stream's suppression list'). With full schema coverage, the baseline of 3 is appropriate; the description does not materially enrich parameter meaning.
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 'Remove' with a clear resource ('stream's suppression list') and explains the action ('reactivate them'). It distinguishes the tool from siblings like create_suppressions and list_suppressions by framing it as removal/recovery rather than addition or listing. It also includes a constraint (SpamComplaint suppressions cannot be deleted), making the purpose even more precise.
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?
Usage is implied: the tool should be used when you want to re-enable previously suppressed addresses. However, it does not explicitly contrast it with alternatives like create_suppressions or list_suppressions, nor does it state clear conditions for when not to use it beyond the SpamComplaint exception. The read-only mode note is a constraint but not an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds the per-type bounce breakdown, which is more about output content than behavioral traits. No additional context (e.g., pagination, rate limits, aggregation behavior) is disclosed, but the annotations lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and object. Every word adds value, with no fluff or repetition of the title. 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.
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 no parameters and has an output schema, so the description does not need to explain return values in detail. The phrase 'aggregate delivery statistics' plus 'per-type bounce breakdown' gives a clear enough picture. However, it could slightly elaborate on the scope of 'delivery statistics' (e.g., success rates, volume) to fully close the gap, even though the output schema likely covers this.
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 add parameter details, but none are needed. The schema shows no properties, and the description's mention of 'per-type bounce breakdown' hints at what the output will contain, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('aggregate delivery statistics') and adds a distinguishing detail ('including a per-type bounce breakdown'). This differentiates it from sibling tools like get_sent_counts and get_bounce_counts, which focus on individual metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain a high-level overview of delivery statistics, but it does not explicitly state when to choose this over other specific stat tools (e.g., get_bounce_counts) or mention any exclusions/alternatives. Usage context is inferred but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description only needs to add scoping context. It explains that suppressions are listed per message stream with optional filters, but does not describe details like pagination, default behavior, or stream fallback. This is similar to the get_calls calibration case, where scope is added but not deep behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the operation and key qualifiers with no redundant wording. 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?
With a well-documented schema (6 optional params, 100% coverage), an output schema, and strong annotations, the description is mostly complete. It could include a hint about common stream_id values or pagination, but these are available in the schema, making the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter (origin, todate, fromdate, stream_id, email_address, suppression_reason) has a clear description. The main description only says 'optional filters' and does not add meaning beyond the schema, so the 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 ('List') with a clear resource ('suppressions') and scope ('for a message stream'). It distinguishes from sibling tools like create_suppressions, delete_suppressions, and list_bounces by targeting suppressions specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clear context ('for a message stream, with optional filters') but does not explicitly mention when to use this tool over alternatives or provide exclusionary guidance. However, the context is sufficient for an agent to infer its list-oriented purpose.
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 readOnly, openWorld, and idempotent hints. The description adds a meaningful behavioral constraint—'requires link tracking'—which is non-obvious and not present in the schema. This improves transparency without contradicting 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, front-loaded sentence that immediately states the tool's purpose and includes a critical prerequisite in parentheses. Every word earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 optional filters, the description covers the core purpose and a key prerequisite, and the output schema reduces the need to explain return values. However, it omits guidance on filtering semantics and pagination, which limits its completeness for an agent deciding how to invoke it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (only count and offset have descriptions). The tool description does not explain the meaning or usage of tag, recipient, or messagestream, nor does it add details beyond the schema. With low schema coverage, the description should compensate but fails to do so.
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 ('Search') and resource ('link click events across outbound messages'), clearly distinguishing this from sibling tools like search_message_opens and get_click_counts. The parenthetical '(requires link tracking)' adds useful scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: to find link click events on sent messages, and it adds an important prerequisite ('requires link tracking'). However, it does not explicitly name alternative tools or exclusion cases, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Persists nothing (safe to run)', which goes beyond the annotations by explicitly stating side-effect-free behavior. The readOnlyHint and idempotentHint are present, and the description reinforces them without contradiction. This adds useful context about safety, though it does not elaborate on rate limits or exact behavior during rendering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core purpose, then provides the safety guarantee and a necessary input requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and an output schema, the description covers purpose, safety, and the main input constraint. It does not explain the meaning of layout_template or template_type, but the output schema likely defines return structure. Given the sibling context and annotations, it is reasonably complete, though not exhaustive.
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 only 14%, so the description carries the burden for parameter meaning. It adds a key constraint: at least one of subject, html_body, or text_body must be provided, which is not encoded in the schema. However, other parameters like template_type, layout_template, and inline_css_for_html_test_render remain unexplained, leaving gaps in semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Validate and render-preview template content.' This specific verb+resource combination distinguishes it from sibling tools like create/edit/delete template or send_email. The preview aspect makes it stand out from simple get_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pre-send validation but does not explicitly state when to use this tool vs alternatives. It provides a parameter requirement ('Provide at least one of subject, html_body, or text_body') and a safety note, but no direct comparison to other tools. This is implied usage rather than explicit 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?
Annotations already indicate write/destructive behavior, and the description adds valuable context: 'Only provided fields change' explains merge semantics, and 'BLOCKED in read-only mode' warns about operating mode. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action, with no wasted words. It efficiently conveys the action, partial-update semantics, and the read-only restriction.
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 an output schema present, return details are not needed. The description covers the essential behavior (update existing, partial fields, read-only block) and the field list is available in the schema. It is sufficiently complete for a simple edit tool, though it could mention prerequisites or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only template_id_or_alias has a description). The description's general statement about partial updates is helpful but does not explain individual parameters like layout_template or html_body. Given the low coverage, the description should compensate more but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing template') with a specific verb and resource, distinguishing it from sibling tools like create_template and delete_template. The additional phrase 'Only provided fields change' clarifies the partial-update semantics, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—when modifying an existing template—and mentions the behavioral rule 'Only provided fields change.' It does not explicitly name alternatives like create_template, but the context is sufficient given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the dual lookup mechanism ('by ID or alias') which is a useful behavioral detail, but it does not disclose error behavior, such as what happens when the template is not found. With annotations present, the bar is lower, and the description provides minimal but non-redundant 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, well-structured sentence that front-loads the action and object. Every word contributes meaning ('Fetch a single template's full details by ID or alias.'), with no fluff or repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple single-parameter schema, an output schema (so return format is not needed), and robust annotations. The description fully covers the operational need: fetching a single template by identifier. It is complete for the tool's complexity and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter (template_id_or_alias) with a description that exactly matches the tool description ('Numeric template ID or alias'). The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and identifies the resource ('single template') with a clear scope ('full details by ID or alias'). This distinguishes it from sibling tools like list_templates (which lists all) and create_template/edit_template/delete_template (which mutate). 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 description implies when to use this tool: when you need a single template's full details, as opposed to listing templates or performing mutations. It clearly contrasts with list_templates, but does not explicitly mention sibling alternatives or state 'use this instead of X'. The context is clear enough for an agent to select it appropriately.
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 mark this as read-only and idempotent. The description adds behavioral context beyond annotations: pagination behavior and a hard cap of 10,000 results. This gives the agent useful expectations about response volume and limitations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It states the core action and key constraints (optional filters, pagination, max results) in ten words, with no redundant wording 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 this is a straightforward search/list tool with a rich input schema and an output schema present, the description covers the essential selection and invocation cues. It omits an explicit comparison to siblings like get_bounce, but this is not critical for a self-explanatory list function. The 10,000-result cap is a useful completeness detail.
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 80%, and the input schema itself includes descriptions for most parameters (count, offset, fromdate, todate, etc.). The description's phrase 'optional filters' adds a high-level grouping but does not explain specific parameters beyond the schema. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('bounces'), and the primary capability ('optional filters'). It also adds pagination and a result limit, which distinguishes it from related tools like get_bounce (single bounce) and get_bounce_counts (counts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to search/filter a list of bounces. The pagination info and optional filters set clear context for a list operation. It does not explicitly name alternatives or exclusions, but the core use case is obvious enough for a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context beyond annotations: 'Requires html_body and/or text_body' clarifies a mandatory condition, and 'BLOCKED in read-only mode' discloses an execution constraint not inferable from annotations alone. No 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?
Two short sentences, front-loaded with the core action, then a requirement and a critical constraint. Zero waste, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 14 parameters and an output schema, but the description covers the essential constraints (single, direct content, body requirement, read-only blocking). It does not explicitly guide toward sibling tools for batch/template needs, which would round out the context, but it is adequate for the 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 71%, so baseline is 3. The description reiterates the html_body/text_body relationship already present in the schema, but adds no new semantic detail about parameters. It does not clarify the remaining 29% of parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a single email with content supplied directly', which is a specific verb+resource+scope. It implicitly distinguishes from sibling tools like send_email_with_template and send_email_batch by emphasizing 'single' and 'content supplied directly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (single, direct content) versus alternatives (templates/batch) through the phrase 'single email with content supplied directly'. However, it does not explicitly name alternatives or state when not to use them, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond the annotations: it discloses the read-only mode block, the template selection constraint, and that the subject is derived from the template. This complements the annotations (readOnlyHint=false, destructiveHint=true) without contradicting them. It does not cover all side effects, but the annotations already signal destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with every sentence serving a purpose: the main action, the key parameter constraint, and a critical behavioral note. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 params, nested objects) and the presence of an output schema and annotations, the description covers the most complex parts: template selection and the read-only block. The schema handles required params like from_email, to, and template_model with its own descriptions. Slight shortfall is that it doesn't summarize the full parameter list or mention the output behavior, but the output schema mitigates that.
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 only 33%, so the description must compensate. It adds important meaning for template_id/template_alias by explaining the XOR constraint and that the subject comes from the template. However, many other parameters (cc, bcc, tags, headers, tracking options) are left to their names alone, and the description does not clarify them. Partial compensation only.
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 'Send a single email rendered from a stored template,' which uses a specific verb and resource while distinguishing this tool from siblings like send_email and send_email_batch. It clearly indicates the scope (single email) and the method (stored template).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that exactly one of template_id or template_alias must be provided, and that the subject comes from the template. It also notes the tool is BLOCKED in read-only mode. This gives clear context for when to use it, but it does not explicitly mention alternatives or when not to choose this tool over send_email or batch variants.
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 that deletion is permanent and that the operation is blocked in read-only mode, adding context beyond the annotations' destructiveHint and readOnlyHint. This clarifies irreversibility and an operational restriction not fully captured by the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action in the first sentence and an important caveat in the second. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool with an output schema available, the description covers the essential behavior, the condition under which it is blocked, and the parameter type. It is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully described in the schema ('Numeric template ID or alias'), and the description also mentions ID or alias. Since schema coverage is 100%, the description adds no extra semantic 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 starts with 'Permanently delete a template by ID or alias,' clearly identifying the action (permanently delete) and resource (template). This distinguishes it from siblings like create_template, edit_template, and get_template.
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 an explicit exclusion: 'BLOCKED in read-only mode,' which tells the agent when not to use it. However, it does not name alternative tools for non-permanent changes, so it stops short of full when/when-not 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety and side-effect profile. The description adds value by revealing the response includes body and message events, which helps the agent anticipate what data will be returned. This goes beyond mere annotation repetition.
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, tightly-worded sentence that front-loads the key action ('Get full detail for one outbound message') and adds a clarifying detail ('including body and message events'). Every word earns its place with zero 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?
Given the tool's simplicity—one required parameter, an output schema is present, and annotations provide safety context—the description is fully sufficient for an agent to select and invoke the tool correctly. No further behavioral or structural information is 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?
The input schema fully describes the single parameter message_id with the description 'Postmark outbound message ID,' giving 100% schema coverage. The tool description does not add any additional meaning or usage guidance for this parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'full detail for one outbound message', and clarifies the scope by noting 'including body and message events.' This clearly distinguishes it from sibling tools like 'search_outbound_messages' (which implies searching/filtering) and 'get_outbound_overview' (which implies a summary).
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 conveys a clear context for use: when you need full detail for a single outbound message. It does not explicitly list alternatives or exclusions, but the sibling tool names (e.g., search_outbound_messages, get_outbound_overview) make it obvious when this specific tool is appropriate, earning a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds valuable behavior details: returns one result per message, instructs to inspect each element's ErrorCode/Message, and notes that the tool is BLOCKED in read-only mode. This provides actionable context beyond the structured fields without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a clear purpose: stating the core function, explaining the response format, and warning about read-only mode. No redundant or filler content; information is front-loaded with the primary 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?
Given that an output schema exists, the description does not need to detail return fields beyond the critical note about per-message ErrorCode/Message. The 500-message limit, template-rendering capability, and read-only block are all covered. The description is sufficient for an agent to select and invoke this tool correctly relative to its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage for the single 'messages' field, including explanation of nested objects (TemplateId/TemplateAlias, TemplateModel, From/To). The tool description does not add additional parameter semantics, but none are needed because the schema is thorough. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send up to 500 template-rendered emails in one request.' This specifies the verb (send), resource (emails), and key constraints (batch, template-rendered). It also distinguishes from siblings like send_email_batch (which lacks template rendering) and send_email_with_template (which sends a single message).
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 use cases: sending multiple template-based emails efficiently in a single API call. It gives a clear context (batch + templates) but does not explicitly exclude alternatives like send_email_batch (non-template) or send_email_with_template (single). Since sibling names alone provide strong differentiation, this is a minor omission.
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 annotations (readOnlyHint=false, destructiveHint=true), the description adds crucial behavioral context: HTTP 200 returned even when individual messages fail, requiring per-message ErrorCode/Message inspection. It also explicitly states the read-only block condition, aligning with the destructive annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core action and limit. No wasted words, and essential behavioral warnings are included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description wisely calls out the non-obvious behavior that HTTP 200 does not imply per-message success. It also covers the batch size limit, field-name expectation, and read-only restriction. This is sufficient for a moderate-complexity batch 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 provides high coverage (100%) for the single 'messages' parameter, describing Postmark field names and the 500-message limit. The description adds little parameter-specific meaning beyond 'individually-composed,' which is somewhat redundant with the schema's 'message objects' detail. The return-value note does not directly enhance parameter 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 uses a specific verb ('send') with a clear resource ('email batch') and scope ('up to 500 individually-composed emails'). It distinguishes from siblings like 'send_email' and 'send_email_batch_with_templates' by emphasizing individual composition rather than templates or single sends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for batch email sending (up to 500) and explicitly warns about read-only block. It does not explicitly name alternatives or state when not to use, but the context is clear given sibling tool names and the 'individual' qualifier.
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 annotations: the 50-address limit and the read-only blocking behavior. These are not present in the annotations, which only declare readOnlyHint=false, destructiveHint=false, etc. No contradiction exists; the write nature is consistent with readOnlyHint=false.
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: the first states the core action and scope, the second adds a critical restriction. No filler or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-described parameters, output schema, and annotations, the description is complete. It covers the action, limit, and a key behavioral constraint (read-only blocking). No other contextual gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both stream_id and email_addresses. The tool description does not add parameter-level detail beyond this, so it meets the baseline for high schema coverage but does not enhance it further.
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'), names the resource ('suppression list'), and specifies scope ('up to 50 addresses', 'a stream's'). It clearly distinguishes from siblings like delete_suppressions and list_suppressions by focusing on the create/add action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it is for adding addresses to a suppression list, with a clear limit. It also gives a when-not condition ('BLOCKED in read-only mode'), which is an explicit exclusion. While it doesn't name an alternative tool, the when-not guidance qualifies as explicit usage direction.
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:

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

Score Badge

Copy to your README.md:

[![postmark_mcp MCP server](https://glama.ai/mcp/servers/zonnepanelendelen/postmark_mcp/badges/score.svg)](https://glama.ai/mcp/servers/zonnepanelendelen/postmark_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/zonnepanelendelen/postmark_mcp'

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