HubVibe: Pay-per-Call Agent Tools: Web Search, Email Verify, KYC Screening, Stocks, Crypto, News

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-structured context: billing only occurs if all parts run ('if any part cannot run, nothing is billed') and the flat $0.15 price, which the schema cannot express.

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

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

Four tight sentences: scope, cost/routing, alternative, return shape. Front-loaded with the bundle contents and no filler; the pricing and fallback rule are each given exactly one clause.

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

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

With an output schema present, the description needn't explain returns, yet it still summarizes the pass plus four sub-result buckets. Combined with annotations, pricing, routing guidance and param docs, an agent has everything needed to select and invoke 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 description coverage is 100%, including the BCP-47 language semantics and rule-id/severity exceptions, so the schema carries the parameter burden. The description adds nothing beyond 'one URL', 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 (audit) and resource (a live URL) and enumerates exactly what is bundled: WCAG 2.1 A/AA, on-page SEO, HTTP security headers, page speed/weight. It is immediately distinguishable from the four single-audit siblings by naming the aggregate scope.

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 an explicit routing rule — 'Use a single audit route when you need only one of the four' — which names the alternative family and the condition that selects it. It also surfaces the cost trade-off ($0.15/call, cheaper than four calls) that drives the bundle-vs-single decision.

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/openWorld/non-destructive, so safety is covered. The description adds real context beyond them: cost ($0.05 per call), the measured-not-estimated behavior, findings emitted only when the page is heavy, and the return shape.

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?

Very dense and front-loaded: scope, metrics, exclusion, pricing, and return shape in a few clauses. Slightly run-on due to comma stacking, costing a little readability.

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 an output schema already exists, repeating the return fields is mildly redundant, but the description supplies the pricing, the measurement basis, and the non-CWV scope that structured fields do not convey. Adequate for a 2-param read-only audit.

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 both parameters (url, language) are already fully documented in the schema. The description adds no syntax or format detail about them, so the baseline of 3 is correct.

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

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

States a specific verb+resource (page speed and page weight audit of a web page) and enumerates the measured metrics (total bytes, HTTP request count, DOM node count). It clearly distinguishes itself from the sibling audit_bundle/audit_seo/audit_wcag family by scoping to page-weight signals.

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

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

Explicitly tells the agent this covers page-weight signals, not Core Web Vitals, and that it works from one real browser load (measured, not estimated). That is a clear when-to-use/when-not signal, though it never names a sibling alternative for the excluded case.

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 traits (readOnly, openWorld, idempotent, non-destructive), but the description adds valuable context not in the annotations: $0.05 per call, findings with severity, and that the audit is based on the real HTTP response. It also clarifies the limitation to header posture only, which is important behavioral scoping.

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 core purpose and stays compact at roughly 60 words. The final returns sentence partly duplicates the output schema, but the cost and limitation details justify most of the text.

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 rich annotations, full schema coverage, and an output schema, the description only needs to carry the non-schema context. It does that well by covering cost, scope, findings severity, and the non-penetration-test boundary, though it could more explicitly route against the other audit_* siblings.

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 url and language parameters are already fully documented in the schema. The description reinforces "any live URL" but adds no syntax, format, or language-handling detail beyond what the schema provides, making the baseline score appropriate.

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 and resource: security headers check for a website, naming HTTPS, HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and CORS. It bounds the scope to headers from a real HTTP response of a live URL and explicitly distinguishes itself from a penetration test, so an agent can tell it apart from sibling audit 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?

It gives clear context for when to use the tool: checking header posture from a live HTTP response. It also supplies a when-not boundary ("not a penetration test"), but it does not name sibling alternatives such as audit_seo or audit_wcag, so it stops short of explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior: pricing at $0.05 per call and the rule-by-rule finding model with severity ('what is missing or malformed'). That is real added context beyond the annotations.

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

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

Front-loaded with the core purpose, then the checked elements, then severity and return shape; the '$0.05 per call' cost is surfaced early. Slightly fragment-heavy but 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 read-only audit tool with a full output schema and complete parameter descriptions, the definition covers scope, input modes, cost, and finding format. The only gap is routing guidance relative to the other audit_* tools, which is minor given the distinct on-page-SEO scope.

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, html, and language. The description's 'live URL or raw HTML' mirrors the schema's anyOf but adds no syntax, format, or mutual-exclusion detail beyond it, so 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+resource ('SEO audit of a web page') and enumerates the exact rule domains checked: title tag, meta description, H1 structure, canonical, OpenGraph, JSON-LD, html lang. The phrase 'on-page SEO check' cleanly separates it from audit_performance, audit_security, and audit_wcag without needing to name them.

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 communicates accepted inputs ('any live URL or raw HTML') and implies usage context for a page-level SEO check, but gives no explicit when-to-use-vs-alternative guidance — e.g. when to reach for audit_bundle instead, or whether raw HTML is preferred over fetching. Usage is implied rather than directed.

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 already covering read-only/idempotent/open-world safety, the description adds real behavioral detail: deterministic rules, failure returns an error rather than a false pass, $0.05 per call, and the exact shape of violations. This is context annotations cannot express.

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

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

Front-loaded with purpose, then engine, semantics, pricing and return shape in a tight block with no filler. The trailing 'Returns:' clause mildly duplicates the output schema.

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

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

For a 3-param read-only audit tool with a full output schema and complete annotations, nothing material is missing; the description even anticipates misuse by warning that unrunnable checks error out rather than pass.

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 url, html and language are already fully documented, including the BCP-47 tag behavior. The description only restates 'live URL or raw HTML' and adds no syntax or format detail beyond the schema, so 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+resource (website accessibility audit, WCAG 2.1 A/AA conformance), names the engine (axe-core in a headless browser), and covers both input modes. It is clearly separable from audit_performance, audit_security, audit_seo and audit_bundle.

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?

Explains the two usage contexts (any live URL or raw HTML) and the cost per call, so an agent knows when it applies. It does not, however, name a sibling alternative or an explicit when-not condition.

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, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lowered. The description adds real behavior beyond that: a 4-step ceiling, a price ($2.75 per call), and non-obvious billing semantics ("Charged only when the answer is delivered"). These are genuinely valuable, though the enumerated return fields repeat the 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?

Purpose and scope are front-loaded, and the prose is scannable. It loses a point because the long "Returns: task, tier, headline..." enumeration is pure duplication of the output schema, which already exists, and the mid-sentence capability list is somewhat listy.

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

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

