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

Beyond the annotations, the description explains the privacy-preserving k-anonymity flow: local SHA-1 hashing, sending only the first five hex characters, local matching, and returning { pwned, count }. It also warns users not to paste real passwords and never to repeat the password back.

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 front-loaded with the core purpose and privacy mechanism, then includes the return shape and safety warning. Every sentence adds useful information without repetition.

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?

Although there is no output schema, the description supplies the return shape. It also covers the privacy model, safe usage warning, and non-disclosure instruction, making it complete enough 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 100% and the parameter already documents using a throwaway string. The description adds meaningful semantics about how the password is handled locally and minimized before transmission, which goes 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 states a specific verb and resource: checking whether a password appears in known data breaches, with named sources and a privacy mechanism. It is clear on its own, but it does not explicitly differentiate this tool from siblings such as hash_text or lookup_cve.

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 use context is clear: check a password against breach data, and use a throwaway or sample string rather than a real password. It does not explicitly say when to prefer this over sibling tools, so it falls short of explicit alternative routing.

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 readOnly, idempotent, non-destructive and closed-world, and the description's 'Idempotent' merely restates one of them. However, it adds genuinely new behavioral information beyond the annotations: the specific substitution forms used and the fact that extracted indicators are also returned, which matters since there is 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?

A single sentence that front-loads the verb and resource list, then the rationale, then the side output. Nothing is redundant or padded.

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 pure function this is nearly complete, and it helpfully signals a side output ('list the extracted indicators') in the absence of an output schema. It stops short of describing the return shape or behavior on text with no indicators, which would fully close the 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?

With 100% schema coverage on a single parameter, the schema already documents 'text' including the 64 KB limit. The description adds no additional semantics about the input beyond naming the indicator types, so the baseline 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?

