LeakData

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

Annotations already cover the safe read-only/idempotent profile, yet the description adds real behavioral context: results are ordered most urgent first, the agent should walk the user through open steps one at a time, and it must never invent steps or self-report progress. These workflow constraints are absent from the structured fields.

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?

Well front-loaded: trigger context first, then return shape, then the operating rules. The enumeration of returned fields is slightly verbose and partially duplicates the output schema, but every sentence still carries usable 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 an output schema present and rich annotations, the description only needed to supply the trigger, the ordering, and the interaction rules — and it does all three. An agent has everything required to call and present this 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?

Zero parameters, which is the baseline 4; the description reinforces this with 'Takes no arguments', removing any doubt, though there is nothing further to add about parameter meaning.

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+resource: returns the open and done steps of the user's own action plan, with stepId, service, masked address and done state. An agent can distinguish it from leakdata.protection_summary or leakdata.breach_lookup purely from the description.

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?

Explicit trigger conditions are given ('when the linked LeakData user asks what they should do about their breaches, what is left on their list'). The exclusion against marking progress implies leakdata.mark_step_done is the alternative, but that sibling is never named, so routing is left 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?

Beyond the readOnly/idempotent/closed-world annotations, it discloses that no sign-in is required, what each result contains (date, account count, exposed data types, summary, first steps), and the interpretation rules for match="similar" and no-match results. That is meaningful operational context annotations cannot carry.

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?

Densely packed but effectively front-loaded: the primary use case and example queries come first, then routing rules and caveats. Long and somewhat clause-heavy, yet nearly every sentence carries either a trigger, an alternative or a correctness caveat.

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 one-parameter lookup with an output schema, the description supplies exactly the missing pieces: when to call it, what it returns in outline, how to interpret weak/no matches, and where to route instead. Nothing an agent needs to invoke it correctly is absent.

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% for the single query parameter, so the schema already defines format, length and the 'never an email/person/password' constraint. The description reinforces this with natural example phrasings but adds no new syntactic or semantic detail 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 names a specific verb and resource — searches LeakData's public breach catalog by company, service or domain — and explicitly distinguishes itself from siblings (leakdata.search for email checks, leakdata.company_monitoring for one's own business). An agent can route to it without opening a 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?