With an output schema present, the return-value list is optional rather than required, and the description still covers cost, billing trigger, step cap, and inputs. What is missing is escalation guidance against the sibling tiers, which matters because those siblings are named _pro and _max.

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 fully documents task, context, fields, and language. The description only restates them ("Input: task; optional context, fields for a JSON answer, language") without adding format, constraint, or interaction semantics. Baseline 3 is appropriate when the schema carries the load.

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 (hand it a task, get a finished result) plus an explicit scope marker, "HubVibe Agent (quick)", and a hard cap, "Up to 4 steps". That scope marker is exactly what separates it from the sibling tiers hubvibe_agent_task_pro and hubvibe_agent_task_max.

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 usage context with concrete example task types (research a company, screen a name, read the markets, compare options) and an implicit boundary via "Up to 4 steps". However, it never names the alternative tiers (hubvibe_agent_task_pro / hubvibe_agent_task_max) or states when to escalate to them, which is the obvious exclusion to declare given the sibling names.

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/openWorld, but the description adds substantial context those fields cannot: the billing model ('Charged only when the answer is delivered'), the exact cost ($20.00 per call), the 20-step budget, and the full response shape including per-step tool traces and sources. This is exactly the behavioral detail an agent needs to judge cost and trust before invoking.

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 dense paragraph that leads with the core promise, then examples, step cap, billing, inputs, and return shape. It is information-rich and nothing is gratuitous, though the trailing 'Returns:' enumeration is long and slightly crowds the routing information an agent most needs up front.

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 a full output schema present, the description needn't enumerate return fields yet does so helpfully, and it covers cost, step budget, and inputs. The only real gap is tier selection among the three agent_task variants, which is the one thing an agent cannot derive from structured data.

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% and all four parameters are already documented in the schema. The description restates them ('task; optional context, fields for a JSON answer, language') but adds no format, default, or constraint detail beyond what the schema provides, so the baseline of 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 concrete verb and resource ('hand it any task in plain words and get the finished result in one call') and enumerates the task families it handles (research, website check, screening, markets, comparison, fact-pulling). The title 'the hardest tasks' plus the 20-step cap and $20 price distinguish it from the sibling hubvibe_agent_task and hubvibe_agent_task_pro tiers.

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 the tier through 'the hardest tasks', the 20-step ceiling, and the $20 price, but never explicitly states when to choose this over hubvibe_agent_task_pro or hubvibe_agent_task. There are no exclusions or routing rules, even though three near-identical siblings exist, leaving the agent to infer the escalation condition.

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 annotations by disclosing cost ($9.00 per call), the billing condition ("Charged only when the answer is delivered"), and the effort ceiling (up to 10 steps) - none of which are in structured fields. Note a mild tension: charging per call sits awkwardly with idempotentHint=true, though this is not a hard contradiction of the read-only/destructive safety profile.

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

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

Front-loads the core promise, then examples, then inputs, then price and returns - a sensible order. It is dense and the trailing return-value list partially duplicates the output schema, but every sentence carries usable information with little 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?

Covers inputs, cost, step limit, and delivery guarantee, and an output schema already exists so the return values need not be explained. Nothing an agent needs to call this correctly is missing other than sibling tiering, which is a differentiation gap rather than a completeness one.

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 four parameters are already documented in the schema. The description only restates inputs ("task; optional context, fields for a JSON answer, language") and adds light interpretation of `fields`, which does not exceed the schema's own descriptions.

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

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

States a specific outcome ("hand it any task in plain words and get the finished result in one call") and a concrete scope boundary ("Up to 10 steps"). It never names or contrasts the sibling tools hubvibe_agent_task and hubvibe_agent_task_max, so the agent must infer the tier from step count alone rather than from an explicit 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?

The example task list (research a company/person, check a website, screen a name, read markets) implies the intended domain of use, but there is no explicit when-to-use, no when-not-to-use, and no pointer to the simpler agent_task or deeper agent_task_max siblings. Usage is inferable but routes are left to the agent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable non-annotation context: live mainnet sourcing, the $0.05 per-call cost signal, and the concrete return fields. It doesn't mention latency or failure modes, so not a full 5.

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

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

Dense but front-loaded: purpose, use case, input, alternative, price, and returns in order. The trailing returns list is arguably redundant given the output schema, but the sentences otherwise 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?

An output schema exists, yet the description still names the key return fields, and it covers input, pricing, and the routing alternative. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description restates the address format ('address (0x...)') but adds nothing on the optional language param. Baseline 3 is appropriate when the schema does 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?

States a specific verb+resource ('Base wallet lookup / address balance') and enumerates exactly what is returned (ETH balance, nonce, contract-vs-EOA). It also names the sibling it is not ('chain.rpc'), so an agent can distinguish it without opening the schema.

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

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

Gives an explicit use case ('check a counterparty, deposit address or contract before paying it') and an explicit alternative with its selection condition ('For token balances or any other read use chain.rpc'). When/when-not/alternative are all present.

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 read-only, idempotent, open-world, non-destructive semantics, and the description adds pricing ($0.02), keyless access, and that data is live from a mainnet node. These are useful operational facts beyond 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-loads the core resource and status, then usage, then pricing and return fields. Efficient and well-ordered, though the trailing return-field list is somewhat redundant given an output schema exists.

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 rich annotations and an output schema, the definition covers what an agent needs: no required input, cost, data source, and use cases. The redundant return-value listing is minor and nothing essential is missing.

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

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

Schema coverage is 100%, so the optional BCP-47 language parameter is fully documented in the schema. The description adds no meaning about the parameter and even says 'No input needed', which is baseline-adequate but does not enrich semantics.

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

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

The description names a specific resource and scope: Base mainnet network status with block height and gas price, pulled live from an RPC node. This clearly separates it from chain_address, chain_transaction, and the generic chain_rpc, though it never names an alternative to sharpen the boundary.

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

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

It gives concrete when-to-use guidance: check Base is moving, time an on-chain action, or estimate gas before sending a transaction. No explicit when-not or named alternative is offered, so it stops short of the top mark.

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 read-only, idempotent, non-destructive, and open-world behavior, so the bar is lower. The description adds genuinely non-structured facts: a $0.05 per-call price, no API key required, allowlisted-methods-only scope, and that revert reasons are surfaced as the call result rather than swallowed. It omits rate limits and what happens when a non-allowlisted method is requested.

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 tool's identity and payment model, then method list, then behavior, then input/output summary — a sensible ordering. It is dense and the parenthetical method enumeration is slightly list-heavy, but no sentence is wasted.

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

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

With a 100%-covered schema, rich annotations, and an output schema, the remaining burden is small, and the description supplies cost, auth, error semantics, and a return shape summary. Only the language parameter and allowlist-failure behavior go unexplained, which are minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents method, params, and the BCP-47 language tag; a 3 is the baseline here. The description confirms 'Input: method; optional params' and gives method examples, but adds nothing on the language parameter or the positional-params convention beyond the schema.

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

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

