DMARC Examiner MCP

export_report_csv

Export a DMARC report to CSV format for offline analysis and record keeping. Use this to access email authentication data in spreadsheet applications.

Instructions

Export a DMARC report as CSV

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "report_id": "<report_id>"
    },
    "name": "export_report_csv"
  }
}

Input Schema

Name	Required	Description	Default
`report_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Aug 19, 2026

TDQS

C2.7/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness2/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 (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.

Parameters2/5

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.

Purpose4/5

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.

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 '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.