This server lets AI assistants query and manage DMARC monitoring data from DMARC Examiner.
Domain management: list, inspect, add, verify, and remove monitored domains; check any domain's public DMARC record
Aggregate report queries: list, view, and get statistics for DMARC reports; export reports as CSV
Forensic report queries: list, view, summarize, and get statistics for RUF forensic reports (Pro plan+)
Alert management: list and dismiss security alerts
Webhook management: list, create, update, delete, and test webhook endpoints (Pro plan+)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DMARC Examiner MCP summarize the latest DMARC report statistics for example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official MCP (Model Context Protocol) server for DMARC Examiner. Query your DMARC monitoring data from AI assistants like Claude Desktop, Claude Code, and Cursor.
DMARC aggregate reports arrive as compressed XML, one file per receiver per day. Reading them means either opening a dashboard or parsing XML by hand.
This server puts that data behind an MCP connection, so you can ask questions instead:
Which sending sources failed DMARC alignment last week?
Show me the domains where SPF passes but DKIM does not.
Export the report for example.com as CSV.
DMARC Examiner is a DMARC monitoring service with a free tier — you need an account to use this server, but not a paid one.
Related MCP server: dns-mcp
Most MCP clients support remote HTTP servers directly. Add this to your MCP configuration:
{
"mcpServers": {
"dmarc-examiner": {
"url": "https://mcp.dmarc-examiner.com/mcp"
}
}
}{
"mcpServers": {
"dmarc-examiner": {
"command": "npx",
"args": ["-y", "@dmarc-examiner/mcp"]
}
}
}Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"dmarc-examiner": {
"url": "https://mcp.dmarc-examiner.com/mcp"
}
}
}claude mcp add dmarc-examiner --transport http https://mcp.dmarc-examiner.com/mcpAdd to your Cursor MCP settings:
{
"mcpServers": {
"dmarc-examiner": {
"url": "https://mcp.dmarc-examiner.com/mcp"
}
}
}Adding the server does not require authorizing. It starts immediately and answers initialize, tools/list and ping without credentials, so your client can list all 21 tools straight away.
A browser opens the first time you call a tool that touches your data. You'll need to:
Log in to your DMARC Examiner account
Select which organization to connect
Approve the requested permissions (scopes)
The call you made is then replayed automatically, so it completes rather than failing.
With Option 1 the MCP client runs this flow itself. With Option 2 the package does it: it registers as an OAuth client, opens your browser, and stores the resulting tokens in ~/.dmarc-examiner/mcp-credentials.json with 0600 permissions. The refresh token is reused on later runs, so the browser step happens once.
Why it works this way. Authorizing on startup is the obvious design and it breaks every automated client: directory checks, scanners and CI have no browser to open, so the server appears to hang and the check times out. We wrote up the failure and the fix, with logs, in Your Remote MCP Server Will Fail Every Directory Check.
You can also drive it directly:
npx -y @dmarc-examiner/mcp login # authorize now, outside your MCP client
npx -y @dmarc-examiner/mcp logout # forget the stored credentialsSet DMARC_EXAMINER_MCP_URL to point the package at a different endpoint.
Tool | Description | Scope |
| List all monitored domains in your organization |
|
| Get details of a specific domain |
|
| Inspect the public DMARC record at |
|
| Add a domain. Returns the reporting email and DMARC record to publish in DNS |
|
| Re-check DNS to confirm the DMARC record carries your reporting address |
|
| Remove a domain from monitoring. Soft delete — historical reports remain |
|
Tool | Description | Scope |
| List DMARC reports with filtering |
|
| Get a detailed report with records |
|
| Report statistics by country and ASN |
|
| Export a report as CSV |
|
Requires the Pro plan or above; these return 403 otherwise.
Tool | Description | Scope |
| List RUF reports with filtering and pagination |
|
| Full detail of a forensic report, including the failed message envelope |
|
| Counters by failure type, delivery result, source IP with geolocation, and domain |
|
| Forensic activity over the last 7 days |
|
Tool | Description | Scope |
| List security alerts |
|
| Dismiss an alert |
|
Requires the Pro plan or above; these return 403 otherwise.
Tool | Description | Scope |
| List configured webhook endpoints |
|
| Create an endpoint. The URL must be HTTPS |
|
| Update the URL, name or active state of an endpoint |
|
| Delete an endpoint permanently |
|
| Send a |
|
Scope | Description |
| View monitored domains |
| Add, verify and remove domains |
| View reports and statistics |
| Export reports to CSV |
| View forensic (RUF) reports |
| View alerts |
| Manage alerts (dismiss) |
| View webhook endpoints |
| Create, update, delete and test webhooks |
For detailed documentation, visit: https://dmarc-examiner.com/docs/settings/mcp-integration?utm_source=github&utm_medium=content&utm_campaign=mcp-repo
Documentation: https://dmarc-examiner.com/docs?utm_source=github&utm_medium=content&utm_campaign=mcp-repo
Email: support@dmarc-examiner.com
MIT — see LICENSE.
Inspect the public DMARC record at _dmarc.. The domain does not need to belong to your organization. Returns parsed policy and rua/ruf addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to inspect — does not need to belong to your organization. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it performs a public DNS lookup (read-only, no destructive side effects), accesses a specific record format, and returns parsed policy and contact addresses. This goes beyond what the schema reveals, providing complete behavioral context for an inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with zero waste, front-loading the core action and then providing additional context (domain scope, return values). Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter with full schema coverage, no output schema, and no annotations. The description is reasonably complete for a simple inspection tool: it specifies the input (domain), the DNS record location, the public nature, and key return elements. However, it does not mention the output format (e.g., JSON structure) or any error conditions (e.g., invalid domain or no DMARC record), but these are minor gaps for a single-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, and the description adds meaning by clarifying the domain does not need to belong to the organization, which the schema description also mentions (redundant but reinforcing). The description's mention of '_dmarc.<domain>' and parsed outputs adds context beyond simple parameter name, but the schema already covers the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a DMARC record at a specific DNS location (_dmarc.<domain>), specifies it retrieves a public record (not belonging to the org), and lists key outputs (parsed policy, rua/ruf addresses). This is a specific verb-resource pair with clear scope, distinguishing it from sibling tools like list_domains or verify_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the domain does not need to belong to the organization, implying no ownership prerequisite, which guides when to use. It does not explicitly state when not to use or name alternatives, but the context among 20+ sibling tools specializing in internal domain management or reporting makes the public lookup purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new domain to the organization. Response includes the reporting_email and dmarc_record values to publish in DNS. May return 402 if the plan domain limit has been reached.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Domain name to monitor (e.g. "example.com"). Stored lowercased. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the response includes reporting_email and dmarc_record values for DNS publishing and that a 402 error is possible. This gives the agent a clear behavioral model for a creation operation, though it lacks details on authentication or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the purpose. Every sentence adds essential information without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one parameter and no output schema, the description covers the core action, response contents, and a notable error condition. It provides sufficient completeness for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single parameter 'name' is already well-documented in the schema (e.g., 'Stored lowercased'). The tool description adds no extra semantic information about the parameter beyond stating the overall action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new domain to the organization,' establishing a specific verb ('Add') and resource ('domain'). This distinguishes it from sibling tools like delete_domain, list_domains, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by noting that the tool may return a 402 error if the domain limit is reached, which helps the agent anticipate billing constraints. However, it does not explicitly exclude scenarios where other tools (e.g., check_dmarc, verify_domain) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new webhook endpoint. URL must start with https://. Returns 422 if the organization has reached its webhook limit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS URL events will be POSTed to | |
| name | Yes | Human-readable label |
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 reveals that the tool creates a resource, requires HTTPS, and can fail with a 422 error. However, it does not disclose whether the operation is idempotent, whether duplicate URLs are allowed, or any rate limiting or side effects beyond the limit check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core purpose, the second adds a key constraint and error condition. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does not describe what the tool returns on success (e.g., the created webhook object, its ID). It only mentions one error case. For a creation tool, this leaves the agent guessing about the response structure. Sibling tools are noted but not leveraged for relative context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters (url and name). The description adds no further meaning beyond the schema, just restating the HTTPS constraint already implied by the url's description in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new webhook endpoint' with a clear verb and resource. It distinguishes from sibling tools like update_webhook, delete_webhook, and test_webhook by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint (URL must start with https://) and mentions a specific error case (422 for webhook limit), but does not guide when to use this tool versus alternatives like update_webhook, nor does it state prerequisites (e.g., authentication, organization membership).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a domain from monitoring. Soft-deletes; historical reports remain accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_id | Yes | Domain UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It correctly states the tool performs a soft-delete and that historical reports remain accessible, which is valuable. However, it does not mention that this is a destructive write operation, what happens to ongoing monitoring for that domain, or whether any authentication or permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. The first sentence states the purpose, and the second provides critical behavioral nuance about soft-delete and data retention. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, no annotations, and no nested objects, the description is minimally complete by stating the action and the soft-delete behavior. However, it lacks information about return values (e.g., success/failure indication), side effects on associated resources like alerts or reports, and error conditions (e.g., what if domain_id doesn't exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'domain_id', which is already clearly described as 'Domain UUID' in the input schema. The description does not add additional meaning about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('domain from monitoring'), and clearly distinguishes from sibling tools like 'list_domains' and 'create_domain'. It also adds a critical clarification about the soft-delete behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for removing a domain from monitoring, but does not provide explicit guidance on when to use this tool versus alternatives like disabling a domain or what prerequisites (e.g., domain must exist) are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook endpoint permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_id | Yes | Webhook UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the permanent nature of the deletion, which is important. However, it does not disclose side effects (e.g., stops webhook deliveries), required permissions, or whether the action is reversible. The word 'permanently' adds some transparency but more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence ('Delete a webhook endpoint permanently.') which is concise and to the point. However, it is extremely minimal and could incorporate more context without sacrificing conciseness. The brevity is efficient but not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description conveys the core action and the permanent consequence. However, it lacks information about prerequisites (e.g., webhook must exist), error conditions, or what happens after deletion. It is minimally complete but could be more helpful for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the single parameter (webhook_id: 'Webhook UUID') with 100% coverage. The tool description adds no additional meaning or constraints about the parameter beyond what the schema states. It does not mention the parameter or its role explicitly. Therefore, it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' and the resource 'webhook endpoint', clearly distinguishing this from sibling tools like create_webhook, update_webhook, test_webhook, and list_webhooks. It leaves no ambiguity about the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to use this tool versus alternatives such as update_webhook or test_webhook. It does not mention any preconditions (e.g., webhook must exist) or exclusions. An agent has no guidance to decide between destructive and non-destructive operations beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dismiss a specific alert
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without revealing any side effects, reversibility, idempotency, permission requirements, or consequences of dismissing an alert. The agent gets no sense of what happens when this tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is too sparse to be considered well-crafted. It omits critical details that could be added in a few more words (e.g., 'Dismiss the alert identified by alert_id, removing it from the active alerts list'). It sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple one-parameter tool, the description fails to provide enough context for correct usage. It does not explain the return value (or lack thereof), the prerequisite of having an alert_id from list_alerts, or the tool's place in the alert lifecycle alongside siblings like list_alerts and get_report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not mention the alert_id parameter at all. It provides no information about the format, source (e.g., from list_alerts), validation, or how it affects the operation. The agent must guess what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Dismiss') and the resource ('a specific alert'), which is clear at a high level. However, it lacks specificity about what 'dismiss' entails in this domain (e.g., acknowledging, removing, or silencing), and does not differentiate from sibling tools like list_alerts that deal with alerts in a different way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool, prerequisites, or alternatives. There is no mention of scenarios like 'Use this after reviewing an alert via list_alerts' or 'Do not use if you need to delete the alert permanently (see delete_domain instead).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a DMARC report as CSV
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must fully disclose behavior. It only states 'Export as CSV' but does not explain whether it returns a file URL, binary data, or triggers a download. No information about authentication, rate limits, or side effects is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no superfluous words. However, given the lack of detail, it risks being under-specified. It earns its place but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema), the description could still be complete with a few more details. It fails to explain the return format, whether the CSV is stored or streamed, or any limitations. The sibling tools suggest a richer ecosystem that remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the parameter 'report_id' has no description in the schema. The description only implicitly references it ('Export a DMARC report') but does not explain what a valid report_id looks like or how to obtain one. For a single required parameter, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Export' and resource 'DMARC report as CSV', clearly indicating what the tool does. It differentiates from siblings like 'get_report' (likely JSON) and 'list_reports' (list) by specifying the CSV format. However, it could be slightly more explicit that it generates a downloadable file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_report' or 'list_reports'. There is no mention of prerequisites or context where CSV export is preferred, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_id | Yes | Domain UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states 'Get details,' implying a read-only operation, but it doesn't clarify whether this tool requires any special permissions, whether it returns cached or live data, or what happens if the domain_id is invalid. The description is too minimal to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without extraneous words. It could be slightly improved by being more specific (e.g., 'by domain ID'), but for a simple tool it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is acceptable but not complete. It fails to mention what constitutes 'details' (e.g., configuration, status, DNS records) or any return format. The context signals show low complexity, so a 3 is adequate, but it leaves the agent guessing about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter ('domain_id') is well-documented with a description and type. The tool description adds no additional meaning to the parameter. According to the guidelines, baseline is 3, and that is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get details) and the resource (a specific domain). It distinguishes the tool from siblings like 'list_domains' (which lists all) and 'create_domain' (which creates). However, it doesn't explicitly say the resource is identified by the required 'domain_id' parameter, which the schema already makes clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_domains' or 'get_report'. It doesn't state prerequisites, such as that the domain must already exist, or indicate that this is the tool to call when you need full details of a single domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full detail of a forensic (RUF) report by UUID, including the raw failed message envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | Forensic report UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the return behavior (includes the raw failed message envelope), which is meaningful. However, it does not mention any destructive effects, authentication requirements, rate limits, or scope of the full detail returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (<20 words) that is front-loaded with the action and resource. It packs necessary details (full detail, raw envelope) without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required parameter, no nested objects, no output schema needed). The description covers the purpose and a key behavioral detail (raw envelope). For a single-param retrieval tool with rich sibling context, this is adequate but could slightly benefit from more usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the parameter. The description adds value beyond the schema by explaining the tool's purpose, but it does not elaborate on the parameter format or constraints beyond what is in the schema. Baseline 3 applies, and the slight improvement is for the added purpose context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Get the full detail of a forensic (RUF) report'), the resource ('forensic report by UUID'), and the scope ('including the raw failed message envelope'). This distinguishes it from sibling tools like 'get_report' (probably DMARC aggregate) and other forensic tools which list or summarize reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring a report UUID, but it does not specify when to use this tool versus the other forensic tools (e.g., list_forensic_reports, get_forensic_reports_statistics, get_forensic_reports_summary) or provide any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated forensic-report counters grouped by auth failure type, delivery result, source IP (with geolocation) and reported domain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes the output structure (grouped counters) but does not mention read-only nature, data freshness, pagination, or any limits. The 'get' prefix and 'counters' implicitly suggest a read operation, but explicit behavioral traits beyond that are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 16 words, front-loaded with the key concept ('Aggregated forensic-report counters'). Every word is necessary and informative. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the main aspects: what is returned and the grouping keys. However, it does not specify whether there are implicit filters (like date range or scope) or the format of the output. Slightly more detail would make it fully complete, but it is already fairly comprehensive for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description adds value by explaining what the tool returns (the aggregation dimensions). With no parameters to document, the description serves as the primary source of semantics, and it does so effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'aggregated forensic-report counters' grouped by four specific dimensions (auth failure type, delivery result, source IP with geolocation, reported domain). It distinguishes itself from siblings like 'get_forensic_reports_summary' and 'get_report_statistics' by specifying the exact breakdowns, 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.
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 such as 'get_forensic_reports_summary' or 'get_report_statistics'. The description implies usage for detailed aggregated views, but does not provide explicit when/ when-not or name sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of forensic activity in the last 7 days — useful for daily digest views.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must carry the full burden. It clearly states the tool returns summary data (not a list) over a fixed 7-day period, implying idempotent/read-only behavior. For a tool with no parameters, this is transparent enough. It could be improved by explicitly stating it is read-only and has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part contributes to understanding: the return type ('summary'), temporal scope ('last 7 days'), and use case ('daily digest'). It is perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and no annotations, the description provides good temporal and semantic context. It could elaborate on the output format (e.g., 'returns aggregate counts and threat categories'), but for a digest-oriented summary tool, this description is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%. The description adds value by explaining the semantic nature of the output (a summary, not raw data) and its time window, which compensates for the lack of an output schema. No additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary of forensic activity over a specific 7-day window, and that it's intended for daily digest views. It uses a specific verb ('get') and resource ('forensic reports summary') and includes a temporal scope that differentiates it from sibling tools like get_forensic_reports_statistics or list_forensic_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's 'useful for daily digest views,' which implies a periodic/recurring use case (e.g., automated daily queries). However, it does not explicitly say when NOT to use it or name alternatives for different time ranges or more detailed forensic analysis. Still, the temporal context and sibling tool names provide enough clarity for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific DMARC report
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description as the sole source of behavioral info. It does not disclose whether the tool is read-only, requires any authentication scopes, or any side effects. The description adds minimal transparency beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it omits critical information that could be added without becoming verbose. It is not front-loaded with the most important details; it just meets the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameter descriptions, the description is insufficient for an agent to know what 'details' are returned or how to correctly provide the input. The tool has 20 siblings, increasing the need for complete guidance, but the description is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter 'report_id' has no description in the schema. The tool description does not explain what a report_id is, how to obtain it, or any format constraints. With one required parameter and no schema documentation, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get details of a specific DMARC report', which identifies the verb (Get) and resource (DMARC report). However, it does not differentiate this tool from sibling tools like 'get_report_statistics' or 'list_reports', which could cause confusion about which tool to use for detail retrieval versus listing or statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 compared to alternatives like 'list_reports' (for overview) or 'get_report_statistics' (for analytics). The description is too generic to help an agent decide when 'get_report' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics for a specific DMARC report
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only says 'Get statistics', implying a read operation, but does not explain what happens if the report_id is invalid, whether the action is reversible, or what the output format is. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is far too concise. It sacrifices completeness for brevity, failing to provide essential details. Every sentence should earn its place, but this one sentence is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, and no annotations, the description should compensate by explaining the return value, potential errors, and usage context. It does none of this, making it completely inadequate 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no description for the sole parameter 'report_id'. The tool description adds no meaning beyond the parameter name itself. It does not clarify the format, source, or constraints of report_id, leaving the agent without necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get statistics for a specific DMARC report', which includes a verb and resource. However, it is vague about what 'statistics' entails and does not differentiate from sibling tools like 'get_forensic_reports_statistics' or 'get_report'. The purpose is clear at a high level but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The agent receives no help deciding between this tool and similar ones like 'export_report_csv' or 'get_forensic_reports_statistics'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List alerts for your organization
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| status | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It does not mention that the tool is read-only (implied by 'list'), whether it requires authentication, or what happens if there are no alerts. The inadequacy is notable for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence long, which could be concise, but it lacks sufficient detail to be functional. Every word is used, but the sentence does not earn its place because it is too sparse to guide the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotation coverage, 3 parameters, and no parameter documentation, the description fails to provide a complete picture. It lacks any return value information, pagination behavior, or parameter explanations, making it inadequate for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must compensate for the 3 undocumented parameters. It does not explain the meaning or effect of 'page', 'status', or 'per_page'. The baseline is 3 due to zero coverage, but the description fails to add value, resulting in a borderline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List alerts for your organization" states only a verb and resource. It does not differentiate from sibling tools like 'dismiss_alert' (for a single alert) or 'list_reports', which also involve listing items for an organization. The failure to specify scope or alert type leaves the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'dismiss_alert' or 'list_reports'. There is no mention of prerequisites, pagination handling, or scenarios where the tool would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all monitored domains in your organization
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool lists 'all monitored domains', implying a read operation and a list response. However, it does not disclose pagination behavior, rate limits, or whether the list is exhaustive or filtered. The minimal disclosure barely meets the threshold for a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it sacrifices necessary information. It is front-loaded and efficient, but the lack of parameter context and behavioral detail makes it under-specify the tool. Conciseness is not an excuse for incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional parameters, no output schema), the description is too sparse. It does not explain what the output looks like, how pagination works, what constitutes a 'monitored domain', or how this tool relates to sibling tools like get_domain or list_reports. The agent lacks sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not mention or explain the 'page' and 'per_page' parameters. The schema itself only lists them as 'number' with no descriptions. The agent has no semantic understanding of what these parameters control (e.g., pagination, page size). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'monitored domains', and the scope 'in your organization'. It effectively communicates the core function. However, it does not explicitly distinguish this tool from sibling tools like 'get_domain' (which retrieves a single domain), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or scenarios where a different tool (e.g., get_domain, check_dmarc) would be more appropriate. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DMARC RUF (forensic) reports with optional filtering and pagination. Returns 403 if the plan does not include forensic reports (Pro plan and above).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| date_to | No | Inclusive upper bound on arrival_date | |
| per_page | No | ||
| date_from | No | Inclusive lower bound on arrival_date (ISO 8601 / "YYYY-MM-DD HH:MM:SS") | |
| domain_id | No | Filter by domain UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that a 403 error can occur if the plan does not include forensic reports, which is a key behavioral trait (plan restrictions). However, it does not mention pagination behavior (defaults, max per_page), whether the tool is read-only, or what the response format looks like. This is adequate but leaves gaps for a listing tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. Front-loaded with the main action (list forensic reports), then adds a behavioral note (403 on plan). Could be slightly more structured by separating filtering/pagination details, but effective overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 output schema, the agent has no idea what the response format is – this is a gap. The description covers the basic action and a key error case, but for a tool with 5 parameters and no output schema, it should provide more context about default pagination values, maximum limits, or what fields the forensic reports contain. The behavioral note about plan restrictions is good, but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% – some parameters like date_from have format hints (ISO 8601) but page and per_page lack descriptions. The description says 'optional filtering and pagination' but doesn't add meaning to the page/per_page parameters beyond what the schema provides. The domain_id and date parameters are implied but not elaborated. Baseline 3 is appropriate with 60% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists DMARC RUF (forensic) reports with optional filtering and pagination. It distinguishes itself from siblings like get_forensic_report (which likely gets a single report) and get_forensic_reports_statistics (which provides stats). However, it could emphasize the list vs. single aspect more explicitly to differentiate from get_forensic_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering and pagination implicitly, but provides no explicit guidance on when to use this tool versus alternatives like list_reports or get_forensic_reports_summary. It does not specify that this is the tool for raw forensic reports (RUF) vs. aggregate reports. The context of 'Pro plan and above' is a usage hint, but it doesn't help with tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DMARC reports for your organization
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| domain | No | ||
| date_to | No | ||
| per_page | No | ||
| date_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states that the tool lists reports, but doesn't disclose whether it supports pagination, what date formats are expected, whether it returns a subset of reports or all, or if there are any rate limits or authentication requirements. For a listing tool with 5 parameters, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is also under-specified. It front-loads the purpose but omits necessary details. While brevity is good, it sacrifices completeness for conciseness, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema, so the description should clarify the filtering and pagination behavior. It only says 'for your organization,' which doesn't explain how domain, date ranges, or per_page work. Given the complexity of the parameters and the lack of structured annotations, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It does not mention any of the five parameters (page, domain, date_to, per_page, date_from), leaving the agent to guess their semantics. The parameter names give some hints, but the description adds no value, failing to compensate for the zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing DMARC reports for the organization. It uses a specific verb ('List') and resource ('DMARC reports'), and the scoping to 'your organization' helps distinguish it from other report-related tools like get_report or get_report_statistics, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus get_report, get_report_statistics, or export_report_csv. It doesn't mention any exclusions or specific contexts, leaving the agent to infer from the tool name and sibling list. With 20+ sibling tools, this lack of guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List webhook endpoints configured for the organization. Returns 403 if the plan does not include advanced alerting (Pro and above).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses a potential 403 error based on plan tier, which is a key behavioral constraint. However, it does not mention other aspects like pagination, rate limits, or whether this is a read-only operation. The single behavioral note is useful but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It includes the core purpose and a critical behavioral note (403 on plan restriction). Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple list operation with a sibling set dominated by related webhook tools, the description covers the main need: what it does and a key failure condition. It could optionally mention the scope (organizational) or that it returns an array, but the lack of output schema makes those details less critical. A 4 reflects good completeness for a trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters, so there are no parameters to describe. The description adds no parameter semantics because none are needed. A baseline of 4 is reasonable: the schema is complete and the description is not expected to elaborate on missing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists webhook endpoints for the organization, which is a specific verb-resource pair. It distinguishes itself from sibling tools like create_webhook, update_webhook, delete_webhook, and test_webhook by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It does not provide explicit when-to-use or alternatives, but the context signals show no parameters, making this tool straightforward to use. The description notes a specific failure case (403 from plan restrictions), which hints at when not to use it. A 4 is appropriate given the simplicity of a list operation with a clear error indicator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a synchronous webhook.test event to verify connectivity. Returns the delivery status. Test events do NOT update last_triggered_at, last_status or failure_count.
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_id | Yes | Webhook UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states test events do NOT update certain properties ('last_triggered_at, last_status or failure_count'). With no annotations provided, the description must disclose all behavioral nuances, and it does so commendably for a simple test tool. It also mentions the synchronous nature and return of delivery status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each providing essential information: action (send test event), purpose (verify connectivity), and key behavioral detail (no side effects on timestamps). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an explicit behavioral note. The description covers the action, return value (delivery status), and key side-effect exception. Given no output schema, a slightly more complete description would ideally mention the shape of the return status, but it is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema for the single parameter (webhook_id). No further elaboration on format or constraints is needed given the coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('send') and resource ('webhook.test event') to clearly state the tool's action. It distinguishes itself from sibling tools like 'create_webhook' and 'list_webhooks' by focusing on a connectivity verification event rather than lifecycle management or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing connectivity ('verify connectivity') and notes that it's for synchronous testing. While it doesn't explicitly exclude alternative tools, the verbs and purpose differentiate it from other webhook and domain tools. There is no guidance on scenarios to avoid, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a webhook. Any combination of url, name and is_active may be provided; URL must remain HTTPS.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New HTTPS URL | |
| name | No | New label | |
| is_active | No | Enable/disable delivery without losing config | |
| webhook_id | Yes | Webhook UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the URL must remain HTTPS but does not disclose potential side effects (e.g., whether updating triggers a test ping, or if deactivating and reactivating affects webhook state). The description adds moderate value beyond the schema but lacks completeness for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with key information front-loaded. Every sentence contributes value: the first states the core action, the second adds partial update semantics and a security constraint. No wasted words. It could be slightly improved by adding a brief note about what happens on update (e.g., confirmation), but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, so the description should compensate for the missing output schema. While it clarifies partial updates and the HTTPS requirement, it does not specify the return value (e.g., whether it returns the updated webhook object or just a success indicator), leaving the agent without complete context. For a mutation tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents each parameter. The description adds marginal value by clarifying that any combination of url, name, and is_active may be provided (implying partial updates) and that URL must be HTTPS. However, it does not explain the webhook_id parameter beyond what's in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a webhook and specifies the modifiable fields (url, name, is_active). While it distinguishes from siblings like create_webhook and delete_webhook, it doesn't uniquely contrast with test_webhook or list_webhooks, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 modify a webhook's url, name, or is_active status) and even specifies a constraint (URL must remain HTTPS). However, it does not explicitly state when not to use this tool versus alternatives like delete_webhook or test_webhook, lacking a complete exclusion guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-check a domain's DNS to confirm the DMARC record contains the organization's reporting email. Updates status to verified on success.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_id | Yes | Domain UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool performs a DNS re-check, confirms a DMARC record condition, and mutates status to verified on success. The side effect (status update) is explicitly stated, which is excellent for a mutation tool with no annotation protections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the core action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter, no output schema, and no nested objects, the description is complete for its complexity. It explains input, action, and outcome. Could mention possible failure states or return format, but not essential for a simple verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter domain_id described as 'Domain UUID'. The description does not repeat this but instead explains what the tool does with the domain, which adds context beyond the schema. However, it could briefly mention that the domain_id must correspond to an existing domain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Re-check', the resource 'domain's DNS', and the specific purpose: confirming the DMARC record contains the organization's reporting email and updating the status to verified on success. This distinguishes it from siblings like check_dmarc (which likely only checks without updating) and get_domain (which retrieves info without verification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after initial domain creation or when DNS changes occur, but does not explicitly state when to use this tool versus check_dmarc or other siblings. No guidance on prerequisites (e.g., domain must exist) 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0check_dmarccreate_domaincreate_webhookdelete_domaindelete_webhookdismiss_alertexport_report_csvget_domainget_forensic_reportget_forensic_reports_statisticsget_forensic_reports_summaryget_reportget_report_statisticslist_alertslist_domainslist_forensic_reportslist_reportslist_webhookstest_webhookupdate_webhookverify_domainScored across 21 tools
Tools are mostly distinct, targeting different resources (domains, reports, alerts, forensic reports, webhooks). However, 'list_forensic_reports' and 'get_forensic_reports_summary' could be confused as both deal with forensic report lists, though one is a full list and the other a summary.
All tools follow a consistent verb_noun pattern (e.g., delete_domain, list_reports, create_webhook). Naming is predictable and clear, with no mixing of conventions.
21 tools is slightly on the high side but appropriate for a DMARC monitoring server covering domains, reports, alerts, forensic reports, and webhooks. Each tool addresses a specific operation, and the scope justifies the count.
The toolset provides solid coverage for domain management, report viewing/export, alert handling, forensic reports, and webhook management. A minor gap is the lack of a tool to update domain details or remove a domain permanently (only soft-delete).
DMARC analytics and domain onboarding for AI assistants — health, SPF/DKIM, compliance, anomalies.
Monitor and manage email authentication (SPF, DKIM, DMARC, MTA-STS, BIMI) for your domains.
Connect AI assistants to Xitoring monitoring: servers, uptime, incidents, metrics, SSL, and alerts.
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