It gives concrete triggering utterances ('Was Canva hacked?'), names two alternatives with their selecting conditions, and covers exclusions ('Not for general security news or a person's name'). Edge-case routing is spelled out via emailCheckAvailable and the company-monitoring handoff.

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 read-only/idempotent annotations: states no sign-in is needed, that it does not enable monitoring or expose personal data, and interprets negative results ('Not listed means not in LeakData's catalog, not that the company was never breached'). That interpretive caveat is exactly the kind of behavior an agent cannot get from structured fields.

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 usage trigger and efficiently dense, but it runs five sentences and some guardrail content (pricing/sales links, repeated non-capability claims) is verbose rather than strictly necessary.

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 an output schema present, return values need not be explained, and the description still covers the trigger, the exclusions, the auth posture, and the meaning of absent results. An agent has everything needed to select and 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 coverage is 100%, so the baseline is 3; the description nonetheless adds meaning by framing the domain as one 'the company verifies it owns,' which clarifies the parameter's business semantics beyond the schema's 'domain the user gave.' It does not add format or syntax detail, so it stays below top marks.

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+resource: it 'explains what LeakData checks for a domain the company verifies it owns and returns any public catalog breaches listed for exactly that domain with their details.' It also carves boundaries against siblings by stating it does not enable monitoring, search employee addresses, or reveal personal data, so an agent can separate it from search/breach_lookup without opening schemas.

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?

Explicit trigger: 'Use this when someone asks about their own company or employer.' Explicit exclusions: not for enabling monitoring, not for searching employee addresses, not for revealing any person's data, and 'do not offer plans, prices or sales links.' Nothing about when to use versus alternatives 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.

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true. The description adds real value beyond them by bounding the blast radius ('Saves the change to the user's LeakData action plan; it does not change anything on the breached site') and clarifying that done=false reopens, so the write is reversible within the plan. No error/permission behavior is described, which keeps it short of a 5.

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 paragraph, but nearly every clause carries a distinct rule (precondition, source of stepId, side-effect scope, the multi-step carve-out). Slightly heavy and led by usage rather than the action, though nothing is 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?

An output schema exists so return values need no explanation. Prerequisites, the fallback tool, the meaning of both parameters, the non-effect on the breached site, and the multi-step edge case are all covered — nothing an agent needs to call this correctly 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%, so the baseline is 3, but the description goes further than the schema: it maps done=true/false to mark-vs-reopen semantics and constrains stepId's provenance to a leakdata.action_plan result, warning against guessing. That is genuine added meaning beyond the field descriptions.

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+resource (mark/unmark a step in leakdata.action_plan) and names the exact sibling artifact the stepId comes from. An agent can distinguish this from leakdata.action_plan or the lookup tools without opening any 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?

Explicit preconditions (only after the user confirms completion), explicit alternatives (call leakdata.action_plan first if no plan result exists in the conversation), and an explicit exclusion ('a request to mark all or several steps done is not confirmation… call this once per confirmed step'). 'Never guess a stepId' closes the remaining misuse path.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds the key non-obvious behavior: this reads stored results rather than performing a scan, and it instructs the agent to report only returned values. It does not discuss freshness limits or empty-result handling, keeping it just short of a 5.

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 trigger clause followed by return contents, sibling routing, and a no-args note — each sentence carries information. The enumeration of returned fields is slightly long given an output schema exists, but it is not wasted since it tells the agent what to summarize.

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 read tool with annotations and an output schema, the description covers trigger, data source, sibling routing, and response handling. An agent has everything needed to select and invoke 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?

There are zero parameters, so the baseline is 4; the description reinforces this with 'Takes no arguments,' leaving no ambiguity that the call needs no input.

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 ('reports stored monitoring results') and enumerates exactly what the user learns: monitored addresses, last-checked times, finding counts, 30-day new findings, open action-plan steps. It clearly distinguishes itself from leakdata.search and leakdata.action_plan.

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?

Opens with an explicit trigger ('when the linked LeakData user asks how their monitoring is going...') and names both alternatives with the condition that selects each: leakdata.search for a fresh check, leakdata.action_plan for the steps themselves. Nothing 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.

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on valuable context they do not convey: no sign-in required, newest-incident-date-first ordering, the lack of a date filter with a prescribed fallback behavior, and the coverage limit that this is one vendor's catalog rather than all breaches worldwide.

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 trigger and purpose, and every sentence carries distinct information (auth, ordering, no-filter caveat, scope limit, exclusions). It is dense and enumerates return fields already covered by the output schema, which is slight redundancy, but there is no 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 read-only lookup with an output schema, the description covers everything an agent needs: when to call it, that no auth is required, what is returned, ordering, the absence of filtering, and the catalog's coverage limits. Nothing material 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 'limit' parameter carries its own description with default and range, so the schema does the work. The tool description never mentions the limit control or how it interacts with the 'newest first' ordering, so it adds no parameter meaning beyond the schema. 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?

The description names a specific verb and resource ('Returns the newest breaches in LeakData's public catalog') and states ordering, returned fields and scope boundaries. It explicitly carves itself out from siblings like search and from adjacent news domains, so an agent can select it 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?

It gives a concrete trigger ('when someone asks which data breaches happened recently'), an explicit exclusion ('Not for general security, ransomware or vulnerability news'), and an operational caveat: there is no date filter, so the agent must inspect returned dates and report when none match the requested period.

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?

Beyond the readOnly/idempotent annotations, it discloses genuinely load-bearing behavior: cached results must not be re-presented as a new check, failures must be reported as incomplete, and — critically — empty results mean no LeakData record matched, not that the email is safe. That last point is behavioral context annotations cannot express.

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 use case and constraints are front-loaded and each sentence carries a distinct safety rule, but it is a single dense block with some redundancy between the query guidance and the schema text. Slightly overstuffed yet defensible for a safety-critical check.

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?

An output schema exists, so return values need no explanation, and the description still covers scope, routing, failure handling, and result interpretation. Nothing an agent needs to call and report this tool correctly 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 50% and the enum 'type' has no schema description, but the description compensates by specifying type='email' and omitting query to use the verified primary email. It does repeat much of the query field's own description, so it adds nuance (user-typed own address) rather than entirely new semantics.

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 the linked user's own email appears in a breach — and names the exact scope (linked account's verified primary email). It clearly differentiates from siblings leakdata.protection_summary and leakdata.company_monitoring, so an agent can route without opening another 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?

It gives explicit when-to-use triggers with example utterances ('Has my email been leaked?', 'Am I in the Canva breach?'), explicit when-not (never for someone else's address, never to look up passwords), and names the alternatives for other cases (protection_summary, company_monitoring).

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