pageaudit

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. The description adds only the mild behavioral note that the index is 'self-describing'; it does not say what the index contains, whether it enumerates endpoints or schemas, or how large the response is.

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 short sentence with the key fact front-loaded; nothing is wasted. It is arguably slightly under-specified rather than verbose, but structurally it is clean.

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 carries the burden of indicating what comes back. 'Self-describing index' gestures at the return shape but does not say whether it yields endpoint names, schemas, or versions — which is the main thing an agent needs to know before calling a discovery endpoint.

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 this is a baseline 4. There is nothing for the description to disambiguate, and it correctly implies a no-argument call.

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 clear verb and resource — 'Discovers the whole PageAudit API' — and the parenthetical '(self-describing index)' clarifies what is returned. It does not need to distinguish itself much from siblings like audit_url or billing, since those are obviously different operations, but it also never states that distinction.

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 phrase 'Discovers the whole... API' suggests a top-level discovery entry point, but there is no explicit when-to-use statement, no mention of it being a first-call orientation tool, and no guidance relative to siblings such as list_tools or get_tool, which could plausibly serve a similar discovery role.

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 only say readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description goes well beyond them: a firewall/rate limit returns 502 target_blocked rather than a score, exhaustion returns 402 with accepts[] and code allowance_spent, there is no captcha, and repeats are allowed after payment. That is exactly the operational detail an agent needs and none of it is in 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?

Front-loaded with the audit scope, then behavioral/payment semantics. Nearly every sentence carries actionable information, though 'This is the product for agents' and the captcha remark lean slightly promotional and could be trimmed without loss.

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?

No output schema exists, so the description must carry return semantics; it states it 'Returns evidence, limits and fixes without a tab' and fully specifies the two error paths (502 target_blocked, 402 accepts[]). It could be slightly fuller on the shape of the evidence payload, but it is sufficient to call the 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?

Schema description coverage is 100%, so the schema already documents 'url' (absolute URL) and 'guest_token' (optional pa_…). The description adds no syntax, format, or constraint detail for either parameter, so it earns only the 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?

The description gives a highly specific verb+resource ('Audits a URL') and enumerates exactly what is audited (SEO/meta, canonical, JSON-LD, robots.txt per crawler, CWV, llms.txt, security.txt, favicon). It also scopes it ('not a security/accessibility certification'). However, it never distinguishes itself from the obvious sibling get_audit (run vs. retrieve results), 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?

It gives clear when-to-use context: 'This is the product for agents', and positions the free path as 'a person signs in with an account to get the trial', plus what to do when the allowance is exhausted (pay and repeat the same call). Clear context, but no explicit statement of when to prefer a sibling such as get_audit or run_tab.

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 and the description need not restate it. It adds some useful behavior context — the 90-day no-paywall window from first use and that the `trial` field reflects state when a session exists — but the phrasing is dense and it omits whether the response differs for anonymous vs. authenticated callers beyond that one clause.

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?

It is a single sentence, which is appropriately short, but the content is front-loaded poorly: it lists nouns before establishing what the tool does, and the parenthetical about session state is tacked on. It is compact but not cleanly structured.

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 tool with no output schema, the description covers the general subject matter but leaves the agent unsure of the return shape and, more importantly, of how this tool relates to the sibling 'pricing'. Adequate but with a clear overlap 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 the schema imposes nothing to explain; per the rubric this is the baseline 4. The description references a `trial` field, but that is an output field, not an input, and no input semantics exist to clarify.

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 enumerates what the tool surfaces (free plan, prices, x402 parameters, trial offer) but never states a verb or makes clear that it returns an informational payload rather than performing an action. It reads like a concepts blurb, and it does nothing to distinguish itself from the sibling tool 'pricing', which plausibly covers the same ground.

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 guidance on when to call this versus the sibling 'pricing', nor any stated prerequisites (e.g., whether a session is needed). The only hint is the parenthetical about a session changing the `trial` field, which is incidental rather than a routing rule.

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 it discloses substantial behavioral traits: no captcha, no account, no payment required; a rate limit of one message per 10 s per network; and the exact overflow behavior (a sooner-arriving message waits its turn rather than erroring). It also explains delivery — the message reaches the team by e-mail and `email` becomes the reply address.

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?

