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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds real operational context beyond them: an AHREFS_API_KEY environment requirement, a 1000-domain cap, URL/subdomain normalization to ICANN roots, and null/zero-value semantics for missing metrics.

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?

Dense but front-loaded, with the core action and data source in the first sentence and the constraints/caveats after. It is a single block with no wasted sentences, though it packs many facts into one paragraph rather than grouping them.

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 burden of describing returns, and it does (DR, attribution, license; nulls for missing; zero is valid). Combined with the auth prerequisite and normalization behavior, an agent has nearly everything needed to 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?

Schema description coverage is 0% for the single 'targets' parameter, so the description must compensate. It does: it explains the 1000-item ceiling and that URLs/subdomains are normalized to registrable roots, which meaningfully clarifies what values are acceptable.

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 (get Domain Rating for registrable domains) plus the exact data source (official free Ahrefs public endpoint). This clearly separates it from siblings like edf_whois_lookup, edf_dns_lookup, and edf_check_domains.

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?

Tells the agent when this applies (standalone, 'independent of the EDF app; no launch or job is needed'), which implicitly routes away from edf_launch/edf_get_job workflows, and clarifies what the metric is NOT (DA, PA, traffic, backlink quality). It stops short of explicitly naming an alternative tool for the cases it excludes.

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=false and readOnlyHint=false; the description adds real behavioral value beyond that by clarifying this is a cooperative request rather than an immediate kill, that no further lookups start, and that already-started answers are retained. It does not address whether the call can be safely repeated (idempotentHint=false) or the eventual job state, so it stops short of full disclosure.

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 tight sentences with the action front-loaded and the behavioral consequence second. No filler, nothing redundant.

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 mutation with no output schema, the description covers the key behavior an agent needs (request semantics, no new work started, partial results kept) and its safety profile is covered by annotations. Missing only the post-call state/return expectations.

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 0% for the single 'id' parameter, so the description carries the burden; it implies the id identifies a job but adds no format, source, or constraint details beyond that. Partial compensation only.

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 (cancel) and resource (job) with an ownership qualifier ('owned by this server'), which makes it clearly distinct from sibling readers like edf_get_job and edf_list_jobs. It does not explicitly name a sibling, but the action 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?

Usage is implied by the action itself (stop a running job), but there is no explicit when-to-use guidance, no note about what happens if the job has already finished, and no mention of alternatives such as letting a job complete or re-launching.

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 the mutation/open-world profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely new behavior: async return of a job ID, the single-concurrent-job limit, delay shared across all workers, and that results are provisional candidates. No auth or error behavior is covered, but the disclosure is well beyond 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?

Front-loads the core action, then layers constraint, workflow, and mode semantics. Dense but nearly every clause carries information; the 'bridge share the configured delay' phrasing is slightly opaque jargon but not wasteful.

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 an async job-launching tool with no output schema, the description correctly substitutes by stating the immediate return (job ID) and the polling/export path. The absence of an output schema is therefore compensated, though retry/failure semantics for the job itself are left unstated.

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 0%, so the description must carry the load, and it does: it defines what each mode means operationally, restates the 1000-domain cap, and explains that concurrency is 1-7 (default 7) and delay is shared across workers. It omits the delay_ms unit/bounds (250-10000) and any per-domain string format guidance.

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+scope: 'Start one saved background domain-check job (up to 1000 domains)'. This clearly distinguishes it from the single-domain siblings edf_dns_lookup and edf_whois_lookup, which the agent can rule out 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?

Gives the follow-up workflow explicitly (poll edf_get_job, export with edf_export_results) and a hard constraint ('only one saved job may run at a time'), plus the mode-selection rule for dns_then_whois vs whois_all. It does not explicitly contrast itself with the synchronous lookup siblings, so it stops 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 declare readOnly=false, openWorld=true, idempotent=false, destructive=false, but the description adds meaningful context beyond them: hard bounds (500 pages / 1000 domains), a same-origin queue, async job-ID return pattern, and the critical limitation that the native regex crawler does not render JavaScript. It does not discuss rate limiting or failure behavior, keeping it just short of 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?