The description states a specific verb and resource ('Base RPC endpoint... any allowlisted read-only JSON-RPC method on Base mainnet') and enumerates concrete methods (eth_call, eth_getBalance, eth_getLogs). It is clearly distinguishable from the higher-level siblings hubvibe_chain_address, hubvibe_chain_transaction, and hubvibe_chain_network, which presumably wrap specific calls.

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 conveys the operating context (pay-per-call, read-only, no API key, bring your own params), which implies when to reach for it, but it never names an alternative or states a when-not condition. An agent must infer that this is the escape hatch when no dedicated chain helper covers the desired call.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. Description adds real context: it is live from Base mainnet (open-world reality), folds the receipt in (a behavioral decision beyond raw RPC), and discloses the $0.05 per call cost, which annotations never state. Does not mention rate limits or caching, keeping it out of 5.

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

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

Front-loaded with purpose, then usage, then input, then pricing, then a return-field list. Every sentence earns its place except the redundant input restatement. Tight and scannable overall.

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

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

With an output schema present, listing return fields in the description is arguably redundant, but the cost disclosure and mainnet-liveness note are genuinely necessary context an agent can't get from structured fields. Minor gap: it never mentions the language parameter, though the schema covers 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%, so the schema fully documents both hash and language. The description restates the hash parameter ('0x transaction hash') which the schema already carries, and omits the language parameter entirely. Baseline 3 is correct when the schema does the heavy lifting and the description adds only repetition.

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 with full scope: 'Base transaction lookup by hash', then enumerates exactly what fields come back (sender, recipient, ETH value, block, status, gas used, log count). An agent can distinguish this from chain_address, chain_rpc, and chain_network 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?

Names the condition and the alternative explicitly: 'Use it to confirm a payment or transfer landed on-chain. For the raw receipt use chain.rpc.' This is a clean when-to-use plus named escape hatch to a sibling.

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, idempotent, non-destructive, openWorld). The description adds behavior annotations don't: execution happens remotely in Google's sandbox rather than on the service's machines, and there is a per-call cost of $0.25. These are meaningful additions, though it says nothing about timeouts or size 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?

Front-loaded with the core action, then usage, input, cost and return shape in a compact block. It is slightly redundant in restating the return fields ('code, output, outcome, summary, model') that the output schema already provides, but nothing is wasted overall.

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

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

With an output schema present, the return-value detail is optional, yet the description still surfaces cost, environment and a routing alternative. It is largely complete for an execute-code tool; only timeout/limit information is missing.

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

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