States a specific verb (defang) and enumerates the exact resource types handled (URLs, IPv4, emails, domains), plus concrete transformation examples (hxxp://, [.], [@]). It doesn't explicitly name the reverse sibling refang_iocs, but the verb itself is unambiguous enough that an agent can distinguish the pair.

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 phrase 'so they are safe to paste into tickets or chat' gives a concrete use case and context, which is clear guidance about when this tool applies. There is no explicit exclusion or named alternative (e.g., 'use refang_iocs to reverse'), so it falls short of a 5.

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 readOnly, idempotent, non-destructive, closed-world. The description adds meaningful context annotations don't: the answer comes from a small bundled table, so coverage is limited and unknown ids may be missing. That's a real behavioral caveat.

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?

One dense sentence with zero filler; the source/table caveat and the log constraint are both front-loaded alongside the core 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?

A simple two-param read tool with a mature annotation profile and no output schema; the description supplies the table-scope caveat and required log semantics. Only a hint about what a 'not found' result looks like is absent, which is minor.

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 full enum for log and an integer range for event_id, so the schema carries the load. The description's note about log-scoped uniqueness duplicates the schema's own description of `log` rather than adding new syntax or format detail.

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 (Explain) and a specific resource (Windows Security/System/PowerShell/Sysmon event ids), plus the output content: meaning, what to look for, related ATT&CK ids. Distinguishes itself from siblings like lookup_cve and explain_mitre_technique by 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?

Gives a usage precondition that matters: 'ids are only unique within a log, so pass the log.' Examples (4625, Sysmon 10) clarify the input domain. It doesn't explicitly name alternatives, but sibling scope is unambiguous.

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 readOnly/idempotent/non-destructive and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the data comes from a bundled offline snapshot and every result carries the ATT&CK version, which matters for staleness/trust. It stops short of stating behavior for unknown or malformed IDs.

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?

A single front-loaded sentence leads with the verb and resource, then enumerates returned fields — useful given there is no output schema. The field list is slightly long but each item is informative, so little waste.

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 enumerating what the response contains (name, tactics, platforms, detection, mitigations, URL, version), and the offline-snapshot note covers the closed-world trait. For a simple single-ID lookup, nothing essential is missing beyond error handling.

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 defines the id pattern, max length, and an example. The description only repeats the example format (T1059.001), adding no new semantics beyond the schema, 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 ('look up') and resource ('MITRE ATT&CK enterprise technique or sub-technique') with a concrete example ID, so an agent knows exactly what the tool returns. However, it does not distinguish itself from the sibling search_mitre, leaving the lookup-by-id vs search distinction implicit.

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 only implied: the single-id lookup and example suggest 'use when you already have a technique ID,' but no explicit when-to-use/when-not guidance is given and search_mitre is never mentioned as the alternative. An agent must infer the routing from sibling names alone.

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 readOnly/idempotent/openWorld=false/non-destructive. The description adds genuine value beyond them: the operation happens "locally" (no network egress, relevant for sensitive text) and is capped at 64 KB, both of which affect how an agent should prepare input.

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?

A single front-loaded sentence with no filler; the algorithm list and the size constraint both earn their place.

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 pure, deterministic, two-parameter tool with full annotation and schema coverage, nothing essential is missing; "hex digest" even covers the return type in the absence of an output schema. Minor gap: no guidance on default algorithm selection rationale.

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 includes the enum values, defaults, and the security caveat on md5/sha1, so the description's restatement of algorithms and the 64 KB cap adds nothing new. Baseline 3 applies when the schema does the work.

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?

Specific verb ("Compute") plus resource ("md5, sha1 or sha256 hex digest of UTF-8 text") with a scope qualifier ("locally"). No sibling offers hashing, so the tool is unambiguously distinguishable from lookup_cve, parse_log_line, 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 "locally" qualifier and size cap imply context (offline, small inputs), but there is no explicit statement of when to pick md5 vs sha1 vs sha256 or when not to use this tool. Usage must be inferred rather than read.

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?

Goes well past the annotations by disclosing the exact payload shape (CVSS v3.x score/vector/severity, dates, weaknesses, CPEs), that CPEs are trimmed, that references are capped at 10, and — critically — that third-party text is quarantined in an "untrusted_fetched_text" field to be treated as data, not instructions. That injection-safety note is a substantive behavioral trait the readOnly/idempotent hints cannot convey.

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, both earning their place: the first defines the payload, the second defines the trust boundary for that payload. Front-loaded with the action and source, with the security caveat immediately after.

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 must describe return values — and it does, listing the field groups and the reference cap. Combined with the untrusted-text warning, an agent has everything needed to call it and to interpret the response safely.

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 parameter already carries a regex pattern and an example (CVE-2021-44228), so the schema does the heavy lifting. The description adds no additional syntax or formatting guidance beyond that, which is the correct baseline 3.

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 ("Fetch a CVE record"), names the authoritative source (NIST NVD), and enumerates exactly which fields come back. No sibling tool overlaps, so no differentiation burden exists, and an agent can tell instantly this is the CVE-detail 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 context of use is clear: given a CVE id, retrieve its record from NVD. No exclusions or alternatives are stated, but the sibling list contains no competing CVE tool, so there is nothing to disambiguate against.

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?

Goes well beyond the annotations by disclosing the 4 KB limit, the no-guessing failure mode (recognised=false), and a trust boundary warning that field values are untrusted log data — a genuinely useful safety cue for downstream handling. Annotations already cover read-only/idempotent/non-destructive, and nothing here conflicts with them.

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?

Four compact sentences, front-loaded with the core action and limit, then formats, then failure behavior, then the trust caveat. No filler sentences.

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 carries the return burden and does disclose the recognised=false flag plus that values are raw log-derived. It doesn't enumerate the structured field set, but for a two-parameter parser this is close to complete.

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 baseline is 3; the description adds value by naming the concrete formats the 'format' enum selects between and by marking auto-detection as the default path. It stops short of describing per-format constraints, but the schema already handles those.

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 ('Parse one log line/event into structured fields') and immediately scopes the supported input families (Sysmon JSON, syslog/auth.log, Windows event text). An agent can tell exactly what this does and what inputs it accepts without opening the schema.

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 clear context: one line at a time, max 4 KB, multiple formats, and the fallback behavior when input is unrecognised. It does not name when-not-to-use or an alternative tool, but no sibling overlaps this parse function, so the omission is minor.

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 establish read-only, idempotent, non-destructive behavior, and the description adds the critical non-obvious trait: the output contains live indicators and must not be interacted with. This is exactly the kind of safety context annotations cannot convey.

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, front-loaded with the transformation and followed by the essential safety warning. Nothing is wasted.

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 transformation tool with no output schema, the description covers purpose, accepted inputs via schema, and the key property of the returned data. It does not explicitly state the return type or shape, though the warning implies the result contains live text.

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?

There is one parameter with 100% schema description coverage, and the schema already explains the accepted content and 64 KB limit. The description adds no parameter detail, which is acceptable given the baseline for fully documented schemas.

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 transformation ('Reverse defanging') and illustrates it with concrete mappings (hxxp -> http, [.] -> ., [@] -> @). It clearly distinguishes the operation from its sibling defang_iocs by specifying it is the reverse.

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 use case is clear: undo defanging on indicators. It adds an explicit operational caution ('do not click or browse'), but it does not name defang_iocs as the inverse alternative or describe 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.

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world (openWorldHint=false); the description adds that results come from a bundled static snapshot and specifies the return shape (id, name, tactics). It stops short of describing ranking or pagination behavior, so it adds context rather than full behavioral depth.

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?

Three short sentences, front-loaded with the resource and scope, then the return shape, then the sibling routing. No filler and every sentence carries 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?

With no output schema, the description usefully names the returned fields, and annotations cover the safety profile. Minor gaps remain around ranking determinism and how many fields a match contains, but an agent has enough to call it 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?

Schema description coverage is 100% and both parameters are documented inline (query examples, limit range 1-25), so the schema carries the parameter burden. The description adds only that matches are ranked, with no additional semantics for query syntax or limit effects – 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?

States a specific verb and resource ('Keyword search over the bundled MITRE ATT&CK enterprise snapshot') and distinguishes itself from the sibling explain_mitre_technique, which is named explicitly. An agent can tell it apart from the other mitre tool without opening either schema.

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?

Explicitly routes detail-seeking callers to explain_mitre_technique, giving clear context for when this tool is the wrong choice. It does not spell out exclusions or when-not-to-search, but the alternative is named directly.

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