postbox-tools

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 meaningfully discloses that SPF, blacklist, and reverse-DNS checks are not possible from a static .eml file, and it implies a non-live, non-SMTP analysis mode. It does not describe return format or side effects, but the limitation disclosure is substantive for this 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 compact and front-loaded: purpose first, then the critical limitation and alternative, then a brief contextual note. Every sentence contributes to agent decision-making, with no redundant verbiage.

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 single-parameter tool with no output schema and no annotations, the description provides enough context to invoke it correctly: it defines the input, explains the offline scope, and points to create_mailtest when authoritative verification is needed. The only minor gap is that it does not describe what the analysis returns.

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 already fully describes the sole parameter (eml as 'The complete raw email source (headers + body)'), and the description's mention of 'full headers + body' adds little beyond the schema. With 100% schema description coverage, the baseline is 3; the description adds no encoding, size, or format constraints.

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 a specific action ('Run a deliverability/content analysis') on a specific resource ('raw RFC 822 email' with 'full headers + body'). It also distinguishes itself from create_mailtest by framing this as a file-based offline analysis, making selection straightforward relative to siblings like check_blacklist and check_spoofability.

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 names a limitation ('with no live SMTP session, SPF, blacklist and reverse-DNS cannot be verified from a file') and gives a direct alternative ('for the authoritative score use create_mailtest instead'). This gives an agent clear when-to-use and when-not-to-use guidance.

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

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 does explain the core behavior—checking a domain's mail-relevant IPs or a single IP against 24 DNSBLs—and states that it returns per-IP listing status. However, it does not mention network side effects, rate limits, or limitations such as DNSBL false positives.

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 concise sentences with no filler. The core operation is front-loaded, the return behavior is stated, and the 'free tool' note adds relevant context without bloating the description.

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 single-parameter tool with a fully described schema and no output schema, the description is nearly complete. It explains what input is acceptedшение, how domains are handled, and what the response conveys. It could be more explicit about the exact output format, but the per-IP listing status summary is sufficient 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?

The schema already describes the 'target' parameter as a domain or IPv4 address (100% coverage). The description adds meaningful nuance by clarifying that a domain is checked via its mail-relevant IPs, which is not present in 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 a specific verb ('Check') with a clear resource ('a domain... or a single IP address') and a precise scope ('against 24 DNS blacklists'). Naming specific lists like Spamhaus ZEN and Barracuda makes it easy to distinguish from siblings such as whois_lookup or check_spoofability.

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 clearly implies when to use the tool: when you need DNS blacklist status for a domain or IP. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to select it appropriately among the listed siblings.

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

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

With no annotations, the description carries the behavioral burden. It clearly indicates a read-only DNS-based analysis and states the output format (A-F grade with findings). It could mention limitations/rate limits, but the 'from its public DNS' phrasing sufficiently implies no domain mutation.

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 core information is front-loaded in two efficient sentences: what it grades, how it grades, and what it returns. The trailing 'Free tool by Postbox Services' sentence adds little for tool selection or invocation, preventing a 5.

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 one-parameter tool with no output schema, the description is complete enough: it names the input domain, the method, and the returned grade/findings. It could elaborate on the findings structure, but nothing essential for a correct call is missing.

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% and the single 'domain' parameter is already documented with an example. The description adds contextual meaning about DNS checks but no additional parameter syntax or formatting details, so the baseline 3 applies.

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?

States a specific verb ('Grade') and resource ('domain... exposed to email spoofing and BEC') with clear method details (SPF, DMARC, alignment, lookalike domains). The A-F grade output distinguishes it from sibling tools like check_blacklist and whois_lookup without ambiguity.

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 intended use is implied: evaluate a domain's spoofing/BEC exposure. However, the description does not explicitly say when to prefer this tool over siblings or when not to use it, leaving selection partly to inference.

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

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 discloses that the address is disposable, that the tool does not send the test email itself (the USER must send it), that it is free, and that results arrive via a separate follow-up call. It stops short of mentioning expiration or rate limits, but the core behavior is clear.

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 compact and front-loaded: the primary action appears first, followed by a dense audit checklist, a required user action, and a pointer to the result tool. Every sentence earns its place, and 'Free tool by Postbox Services' is a useful cost signal rather than 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?

For a zero-parameter tool with no output schema, the description covers the essential workflow, the audit dimensions, and the follow-up call. It could be slightly more explicit about the response format or address lifetime, but an agent has enough information to invoke and sequence the tool 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 an empty input schema, so no parameter documentation is needed. The description's reference to a 'returned address' is sufficient context for how the result is used even though the response schema is absent.

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 opens with a specific verb and resource: 'Create a disposable test address for a full email deliverability audit.' It clearly distinguishes the create step from the companion get_mailtest_result tool and enumerates the audit's scope, so an agent knows exactly what this tool produces.

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 gives a clear two-step workflow: call this tool, then have the user send an email, then call get_mailtest_result. It does not explicitly state when not to use sibling tools like check_blacklist or whois_lookup, but the full-audit purpose is enough to guide selection in most cases.

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

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