Schema description coverage is 50%: the 'language' parameter is richly documented in the schema, while 'code' is undocumented but self-evident. The description only says 'Input: code' and never mentions the language parameter, so it neither compensates for the gap nor adds meaning beyond the schema. Baseline 3 is appropriate.

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 ('Run Python code in a sandbox') and clarifies the execution environment ('Google's hosted sandbox'). It routes overflow clearly by naming the sibling alternative for BigQuery questions (data.query), so an agent can distinguish it from data tools 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?

Explicitly scopes usage ('calculations, data transforms and checks an agent should not do in its head') and gives one named alternative for a specific case ('Questions over BigQuery data: data.query'). It has no blanket when-not-to-use rule, but the routing guidance is concrete and actionable.

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/idempotent/non-destructive, so the safety profile is covered. The description goes beyond them with genuinely useful operational facts: the $0.50 per-call cost, the extraction sources ('schema.org, Open Graph, Shopify JSON; a browser only when needed'), and the freshness signal (a checked_at stamp plus evidence). It does not mention latency, failure modes, or rate limits, so it is 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 purpose and cost are front-loaded and each clause carries content, but the trailing 'Returns: available, availability, price, currency, options[], matched_option, quantity_ok, ship_to_ok, shipping, eligibility_notes[], evidence[], source, confidence, checked_at' enumerates output fields that are already defined by the tool's output schema. That enumeration is wasted tokens in a single dense paragraph.

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

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

An output schema exists, so the description does not owe the agent a return-value contract, and annotations plus a 100%-covered schema carry the parameter detail. The description supplies the remaining essentials (sources read, browser fallback, per-call cost, freshness stamp), which is sufficient for a read-only, single-URL query. Missing only explicit sibling routing.

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 baseline is 3 and the schema already carries the syntax (ISO alpha-2 for ship_to, BCP-47 for language). The description adds some meaning for variant ('which option matches the variant you name') but its input summary omits the language parameter entirely, so it does not fully compensate or exceed the schema.

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

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

The opening clause states a specific verb and resource ('Product availability and price check: is it in stock and buyable right now') and enumerates the facets (price, options, variant match, ship-to). It is clearly not a shipping-quote tool and not a generic page fetcher, so an agent can place it. It stops short of naming the confused siblings (hubvibe_commerce_shipping, hubvibe_extract_page, hubvibe_fetch_raw), so it earns a 4 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?

Usage is implied by the framing ('can this be bought or booked right now') and by the mention of reading product/booking pages, so an agent can infer the trigger. There is no explicit when-not, no prerequisite statement, and no comparison against the overlapping siblings (commerce_shipping, extract_page). Minimum-viable guidance only.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is well covered. The description adds genuinely new behavioral context beyond them: the tool opens a real cart session, quotes from the live store, places no order, and costs $0.50 per call. The cost and side-effect disclosure are valuable and not derivable from annotations.

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

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

Front-loaded with the core purpose and the key behavioral facts (real cart, no order, price), which is strong. However, the trailing 'Returns: ...' enumeration essentially duplicates the existing output schema and adds length without new 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 nested-object, open-world commerce tool, the definition covers mechanism, cost, side effects, required inputs and result shape. Since an output schema exists, the return-field list is redundant rather than necessary, but nothing an agent needs to invoke the tool correctly is missing.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description restates the input shape (url, ship_to{country, province, postal_code}, optional variant, quantity) without adding format or semantic detail beyond the schema, and omits the language parameter, so it neither compensates nor underperforms. Baseline 3 is appropriate.

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 ('Shipping cost and delivery check for any Shopify store') and clarifies the mechanism ('a real cart session and the store quotes its shipping options'). It is clearly distinguishable from sibling hubvibe_commerce_availability, which handles availability rather than shipping/eligibility.

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 context by describing the cart-session mechanism and noting 'No order is placed', but it never states when to use this tool versus alternatives, nor any prerequisites or exclusions. A single routing sentence would have lifted this score.

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 openWorld, so the safety profile is covered. The description adds valuable behavioral context beyond that: a per-call cost ($0.05), the external data sources used, and the fact that every field names its source. It does not cover failure modes or authentication, but the additions are meaningful.

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 purpose and data fields, which is good, but the lengthy 'Returns:' block duplicates the output schema, which already exists. That redundancy is unnecessary and reduces overall conciseness, though the structure remains logical.

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 tool's complexity, the description provides a thorough overview of inputs, outputs, sources, cost, and field-level provenance. An output schema exists, but the description still usefully summarizes the return structure. It is nearly complete for calling the tool correctly, though sibling differentiation would strengthen it further.

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 fully documents name, domain, and language. The description only repeats 'Input: domain or name' without adding format, constraints, or alternatives beyond what the schema provides. Baseline 3 is appropriate.

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 (enrichment) and resource (company firmographics), and enumerates exactly what data is returned (legal name, headcount, LEI, SEC CIK, socials, etc.). It does not, however, distinguish this tool from potential siblings like hubvibe_research_company or hubvibe_identity_check, so it falls short of the top mark.

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

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

Usage is implied by 'Company enrichment / firmographics by domain or name' and the list of sources, but there is no explicit when-to-use, when-not-to-use, or which alternative to pick among the many research and market siblings. The agent must infer 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 cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful non-annotation context: per-call pricing ($10.00), the row-level output shape (bounds, flag, probability) and the anomaly count, including a gib_processed cost signal. It omits auth/permission requirements that a BigQuery-backed tool likely needs.

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

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

Front-loaded with the core purpose and mechanism, then modes, then I/O. It is dense and mostly earns its space, but the trailing 'Returns: ...' inventory duplicates the output schema field-by-field and is largely 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 an output schema present, the return-value restatement is unnecessary; the description's real value is the mode semantics and the cost signal. Given a 9-parameter tool with 67% schema coverage, it covers the call pattern adequately but leaves max_scan_gib and the required-vs-optional boundary partly to the schema.

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%, so the schema already documents several parameters (target_last, anomaly_prob_threshold, language, id_cols). The description largely restates parameter names and the two mode-setting parameters, adding modest value such as the single-table-vs-history+target semantics. Two parameters (max_scan_gib, data_col) remain undocumented in either place.

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 ('anomaly detection on a time series') and names the underlying mechanism (BigQuery AI.DETECT_ANOMALIES / TimesFM), which is unusually concrete. It does not differentiate itself from the closest sibling, hubvibe_data_forecast, so an agent must infer that distinction from the name alone.

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?

Explains the two operating modes clearly: one table whose latest periods are scored against its own history (via target_last), or a separate history and target table. This tells the agent how to configure a call, but gives no explicit when-not or alternative-tool 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 that this is read-only, idempotent, open-world, and non-destructive. The description adds valuable operational context: nothing to train, per-series forecasting, output bounds, and a $10.00 per-call cost, though it does not discuss permissions or 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?

The description is dense and front-loaded with the model and purpose, then input, cost, and return details. The Returns section duplicates the output schema somewhat, but the content remains useful and there is little wasted wording.

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 output schema exists, the description does not need to exhaustively explain return values, and it still provides a useful summary. The main gap is max_scan_gib, which is undocumented in both schema description and tool description despite being relevant to cost control.

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 names the three required parameters and two optional ones, adding minor meaning for horizon and id_cols. However, it omits language and max_scan_gib, and with only 57% schema description coverage it does not fully compensate for those gaps.

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: forecast any BigQuery table using TimesFM/AI.FORECAST. It explains the core mechanism and required inputs, making it clearly distinguishable from sibling tools like hubvibe_data_query or hubvibe_data_anomalies.

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 with examples: sales, traffic, demand, and metric forecasts. It does not explicitly list when not to use it or name alternative tools, so it stops just short of full guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing cost ('$0.10 per call'), the data provenance (World Bank/Eurostat) and the presence of an update stamp — genuinely useful context an agent cannot get from the annotations. It omits rate limits or latency behavior, 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 opening is front-loaded and efficient, but the second half spends a long run-on enumerating the full return shape — indicator{}, observations[], latest{}, change{}, as_of, source_url — which duplicates the output schema that already exists. That verbosity dilutes an otherwise dense 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 5-parameter, read-only, open-world lookup tool with a full output schema and complete annotations, the description supplies the extra an agent needs: pricing, provider coverage, and the annual/monthly split. The only wasted content is the return-value enumeration, which the output schema already carries.

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 baseline is 3. The description only restates the parameter names ('Input: indicator, country; optional last, frequency') and adds nothing about accepted formats beyond what the schema's own per-property descriptions already say (ISO codes, alias list, enum). Baseline 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?

It names a specific verb/resource set — 'Economic data / macro indicators for any country, live' — and enumerates the concrete indicator families (GDP, inflation, unemployment, etc.) plus the two upstream sources (World Bank, Eurostat). That is far more specific than a tautology, but it never distinguishes itself from plausible siblings such as hubvibe_data_query, hubvibe_opendata_table or hubvibe_finance_analytics, so it falls short of a 5.

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

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

It explains source coverage ('Annual for 200+ economies from the World Bank; monthly EU inflation and unemployment from Eurostat') which implicitly guides frequency choice, and the schema documents 'auto'. However there is no explicit when-to-use/when-not guidance, no alternatives named among the many sibling data tools, and no mention of prerequisites. Usage 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: dry-run-then-refuse-above-ceiling cost bounding, a $0.50 per-call price, and the return shape with cache_hit. These are exactly the operational traits an agent needs before invoking.

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

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

Dense and front-loaded: purpose, cost behavior, inputs, alternative, price, and return shape in a few tight sentences. The telegraphed 'Input: sql; optional max_scan_gib' fragment is efficient, though the overall block is packed enough that a 5 would overstate its clarity.

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?

Covers purpose, input names, cost/refusal behavior, pricing, the plain-English alternative, and return fields. With an output schema present it needn't restate return values, yet it still summarizes them usefully, so nothing needed for a correct call is missing.

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

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

Schema coverage is 100%, so the schema documents sql, language, and max_scan_gib itself. The description names sql and max_scan_gib and adds the useful framing that max_scan_gib is an enforced ceiling, but it never mentions the language parameter. Baseline 3 is appropriate when the schema carries the load.

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 ('run a read-only SQL query') and names the data scope (Google public datasets with examples). It also explicitly distinguishes itself from the plain-English sibling data.question, so an agent can route 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 a clear routing rule: use this for SQL, use data.question for plain English. It also explains the cost-bounding context (dry-run first, refused above ceiling), which tells the agent when the call may fail. It lacks explicit when-not-to-use guidance beyond the one alternative, so it falls short of 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/idempotent/non-destructive/openWorld, so the bar is lower, yet the description still adds real context: a byte ceiling on execution, a $5.00 per call cost, and the fact that the generated SQL and exact columns/rows are surfaced. That pricing and resource-limit disclosure is genuinely useful behavior an agent cannot get from annotations.

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

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

Front-loaded with the core purpose and scannable in one paragraph. There is mild redundancy between 'returned with the SQL, columns and rows it used' and the trailing 'Returns: answer, sql, columns[], rows[], gib_processed', which repeats the same payload list.

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

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

An output schema exists, so the return payload does not need spelling out, though the description does so anyway. With cost, execution ceiling, scope, and usage context covered, an agent has what it needs to call the tool correctly; only the sibling differentiation and the language parameter are left implicit.

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 75% and already documents table format ('project.dataset.table'), columns as hints, and the BCP-47 language default. The description only restates 'question, table; optional columns' and omits the language parameter entirely, so it adds little beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource: ask a BigQuery table a question in plain English and get a written answer via generated SQL. Scope ('any BigQuery table, including Google's public datasets') is precise. It does not, however, name or contrast with the obvious sibling hubvibe_data_query, so an agent must infer the split.

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?

"Use it for analytics questions without writing SQL" gives a clear positive condition for selection, implicitly steering users away from writing their own SQL. No explicit when-not or named alternative (e.g. hubvibe_data_query) is provided, keeping it 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, idempotent, openWorld, and non-destructive, so safety is covered. The description goes beyond that by disclosing pricing ($0.05 per call), the flagging behavior (missing/duplicate SPF, DMARC gaps, near-expiry certs), and the browser-like TLS check, which are genuinely useful traits not in the structured 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?

Dense but front-loaded with the core purpose before the detail, and every clause is informative. However, the long 'Returns:' enumeration substantially duplicates the output schema, which is redundant given a formal output schema exists, keeping it off a 5.

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 read-only lookup with full schema coverage and a formal output schema, the description is complete enough to invoke correctly. The return-value listing is redundant against the output schema, and version/pagination or rate-limit context is absent, but nothing essential is missing.

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

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

Schema description coverage is 100%, so parameters are already documented in the schema. The description only restates that domain accepts a URL, which the schema also says, and says nothing about the tls toggle or language option. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('DNS lookup and domain health check') and enumerates exactly what it covers: A/AAAA/CNAME/MX/NS/TXT/CAA/SOA records, SPF/DMARC parsing, and TLS verification. This distinguishes it clearly from siblings like hubvibe_ip_lookup, hubvibe_email_verify, and the audit_* 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?

The description implies the scenario (domain health check, flags missing SPF/DMARC) but never states when to use this versus alternatives such as hubvibe_email_verify or hubvibe_ip_lookup, nor any prerequisites or exclusions. A competent agent can infer usage, but no explicit routing guidance is 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?

Beyond the readOnly/destructive/idempotent annotations, it discloses real behavioral traits: checks are performed live against DNS and the mail server, no message is sent, a per-call cost of $0.02, the four possible verdicts, and the exact signals flagged (disposable, role account, catch-all, typos). This is materially more than the annotations convey.

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

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

Purpose and caveats are front-loaded well, but the trailing enumeration of every return field (email, normalized, local_part, domain, ... checked_at) largely duplicates the output schema and pads length without adding decision-relevant 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?

Covers what is checked, the verdict taxonomy, cost, and side-effect-free behavior, which is enough to call it correctly. The long return-field list is unnecessary given an output schema exists, but nothing an agent needs is missing.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents 'email' and the optional BCP-47 'language'. The description only restates 'Input: email' and does not mention the language parameter at all, so baseline 3 is appropriate.

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 ('Email verification / email validation') and immediately frames the question it answers ('will mail to this address arrive?'), which no sibling tool does — the closest relatives (hubvibe_phone_parse, hubvibe_identity_check) operate on different inputs. An agent can select this without opening the schema.

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

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

The title and the framing 'before you send' make the use context explicit, and 'No message sent' clarifies the non-intrusive mode. However, it never names an alternative or states when NOT to use it (e.g., bulk list hygiene vs single-address checks), which keeps it 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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds genuine value beyond them: JavaScript rendering behavior, the $0.10 per call cost, and the exact return shape. It does not, however, mention rate limits, failure modes, or what happens on non-HTML content.

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 core purpose, then usage, then alternatives, cost, and return shape in a compact telegraphic style. Every clause carries information, though the shorthand notation ('Input: url', 'Returns: ...') is terse rather than polished.

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

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

For a single-fetch extraction tool, the description covers purpose, usage, alternatives, cost, and return fields, and an output schema exists so return values need not be fully explained. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (url, language) are fully documented in the schema, and the description only restates 'Input: url'. It adds no syntax, format, or meaning beyond what the schema already provides, so the baseline of 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 ('Web scraping / web page to clean text') with the differentiating detail that it renders in a real browser including JavaScript pages, returning readable text. It explicitly names the sibling alternatives (fetch.raw, research.brief), so an agent can distinguish it from hubvibe_fetch_raw and hubvibe_research_brief 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 concrete when-to-use guidance ('read an article, docs page or product page before summarising or extracting') and routes to alternatives with conditions attached: raw status/headers/body goes to fetch.raw, a question answered from the page goes to research.brief. This is explicit when/when-not/alternatives coverage.

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/destructive=false/openWorld, but the description adds genuinely non-structured behavior: non-2xx statuses are returned as results rather than errors, redirects are followed with final_url reported, and responses may be truncated ($0.10 per call is also disclosed). It does not cover auth requirements or rate limits, so it is strong but not exhaustive beyond the annotations.

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

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

Front-loaded with the core action, then behavior, then sibling routing, then cost and return keys. Dense but every clause carries signal (status semantics, redirects, truncation, pricing, return shape), with only the explicit returns list being slightly redundant given the output schema.

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

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

For a 2-param read-only fetch with full annotations and an output schema, the description supplies everything an agent needs: scope, sibling routing, status/redirect/truncation semantics, and cost. No meaningful gap remains.

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 both parameters (url, language) are already documented in the schema. The description only restates 'Input: url' and ignores the language parameter, adding no meaning beyond what the schema provides; 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+resource ('HTTP fetch / GET any URL') and pins down scope as a raw, unprocessed fetch. It explicitly distinguishes itself from the sibling hubvibe_extract_page ('Readable text from a rendered page: extract.page'), so an agent can route between them without opening a schema.

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

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

Gives concrete when-to-use cases (API checks, uptime probes, raw HTML) and names the alternative plus the condition that selects it (readable text from a rendered page -> extract.page). Nothing about routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds valuable behavioral context: it is 'deterministic, every formula named, no LLM', it discloses a '$0.50 per call' cost, and it names the exact output sections. This is exactly the kind of context annotations cannot 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?

The description is front-loaded with purpose and key computational scope, and the deterministic/cost disclosures earn their place. However, the final sentence enumerating return keys (source{}, n, n_returns, periods_per_year, metrics_computed[], returns{}, etc.) is largely redundant because an output schema already exists, which slightly detracts from conciseness.

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 high schema coverage, rich annotations, and the presence of an output schema, the description is complete enough for correct invocation. It communicates input modes, deterministic behavior, pricing, formula scope, and optional features without needing to re-explain all return values or parameter constraints.

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% and the schema documents all 13 parameters with defaults, ranges, and nested structure. The description only briefly summarizes the inputs ('prices or symbol; optional metrics, benchmark, option, kelly'), adding almost no semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 domain and resource — 'Trading and portfolio math' — and enumerates the exact computations it performs (returns/CAGR, volatility, Sharpe, Sortino, drawdown, VaR/CVaR, beta, alpha, SMA/EMA, RSI, Bollinger, Black-Scholes, Kelly). This clearly distinguishes it from sibling market-data tools like hubvibe_market_quote or hubvibe_market_stock, which retrieve data rather than compute formulas.

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 states the two input modes ('over prices you send or a ticker fetched live') and lists optional inputs, so an agent understands the basic invocation context. It does not explicitly state when to avoid this tool or name sibling alternatives, but the use case is narrow and the context is clear enough 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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful context beyond that: the $0.10 per-call cost, the meaning of the fraud flags (sanctions hit, disposable email, VoIP, country disagreement), and the risk-level semantics. It does not mention auth or rate limits, 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 core purpose and use case, and information-dense. However, the return content is stated twice — once in prose ('Returns each result, fraud flags...') and again as a structured 'Returns: input{}, risk...' block — which is redundant, especially since an output schema exists.

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 complex multi-check aggregator, the description covers inputs, the anyOf constraint, cost, use case, flag semantics and risk levels. With an output schema also present, an agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters in detail. The description summarizes the key inputs ('any of name, email, phone, ip; optional country, birth_year') and conveys the anyOf requirement, but omits language and phone_region and adds no syntax the schema lacks. Baseline 3 is appropriate.

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+resource (KYC screening / identity risk check) and enumerates exactly what is screened for each input type (OFAC/UK/EU sanctions, mailbox/disposable/role email checks, phone validity/country/line type, IP country/network). This lets an agent distinguish it from the narrower siblings hubvibe_sanctions_screen, hubvibe_email_verify, hubvibe_phone_parse and hubvibe_ip_lookup, which each cover only one facet.

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 a concrete usage context ('Use it before onboarding a user or counterparty'), which is actionable. It does not, however, state when NOT to use it or explicitly route the agent to the single-purpose siblings when only one check is needed, so the routing guidance is implied rather than explicit.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint=false, idempotentHint, openWorldHint), so the bar is lower. The description adds genuinely useful non-annotation context: the cost ($0.50 per call), the model used, and the return shape (base64 bytes with MIME type). It does not mention rate limits or latency.

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

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

Dense and front-loaded: purpose, use cases, inputs, cost, and returns in a compact block with no filler. Every clause carries information an agent can act on.

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

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

With an output schema present, listing return fields is redundant but harmless, and the cost/model/use-case context rounds out the picture well. The main gap is that the 'language' parameter goes unmentioned and there is no explicit routing against image-adjacent siblings.

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 documents all three parameters (67% coverage, with prompt and aspect_ratio described) so the baseline is 3. The description restates prompt and aspect_ratio but omits the 'language' parameter entirely, adding no syntax or format detail beyond the schema.

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

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

States a specific verb+resource ('AI image generation / text to image: one image from a text prompt') and names the underlying model (Google Imagen 4). It clearly distinguishes itself from image-adjacent siblings like hubvibe_video_generate and hubvibe_llm_generate by being text-to-image specifically.

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 concrete use cases ('illustrations, thumbnails, product mockups and social images'), which supplies clear context for when to reach for it. It stops short of naming alternatives or exclusions (e.g., when to use video_generate or llm_generate instead), so it doesn't reach the top tier.

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, openWorld and non-destructive, so the safety profile is covered. The description goes beyond that with the $0.02 per-call cost, the DB-IP Lite source with monthly refresh, and the important caveat that location is the network's registered place rather than a street 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?

Front-loaded with the core purpose, then cost and inputs, then a compact returns list. It is dense but each segment (source, licensing, caveat, price) carries information an agent needs; only the verbose returns enumeration overlaps with the output schema.

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

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

With annotations and an output schema present, the description still supplies the pricing, data provenance, update cadence and the semantic caveat about location precision, which is more than required. The only gap is sibling routing, which is outside strict completeness.

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 both ip and the optional language tag. The description only echoes 'Input: ip' and adds no syntax or format detail beyond 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 and resource (IP geolocation/lookup) and enumerates exactly what is returned: coordinates, ASN/organisation, reverse DNS, and public/private/reserved scope for IPv4 and IPv6. An agent can immediately tell this is the IP-intelligence tool, distinct from hubvibe_domain_dns and hubvibe_identity_check.

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 (pass an IP, get geolocation) and the description adds practical context like cost and data source, but it never says when to pick this over siblings such as hubvibe_domain_dns or hubvibe_identity_check, nor any exclusions or prerequisites.

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 read-only/idempotent/open-world/destructive, and the description adds genuinely useful context beyond them: a single plain-HTTP fetch with no browser rendering, the $0.25 per-call cost, and that accessibility signals are 'static' only. It stops short of noting rate limits or what happens if the site 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?

Purpose and capabilities are front-loaded effectively, but the long 'Returns:' enumeration restates field-by-field output that the output schema already provides, consuming roughly half the text without earning its place. Trimming the return listing would sharpen it considerably.

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 3-param aggregate tool with a full output schema, the description tells the agent everything needed to invoke it correctly and what it aggregates. Return-value explanation is redundant given the output schema, so completeness is high though not perfect.

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 schema itself explains url, language and business_name in detail. The description restates only url and optional business_name and omits the language parameter entirely, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource (qualify a business website as a sales lead) and enumerates exactly what is produced: SEO, security, accessibility, tech/tags, email, company profile and a 0-100 opportunity score. The 'in one call' framing and single plain-HTTP fetch clearly distinguish it from the granular audit_seo / audit_security / audit_wcag siblings.

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

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

The sales-lead-qualification context and 'one call, plain HTTP, no browser' hint at when to reach for it over the separate audit tools, but the description never explicitly says when to use this vs. the audit_* or hubvibe_company_enrich siblings, nor states any exclusions. Usage is implied 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, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: grounding to the supplied text only, refusal rather than hallucination, the exact backend model, and a $0.25 per-call cost. It does not discuss latency, token limits, or input size 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?

The description is front-loaded with purpose before mechanics, and packs cost, model and return fields into compact sentences. The clause 'Fixed JSON fields: llm.extract' is opaque jargon that does not clearly earn its place for an agent deciding how to call the tool, which is the only real waste.

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

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

An output schema exists, so return values need not be explained, yet the description still lists answer/model/tokens cheaply. Combined with cost, model, grounding behavior and input list, an agent has enough to call this correctly. Missing input-size or rate-limit guidance for a paid LLM call keeps it short of 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?

Schema description coverage is 100%, and the schema already documents text, question (optional) and language (BCP-47 with default). The description only restates these at a high level ('Input: text, question; optional language'), adding no format or syntax detail. However, it usefully notes that question is optional and that language defaults to the input language, which maps to the schema's semantics. Baseline would be 3; the brief optionality/default restatement nudges it slightly above baseline but no new parameter meaning is introduced.

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 capability: grounded question answering over user-supplied text using Gemini, with the explicit caveat that it will not guess when the answer is absent. That is far more specific than a generic 'analyse text' title, and the grounding constraint implicitly separates it from freeform siblings like hubvibe_llm_generate. It never names a sibling explicitly, so it falls short of full 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?

It gives concrete use cases ('summaries, Q&A and checks over documents, emails and pages'), which tells an agent when this tool fits. There is no explicit when-not guidance or named alternative (e.g. hubvibe_llm_extract or hubvibe_data_question), so routing between LLM siblings still requires inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds behavior the annotations cannot carry: no invented values, null where the text does not state a value, the underlying model (Gemini), the return shape, and the $0.25 per-call cost. That is meaningful disclosure of semantics and cost beyond 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?

It is compact and front-loads the core verb+resource, then the use cases, then input/return notes. The pricing sentence is short and earns its place for a metered call. The colon-heavy fragments are dense but not wasteful.

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

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

For a 3-parameter tool with an output schema, the definition covers purpose, inputs, null-handling, cost, and one routing alternative. The missing mention of the language parameter is the only real gap, and return values need not be re-explained since an output schema 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 description coverage is 67%. The description names 'text, fields[]' and explains the resulting output keyed by the requested fields, plus the null-when-absent semantic. However, the optional 'language' parameter is never mentioned in the description, so it does not fully compensate for the coverage gap. Adequate but with a clear omission.

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: 'pull the fields you name out of any text into a JSON object with exactly those keys.' It is clearly an extraction tool, and it names a sibling route ('From a live web page: research.page_facts') for the adjacent case. It does not distinguish itself from the LLM-family siblings (llm_generate, llm_analyze), so it falls short of a 5.

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

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

It gives concrete use cases ('turn emails, invoices, pages or documents into clean records') and redirects one case to an alternative ('From a live web page: research.page_facts'). That is clear positive context, though there is no explicit when-not-to-use statement covering free-form generation or analysis tasks handled by siblings.

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/idempotent/destructive=false, so the safety profile is covered. The description adds genuinely useful operational context: paid per call at $0.25, no API key or account required, and the default provider (Gemini). It does not discuss rate limits or how temperature affects repeatability.

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 purpose and efficient overall, but slightly cluttered: "Input: prompt" restates the required parameter, "paid per call" and "$0.25 per call" duplicate each other, and the return-value list is redundant given an output schema exists.

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 7-parameter tool with an output schema, the description covers purpose, cost, defaults, and the sibling alternative well, so an agent has what it needs to call it. Minor gaps remain around prompt length limits and whether temperature breaks the declared idempotency, but the core is 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating the default provider ("Gemini by default, other configured models by provider and model") and enumerating the optional knobs (system, max_tokens, temperature) in one place, though it adds no format or interaction detail for language/model.

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

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

The description names a specific verb+resource ("LLM text generation / chat completion: a raw completion from your prompt") and immediately differentiates itself from the sibling hubvibe_llm_analyze ("Answer grounded in your own text"). An agent can tell this apart from the other llm_* tools without opening any schema.

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

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

It gives concrete use cases ("drafting, rewriting, translation, classification or any prompt") and points to the alternative tool for grounded answers. It stops short of explicit when-not conditions (e.g. use extract for structured output), so it's clear but not fully routing.

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 the safe read-only, idempotent, open-world profile, and the description adds meaningful behavior beyond them: the Overture Maps data source (80M+ places), the $0.10 per call cost, nearest-first ordering, the radius-widening fallback, and language translation semantics for human-readable strings.

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 recognizable examples and scope before the mechanics, and every sentence is purposeful. The one inefficiency is enumerating the full return field list, which duplicates the existing output schema and could be trimmed.

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 rich annotations and a present output schema, the description supplies everything an agent needs: cost, data provenance, result ordering, and the widening fallback. The redundant returns enumeration is harmless rather than a 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 description coverage is 100%, so the schema already documents all parameters including bounds, defaults, and length limits. The description's 'Input: query; optional near, lat and lng, radius_m, limit' largely restates the schema and adds no syntax or defaults beyond it, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('Places near me / local search anywhere') and illustrates with concrete queries ('coffee near the Ferry Building', 'ramen near Shibuya Station'). It is clearly distinguishable from siblings like hubvibe_maps_route and hubvibe_maps_weather 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?

Gives strong usage context: example query formats, the meaning of the 'near' vs lat/lng inputs, and the fallback that 'the area widens when nothing is close'. However, it does not explicitly state when to prefer this over hubs like maps_route or name an alternative, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely new disclosure beyond them: the backing service (Google Maps Grounding Lite), the fact the result follows that service's own shape, and a $0.10 per-call cost, which is material for an agent deciding whether to 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-loaded with purpose, then inputs, then cost, then return shape — a sensible order. Some low-value restatement (listing output fields already covered by the output schema) keeps it out of 5 territory.

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

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

With an output schema present, the description is not obliged to enumerate returns, yet it still signals the result shape, and it covers inputs, modes and cost. The main gap is routing guidance away from hubvibe_traffic_route, given the near-identical terrain.

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% (origin and destination carry no descriptions), and the description adds no format, disambiguation or example for them — it merely names the inputs. travel_mode's enum and DRIVE default are simply restated from the schema, and the language parameter is never mentioned. Marginal added value over structured fields.

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 ('Directions between two places' / 'Compute a route') with the supported modes, so the agent knows exactly what it produces. It does not, however, disambiguate from the overlapping sibling hubvibe_traffic_route or hubvibe_maps_places, which is the only thing keeping it from 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?

Gives clear use context ('Use it for trip planning and ETAs'), which is enough to place the tool in a workflow. It stops short of naming when not to use it or pointing to the closely related hubvibe_traffic_route alternative, so the sibling-overlap risk is unaddressed.

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, openWorld and non-destructive, so the safety profile is covered. The description adds valuable context the annotations do not: the $0.10 per-call cost, the MET Norway data source, NWS as the US alert source, and the existence of alerts_covered and sections_failed fields hinting at partial-failure 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?

Purpose, sources, cost, inputs and outputs are all present and reasonably front-loaded. The long 'Returns:' enumeration is somewhat wasteful given an output schema exists, but the labeled structure keeps it scannable and it is not repetitive prose.

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?

Because the output schema exists, the return-value enumeration is not strictly needed, but the description still conveys source, cost, and the US-only alert caveat that an agent should know. Nothing critical for correct invocation is missing, though explicit sibling routing would complete 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 description coverage is 100%, so the baseline of 3 applies. The description restates the location input formats (place name, address, airport code, lat/lng), which the schema already documents, and makes no mention of the optional language parameter.

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

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

States a specific verb+resource (weather forecast) with explicit scope: current conditions, 24-hour and seven-day forecast, plus NWS alerts. Clearly distinguishable from siblings like hubvibe_maps_places (geocoding) and hubvibe_maps_route/hubvibe_traffic_route (routing).

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?

Explains accepted input forms (place name, US address, airport code, or lat/lng) and notes alert coverage is US-only, which implies usage. However, it never says when to prefer this tool over siblings such as hubvibe_maps_places for resolving a location, nor any prerequisites or 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/idempotentHint/openWorldHint, so the safety profile is covered. The description adds value beyond that: it discloses the upstream source (EDGAR XBRL, official), a cost of $0.05 per call, latest-filing restatement behavior, and a 'checked_at'/'as_of' freshness signal.

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 purpose, then inputs, cost, and return shape in a compact sequence. The concept enumeration is long but load-bearing; the return-field list is borderline redundant with the output schema but serves as a quick contract summary.

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?

Covers source, input modes, default concepts, filtering, cost, restatement semantics, and currency of data — everything an agent needs to call it correctly. With an output schema present, the description needn't detail return values further, and it doesn't.

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 still adds meaning by restating the symbol-or-cik alternation, summarizing the default concept set, and framing periods/forms as optional filters. It doesn't add format/syntax detail beyond the schema, so it lands just above baseline.

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

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

Specific verb+resource: 'SEC filings / company fundamentals' from EDGAR's official XBRL API, with an explicit enumeration of the line items it returns (revenue, net income, diluted EPS, assets, etc.) and the forms it draws from (10-K, 10-Q). This distinguishes it from siblings like hubvibe_market_stock (prices) and hubvibe_finance_analytics.

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?

States the input contract (symbol OR cik), that arbitrary XBRL concepts are accepted, and that restatements resolve to the latest filing — enough context to know when this tool applies. It does not, however, explicitly name a sibling alternative or say when NOT to use it (e.g. intraday price vs. filed fundamentals).

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/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: live EDGAR parsing at call time, a $0.10-per-call cost, default windows (90 days, 20 filings), and that outputs carry a source/checked_at/notes trail.

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

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

Front-loads the core purpose well, but the transaction field list appears twice ('Each trade:' then again inside the 'Returns:' enumeration), which is redundant especially since an output schema already exists. Dense but not tight.

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 read-only market-data tool with an output schema, the description covers source, cost, input modes, defaults, and summary shape — more than enough for correct invocation. It does not need to enumerate return fields given the output schema, so its completeness is slightly above adequate.

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 all seven parameters (cik, days, codes, symbol, language, max_filings, include_derivatives). The description restates symbol/cik/days/codes and adds code meaning context ('P' buys, 'S' sells) but omits language, max_filings, and include_derivatives, so 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+resource (parsed insider buying/selling from SEC Form 4 filings) with clear scope, source (EDGAR), and timing (parsed at call time). An agent can distinguish it from siblings like market_quote or market_stock without opening a schema.

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

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

Gives input guidance (symbol OR cik, optional days/codes with defaults) and mentions the data source, but never states when to prefer this tool over alternatives (e.g., market_intel, company_enrich) or any exclusions. Usage is implied rather than spelled out.

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, openWorld). The description adds genuinely useful context beyond them: a $5.00 per-call cost, a disclaimer/not-investment-advice framing, and the epistemic posture of the output ('says what the numbers do and do not support'). It does not disclose latency, rate limits, or error behavior, 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?

