Couryo free email tools

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

Annotations already declare readOnlyHint and openWorldHint, and the description usefully adds 'Free, read only' and describes the response shape: a 0-100 score, a grade, plain-language fixes and copy-ready records. That return-value context matters since there is no output schema. It does not cover rate limits or error behavior.

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?

Front-loaded with the verb, but the first sentence is a long run-on packed with parentheticals, and the entire text is duplicated in Portuguese, roughly doubling length for the same information. The density is informative but not tight.

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 two-parameter read-only checker with no output schema, the description covers what is inspected, what comes back, and that no payment or auth is required. Minor gaps remain around failure behavior for unresolvable domains and response timing.

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 both parameters are already documented in structured fields, including the DKIM selector example. The description only reinforces that DKIM is probed on common selectors plus the optional one, adding little 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?

Uses a specific verb (checks) with a precisely enumerated set of resources: SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI. This clearly separates it from the generate_* siblings, which produce records rather than inspect an existing 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?

Implies usage with 'of any domain' and notes the dkim_selector alternative for custom selectors, but never states when to pick this over generate_spf, generate_dmarc or verify_email. The distinction is inferable from the verb 'checks' but never explicit.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by saying it is free and by specifying the classification categories (hard, soft, policy), the provider, and the next step, though it does not discuss unrecognized input behavior.

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 English portion is front-loaded and efficient, stating purpose, classification, and outputs with no wasted preamble. The bilingual duplication adds length without new information, but it is defensible for a bilingual tool title and does not obscure the core definition.

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 read-only tool with one required string parameter and no output schema, the description is nearly complete: it explains the input as raw error text and describes the returned classification, provider, and next step. It could say more about how unrecognized or ambiguous messages are handled, but no critical gap remains.

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 is fully documented as the error or bounce text 'as it came.' The description provides example error strings, but adds no syntax, format, or boundary guidance beyond the schema's maxLength and required status.

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 verb and resource: it explains a bounce or SMTP error text in plain words. It also names the outputs (hard/soft/policy classification, provider, next step), which distinguishes it from sibling tools like verify_email and the DNS/DMARC/SPF generators.

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 examples and wording imply it should be used when the caller has raw bounce or SMTP error text to interpret, but there is no explicit guidance about when to choose it over alternatives. No exclusions or prerequisites are stated.

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?

Adds context beyond annotations: 'Free, no network' corroborates openWorldHint=false and tells the agent no external calls occur, and it clarifies the output is a single TXT record rather than a published DNS change. It does not state whether anything is written to a zone or merely returned as text, leaving a small gap.

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 English sentence is front-loaded with purpose, then rollout advice, then the cost/network constraint — a sensible ordering with no filler. The Portuguese sentence largely restates a subset, which is mild redundancy but supports the bilingual title.

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 five parameters, no output schema, and only 40% schema coverage, the description should say more about pct semantics and subdomain policy, and should confirm that the record string is returned rather than published. It covers the essentials of what is produced but leaves real gaps 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 coverage is only 40%: rua and domain are documented in-schema; policy and subdomain_policy have enums but no prose, and pct has no description at all. The description adds meaning for policy (p=none rollout) and rua (report address), but leaves pct and subdomain_policy unexplained.

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 and resource — 'Builds one DMARC record (TXT at _dmarc.<domain>)' — including the exact DNS location, which distinguishes it from sibling generate_spf. It stops short of naming a sibling to route away from, but the resource is 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?

Provides operational guidance on policy progression (start p=none, then quarantine/reject once senders pass aligned SPF/DKIM), which is useful but is advice about DMARC configuration rather than about when to call this tool versus check_domain_dns or verify_email. No exclusions or preconditions for invocation are given.

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?

Annotations already cover readOnlyHint and openWorldHint=false, so the bar is lower; the description still adds real behavioral content by warning about the 10-DNS-lookup limit and the cost of each include, and by confirming 'free, no network.' It does not spell out the exact return shape, though 'builds one SPF record' strongly implies a single string.

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 English text is front-loaded and dense with the verb, inputs, and the key constraint in three sentences. The Portuguese half repeats the first sentence at lower detail, which is reasonable for a bilingual audience but adds no new information.

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 6-parameter, no-required-field generator with no output schema, the description covers what is produced, the safe default, and the lookup limit. Only the semantics of ip4/ip6 and the neutral policy value are left implicit.

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 50%; a, mx, and includes are documented in the schema, but ip4, ip6, and policy are not. The description partially compensates by mapping softfail to ~all and fail to -all, yet it says nothing about accepted IPv4/IPv6 address format or what neutral means. Baseline 3 given the partial 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?

States a specific verb and resource ('Builds one SPF record (TXT at the domain)') and enumerates exactly which inputs feed it (includes, IPv4/IPv6, mx, a). It is unmistakably distinct from the sibling generate_dmarc, which produces a different record type.

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?

Gives concrete guidance on the critical decision: start at softfail (~all) and move to fail (-all) only once every sender is listed. That is strong in-tool usage direction, but it offers no explicit routing advice versus siblings like check_domain_dns or generate_dmarc.

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?

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds substantive behavior: nothing is sent, the mailbox is never probed (so an 'invalid' verdict cannot come from SMTP rejection), it costs nothing, and the output collapses to a three-value verdict plus did_you_mean. That is real context an agent cannot get from 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.

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

The English portion is front-loaded and dense, listing checks and then the verdict format with no filler. The definition is roughly doubled in length by the Portuguese restatement, which is presumably intentional localization but adds no new information for an English-reading 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?

With no output schema, the description compensates by naming the verdict values (valid/risky/invalid) and the did_you_mean field, so an agent knows how to parse the response. It also closes the main ambiguity for a verification tool — that no mail is sent and no mailbox probe occurs — so there is nothing material missing 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?

Only one parameter with 100% schema description coverage, so the schema carries the semantics and no compensation is needed. The description adds value indirectly by showing the input domain with real address examples like 'gmail.com.br' and 'hotmial.com', though it does not describe the email parameter itself.

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 and resource ('Checks one email address') and then enumerates the exact checks performed: format, provider typo correction, disposable inbox, shared mailbox prefixes, and MX lookup. The scope is single-address email validation, which cleanly separates it from check_domain_dns and the SPF/DMARC generators.

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 context is clear from 'Checks one email address' and reinforced by the exclusion 'The mailbox itself is never probed', implying an SMTP-probe tool would be the alternative if mailbox existence were needed. However, no sibling is named explicitly as the alternative for domain-level or MX-only questions.

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