No annotations are provided, so the description must carry safety and behavioral disclosures. It only says 'get' (implying read-only) and 'free tool', but doesn't mention rate limits, required permissions, or what exactly the result contains. This is minimal behavioral transparency for a tool with no annotations.

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 the core purpose front-loaded. The second sentence's 'Free tool by Postbox Services' adds trust context but is not essential for invocation, making it slightly less than perfectly lean.

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 description tells what it does and why, but for a tool with no output schema and no annotations, it omits details like result format, safety profile, and when not to use it. It's adequate for a simple lookup but leaves an agent to infer several operational aspects.

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 documents the only parameter (domain) with 100% coverage, so the description doesn't need to add much. It adds no extra semantics beyond what the schema provides, matching the baseline for high schema description 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 retrieves a domain's registration date and age, a specific verb and resource. It adds context about sending reputation, but doesn't explicitly distinguish it from the sibling whois_lookup, which may also return registration data.

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 evaluating sending reputation ('young domains have weak sending reputation'), but doesn't explicitly state when to prefer this over alternatives like whois_lookup or provide exclusions. The context is helpful but not explicit guidance.

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

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

With no annotations, the description carries the full burden. It adds useful behavioral context: the result depends on a prior create_mailtest call and a user action (sending email). However, it does not disclose what happens if the user hasn't sent the email yet, whether the tool blocks/polls, or how errors are surfaced. 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.

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

The description is one sentence that is front-loaded with the action and object, then provides the necessary workflow context. Every word earns its place; no filler or 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?

For a simple one-parameter fetch tool with no output schema, the description covers the essential context: what it returns, what it depends on, and when to call it. The only mild gap is unspecified behavior when the email hasn't been sent yet, but the phrase 'once the user has sent...' implicitly addresses that.

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 single parameter 'id' is already documented as 'The test id returned by create_mailtest'. The tool description adds no additional parameter meaning beyond reinforcing that relationship. Baseline 3 applies since the schema carries the load.

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 ('Fetch') with a precise resource ('score and breakdown of a mail test created with create_mailtest'). It also includes the precondition ('once the user has sent their email to the disposable address'), which clearly distinguishes this tool from siblings like check_blacklist or whois_lookup.

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 workflow context by linking the tool to create_mailtest and specifying the prerequisite user action. It doesn't explicitly exclude alternative tools, but the reference to the specific creation tool and the timing ('once the user has sent...') gives an agent enough guidance to know when to invoke this versus the sibling tools.

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

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

With no annotations, the description carries the behavioral disclosure burden and does so well: it reveals the tool makes server-side requests, follows every hop, and reports status, IP, TLS, timing, and domain/security flags. It does not mention limits such as maximum hops or rate limits, but the core behavior and output categories are 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.

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

The main sentence is dense but well structured, front-loading the action and then listing what each hop yields, followed by the detection flags. The trailing 'Free tool by Postbox Services' adds no actionable information for an AI agent, so it is not entirely free of 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?

For a single-parameter tool with no output schema, the description provides enough context to call it correctly: it defines the input URL type, explains what the trace does, and enumerates the returned data categories (status, IP, TLS, timing, flags). No critical invocation detail appears missing.

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 already fully documents the single 'url' parameter (100% coverage), including the requirement for an absolute http:// or https:// URL. The description repeats the idea of following a URL but adds no new parameter-level semantics, so the baseline score of 3 applies.

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 a specific action ('Follow a URL server-side through every HTTP redirect hop') and a concrete outcome ('real final destination'), with a clear domain: URL redirect tracing. This clearly differentiates the tool from the email/blacklist/whois sibling tools.

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 establishes when the tool is relevant: when a caller needs to trace HTTP redirects, see per-hop status/IP/TLS/timing, or detect phishing/deliverability flags. It does not explicitly list when-not-to-use or name a direct alternative, but the context is clear and no sibling offers a comparable function.

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

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

No annotations are present, so the description carries the disclosure burden. It clearly enumerates the returned fields, says it provides a summary, and notes it is a free tool, which suggests no authentication or payment barrier. It does not discuss redacted WHOIS data or rate limits, but these are minor for a read-only lookup.

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 compact sentences with the key payload front-loaded: registrar, dates, nameservers, DNSSEC, and status flags. The attribution clause is short and does not dilute the 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?

With one required parameter and no output schema, the description lists the expected return fields, which is enough for an agent to invoke and interpret results. It omits edge considerations like WHOIS redaction or availability guarantees, but those are secondary for a simple lookup 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% and the schema already documents the domain parameter with an example. The description only restates 'for a domain' and adds no additional syntax, format, or validation detail beyond the schema, so the 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 states the result precisely: a WHOIS summary with registrar, dates, nameservers, DNSSEC, and status flags. It is clearly about domain WHOIS data, but it does not explicitly contrast with the sibling get_domain_age, which likely overlaps on registration date.

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?

Usage is implied: an agent should call this when it needs a WHOIS summary for a domain. However, there is no explicit when-not-to-use guidance or mention of alternatives among the sibling tools, so routing is left to inference.

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