Purpose is front-loaded, which is good, but the text repeats itself for no gain: 'Free, no captcha and no payment' is restated as 'No captcha, no account, no payment,' and the 10-second-per-network queue rule is stated twice in near-identical wording. The parenthetical insertions also make it denser than needed.

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 10-parameter, non-read-only, non-idempotent tool with full schema coverage, the description covers what matters: no auth/payment, throttling behavior, and message delivery. Since there is no output schema, it could say more about the success/error response, but the queueing note covers the main failure mode.

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 already 100%, so the baseline is 3, but the description adds real meaning: `tipo` selects the proposal route and its `espaco` placement ids come from `GET /api/partners`, and `email` is used as the reply address in the delivered e-mail. It does not, however, explain field applicability per `tipo` value beyond noting that the proposal fields turn on.

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: write a question or a sponsorship/partnership/ad proposal to the people behind the product. That is unambiguous and cannot be confused with any sibling (billing, endpoints, environments, etc.), though it never explicitly differentiates itself from a named alternative.

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 clear usage context: use it for a question or for a sponsorship/partnership/ad proposal, and states that a single route serves both cases via `tipo`. No exclusions or named alternatives are offered, but with no competing sibling there is little to disambiguate.

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 safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds meaning beyond that: the returned token is the persistent identity linking tabs to their audits, which explains why it must be retained and implies each call yields a new guest. It stops short of stating auth needs or whether repeated calls create duplicate guests.

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, zero filler, with the core action front-loaded and the retention warning immediately after. 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 tool with no output schema, the description covers what is produced (a guest token) and why it matters. It omits token lifetime/expiry and how the token is subsequently supplied to run_tab or audit_url, leaving a small 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 there is no schema semantics for the description to supplement. Per the rubric, an empty parameter set establishes a baseline of 4.

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: 'Creates a guest token pa_… for the tab workspace.' This is clearly distinct from the create_tab sibling. However, it never explicitly contrasts itself with alternatives, so it lands at 'clear but no sibling differentiation' rather than 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?

'Keep the token: it is the identity of the tabs and of the audits tied to them' gives real post-call guidance (persist the token), but the description never says when to call this versus alternatives such as create_tab, nor what prerequisites exist. Usage is implied rather than stated.

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

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

Annotations already declare it is a non-idempotent write that is not destructive. The description adds genuinely useful behavior beyond that: the 402 payment-gate response shape with `accepts[]` and the 'pay and repeat' recovery path. It does not cover auth scope beyond guest_token, but the added billing semantics are valuable.

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 core action and followed by the edge-case response. Every clause earns its place with 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 mutation tool with no output schema and no annotations covering failure modes, the description covers the main operational surprise (the 402 paywall). The remaining gap is the undocumented guest_token parameter, but overall it is sufficient to call the 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?

Schema description coverage is 67%; url and alias are documented in the schema, while guest_token is undocumented in both. The description mentions the URL concept but adds no format, alias behavior, or guest_token meaning beyond what the schema already provides.

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: 'Opens a tab for a URL in the workspace.' This clearly separates it from read/list siblings like list_tabs, tab_history, and watch_tab. It stops short of naming those siblings or contrasting behavior, but the core purpose 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?

The description implies usage (create a tab for a URL) and adds a failure condition, the 402 when past the free allowance, but never states when to choose this over run_tab or watch_tab. Usage is inferred rather than guided.

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 the description adds meaningful context beyond them: no account, no key, no lead capture, and that the snippet is returned already assembled with the site's name and colour. It omits any rate-limit or side-effect detail, so not 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?

