Bastion Helix Agent Lens

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

Beyond the annotations (readOnly/openWorld/non-destructive), the description discloses that rendering is used as a fallback when HTML has no elements, that billing occurs only on success, and the exact price and payment paths. Missing only access/prerequisite or rate-limit details, so it earns a 4 rather than 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 return payload before moving to fallback behavior and pricing; four sentences with essentially no filler. The pricing sentence is dense but genuinely relevant to a paid, per-call API.

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 the work of describing return values thoroughly. However, for a 3-parameter tool with 0% schema coverage, it leaves the engine selection entirely unexplained, which is a material gap for an agent choosing between fetch and chromium-style rendering.

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 description adds no parameter semantics: url, user_agent, and especially the engine enum (auto/fetch/kitesurf/chromium) are never explained. 'Uses the rendered page when the HTML alone has none' gestures at engine behavior but never ties it to the parameter or its values, leaving the most consequential input 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 names a concrete verb and resource ('Returns the forms... buttons and links on a page') and enumerates the returned contents (fields, labels, required flags, CSS selectors), so an agent knows exactly what comes back. It does not explicitly differentiate itself from siblings like extract, read, or screenshot, which keeps it below 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?

'each with a CSS selector an automation tool can use' implies the intended use case (browser automation), and the rendered-page note implies when the tool is necessary. But there is no explicit when-to-use/when-not clause and no mention of when extract, read, or screenshot would be preferable.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond that: the call is free and the credential source is the Authorization header. It does not say what happens with a missing/invalid key or what form the response takes.

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 waste, with the key fact (free credit balance) and its unit front-loaded. Nothing is padded or repeated.

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

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

For a zero-parameter read tool, this covers the essentials, and the unit conversion helps interpret the result even absent an output schema. A note on the return shape (e.g., a numeric balance) or failure behavior for an invalid key would make it fully 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?

Zero parameters, so semantics carry no burden and the baseline is 4. The description adds value by explaining that the implicit input is the Authorization header credential.

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 makes clear this returns the remaining credit balance tied to the API key in the Authorization header, plus the unit conversion (1 credit = US$0.001). No explicit verb is used and it partly restates the title, but the resource and scope are unambiguous. The sibling tools (read, extract, screenshot, delta, site, actions, preflight) operate on entirely different resources, so no sibling disambiguation is needed.

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?

'Free.' signals that calling it costs nothing, which implicitly encourages calling it before metered operations. However, it never states when to use this versus a preflight-style check, nor any preconditions (e.g., valid key required). Usage is only implied, not 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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses how caching is decided (HTTP ETag/Last-Modified), that no state is stored server-side and the fingerprint lives with the agent, and the billing model (charged only on success, US$0.001 per call, API key credits or x402). These are exactly the operational facts the agent needs and that the annotations do not provide.

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

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

Well front-loaded: the use case comes first, then the mechanics, then the billing note. It is efficient overall, though 'Saves tokens on every re-check' restates the opening premise and reads as light marketing.

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 still documents the return shape — sections plus fingerprint on the first call, changed sections and removed headings on subsequent calls, or changed:false. Combined with the annotation coverage of the read-only profile and the explicit billing terms, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25%, so the description must compensate. It fully explains 'previous' semantics — send back the fingerprint from the prior call, omit on first call, and what comes back (changed sections, removed headings, changed:false). The 'engine' enum values and 'user_agent' are left completely unexplained in both schema and description, which keeps this from a 5.

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 concretely explains the two-call delta workflow: the first call returns sections plus a fingerprint, and re-calls return only changed sections. This goes well beyond the name 'delta' and makes the resource and operation unambiguous. It doesn't name the sibling tool (e.g. 'read') as the one-off alternative, so the differentiation is implied rather than stated.

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?

'For pages an agent checks again and again' clearly signals the usage context on the first call and implies that one-off fetches belong elsewhere. What's missing is an explicit exclusion or named alternative such as the 'read' sibling for single fetches.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: no AI inference is involved, values are authoritative rather than inferred, and billing is success-only at US$0.002 per call, which matters for an agent deciding whether to call it repeatedly. Failure modes and engine fallback behavior are still 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?

The opening sentence delivers the core differentiator first, followed by a dense but scannable payload list. The pricing sentence at the end earns its place for cost-aware agents, though the payload enumeration is long enough to slightly dilute front-loading.

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

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

With no output schema, the description must convey return values, and it does so thoroughly via the payload enumeration. Pricing and success-only charging cover the commercial caveat. The remaining gap is operational: nothing explains the engine choice or what happens on failure/blocked pages.

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 full burden, yet it says nothing about any of the three parameters. The `engine` enum (auto/fetch/kitesurf/chromium) is entirely unexplained — an agent cannot know when to force `chromium` versus `fetch`, and `user_agent` is never mentioned at all.

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 operation and then enumerates the exact resources returned: JSON-LD/schema.org objects, prices and offers, meta/Open Graph tags, canonical URL, language versions, licence, feeds, and HTML data tables. That enumeration ('exact values instead of guesses from text') implicitly separates it from the plain-text sibling `read`, so an agent can tell what this tool returns 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?

'Exact values instead of guesses from text' plus 'No AI model involved' clearly signals the context: use this when you need machine-readable facts rather than prose extraction. It does not name an alternative sibling (e.g. `read`, `preflight`, `actions`) or an explicit when-not, so it falls short of a 5.

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

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