Dense and front-loaded: purpose first, then scope limits, then the return/poll pattern, then the JS caveat. Four tight sentences with little waste, though 'EDF' is used without expansion and the ordering could group the caps with the parameter meaning more tightly.

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 tool with 0% schema coverage and no output schema, the description covers purpose, bounds, async return, and a key limitation, but leaves delay_ms and the meaning of the returned job payload unaddressed. Adequate but with clear gaps for an agent configuring a crawl.

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 0%, so the description carries the burden. It maps some params to behavior — 'website or sitemap' (mode), 'at most 500 pages/1000 domains' (max_pages/max_domains), and 'optionally check them' (check_domains) — but delay_ms and the url constraint are never explained, and no value-level semantics beyond the caps are given.

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 ('Start a bounded EDF crawl of one public website or sitemap'), plus the side-effect of discovering external hostnames. It is clearly distinguishable from siblings like edf_check_domains or edf_dns_lookup, and it names the follow-up tool edf_get_job.

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 implicit context for use (start a crawl, then poll edf_get_job) but offers no explicit when-to-use vs when-not, and does not contrast with alternatives such as edf_check_domains for just checking hostnames. The async handoff to edf_get_job is the only routing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine non-annotation context: the 100-domain batch ceiling and the important interpretive caveat that a negative DNS result does not mean the domain is unregistered.

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, no filler. The operational scope is front-loaded and the caveat follows immediately, so an agent reads the actionable content first.

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 tool with rich annotations, the description covers purpose, limit, and result interpretation. With no output schema present, it should ideally indicate what the check returns (resolved A records vs. per-domain status), and it gives no input format guidance, leaving two real gaps.

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 0%, and the one parameter (domains) gets no format guidance in the description — it is unclear whether bare hostnames, URLs, or FQDNs are accepted. The description only echoes the schema's maxItems=100 constraint via 'up to 100 domains', adding batch framing but little semantic 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?

Specific verb and resource: 'Run native EDF batch A-record DNS checks', with a stated scope of 'up to 100 domains'. This implicitly separates it from siblings like edf_whois_lookup and edf_check_domains by naming the exact record type and mechanism, though it never names an alternative explicitly.

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 line 'Missing DNS is not proof of domain availability' implies the agent should not treat this as an availability checker and should look elsewhere (e.g., whois or a domain check) for that judgment. However, no explicit when-to-use, when-not-to-use, or named alternative is provided, leaving the routing 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 establish that this is a non-read-only, closed-world, non-idempotent write. The description adds genuinely new context beyond them: the write is sandboxed to 'the EDF data exports folder' and the return value is a local absolute path. It stops short of stating overwrite/repeat-call behavior, which matters given idempotentHint=false.

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, zero filler, with the action and return value front-loaded before the filter and sandbox details. 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 helpfully names the return value (absolute path) and covers the write side effect and its scope. The main gap is the required id parameter and any caveat about repeated exports, but for a 3-parameter tool this is largely sufficient.

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 0%, so the description must compensate, and it partially does: 'status filter, e.g. candidate_available' explains the status parameter and 'CSV or JSON' maps to format. The required id parameter is only loosely implied by 'a saved job', leaving its semantics (job identifier) undocumented in both places.

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 ('Export a saved job to local CSV or JSON') plus the return value ('absolute path'), so the agent knows exactly what it produces. It does not explicitly contrast itself with siblings like edf_get_job or edf_list_jobs, which is the only reason it falls short of a 5.

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?

There is no statement of when to choose this over edf_get_job or edf_list_jobs, nor any prerequisite such as the job needing to be finished before export. The only usage hint is that status is an optional filter with an example value, which is thin 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds two useful non-annotation facts: results are paginated and EDF native labels are provisional (a data-reliability caveat). It says nothing about result volume, ordering, or whether provisional labels can change between calls.

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, front-loaded sentences with no filler. The provisional-label caveat is somewhat cryptic without elaboration, but 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 tool with three completely undocumented parameters, no output schema, and an unexplained enum, the description is thin. An agent cannot determine what 'source' selects or how paging behaves from either the schema or the description.

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 0%, so the description must carry the burden for limit, offset, and source. It only hints at pagination and never explains the checker/crawler enum or the defaults, leaving the semantics of all three parameters essentially undocumented.

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: read paginated results from the manual EDF app UI. It distinguishes itself from sibling edf_get_job. It is slightly vague on what 'EDF app UI results' actually contain, but an agent can tell it apart from the job-oriented siblings.

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 automated-job consumers to edf_get_job instead, which is a clear when-not signal. It does not, however, mention the other plausible alternatives such as edf_export_results or edf_status, so the routing is only partial.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. 'Does not change settings' merely restates destructiveHint=false and adds no new behavioral detail such as required auth, whether the returned config is live or cached, or any scoping constraints. With annotations carrying the burden, a 3 is appropriate.

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 with no filler, and the primary action is front-loaded ahead of the optional-parameter and safety notes. Every sentence carries information an agent needs.

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-optional-parameter config reader with no output schema, the description covers the action, the optional narrowing argument, and the fact that nothing is mutated. It could hint at the shape of the returned configuration, but with no output schema an agent would not be much better served by prose about the response.

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 0%, so the description must compensate, and it does: 'Optionally inspect one TLD' explains both the meaning and the optionality of the sole `tld` parameter. It does not restate the schema's lowercase pattern or length bound, but the description meaningfully exceeds the bare 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?

States a specific verb and resource: 'Read the EDF native DNS and WHOIS configuration,' with a secondary scope note about inspecting one TLD. An agent can distinguish it from the lookup siblings (edf_dns_lookup, edf_whois_lookup) by the word 'configuration,' though the description never names those siblings explicitly, so differentiation requires inference.

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?

'Optionally inspect one TLD' gives implied usage for the single parameter, telling the agent the call is valid with no argument. However, there is no explicit when-to-use vs. when-not guidance and no mention of how this differs from the DNS/WHOIS lookup siblings, which is the most likely routing confusion for an agent.

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, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the polling loop and the enumeration of terminal states, which is exactly what an agent needs to drive the call sequence.

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 core purpose, then polling behavior, then the one parameter caveat. No filler and nothing repeated from the schema.

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 does cover the return shape at a high level (job progress plus paginated result rows) and the terminal-state set that governs repeated calls. Pagination mechanics (defaults, max page size) are left to the schema, which is acceptable.

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 0% and there are four parameters. The one clarifying statement ('status filter applies to result rows') usefully disambiguates the enum so it is not mistaken for filtering on job state, but id, limit, and offset are left entirely unexplained by both schema and description.

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 (Get) and resource (saved job progress and paginated result rows), which is materially more informative than the bare name edf_get_job. It does not explicitly distinguish itself from siblings edf_list_jobs or edf_cancel_job, so an agent must infer the boundary.

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 operational context: poll repeatedly until the job reaches a terminal state (completed, cancelled, failed, interrupted). It does not name alternatives such as edf_list_jobs (to discover job ids) or edf_cancel_job, so the routing guidance is incomplete rather than 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=false, idempotentHint=false and destructiveHint=false. The description adds genuinely new behavioral context: it leaves existing manual work intact and will report if EDF must first be closed, which tells the agent about side effects and preconditions beyond the annotation set.

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 short sentences with no waste, front-loading the primary action before the fallback mode and the side-effect note. Every clause earns its 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 zero-parameter, no-output-schema launch tool, the description covers the essential action, the non-destructive behavior toward existing work, and the possibility of a 'must close first' report. It stops short of explaining what the automation connection returns or how the caller should react to the close-required report.

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 takes zero parameters, so the description carries no parameter burden. Baseline 4 is appropriate; there is nothing for the description to disambiguate in the input 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?

States a specific verb and resource ('Start EDF') and clarifies the two operating modes: a loopback automation connection or reusing the exact installed EDF page. It does not directly name or contrast a sibling tool, but 'launch' is clearly distinct from the read/query siblings (edf_status, edf_list_jobs, 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?

Implies when the tool applies (starting EDF) and notes the two connection strategies, but gives no explicit when-to-use vs. when-not-to-use guidance or prerequisite conditions (e.g., when a loopback connection is preferable to reusing the installed page).

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, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds one genuine behavioral fact beyond that — interrupted jobs are retained across server shutdown — but says nothing about ordering, pagination, or freshness of the 'progress' figures.

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 short sentences, no redundancy, and the core purpose ('List saved EDF automation jobs') is front-loaded before the retention caveat. 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?

For a zero-parameter, read-only listing tool with annotations covering the safety profile, the description is largely sufficient. With no output schema, it could say a bit more about what each listed job contains (status fields, ordering), which is the only remaining 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and the description correctly does not invent or describe parameters that do not exist.

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 gives a specific verb and resource — 'List saved EDF automation jobs and their progress' — which is clearly distinguishable from the singular sibling edf_get_job and from edf_launch/edf_cancel_job. It does not explicitly name the sibling it contrasts with, so it stops short of a 5.

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 by the word 'List' — an agent can infer this is the enumerate-all-jobs call, but there is no explicit statement of when to use this versus edf_get_job (single job), edf_status, or edf_cancel_job. No exclusions or preconditions 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds the non-obvious behavioral fact that it observes live state and UI activity but will not start the app, which is genuinely beyond what the annotations 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 short sentences, front-loaded with the verb and the list of inspected items, and the negative constraint placed last. No filler, though 'exact inspected package' is cryptic enough to slightly blur an otherwise tight statement.

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, fully-annotated diagnostic tool this is largely sufficient — the agent knows it is a safe read that will not launch anything. The only gap is that with no output schema, the shape of the returned status (pass/fail vs. detailed report) is left unstated.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.

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 concrete verb ('Check') and enumerates exactly what is inspected: the EDF installation, the inspected package, live connection, and manual UI activity. That is far more specific than the name alone, though it never names a sibling besides implicitly contrasting with edf_launch.

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 clause 'Does not start the app' functions as a when-not and implicitly routes the agent to edf_launch, which is real routing signal. However there is no positive statement of when to reach for this rather than edf_get_configuration or edf_get_job, so usage remains only implied.

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 open-world behavior, so the safety profile is covered. The description adds real context beyond that: it discloses the output shape (conservative classification, native evidence, optional raw text) and explicitly bounds the tool's claims with 'No expiry-history or purchase guarantee', which is exactly the kind of limitation an agent needs.

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 action and scope, followed by output and limitation. No filler, and every sentence contributes something an agent would otherwise have to guess.

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 steps in to sketch the return value (classification, evidence, optional raw text), and the annotations cover the safety profile. Only minor gaps remain, such as expected domain format and failure behavior, which are acceptable for a low-complexity, two-parameter 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 description coverage is 0%, so the description must carry parameter meaning. 'optional raw text' maps reasonably to include_raw, giving some semantic value, but the required 'domain' parameter gets no format, normalization, or accepted-input guidance anywhere.

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 (WHOIS lookup for a single domain) and signals scope with 'for one domain'. It is clearly distinguishable from siblings like edf_dns_lookup or edf_check_domains by the WHOIS resource, though it never names an alternative explicitly.

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?

There is no statement of when to use this tool versus the sibling lookups, no prerequisites, and no exclusions for usage. The closing caveat about expiry history and purchase guarantees constrains expectations of the output, not the choice of tool.

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