The core point is front-loaded, but the message is redundant: 'no account, no lead capture' and 'no account or key' restate the same idea, and 'one script tag' appears twice in consecutive sentences. Tightening would lose nothing.

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 discloses what comes back ('the answer comes back with `snippet` already assembled') and confirms there are no required params. Annotations carry the safety profile, so the remaining coverage is adequate, though return shape could be slightly more explicit.

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 schema already documents url, brand, color, and theme — the baseline is 3. The description only gestures at brand ('your name') and color ('your colour') and adds no format guidance beyond the schema's 'hex' hint.

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 resource (the embeddable widget snippet) and what it produces — an assembled one-script-tag snippet — which is clear enough to distinguish from read siblings like get_audit or audit_url. It does not explicitly name a sibling it differs from, 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?

It tells the agent to 'send the same query you would send to /embed', which implies the calling context, but gives no when/when-not guidance and never references an alternative MCP tool. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds non-obvious behavior: re-reading is free and does not consume the allowance, and the page HTML is discarded while the report is retained. That is real value 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?

Two tight sentences that front-load what is returned and then the cost/no-retention caveat. The 'costs nothing and does not count against the allowance' phrasing is slightly redundant but each sentence carries 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?

With no output schema, the description does minimally describe the return payload ('fixes' per finding) and confirms the report is retained. However it leaves the required guest_token entirely unexplained, so an agent may fumble the call even though the read semantics are clear.

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 50%: `id` is documented in the schema, but `guest_token` has no description anywhere. The tool description never mentions any parameter, so it does nothing to compensate for the undocumented token.

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 ('re-reads an audit already made') and names what comes back ('fixes', the ready fix for each finding). It implies the audit must already exist, which differentiates it from the creation path, but it never names the sibling (e.g. audit_url) that produces that audit.

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

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

Usage context is implied rather than stated: 'already made' and the cost note signal this is the cheap re-fetch path once an audit ID exists, but there is no explicit when-to-use vs. when-to-create guidance or mention of a prerequisite beyond the required id.

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 covered. The description adds that the response includes both metadata and markdown of an SVG badge, which is useful context, but says nothing about format details or size/rate constraints.

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 short sentence, front-loaded with the core resource. It is terse but every word earns its place; it could be slightly more explicit about the verb.

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 some burden for describing return values, and it does so only minimally ('metadata and markdown'). For a simple single-param read tool with full annotation coverage, this is adequate but thin.

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 slug parameter is documented in the schema as a '24-char public slug'. The description adds no further parameter meaning, 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?

The description names a specific resource (metadata and markdown of the SVG badge of a shared report), so an agent knows exactly what comes back. It lacks explicit differentiation from siblings, but the sibling list (api_index, billing, run_tab, etc.) contains no overlapping badge-related tool to disambiguate against.

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 guidance on when to call this versus alternatives, nor any stated precondition beyond the required slug. The agent must infer usage entirely from the phrase 'shared report'.

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. The description adds meaningful behavioral context: the patch is generated without a model, based only on page facts, and each finding maps to a deterministic class. It does not cover auth or pagination, but the output generation behavior is well disclosed.

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 tool's purpose, then efficiently explains the three fix classes. It is dense but each sentence serves to clarify the output, and there is no redundant filler. Slightly more structure could improve readability, but it is appropriately sized.

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 no output schema, the description does a good job explaining the return content (head block, files, templates, and fix classes). However, it omits usage guidelines and leaves the required guest_token completely undocumented, so an agent cannot fully infer how to invoke the 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?