The payload is front-loaded: the composite capability comes first, then usage, then inputs, then the returns list. The 'Returns: spot{}, prediction_markets[], news[], news_note, analysis, disclaimer' tail is somewhat listy but earns its place as a quick output preview. Minor redundancy around the input list keeps it from a 5.

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 multi-source aggregation tool with an output schema, the description covers the sources, the synthesis behavior, cost, usage scope, and a returns preview. An agent can decide whether to call it and what to expect without opening the schema.

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 80%, so the schema already carries most parameter meaning. The description restates product_id, query, question and limit, and its BTC-USD example duplicates the schema's own 'e.g. BTC-USD' note. It omits the language parameter entirely, adding little beyond the structured data — 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 composite capability: live Coinbase spot price + Polymarket probabilities + GDELT news on the same subject, synthesized into a written analysis. This is clearly distinguishable from siblings like hubvibe_market_quote (quote only), hubvibe_market_prediction (prediction only) and hubvibe_news_search (news only) because it names the fusion 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?

'Use it for a quick read on Bitcoin, Ethereum or any coin' gives clear usage context, and the 'Market data only, not investment advice' line bounds the scope. It does not, however, name an alternative or state when a narrower sibling (e.g. hubvibe_market_quote or hubvibe_market_prediction) would be preferable, so the routing guidance is incomplete.

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, idempotent, openWorld), but the description adds two pieces of genuinely operational context: cost ($0.05 per call) and the billing rule that an unmatched topic is 'refused free, never sold empty.' That directly affects how an agent should budget and retry. It stops short of describing freshness/latency or pagination behavior, 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?