Annotations already declare readOnly, openWorld, and non-destructive, so the safety profile is covered; the description adds cost ("Free"), a rate limit ("Rate-limited per IP"), and the fact that the check covers both this service's and the caller's own bot rules. It does not describe the response shape or what happens when robots.txt is unreachable.

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 cost and timing cue are front-loaded in two short clauses, then the checks are listed compactly. The middle sentence is long and clause-dense (three engines, three rule sources), but every element carries information the caller 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?

With no output schema, the description does the work of telling the agent roughly what comes back — an allowed/blocked verdict plus a recommended engine — which is the key decision information. Some detail on the response structure or failure modes is missing but not essential for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented in structured form. The description restates that user_agent triggers a check of your own bot's rules, which reinforces but does not meaningfully extend the schema, so the baseline 3 applies.

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

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

States a specific verb (check) and resource (a page/URL) and enumerates exactly what is being checked: robots.txt rules, Content Signals, meta robots, bot checks/sign-in, and required rendering engine. This is clearly distinguishable from siblings like read, extract, or screenshot, which consume the page rather than vet 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?

"Before an agent spends money or time on a URL" gives a concrete trigger condition, and the engine-selection clause (plain fetch vs Kitesurf vs Chromium) tells the agent how to act on the result. It stops short of naming sibling tools as alternatives or stating when this check can be skipped.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses the fetch → Kitesurf → Chromium escalation ladder, that the chosen engine is reported back, that requests are refused free of charge on robots.txt or bot-check, and the exact $0.004 success-only price. These are the operational facts an agent needs before committing a paid call.

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 return value, then engine strategy, then refusal rules, then cost — a sensible order. Four dense sentences, each doing work; only the price clause is mildly redundant with 'charged only on success'.

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, yet the description specifies the return format (Markdown, absolute links) and which engine succeeded. It is missing truncation behavior for max_chars and any mention of error shapes, but for a single-URL fetch with annotations covering safety, coverage is good.

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 four parameters, so the schema carries no semantics. The description explains the escalation behavior that underlies the 'engine' enum ('auto' means try cheapest first), which is genuinely useful, but says nothing about max_chars truncation or user_agent overrides.

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 outcome: returns the main content of a web page as clean Markdown with absolute links. That is clearly distinct from screenshot (image capture) or extract (structured data) among the siblings, though no sibling is named 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?

It describes conditions under which the tool refuses (robots.txt, Content Signals, bot check) and that billing only applies on success, which implicitly frames when it is appropriate. But it never names an alternative like extract, preflight, or screenshot, nor says when to prefer them.

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 destructiveHint=false, and the description adds genuinely new behavioral context: billing occurs only on success, the exact price is US$0.008 per call, and payment can come from API key credits or x402. It does not disclose how the image is returned (binary, URL, expiry) or any timeout/rate limits.

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 tight sentences with the output format and default size front-loaded, followed by engine logic and pricing. The only minor redundancy is stating both "charged only on success" and a per-successful-call price, but the density of information per sentence is high.

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 tool with no output schema, the description covers cost and engine selection but leaves the return shape unspecified (image bytes vs. hosted URL, dimensions when full_page is set, failure behavior). It is adequate to invoke, not quite adequate to reason about 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?

Schema coverage is 0%, so the description must carry parameter meaning, and it does explain the non-obvious 'auto' enum behavior (Kitesurf by default, Chromium when video or WebGL is needed) and implies full_page via "or the full page". However, url and user_agent receive no explanation and no viewport override or format hints are offered, leaving half the parameters to inference.

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 opens with a concrete verb and resource ("PNG screenshot of a page") plus the default resolution, which is enough to distinguish it from text-oriented siblings like extract and read. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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 that you call this when you need a visual rendering rather than extracted text, but there is no explicit when-to-use/when-not or pointer to extract/read as alternatives. The engine selection guidance is parameter-level rather than tool-level 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/openWorld/non-destructive), yet the description adds genuinely new context: the tool is free, it is rate-limited per IP (and therefore may fail under repeated calls), and its return surface is an inspection of the site's own published metadata. These are traits the annotations do not supply.

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 pieces — the cost, one dense content sentence with a colon-led enumeration, and the rate-limit caveat — with zero filler. The most decision-relevant facts (free, rate-limited) sit at the edges where they are easy to scan.

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, no-output-schema read tool, the description covers cost, limits, and the shape of what comes back, which is exactly what is needed given no output schema exists. It stops just short of saying what happens for sites with no llms.txt or sitemap, which would have closed the last 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 100%, so both parameters are already documented — baseline 3 applies. The description does add a small amount of meaning by implying the robots.txt crawler check is scoped to the caller's own bot, which connects loosely to the user_agent param, but it never explicitly maps that param to that behaviour.

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 concretely what the card contains (llms.txt/llms-full.txt, sitemap with page count, feeds, language versions, Content Signals, robots.txt crawler allowances), so the resource is unambiguous even though the tool name 'site' is generic. It does not, however, differentiate itself from siblings like preflight or extract, which an agent could plausibly confuse it with.

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?

"Everything an agent should know about a website before using it" implies a reconnaissance/pre-flight use case and the timing (before acting on the site). But it never states when NOT to use it, nor names an alternative sibling (e.g. preflight, extract) for cases where a full site card is overkill.

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