The description does not mention either input parameter. The schema documents only the 'id' parameter ('Audit ID, from Audit.id'), while 'guest_token' has no description anywhere. With 50% schema coverage and no compensating explanation, agents lack clear semantics for the required guest_token.

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 clearly states that the tool returns a consolidated patch of an audit, with a detailed breakdown of the patch structure and the three fix classes. However, it does not distinguish this tool from siblings like get_audit or audit_url, leaving the agent to infer when to use it.

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 provides no explicit guidance on when to use get_patch versus alternatives such as get_audit, audit_url, or run_tab. There are no conditions, prerequisites, or exclusions mentioned, so the agent must guess the appropriate context.

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 covered. The description adds only the idea of retrieval by slug and vaguely references 'copy and checks', without explaining what data is returned, auth requirements, or error behavior. With annotations carrying the safety burden, this is adequate but thin.

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 short sentence that is well within any reasonable size limit and front-loads the resource. The awkward 'Copy and checks' phrasing is a clarity issue more than a structural one, but the sentence remains efficient.

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 getter with annotations and no output schema, the description should still clarify what is returned. 'Copy and checks' is too vague to tell whether it returns the tool's configuration, source, or validation results, leaving a meaningful gap for an agent deciding whether to call it.

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 is already documented as 'tool slug'. The description adds an example slug format, which provides minor clarification, but the schema carries the core semantics. This matches the baseline of 3 when structured fields do the heavy lifting.

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 identifies the resource (one micro-tool) and the lookup key (by slug) with an example, but the phrase 'Copy and checks of' is grammatically unclear and does not state a clean verb. It only partially distinguishes the tool from the sibling list_tools, which enumerates many tools.

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?

No guidance is given on when to use this tool versus list_tools or other get_* siblings. The only implied usage is looking up a single tool by slug; no prerequisites, exclusions, or alternatives 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value by revealing that the response includes the commit deployed right now, which is not derivable from annotations. It stops short of describing the response fields or whether a failing check returns an error status, 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 short sentence that front-loads the core concept ('Liveness'). It is efficiently sized, though the trailing clause about the smoke test is ambiguous rather than informative, slightly reducing its value.

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 parameters and no output schema, the description carries the burden of explaining the return value, and it only gestures at it ('the commit deployed right now'). It does not describe what a healthy or unhealthy response looks like, which an agent needs to interpret the result.

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, which is the baseline-4 case. The description adds no parameter meaning, but none is needed or possible here.

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 conveys that this is a liveness endpoint that also reports the currently deployed commit — a specific resource (health/version state). However it opens without a verb and the second clause ('the smoke waits for its own deploy') is internal jargon that obscures more than it clarifies. No sibling is health-related, so differentiation is not required, but the purpose could be stated plainly in fewer words.

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 only usage hint is 'it is how the smoke waits for its own deploy', which vaguely suggests deploy-verification polling but is phrased in opaque team jargon. There is no explicit statement of when an agent should call this versus not, nor any precondition or polling 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 establish readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the polling contract, that wait is capped at 25, and that the call returns as soon as a running test finishes. It omits auth requirements for guest_token.

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 result states, which is good, but the wait/long-poll behavior is stated twice in near-identical sentences ('With wait (up to 25) it answers as soon as a running test finishes' and 'Long-poll: with `wait` the answer comes as soon as...'). The redundancy costs it a point.

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?

No output schema exists, so the description carries the return-value burden and does so by enumerating the result states and their payloads. Combined with the polling contract, an agent has enough to call it correctly; the unexplained guest_token is the only notable 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?

Schema coverage is 67% and the schema already describes id and wait's 0-25 range. The description goes further by explaining wait's actual effect (long-poll resolution semantics), which is genuine added meaning. guest_token remains undocumented in 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?

Names a specific resource (lab tests of an audit) and enumerates the possible result states (running, finished with scores/metrics/savings, failed). An agent can tell what it returns, but it never distinguishes itself from the sibling lab_test, which is the most likely confusion point.

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

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

Provides useful operational guidance ('Repeat until it is not running') and explains the long-poll pattern, which implies when to call it repeatedly. However it never states when to use this versus lab_test, nor any prerequisite like a completed audit, so routing guidance is 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?

