Skip to main content
Glama

dns-doctor

by dev.dnsdoctor
OverviewDiscussionsAdmin

parse_dmarc_report

Read-onlyIdempotent

Use this when the user uploads or pastes a DMARC aggregate (RUA) XML report and asks what it says. Parse ONE DMARC aggregate (RUA) report into readable per-source aggregates: who sent mail as the domain, how much, and what share was SPF/DKIM aligned. Pass the file's bytes base64-encoded in content_base64 (XML, .gz or .zip; up to 2 MiB decoded) with an optional filename. Nothing is stored — the report is parsed and discarded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameNoOptional original attachment filename, recorded in logs only — format detection is content-based, so this changes nothing about parsing.
content_base64YesOne DMARC aggregate (RUA) report file, base64-encoded: the .xml, .xml.gz or .zip attachment exactly as received, up to 2 MiB decoded. Encode the file bytes — do not paste raw XML here.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / filename / description
      Previous value: -"Optional original attachment filename (e.g. 'google.com!example.com!....xml.gz') — improves format detection and error messages, changes nothing else."New value: +"Optional original attachment filename, recorded in logs only — format detection is content-based, so this changes nothing about parsing."
  2. Changed2 schema fields changed
    • addedInput schema / properties / content_base64 / description
      Added value: +"One DMARC aggregate (RUA) report file, base64-encoded: the .xml, .xml.gz or .zip attachment exactly as received, up to 2 MiB decoded. Encode the file bytes — do not paste raw XML here."
    • addedInput schema / properties / filename / description
      Added value: +"Optional original attachment filename (e.g. 'google.com!example.com!....xml.gz') — improves format detection and error messages, changes nothing else."
  3. Added

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states that nothing is stored and the report is parsed and discarded, and it discloses supported formats and the 2 MiB decoded size limit. With readOnly and idempotent hints already present, this adds meaningful behavioral detail without redundantly repeating the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences front-load the trigger and purpose, then pack constraints and side-effect disclosure with zero filler. Every clause earns its place.

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?

Covers the input encoding, accepted formats, size constraint, optional filename, the single-report scope, the output shape, and the no-storage guarantee. Nothing is needed to call it correctly that is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents base64 encoding, formats, size limits, and the filename param. The description restates these constraints but doesn't add substantial meaning beyond the schema, so a mid score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb ('Parse ONE DMARC aggregate RUA report'), a precise resource (DMARC aggregate/RUA XML report), and exactly what output results (per-source aggregates with volume and SPF/DKIM alignment). The 'Use this when user uploads or pastes... asks what it says' phrasing clearly distinguishes it from sibling tools that build or monitor DMARC records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger condition is given: use when the user uploads or pastes a DMARC aggregate report and asks what it says. No explicit when-not-to-use or alternative tool is named, but the trigger is specific enough to route the agent correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All dns-doctor toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources