BACKLNK

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description matches that by describing a builder that emits text lines with accompanying explanations and warnings rather than anything that mutates state. It adds real value beyond the annotations by disclosing that the output includes per-line explanations and warnings; the main undisclosed behavior is precedence between an explicit preset and the crawlers/purposes overrides.

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: the first front-loads what the tool produces, the second covers how to drive it via presets or granular decisions. Dense but every clause carries information; only minor friction from nesting three preset definitions inside one sentence.

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 no-output-schema tool with nested objects (purposes, crawlers), the description does say the result is robots.txt lines with explanations and warnings, which is the key return-value hint. However, it never clarifies how a preset interacts with explicit per-purpose or per-crawler overrides, nor whether the generated lines are merely returned or applied anywhere — the one gap an agent could actually stumble on.

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 67% and the three preset enum values have no descriptions in the schema, so the description's gloss — 'block-training: Block AI training, stay in AI search', 'block-ai: Block AI crawlers, keep search engines', 'allow-all: Allow every crawler' — supplies meaning the schema cannot. It also names the two override axes ('per purpose and per crawler token'), though it does not explain how those combine with a preset.

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 robots.txt lines that allow or block AI crawlers from BACKLNK's reviewed crawler catalog.' It also discloses what the output contains ('what each line does and warnings'), which no sibling tool (get_report, list_checks, run_checks, usage, verify_fixes) offers, so an agent can route to it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly presents the two invocation modes — pick a named preset for a standard stance, or 'decide per purpose and per crawler token' for fine-grained control — and each preset carries its own intent label (block-training, block-ai, allow-all). It stops short of saying when this tool is *not* appropriate or how preset and manual inputs combine, so it is clear context without exclusions.

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 genuinely useful behavior beyond that: the default filtering mode hides non-actionable findings, so an agent knows its view is already curated unless it passes detail="all". It omits what happens when audit_id is unknown or the check is still running, which keeps it from 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 sentence with the return payload front-loaded and the enum semantics appended in a parenthetical; every clause carries information. The nested quoting inside the parenthetical makes it slightly harder to parse than a two-sentence split would be.

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?

There is no output schema, so the description must characterize the return value, and it does enumerate the fields delivered (state, summary, counts, findings). For a simple two-parameter read tool with full schema coverage and annotations, the only missing piece is failure behavior for a stale or invalid audit id.

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 by defining the two enum values semantically — "actions" yields issues and warnings only, "all" yields every finding — which the schema only labels as "Default \"actions\"" without explaining the distinction.

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: "Returns the compact report of an earlier check," followed by the concrete payload (state, summary, counts, findings). It is clearly a result-retrieval tool distinct from run_checks (which produces audits) and list_checks (which enumerates them), though it never names those siblings 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?

"of an earlier check" implies the prerequisite that an audit must already exist, and the schema reinforces this via audit_id "returned by run_checks." But there is no explicit when-to-use vs when-not guidance, and no routing between this and list_checks or verify_fixes for an agent deciding which report view to fetch.

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 the meaningful remaining behavior by describing the shape of the returned catalog. It does not say whether the catalog is static or environment-dependent, which is a minor gap for a listing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, both front-loaded with the essential fact first (what it lists, then what to do with the result). Nothing is repeated from the title or annotations, and 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 zero-parameter catalog tool with no output schema, the description supplies what the return values contain and how they feed run_checks, which is the information an agent actually needs. Only the static-vs-dynamic nature of the list is left unstated, a small omission for this complexity level.

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 there is no parameter semantics to explain and the baseline of 4 applies. The description correctly spends no words on input arguments.

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 ("Lists every check BACKLNK can run") and immediately enumerates the fields returned (id, what it looks at, scope and limits), so an agent knows exactly what it gets. It also names the sibling run_checks and the relationship between the two, so it is distinguishable 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?

The sentence "Use the ids with run_checks" gives an explicit call sequence: discover here, then execute there. It gives clear usage context but no explicit exclusion or precondition (e.g., whether ids are stable across sessions or whether this must be called before every run).

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 safety (readOnly, openWorld, non-idempotent), and the description adds genuinely new behavior: an ~40 second wait bound, per-check return structure, issue ordering by importance, and that each issue carries evidence plus a recommendation. With no output schema, this return-value disclosure is the main value-add; only error/failure behavior and any quota cost are left unstated.

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, with the core action and time bound front-loaded and the return contract following. The default check list is the densest part but is load-bearing information not available elsewhere.

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 4-parameter, no-output-schema tool with read-only annotations, the description supplies latency expectations, return shape, prioritization, and the handoff to sibling tools. What is missing is marginal but real: what happens on timeout or failed checks, and whether repeated runs consume quota (relevant given a 'usage' sibling exists).

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 earns above baseline by enumerating the actual default check ids (meta-tags, page-structure, ai-crawler-access, redirects-headers, entity-schema), which the schema only alludes to as 'the quick default set'. It does not add meaning for url, mode, or fresh beyond what their schema descriptions already say.

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 ('Runs BACKLNK checks on one public URL'), names the scope constraint (single public URL), and implicitly separates itself from get_report/verify_fixes by noting it only produces audit ids for them. An agent can distinguish this from list_checks and get_report 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?

Clear context is given: this is the entry point that produces audit ids consumed by get_report and verify_fixes, and it explains the default check set when 'checks' is omitted. It lacks explicit exclusions (e.g. when to prefer verify_fixes over a re-run, or when to set fresh=true vs relying on cache), so it stops short of a full when/when-not map.

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 safety and scope are covered. The description adds meaningful context beyond that: the counters are scoped to 'this API key' and reported over two windows (today, this hour). It does not disclose return format, reset timing, or whether limits are plan-based.

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 sentence, front-loaded with the resource and the two time windows, with no padding. Minor awkwardness in the phrasing 'has used and has left' slightly hurts readability but nothing is superfluous.

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 no-parameter, no-output-schema read tool this is nearly sufficient: the description tells the agent exactly what the response conveys (used and remaining checks, per day and per hour). What is missing is whether 'left' is a hard quota and what happens at zero, which would matter for deciding to call run_checks.

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 there is no parameter meaning to add and the schema already forbids additional properties. Baseline 4 applies; the description correctly does not waste words on nonexistent inputs.

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 the resource (API key usage) and the specific quantities returned: checks used and checks remaining, for both the day and the hour. That is clear enough to separate it from siblings like list_checks and run_checks, though it lacks an explicit verb (e.g. 'Get/read') and never restates the tool's identity beyond the counters.

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: an agent can infer this is the quota-check tool to call before run_checks, but the description never says when to use it, when not to, or that it is the alternative to running a check blind. No prerequisites or quota-exhaustion behavior are mentioned.

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 annotations, the description discloses that the check is re-run fresh, that the call waits up to about 40 seconds, and that results are returned as fixed, new, still open, and not re-checked findings. This adds meaningful behavioral and output context, though it does not cover auth or rate-limit 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 description is a single front-loaded sentence that moves from deployment context to action, timing, and return categories. It contains no filler and every clause contributes useful 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?

Given the single fully documented parameter, the safety annotations, and the absence of an output schema, the description provides enough context to call the tool and interpret its main outcome categories. It could be slightly richer about the exact comparison output format, but it is largely 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?

The only parameter is audit_id, and the schema already documents it fully as the audit id returned by run_checks. The description does not add parameter-specific meaning beyond the schema, so the baseline of 3 applies with full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: re-run the same check on the same URL and options, then compare against the original run. It is clear what the tool does, but it does not explicitly name sibling tools such as run_checks or get_report to sharpen differentiation.

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 'After the fixes are deployed' gives a clear usage context for verification rather than initial checking. It does not explicitly say when not to use it or name alternatives, so it falls short of the top score.

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