It is front-loaded with the topic and probability semantics, which is good, but the trailing 'Input: optional query, limit.' and 'Returns: markets[] with question, implied_probabilities[], volume, end_date.' duplicate the input schema and the existing output schema, adding length without new 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 annotations, 100% schema coverage and an output schema, the description only needs to add what structured fields cannot: it supplies cost, the free-refusal rule, and supported query styles. That is sufficient for correct invocation, though a note on rate limits or result freshness would have made 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?

Schema description coverage is 100%, including ranges, query examples and the full BCP-47 semantics of 'language', so the schema already carries parameter meaning. The description's 'Input: optional query, limit' restates the schema without adding format or interaction detail and omits 'language' entirely, making this a baseline-3 case.

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 resource (live Polymarket prediction markets), the derived value (implied probability per outcome) and the accompanying fields (volume, liquidity, end date) — an agent immediately knows what comes back. It does not differentiate itself from adjacent siblings such as hubvibe_prediction_events or hubvibe_predictive_probability_engine, and the phrase 'One market by slug: prediction.market' is ambiguous about whether it refers to itself or another tool.

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 usable retrieval modes ('search by topic words or tickers (BTC, fed rate cut) or take the biggest markets'), which implies when to supply a query vs. omit it. However there is no explicit when-to-use guidance against the sibling prediction tools, nor any statement of prerequisites or limitations beyond the free-refusal behavior.

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