stalwart-jmap-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 target distinct resources (accounts, domains, queue, IPs, emails), but list_accounts and list_principals overlap since accounts are principals of type 'individual', and list_objects can list many types already covered by dedicated list tools. Descriptions mostly clarify, but the duplication creates minor ambiguity.
Naming Consistency4/5
All tools use the stalwart_ prefix and mostly follow verb_noun naming (list_accounts, create_domain, delete_queue_message). Exceptions like server_info (noun-only) and queue_pause/queue_resume (noun-verb instead of verb-noun) break the uniform pattern, but the overall style is still predictable.
Tool Count2/5
With 39 tools, this server is excessively large for an MCP interface. Even for a broad mail server admin domain, the sheer number of tools makes selection harder and suggests over-fragmentation, exceeding the 25+ threshold for 'too many'.
Completeness3/5
The tool set covers many admin operations (accounts, domains, queue, IP blocks, mailing lists) but only provides read-only access to identities, vacation responses, and Sieve scripts—no create/update/delete for these. This leaves notable gaps for full lifecycle management.
Average 4/5 across 39 of 39 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'min length enforced by server' but omits critical traits like permissions required, impact on existing sessions, or whether the account must exist. The mutation nature is implied but not elaborated.
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 and front-loaded, with a clear one-line summary followed by a compact args section. No filler or redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutation tool with no annotations, the description is incomplete. It doesn't cover side effects, authorization, error scenarios, or prerequisites. The output schema exists, so return values are not needed, but behavioral context is missing.
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 0%, and the description only restates 'account id' and 'new password', adding minimal meaning beyond the parameter names. It mentions server-enforced min length but lacks format, constraints, or examples.
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 'Reset an account's password' with a specific verb and resource. It distinguishes from siblings like create/delete account by focusing specifically on password reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., account must exist), or exclusions. The description simply states the action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that tokens are masked, which is a useful security detail. However, it does not mention other behavioral aspects such as read-only nature, pagination, or any side effects, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource, with a useful parenthetical. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is very thin. It lacks details about pagination/limit behavior, what happens when no keys exist, and any authorization or scope context. With 0% schema parameter coverage and no annotations, the description is insufficient to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The parameter name is self-explanatory, but the description adds no meaning beyond the schema, and with zero coverage, it fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') on a specific resource ('Stalwart API keys'), which clearly distinguishes it from sibling tools like list_accounts or list_domains. The parenthetical also adds a distinguishing feature about masked tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: if you need to list API keys, use this tool. However, there is no explicit guidance about when to use it versus alternatives like create_api_key or delete_api_key, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'List' clearly implies a read operation, but it does not disclose potential nuances such as whether scripts are returned by name only, ordering, pagination, or permission requirements. The simple verb provides baseline transparency but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is appropriately brief for a simple list operation, though it could benefit from a bit more contextual detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the basic purpose but lacks usage guidance and context about when to use it versus sibling tools. It is minimally viable but leaves gaps in situational understanding.
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 schema has 0% parameter description coverage and the tool description does not explicitly explain the account_id parameter. The phrase 'of an account' loosely implies it, and the parameter name is self-explanatory, but the description adds minimal value beyond the schema's existing 'account_id' title.
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 'List Sieve filter scripts of an account' uses a specific verb and resource, clearly distinguishes this from sibling tools like list_domains or list_identities, and specifies the scope (per account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention appropriate contexts, prerequisites, or exclusions, leaving users to infer that it is the tool for Sieve scripts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' implies a read-only operation, but the description does not disclose pagination behavior, whether a limit applies, or any other operational details. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no redundant information. It is concise and front-loaded, covering the essential purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and an output schema, the description is adequate but not rich. It fails to clarify how 'limit' works or what 'configured' precisely includes, leaving some gaps for the agent to infer.
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 0% and the description makes no mention of the 'limit' parameter. Although the parameter name and default value in the schema are somewhat self-explanatory, the description adds no further meaning or usage context.
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 'mail domains' and scope 'configured in Stalwart'. This cleanly differentiates it from sibling tools like create/delete domain or list accounts.
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 statement implies when to use the tool: whenever mail domains need to be listed. However, it offers no explicit guidance about when not to use it or alternatives, which would be helpful given the many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not explicitly disclose read-only behavior, side effects, or authentication requirements; the verb 'Get' weakly implies a safe read, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, front-loaded sentence with no filler; every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema and a single optional parameter, the description conveys the core function; the absence of behavioral details is a gap but not fatal for this simple read tool.
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 0%, and the description does not explain account_id beyond 'of an account'; it provides minimal semantic context but no format, requiredness, or relationship to other tools.
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 'Get auto-reply (vacation response) settings of an account' with a specific verb and resource, clearly distinguishing this tool from sibling get_* tools by focusing on vacation-response settings.
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 only implies when to use it (when needing an account's auto-reply settings); it does not mention alternatives like get_account or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It explains that the list returns a 'compact summary' but does not disclose side effects, authentication requirements, pagination behavior, or sorting/ordering. The read-only nature is implied but not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, with a clear purpose statement and a structured Args section. Every sentence adds value, and the parameter explanations are efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is mostly complete. It covers purpose and parameter semantics, but lacks explicit guidance on use cases or interactions with other account-related tools, which is a minor gap for a list operation in a larger toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: 'limit: max rows (default 50)' and 'search: optional substring match on account name'. This adds meaningful semantics beyond the raw schema types and defaults.
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 'List mail accounts (users) with a compact summary', using a specific verb and resource. It differentiates from sibling list tools like list_domains or list_mailboxes by focusing on accounts, though it does not explicitly contrast with stalwart_list_principals which may also cover accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to prefer get_account for details or list_principals for broader principal listing. The description only explains the parameters, not the intended context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states the action 'pause' but does not reveal whether the operation is reversible, whether it affects all outbound messages, or whether it requires administrative privileges. No side effects or implications 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 concise sentence that immediately identifies the action and target. It contains no filler and is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is minimally adequate but lacks important context about the effects of pausing (e.g., that queue processing stops until resumed) and the relationship to stalwart_queue_resume. This leaves some gaps for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all inputs. The baseline of 4 applies, and the description adds no additional parameter-level context, which is acceptable since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pause' and a clear resource 'outbound MTA queue processing', which unambiguously identifies the operation. It distinguishes from sibling tools like stalwart_queue_resume and stalwart_list_queue by naming the exact action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or how it relates to alternatives such as stalwart_queue_resume. There is no mention of prerequisites or expected effects, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It states the action but does not explain side effects, whether it is read-only, what 'live' means, or what the output structure looks like. The description lacks any behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one clear purpose sentence followed by a structured parameter list. There is no redundant or extraneous text, and each line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and parameter meanings, and the presence of an output schema reduces the need to document return values. However, it lacks usage context such as when to invoke this tool, what to expect from the results, and any limitations or prerequisites. This makes it minimally viable but not comprehensive.
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 Args section adds meaningful definitions for each parameter (e.g., 'message: full RFC 5322 message' and 'remote_ip: connecting IP'). This compensates for the schema's 0% description coverage and helps the agent understand exactly what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a live DMARC/SPF/DKIM/ARC troubleshoot on a message,' which is a specific verb+resource statement. It clearly distinguishes this tool from the sibling tools, most of which handle account/domain management, by focusing on message authentication troubleshooting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related tools like classify_spam, so the usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without detailing idempotency, side effects, or behavior when the queue is already running. This leaves the agent unaware of potential error conditions or state changes.
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 states the action and target without any redundant or extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an existing output schema, the description conveys the core purpose sufficiently. However, it could be more complete by explicitly linking to stalwart_queue_pause or noting idempotency behavior. The overall complexity is low, so the minimal description is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of the (empty) parameter set. The description adds no parameter details, but none are necessary. A baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "Resume" with a clear resource "outbound MTA queue processing", which precisely distinguishes it from the sibling tool "stalwart_queue_pause". It immediately conveys the tool's function 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as stalwart_queue_pause or stalwart_list_queue. There is no mention of prerequisites (e.g., queue must be paused) or typical invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('Add') without revealing side effects, requirements, or validation rules, such as whether the domain must be unique or whether DNS changes are needed. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the purpose, and includes an args block that directly addresses the only parameter. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description adequately states the core action. However, it omits any context about prerequisites, side effects, or relationships to other domain operations, leaving gaps that an agent would need to infer or discover elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a title for the 'name' parameter with no description (0% coverage). The tool description adds meaning by giving an example ('e.g. example.com') that clarifies the expected format. This compensates well for the schema gap, though it could be more detailed about constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new mail domain' with a specific verb and resource. It distinguishes from sibling tools like delete_domain and list_domains, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for creating domains, but it provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. Usage is inferable from the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral aspects. It only explains the boolean parameter's meaning but does not state whether the operation is destructive, requires privileges, or has performance impacts. The term 'negative caches only' is unexplained.
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: a two-word action phrase and a structured argument definition. Every word adds value, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the core operation and parameter effect. However, it lacks any context on when cache invalidation is necessary or what side effects to expect, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a boolean with default false and no description. The tool description explicitly maps True to invalidating all caches and False to negative caches only, fully clarifying the 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 opens with a clear imperative 'Invalidate server caches,' specifying the action (invalidate) and target (server caches). This is distinct from sibling tools like reload_settings or queue management, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as stalwart_reload_settings. It fails to mention use cases like 'after configuration changes' or when cache inconsistencies are suspected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It correctly indicates a read operation (list), which is safe. But it does not describe potential side effects, permission requirements, or behavior when account_id is omitted (e.g., defaulting to 'b'), which would be useful 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, front-loaded sentence with no filler words. It states the resource and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list with an output schema (which presumably describes the return format). The description covers the purpose and scope adequately. However, the unresolved parameter semantics (account_id) and lack of any behavioral caveats prevent a perfect completeness score.
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 0% – the description never mentions the account_id parameter. While 'of an account' hints at the parameter, it does not explain the default behavior or what values are acceptable. The schema provides only a type and default, leaving semantics unclear. The description fails to compensate.
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 'List sending identities (From addresses) of an account' uses a specific verb and resource, clearly distinguishing this from sibling list tools (list_accounts, list_domains). The parenthetical '(From addresses)' adds precision about what identities are.
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 from the tool name and context (listing identities for an account). However, there is no explicit guidance on when to prefer this over related tools, nor exclusions or alternatives like a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only notes the use of the standard JMAP principals namespace, but does not state that the operation is read-only, whether it requires special permissions, how pagination works (beyond limit), or what the response looks like. This is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a one-sentence purpose, a protocol note, and an Args section. Every line adds value, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter listing tool with an output schema, the description is adequate but not complete. It does not explain how results are ordered, whether all types are included when no principal_type is given, or how this tool relates to sibling list tools. The output schema presumably covers return values, but some contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description must compensate. It does by enumerating all accepted principal_type values (individual, group, list, domain, tenant, role, apiKey, oauthClient, resource, location) and explaining limit as max rows with a default. This adds meaningful guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists principals and enumerates the types (users/groups/lists/domains/roles/tenants). This is a specific verb+resource+scope that distinguishes it from sibling list tools like list_accounts or list_domains.
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 parenthetical list of principal types implies that this tool is the broad listing tool for all principal kinds, while siblings like list_accounts or list_domains cover specific subsets. However, no explicit when-to-use or alternatives are mentioned, leaving the guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return content but does not mention side effects, authentication requirements, or rate limits. The name suggests read-only behavior, but it is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action and lists specific return fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with zero parameters and an output schema present. The description sufficiently explains what the tool does, and the output schema details the return structure. No further context is needed for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. Baseline for 0 params is 4, and the description adds no unnecessary detail.
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 verb ('Return') and resource ('Stalwart server info'), listing specific items (edition, capabilities, account used). This distinguishes it from sibling tools, as no other tool focuses on general server info.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools for similar tasks. The purpose is implied, but no explicit usage context is provided.
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 discloses a critical behavioral trait: the token is shown only once in the response. However, with no annotations, it does not mention whether special permissions are required to create a key, or any side effects beyond the one-time token display. This is moderately transparent but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence stating the core action, a note, and a tidy Args list. Every sentence earns its place, and the most important information (token shown once) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a create operation with two parameters. The token-displayed-once caveat is critical and present. An output schema exists, so return details need not be in the description. It lacks mention of prerequisites or permissions, but overall it is adequately complete given the simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries full responsibility for explaining parameters. It does so effectively: 'description' is marked required, and 'permissions' has a default of server default. The note clarifying that the object has no 'name' field prevents confusion. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new API key' with the crucial caveat that the token is shown once. This specific verb+resource structure distinguishes it from siblings like list_api_keys and delete_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The note about the ApiKey object having no 'name' field is more about parameter usage than usage context. No mention of scenarios where creating an API key is appropriate or when to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states that an IP is blocked and lists parameters; it does not mention side effects (e.g., whether the block applies immediately, whether it blocks all mail from that IP, or if it is reversible by unblock_ip). It also doesn't clarify if a missing expiry means a permanent block.
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 with a clear first sentence and a structured Arg list. Every parameter is briefly explained without redundancy, making it efficient to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameter semantics, which is adequate for a simple blocking operation with an output schema present. However, it omits guidance on undo behavior and side effects, so it is not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by defining 'address' as 'IP or CIDR', making 'reason' optional, and specifying 'expires_at' as an optional ISO 8601 UTC timestamp with a concrete example. This adds meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Block an IP address (spam defense),' which is a specific verb-resource pair that clearly states the tool's function. It distinguishes from sibling tools like 'stalwart_unblock_ip' and 'stalwart_allow_ip' by focusing on blocking.
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 '(spam defense)' implies the use case (blocking malicious senders), but there is no explicit statement of when to use this tool versus alternatives like allow_ip or unblock_ip. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure. It transparently lists allowed obj_type values and the limit default, but does not explicitly state read-only behavior, permissions, or error semantics. 'Listing' implies a safe read, yet this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring with a two-sentence summary and a concise Args block. Every word contributes meaning, 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?
Given the simple nature of the tool and the presence of an output schema, the description is mostly complete. However, it lacks any mention of alternative dedicated list tools or authentication requirements, which would further help an agent choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions, but the description fully compensates by listing all valid values for obj_type and explaining limit as 'max rows (default 50)'. This adds complete meaning to every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Generic listing for admin object types' and enumerates all supported object types, providing a specific verb and resource. It distinguishes itself from sibling dedicated list tools (e.g., stalwart_list_accounts) by being explicitly generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this generic tool versus the specific list tools for accounts, domains, etc. The description implies a fallback role but does not explicitly state when to prefer it or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions impersonation capability but fails to disclose read-only nature, pagination behavior beyond limit, or required permissions. This is a significant gap for a search tool without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence overview plus a compact Args list. Every line adds value and is front-loaded with the tool's purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers all parameters and override behavior. It lacks contextual notes about when to use vs siblings, but that is more of a guidelines issue; the invocation semantics are complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides concrete meaning for all five parameters: account_id special value 'b', mailbox_role allowed values, mailbox_id override, text search scope, and limit default. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search emails in an account' with a specific verb and resource. It distinguishes from siblings like get_email (single retrieval) and list_mailboxes (folder listing).
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 alternatives are given. The parameter descriptions imply usage for searching, but no exclusions or references to sibling tools like get_email are provided, leaving the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly labels the operation as 'Destructive' and states that confirm must be True to proceed, which is valuable safety information. However, it does not disclose any additional behavioral details such as reversibility, side effects, or the nature of the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the action, the second warns about destructiveness, and the argument list is presented clearly. Every sentence earns its place with minimal 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 only two parameters, and the description covers the essential usage (how to get ip_id, confirm requirement). An output schema exists (as per context), so the lack of return value details is acceptable. The description is sufficient for a straightforward operation, though it could mention any side effects or prerequisites beyond the confirm flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type information (string, boolean) with no descriptions. The description compensates by explaining that ip_id is a 'blocked ip id (from stalwart_list_objects(obj_type='blocked_ip'))' and that confirm 'must be True to proceed'. This adds meaningful context beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove an IP block' which is a specific verb + resource. This distinguishes it from sibling tools like stalwart_block_ip, stalwart_allow_ip, and stalwart_unallow_ip by focusing on the unblock action. The destructive warning further clarifies the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to obtain the required ip_id (from stalwart_list_objects) and the necessity of confirm=True. However, it does not explicitly mention when to use this tool versus alternatives like stalwart_allow_ip or stalwart_unallow_ip; the usage is implied rather than explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that 'name' creates an email address like 'news@domain.com' and identifies 'recipients' as member emails, but it doesn't mention side effects, permissions, or whether the list is immediately usable. This is partial but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the purpose, and each argument line earns its place. No filler or redundancy; it's a model of efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the 4-parameter input schema and no annotations, the description covers all parameters with examples and a source hint. An output schema exists, so return value details aren't needed. It lacks error conditions or permission prerequisites, but for a create tool with good parameter coverage, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: 'name' gets an example and derived email format, 'domain_id' gets a source instruction, and the optional parameters are clearly labeled as 'description' and 'member email addresses'. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a mailing list' with a specific verb and resource. It distinguishes from siblings like stalwart_delete_mailing_list by the action, and the example with 'news@domain.com' adds clarity to 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context by noting that domain_id comes from stalwart_list_domains, which is a usage guideline for obtaining a valid value. However, it doesn't explicitly mention when to use this tool instead of alternatives like stalwart_delete_mailing_list, though the create/delete distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the effect (bypass spam checks) and parameter constraints (expiry format), but does not mention persistence, interaction with block lists, or whether it overrides existing blocks. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lines of prose followed by a compact argument list. Every sentence and bullet earns its place, with no filler or redundant restating of the tool name.
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 allowlist action with an output schema present, the description covers the core behavior and parameter semantics. It could mention how an allowlisted IP interacts with blocked IPs, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaning to all three arguments: address is 'IP or CIDR', reason is optional, and expires_at is 'optional ISO 8601 UTC expiry'. This provides format and optionality information beyond the bare string 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 opening sentence 'Allowlist an IP address (bypass spam checks)' uses a specific verb and resource, and the parenthetical clearly differentiates it from blocking-related siblings like stalwart_block_ip, stalwart_unblock_ip, and stalwart_unallow_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'bypass spam checks' provides clear context for when this tool is appropriate. It does not explicitly mention alternatives or exclusions, but the intended use case is unambiguous given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return content (headers, body preview, raw message) but does not mention error behavior, permissions, or side effects. For a read-only get operation, this is adequate but lacks some 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 very concise, consisting of two sentences plus an args list. It is front-loaded with the purpose and includes only essential details, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers the core function and parameter origins. However, it lacks details on error handling and the odd default for account_id, but given the low complexity, the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning by defining 'account id' and 'email id' with a useful note that email_id comes from stalwart_search_emails. This goes beyond the schema titles and defaults, though it remains brief.
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 'Get one email in full' with a specific verb and resource. It distinguishes from sibling tools like search_emails (search vs. get) and get_queue_message (different resource).
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 implies when to use this tool by noting that email_id comes from stalwart_search_emails, which gives a workflow hint. However, it does not explicitly state alternatives or when-not-to-use, but the context is clear for a simple fetch operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention the significant trait of not requiring a restart, but it omits details about prerequisites (e.g., updated cert files already in place), failure modes, or side effects. This is minimal but not misleading, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Reload TLS certificates without restart.' Every word contributes to the purpose and key benefit, with no unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters) and the presence of an output schema, the description sufficiently explains what the tool does. It could add a note about prerequisites (e.g., certificates must already be updated), but the current information is adequate for a basic understanding.
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 input schema is trivially fully covered. There are no parameter semantics to explain, and the description does not need to compensate for any schema gaps. The baseline of 4 for a parameterless tool 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 ('reload') and a specific resource ('TLS certificates'), clearly distinguishing it from the sibling tool 'stalwart_reload_settings'. The phrase 'without restart' adds a key operational nuance that clarifies the tool's non-disruptive 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 the tool: after updating TLS certificates, to apply them without a full restart. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent can infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It adds useful context: name creates alice@domain.com, password is the initial password, and locale/time_zone have defaults. However, it does not disclose permissions, duplicate-name behavior, whether a null password is allowed, or what the response contains.
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 front-loaded with a one-sentence purpose and followed by a concise Args list. Every parameter line adds distinct value and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all input parameters, includes defaults, and references the needed domain source. With an output schema present, return values need not be detailed. Minor gaps remain around null password behavior and duplicate account handling, but these do not seriously undermine usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining all six parameters. It adds a local-part example, source for domain_id, optional status for description, and defaults for locale and time_zone, going well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new mail account (user)', a specific verb and resource. It also clarifies that 'name' is the local part, distinguishing it from related account tools like list, get, delete, or set password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for creating accounts and explicitly directs users to stalwart_list_domains for domain_id. It does not state when not to use it or contrast with stalwart_set_account_password, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that secrets are masked, which is useful, but omits behavior for not-found cases, authentication requirements, or what happens if both identifiers are provided. This adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded summary and clear parameter breakdown. Each sentence adds value without waste.
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 lookup tool with an output schema, the description covers the essentials. The main gap is the lack of clarity on mutual exclusivity of the two parameters and error handling when no match is found. Still, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains both parameters: account_id with its source (stalwart_list_accounts) and email with a concrete example. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full account detail', and specifies identification by ID or email. This distinguishes it from sibling tools like list_accounts or get_queue_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?
It provides a clear intended use: retrieve account details by ID or email. It even notes that account_id comes from stalwart_list_accounts, giving a practical pointer. However, it doesn't explicitly discuss when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. The verb 'List' implies a read-only operation, and the mention of 'selector + stage' gives a hint about the return content. However, it does not explicitly confirm that the operation is non-destructive or describe any permissions, rate limits, or other side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences: the first clearly states the tool's purpose, and the second explains the parameter. No unnecessary information is included, making it easy to parse quickly.
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 low complexity of a list tool and the existence of an output schema (which is assumed to describe the return format), the description is reasonably complete. It specifies the entity (DKIM signing keys), the output fields (selector and stage), and the optional filter. It does not mention pagination or sorting, but these are likely covered by the output schema or are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter domain_id is explained in the description as an optional filter and the source for valid values is given (from stalwart_list_domains). Since the schema provides only a generic title with no description (0% coverage), this explanation fully compensates and adds meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists DKIM signing keys with selector and stage, using the specific verb 'List' and a concrete resource. This distinguishes it from sibling list tools like stalwart_list_accounts and stalwart_list_domains by naming the DKIM-specific entity.
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 context for the optional domain_id filter and tells the agent where to obtain valid domain IDs (from stalwart_list_domains). This is a useful guideline, though it does not explicitly state when to use this tool over alternatives like stalwart_generate_dkim or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses what information is shown (envelope return-path, per-recipient status/retry info, size, age), which is useful. It does not mention side effects, but listing is inherently read-only and no conflicting behavior is indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by useful output details and an alternative tool reference. Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple list operation with an output schema present, the description covers the essential information: what it lists, what fields are shown, and how to get more detail if needed. It is concise yet complete for typical usage, though it does not explain limit behavior or ordering, which could be a minor gap.
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 schema has one parameter (limit) with no description and 0% coverage, yet the description does not mention it or explain its behavior. The parameter name is self-explanatory, but the description fails to add any guidance about defaults, maximums, or usage, so it does not compensate for the schema 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 'List messages currently in the outgoing mail queue' with a specific verb and resource. It also distinguishes itself from the sibling stalwart_get_queue_message by noting the difference between metadata listing and full raw content retrieval.
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 clear context on when to use this tool (to list outgoing queue messages) and explicitly names an alternative (stalwart_get_queue_message) for full raw content. This gives the agent direct guidance on choosing between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the key behavior 'hot reload, no restart,' which conveys non-disruptiveness. However, it doesn't mention any potential side effects (e.g., if invalid settings cause a rollback) or whether admin privileges are required. The added context is above a tautology but lacks full transparency for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the verb, resource, and key behavioral trait in only eight words. Every word earns its place; there is zero fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter maintenance action with no output schema requirement, the description is complete. It tells the agent exactly what the tool does and the value proposition (no restart). Sibling tools cover related but distinct actions, and the description makes this tool's role clear within that set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not expected to explain parameter semantics. The schema coverage is trivially 100% with an empty properties object. The baseline for zero-param tools is 4, and the description adds no unnecessary parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reload' with a clear resource 'Stalwart server settings' and adds the key distinction 'hot reload, no restart' which differentiates it from a full restart and from sibling tools like stalwart_reload_tls_certificates. This 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 clearly implies when to use it: to apply settings changes on a running server without restarting. While it doesn't explicitly exclude alternatives or mention prerequisites, the context is clear for a zero-parameter maintenance operation. The lack of explicit alternative naming is a minor gap but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the primary effect (rescheduling the retry time) and the retry_at format, but it does not mention whether the operation is idempotent, overwrites existing retry counts, requires specific permissions, or what errors might occur. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, with a single-sentence purpose followed by concise parameter definitions. Every word adds value, and the most important action is front-loaded. There is 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?
The tool is simple (2 required parameters), an output schema exists (so return value is covered elsewhere), and the description provides essential context including the parameter source. It is complete enough for a competent agent to invoke correctly, though it could add a bit more about edge cases or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description fully compensates by explaining message_id as a queued message id from stalwart_list_queue and by giving retry_at a precise ISO 8601 UTC format with an example. Both parameters are meaningfully documented beyond their names, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Reschedule') on a specific resource ('queued message') and specifies what is changed ('next retry time'). It distinguishes the tool from siblings like stalwart_delete_queue_message and stalwart_get_queue_message because rescheduling is a unique operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used to change a queued message's retry time, and it instructs the agent to obtain message_id from stalwart_list_queue. It does not explicitly state when not to use it, but the reference to the sibling tool provides enough guidance for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses one specific behavior—remote_ip 0.0.0.0 is rejected—but does not state whether the operation is read-only, requires authentication, or has other side effects. This leaves the safety profile partially ambiguous.
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 plus a compact bullet list of parameters. It is front-loaded with the core purpose and each parameter earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations, the description fully specifies all invocation details including required vs optional parameters, defaults, and a special-case constraint. The presence of an output schema likely covers return value documentation, so the description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter: message is a full RFC 5322 message, env_from is required, remote_ip has a default and rejection note, and ehlo_domain/env_rcpt_to are marked optional. This provides meaning beyond parameter 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 'Run the spam filter on a message and get the score,' which identifies a specific action and result. It is distinct from sibling tools that manage accounts, domains, queues, etc., making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking spam classification of a message, with no overlapping sibling tools. While it doesn't explicitly name alternatives or exclusions, the unique functionality provides clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by explicitly stating 'Destructive — requires confirm=True'. It also clarifies the confirm parameter must be True to proceed, which is critical behavioral info beyond the schema's default false. Minor gap: it doesn't mention reversibility or effects on existing sessions, but the destructive nature is clearly 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 extremely concise, using a clean two-line summary followed by a minimal Args list. Every sentence earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 2 parameters and an output schema present, the description covers the essential context: destructive nature, required confirmation, and parameter provenance. It doesn't explain return values, but the output schema likely covers that. The lack of annotations is offset by the description's clear behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does by explaining api_key_id as 'key id (from stalwart_list_api_keys)' and confirm as 'must be True to proceed'. This adds practical meaning beyond the raw field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an API key' with a specific verb and resource, and it distinguishes the tool from siblings like stalwart_create_api_key and stalwart_list_api_keys by focusing on deletion. The arg list further clarifies that it takes an API key ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is a destructive operation requiring confirm=True, and it implies usage with 'from stalwart_list_api_keys' for obtaining the ID. However, it does not explicitly state alternatives or when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that selector is auto-generated if omitted and that algorithm defaults to 'rsa' (2048-bit) or 'ed25519', providing some parameter-level behavior. However, it omits side effects such as whether an existing key with the same selector is overwritten, permissions required, or where the generated key is stored. This is a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single lead sentence followed by a compact args list. Every line conveys distinct information—purpose, parameter source, default behavior, and algorithm options—without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 3-parameter tool with one required parameter and an output schema. The description covers all parameters, provides a prerequisite (domain_id from list_domains), and clarifies defaults. Since an output schema exists, omission of return-value details is acceptable. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: it explains domain_id's source (from stalwart_list_domains), selector's auto-generation behavior, and algorithm's two options with the default key size. This adds meaningful value beyond the raw schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate a new DKIM signing key for a domain,' which uses a specific verb (generate), identifies the resource (DKIM signing key), and specifies the target (domain). This clearly distinguishes it from sibling tools like stalwart_list_dkim_signatures, which lists existing keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite by noting that domain_id comes from stalwart_list_domains, guiding when this tool is appropriate (after a domain exists). However, it does not explicitly contrast with sibling tools like stalwart_list_dkim_signatures for viewing existing keys, so there is no 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly labels the operation as destructive and mandates confirm=True, which informs the agent about safety-critical behavior. It also adds context that domain_id comes from stalwart_list_domains, aiding correct usage.
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, front-loading the key fact ('Delete a mail domain. Destructive — requires confirm=True') before listing parameters. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with 2 parameters and an output schema, the description adequately covers the purpose, destructive nature, confirmation requirement, and parameter provenance. It doesn't detail post-delete effects on dependent data, but that's beyond minimal completeness for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving all parameter semantics to the description. The description fully explains both parameters: domain_id (source from stalwart_list_domains) and confirm (must be True to proceed). This adds complete meaning beyond the raw 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 'Delete a mail domain', which uses a specific verb and resource, clearly distinguishing it from sibling tools like create_domain or delete_account. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns 'Destructive — requires confirm=True', providing clear context that this tool is dangerous and needs explicit user confirmation. It doesn't mention alternatives or when-not-to-use, but the destructive flag serves as a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Destructive' and requires `confirm=True`, warning the agent of the irreversible nature and the safety check. It could add more detail about cascading effects, but the core danger is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences plus an args list. It front-loads the destructive nature and condenses essential usage into a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with an output schema present, the description is largely complete. It covers what the tool does, the source of the parameter, and the confirmation requirement. Missing details like permission requirements or effects on members are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters beyond the schema: `list_id` provenance and `confirm` semantics ('must be True to proceed'). Given schema descriptions are absent (0% coverage), this added guidance is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a mailing list,' a specific verb and resource. This clearly distinguishes it from sibling tools like stalwart_create_mailing_list and stalwart_delete_account.
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 context by instructing that `list_id` should come from `stalwart_list_objects(obj_type='mailing_list')`, giving a clear precondition. It does not explicitly mention alternative tools or exclusions, but the targeted deletion context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it returns full detail including parsed headers and raw RFC 5322 message. It does not explicitly state it is read-only, but the verb 'get' and the return description imply safety. It could benefit from stating 'this is a read-only operation', but it provides meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the main purpose, and includes a concise parameter explanation. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and an output schema, the description provides sufficient context: what it does, what the output contains, and how to obtain the required input. It is fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), but the description includes an Args section explaining that message_id is the queued message id from stalwart_list_queue. This adds crucial semantic meaning, though it does not specify the exact format or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Full detail of one queued message') and the resource (queued message). It distinguishes itself from sibling tools like stalwart_list_queue (listing) and stalwart_delete_queue_message (deletion) by focusing on retrieving full detail of 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?
It gives clear context for when to use the tool: to get full detail of a queued message, and explicitly mentions that message_id comes from stalwart_list_queue, implying a workflow. It does not explicitly mention when not to use it or list alternatives, but the parenthetical does guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly flags the operation as 'Destructive' and mandates confirm=True, providing essential risk information for an AI agent. It could add more detail about irreversibility or cascading effects, but the core safety cue is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the action and warning in two short sentences, followed by a compact parameter list. Every sentence contributes value.
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 destructive tool with a defined output schema, the description covers the essential aspects: what it does, the danger, the mandatory confirmation, and parameter semantics. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description compensates by explaining both parameters: account_id is sourced from stalwart_list_accounts, and confirm must be True to proceed. This gives the agent the necessary context to correctly set arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a mail account') with a specific verb and resource. It distinguishes from sibling delete tools by specifying 'account' as the target, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational guidance by warning that the operation is destructive and requires confirm=True. However, it does not explicitly discuss when not to use it or mention alternatives, but the context of deleting a mail account is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly flags the operation as destructive and mandates confirm=True, which is essential safety information. It does not detail irreversibility or side effects beyond 'destructive,' but that is adequate for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two lines of purpose and a short argument list—with no fluff. Every sentence is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter delete operation and the presence of an output schema, the description covers what the tool does, how to use it, and the safety requirement. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does: message_id is identified as a queued message id from list_queue, and confirm is explicitly required to be True. This adds clear semantics beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target ('a message from the outgoing queue'), which distinguishes it from sibling tools like list_queue, get_queue_message, and reschedule_queue_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?
It provides clear context that the message_id comes from stalwart_list_queue, but does not explicitly discuss when not to use this tool or alternatives (e.g., reschedule instead of delete). This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation through the verb 'List' and discloses a key behavioral trait: the token's impersonation capability allows access to other user accounts. This goes beyond basic listing semantics, though it doesn't detail output format or error handling (mitigated by the output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by a single parameter bullet. It is front-loaded with the primary function and contains no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers purpose, parameter semantics, and access control context. With an output schema present, there is no need to describe return values, and the description is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains the only parameter, account_id, noting the special value 'b' for postmaster/admin and clarifying that other accounts can be accessed via impersonation. This adds substantial meaning beyond the schema, which only provides a default value and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List mailboxes (folders) of an account' and specifies the output includes 'email counts'. This makes the tool's purpose unambiguous and distinct from sibling tools like stalwart_list_accounts or stalwart_list_identities.
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 the tool: whenever mailboxes for an account need to be listed with counts. It provides context about the account_id parameter, including the default admin account and impersonation access, but does not explicitly mention alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the burden. It explicitly labels the operation 'Destructive' and warns that confirm=True is required, which discloses a key behavioral trait. It also specifies the resource being removed (an IP from the allowlist). The source for the ip_id adds prerequisite context, though it doesn't discuss reversibility or authorization.
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 lines, front-loads the purpose and destructiveness, and then lists the two args with brief, necessary explanations. Every sentence contributes.
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 two-parameter removal tool, the description provides purpose, prerequisite lookup, and a mandatory confirmation flag. An output schema exists, so return-value documentation is not needed. It is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows 'Ip Id' and 'Confirm' with no descriptions. The description adds crucial semantics: ip_id is an allowed IP id obtained from stalwart_list_objects(obj_type='allowed_ip'), and confirm must be True to proceed. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Remove an IP from the allowlist,' a specific verb+resource statement. This clearly identifies the operation and distinguishes it from siblings like allow_ip, block_ip, and unblock_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by requiring the allowed_ip id to be fetched from stalwart_list_objects, and explicitly notes the confirm parameter must be True. It does not explicitly contrast with alternatives like unblock_ip, but the instruction is unambiguous.
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:

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

Score Badge

Copy to your README.md:

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

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