With annotations only declaring that this is a non-read, non-destructive write, the description carries real load: asynchronous 202 semantics, expected duration (~25 s to 2+ minutes), where the result lands (summary.lab.<strategy>, surfaced in GET /api/audits/:id, the tab and shared report), that the audit score is unaffected, in-flight deduplication, and concurrency/rate limits (4 concurrent, 6/network/hour, 500/day) plus cost (free, no x402 charge).

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-loading is good, but the text is substantially duplicated: the 202 response and ~25 s–2 min duration appear twice, and 'does not change the audit score' is stated twice in near-identical wording. Nearly half the text is restatement, so several sentences do not 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 an async, rate-limited, no-output-schema tool, the description covers everything an agent needs: fire-and-forget semantics, where to retrieve results later, dedup behavior, limits and cost. Nothing material is missing and there is no output schema to compensate for.

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 67% and the description adds only indirect parameter context ('the same strategy', 'summary.lab.<strategy>'), while mobile/desktop semantics live in the schema itself. guest_token is undocumented everywhere. With most parameter meaning already in the schema, this lands at the 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 ('Starts a lab test of an audit's page') and immediately specifies the underlying engine and the four measured categories. It also names the sibling that consumes the result ('then read it with lab_result'), so an agent can distinguish it from lab_result and run_tab 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?

Gives clear sequencing guidance ('Answers 202 at once ... then read it with lab_result') and a conditional exclusion ('Calling again while the same strategy is running does not start a second test'). It does not compare against other test-running siblings like run_tab or watch_tab, so it stops short of full when-not-to-use 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond that by enumerating the payload — tabs, focused tab, last report, remaining allowance, prices — telling the agent this single call returns a full snapshot rather than a partial list.

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 core action front-loaded and the payload summary following. Every clause earns its place; there is no filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully summarizes what is returned, which is a strength. But it omits any auth/permission expectations for guest_token and offers no guidance on refresh or failure behavior, leaving gaps for a required-token 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?

The single required parameter guest_token has 0% schema description coverage, so the description must compensate, and it does not define or explain the token. The parenthetical "(guest or session)" only indirectly gestures at the guest/session distinction without clarifying the parameter's role.

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 the owner's tabs") and scopes it to guest or session context, so it is clearly distinct from siblings like create_tab, run_tab, and tab_history. It stops short of explicitly naming an alternative, but the verb+resource is unambiguous.

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

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

Usage is only implied: "One call draws the whole screen" hints that this is the broad fetch-everything call, which helps an agent choose it over narrower tools. However, no when-to-use/when-not conditions or alternative tool names 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=true, idempotentHint=true, and destructiveHint=false, so the safety and repeatability profile is fully covered elsewhere. The description adds the shape of what is listed (title, meta, canonical, OG, JSON-LD) but says nothing about ordering, pagination, or whether it returns names or full definitions.

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 short sentence with the verb front-loaded and the scope detail in a parenthetical. Nothing is padded or 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?

With no parameters and no output schema, the description carries the burden of telling the agent what comes back, and it only partially does so by naming the fields of a micro-tool rather than describing the list itself (count, ordering, identifiers). It is adequate for a trivial zero-arg read, but leaves the return shape undefined.

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 schema has zero parameters and 100% coverage, which sets the baseline at 4; there is no parameter to mis-describe. The description neither helps nor hinders here, as no input semantics exist to explain.

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 clear verb (Lists) and a resource (the micro-tools), and the parenthetical enumerates what those tools' content covers (title, meta, canonical, OG, JSON-LD), which orients the agent toward SEO/meta tooling. It does not, however, distinguish itself from siblings such as api_index or get_tool, so an agent still has to infer which listing tool it wants.

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 when-to-use guidance and no mention of alternatives, even though sibling names like api_index, get_tool, and list_tabs clearly overlap in the 'enumerate things' space. Nothing tells the agent when this catalogue-style listing is preferable to fetching a single tool via get_tool.

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?

The annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description starts from a lower bar. It does add one genuine behavioral fact not in the annotations — that the endpoint is free to call ('no charge') — but says nothing about freshness, caching, or the shape of the pricing data returned.

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 short sentence with no filler; the content claim is front-loaded and immediately followed by the cost reassurance. 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, read-only lookup with no output schema, the description adequately states what is returned (public prices and free allowances) and that the call is free. Only the return format or freshness of the pricing data is left unspecified, which is a minor gap at this complexity.

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 is 4 and there is nothing for the description to clarify. It appropriately does not invent parameter 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?

The description names the specific resource it exposes: current public prices and free allowances. It is clear what an agent gets back, though the phrasing is a label rather than a verb+resource statement, and it does not explicitly distinguish itself from sibling tools like billing or api_usage that could also look price-related.

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 explicit when-to-use guidance and no naming of alternatives (billing, api_access_buy, api_usage). 'No charge' is the only usage-relevant hint, signaling the call itself is free, but which tool to consult for actual account costs versus public list prices 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 flag this as non-read-only and non-idempotent, but the description adds genuinely new behavioral context: it shares the daily allowance with POST /api/audit and returns 402 with accepts[] when the quota is exceeded. These quota/error-code details are not derivable from the annotations or 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?

Two compact sentences with zero filler, and the core action is front-loaded before the quota caveat. Every clause 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 two-param re-audit tool with no output schema, the description covers the key operational risk (quota consumption and the 402 failure mode). It leaves the guest_token credential unexplained and doesn't say what a successful call yields, though no output schema obligates it to.

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%: the schema documents id as the tab to re-audit, but guest_token has no description anywhere. The description adds nothing about either parameter and does not compensate for the undocumented guest_token.

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?

"Re-audits the tab's URL" gives a specific verb (re-audit) plus resource (the tab's stored URL), so an agent can tell this apart from a fresh audit. It stops short of explicitly contrasting with the audit_url sibling, which shares the same conceptual space.

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: you call this on an existing tab (id required) to refresh its audit rather than creating a new audit. There is no explicit when-to-use versus audit_url, get_audit, or tab_history, and no stated prerequisite beyond owning a tab id.

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 still adds real behavior: full retention of every run, diffing by finding code rather than message, and URL-based matching for runs that predate the watch feature. It omits auth expectations and pagination behavior across the limit window, keeping 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?

Front-loaded with the resource and its meaning, then layers in the change semantics. Dense but every clause carries information; the parenthetical field list is mildly heavy but not 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?

With no output schema, the description carries the return-value burden and does so: score, counts, and a `change` object with point delta plus `broke`/`fixed` findings. What is missing is a note on the guest_token credential and how limit affects the returned series.

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 67% (guest_token is undocumented), and the description never mentions id, limit or guest_token directly. It only implicitly frames "the tab" that id must reference. Baseline 3 is appropriate for mid-level coverage where the schema does most of 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?

States a concrete verb and resource: reading a tab's previous runs and the diff between consecutive runs. The described payload (score, counts, appeared/disappeared findings) is specific enough that an agent can distinguish it from list_tabs, run_tab, watch_tab and get_audit 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?

"this is where you read the series" points at when to use it, and "Every run has always been kept" implies historical coverage. However there is no explicit contrast with siblings (run_tab to produce a run, watch_tab for ongoing, get_audit for a single audit), so the routing guidance stays implied rather than stated.

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

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

Annotations only carry readOnly=false, destructive=true, idempotent=false; the description goes further by disclosing the auth failure mode (403 account_required), the alert-only-on-regression behavior ('never on an improvement'), and a per-account page quota. It still doesn't explain the destructiveness implied by turning the watch off or confirm idempotency of repeated 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?

The core effect ('re-audited once a day and an e-mail when the score drops or a new error/warning appears') is stated twice, once in sentence one and again in the monitor:true sentence, and the account requirement is likewise restated. The duplication wastes space in an otherwise front-loaded description.

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 mutation tool with no output schema, the description covers the essentials: what changes, the auth requirement and its failure code, alert semantics, and a quota limit. It is nearly complete, missing only the reversibility/effect of disabling the watch.

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 all four parameters are already documented in the schema. The description adds context for monitor ('never on an improvement') but says nothing extra about monitor_email or id, 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 and resource: turning the daily watch on or off for a tab, with the concrete effect (re-audit once a day and e-mail on score drop/new error). This is clearly distinguishable from siblings like run_tab, list_tabs, and audit_url.

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 conditions for use: the signed-in account is required and a guest token yields 403 account_required. It does not explicitly route between sibling tools, but the toggle semantics and account prerequisite are unambiguous.

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