Bob Research Tools

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

Annotations cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description adds substantial context beyond them: expected latency of 2-5 seconds, truncation at 8,000 characters with a truncated flag, refusal of login-gated pages, x402 per-call payment, a 60 calls/minute per-client rate limit, and that failed calls are not charged. This is exactly the operational detail 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-loads the output contract (markdown, unsummarized, 8,000 char cap, response shape) before operational caveats, then routes to siblings. Every sentence carries distinct, load-bearing information with no filler.

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

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

Although an output schema exists and return values need not be described, the description still adds cost, rate-limit, latency, auth, and truncation behavior that structured fields do not capture. For a single-parameter extraction tool, nothing an agent needs to call 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 coverage is 100% and the single url parameter is already documented as a public http/https address with private/local addresses refused, so the baseline is 3. The description goes beyond it by specifying that the address must be of the specific page and not a site's home page, a constraint absent from 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 and resource ('Returns the main text of one public web page as clean markdown'), defines the scope (one page, unchanged, not summarized, 8,000 char cap) and the exact return shape. It explicitly distinguishes itself from page.summarize, so an agent can choose 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 explicit when-to-use rules and exclusions: pass a specific page not a home page, login-gated pages cannot be read, use page.summarize for a short version, and for multiple pages or crawling, get addresses from web.search and call once per address. Alternatives and conditions are named rather than 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 cover readOnly/openWorld/destructive, but the description goes well beyond them: live fetch semantics, 3-6 second latency, paywall limitation, paid-per-call via x402, and the important billing behavior that a timed-out read fails without charge. That is exactly the operational 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?

Information is front-loaded: what it produces first, then latency, then fetch caveats, then routing to page.extract, then cost/failure semantics. Every sentence carries distinct, actionable content with no filler.

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

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

Despite an output schema existing, the description still summarizes the return shape, and it covers the one risk an agent cares about for a paid, live-fetch tool (unreadable pages and non-charged failures). Nothing needed 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 coverage is 100% for the single url parameter, so the baseline is 3. The description adds genuinely useful usage semantics beyond the schema by specifying that the address must be the specific page rather than a home page, which is a selection constraint not encoded in 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 (condense/summarize) and resource (one public web page) with quantified output shape (80-word summary, up to 4 key points, {url, summary, key_points}). It also explicitly distinguishes itself from the sibling page.extract, so an agent can route correctly 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 explicit when-to-use ('Pass the address of the specific page, not a site's home page') and names the alternative for a different need ('Use page.extract for the page's own text'). It also states the failure condition (pages behind login/paywall may return little), which is real selection 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?

Goes well beyond the annotations: reveals latency (4-9s), x402 paid-per-call billing, a 60 calls/min per-client rate limit, that failed/timed-out/capacity calls are not charged, and that calls are independent and parallelizable. Annotations only cover the read-only/open-world profile, so this fills the real behavioral gap.

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 output shape, then routing, then usage and billing. Efficient overall, though the 'one question per call' instruction is stated twice (once in usage, again in the closing parallel-calls sentence), which is slightly 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 and rich annotations, the description supplies everything else an agent needs: latency expectations, cost model, rate limits, failure billing behavior, and invocation constraints. Nothing material is missing for a single-parameter tool.

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

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

Schema coverage is 100% so baseline is 3, but the description adds meaningful semantics the schema lacks: name the people, places and dates the question depends on, and ask exactly one question per call. This is genuine invocation guidance beyond the 1-500 character constraint.

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 (answers a research question from the live web) plus concrete output shape (max 80 words, up to 3 source URLs, {answer, sources}) and latency. It explicitly disambiguates from web.search and research.factcheck, so an agent can select it without opening other schemas.

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 explicit routing: 'use web.search for raw links or research.factcheck to verify a claim', and states the calling convention 'one question per call' with the reason (multiple questions get one blended answer). When-to-use and the alternatives are both named.

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/non-destructive, and the description adds substantial context on top: typical 5-8s latency, x402 per-call payment, no charge on timeout failure, and the rule that facts appear only when sources state them with conflicts resolved to the most recent dated figure.

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 what is returned and the response shape, then layers timing, input guidance, sourcing rules, and payment terms. Every sentence carries information, though the run is dense enough that a reader must parse several distinct concerns in one block.

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 structure needn't be explained, yet the description still covers cost model, failure behavior, latency, and sourcing caveats. Nothing an agent needs to decide to call it, or to interpret a failure, 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 baseline is 3, but the description meaningfully enriches the single parameter: a website address avoids name clashes while a bare name resolves to the best-known match, and ambiguity is surfaced in the output. That is real semantics beyond the schema's 'company name or website' text.

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 ('Returns a short sourced brief on one company') and enumerates the returned fields, so an agent can distinguish it from research.answer, research.market, or page.summarize 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 clear usage context: pass a website to avoid name clashes, bare names resolve to the best-known company, and ambiguity is flagged in the summary. It does not explicitly name a sibling tool or state when a different research tool would be preferable, so it stops short of full 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 cover the safety profile (readOnly, non-destructive, open-world), and the description adds value beyond them: latency expectation (4-9s), the returned fields, and monetization behavior ('paid per call with x402; a failed call is not charged'). The billing and failure-charging disclosure is exactly the kind of operationally critical context an agent needs.

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

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

Front-loaded with purpose, output shape and latency, then routing and usage rules — every sentence carries information. Minor redundancy: 'Read-only' restates the readOnlyHint annotation and could be dropped.

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?

Output schema exists, so return values need no further explanation, yet the verdict enum is still summarized helpfully. Latency, cost model, input format, and when-to-use alternatives are all covered for a one-parameter tool.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds real semantic guidance beyond the schema: write the claim as a plain statement, keep it to one claim per call, and split compound claims. That constrains how the single string parameter should be composed.

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 ('Checks one factual claim'), names the output shape, and explicitly distinguishes itself from the sibling research.answer. An agent can select it 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 explicit routing rules: use research.answer for open questions, split compound claims into separate calls, call once per claim for multiple claims. When-not and alternatives are both 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 cover the read-only/open-world safety profile, yet the description adds materially new behavior: typical latency (5-8 seconds), a paid x402 per-call model, and the failure-and-no-charge contract. This is exactly the extra 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?

One front-loaded paragraph ordered purpose, output, usage, then cost/behavior — every sentence carries information. Slightly dense, and listing the output field names is mildly redundant given an output schema exists, but nothing is wasted.

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

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

Covers purpose, required input wording, exclusions, latency, pricing, and failure semantics; with an output schema present, it need not explain return values. An agent has everything needed to decide and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real guidance beyond the schema by telling the agent to include the market's date or threshold and giving concrete examples ('by Dec 31, 2026', 'above 4.5%'). That is actionable formatting advice the schema does not supply.

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

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

States a specific verb and resource ('Builds an evidence brief for a prediction-market question ... from the live web') and even enumerates the output shape, so an agent can distinguish it from generic research siblings 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?

Explicitly routes general questions to a named alternative ('Use research.answer for general questions') and states what it is not for ('no probability, forecast or trading advice'). It stops short of contrasting with the other research.* siblings (factcheck, company), so it is clear but not exhaustive.

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

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

Beyond the annotations' read-only/open-world safety profile, it discloses latency (3-7 seconds), the x402 paid-per-call model, and the failure semantics ('if nothing recent is found the call fails and is not charged'). It also bounds output to what dated results support. Rich behavioral context an agent cannot get from 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?

A single dense paragraph that front-loads the return shape and core purpose, then layers constraints, alternatives, and cost. Every sentence carries load, though the inline schema sketch makes the sentence long and slightly harder to scan.

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

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

Covers return shape, result count, ordering, latency, pricing, failure behavior, and parameter tuning. An output schema exists, yet the description still adds the interpretive details an agent needs before committing a paid call. Nothing material 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 baseline is 3, but the description adds genuine meaning: q should be a short topic/name rather than a full question, and days is a look-back from today (1-30, default 7) that must be raised for quiet topics. This is more than a restatement of 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 and resource ('Returns recent news on one topic, person, company or event') and immediately distinguishes itself from web.search for raw links. An agent can pick it apart from the research.* and web.search siblings without inspecting schemas.

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 alternative ('Use web.search for raw links'), query-shaping advice ('a short topic or name works better than a full question'), and parameter tuning guidance ('a quiet topic needs a larger value'). Both when-to-use and how-to-use are covered.

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/non-destructive, and the description adds genuinely new behavioral facts: an x402 payment is required per call, and there is no charge when the search fails or returns nothing. That billing/refund semantics is exactly the kind of context annotations cannot 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?

Four dense sentences, front-loaded with what it does and the return shape, then routing, then query/date guidance, then billing. Nothing is padded or repeated.

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

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

Output schema exists, so return values need not be explained, yet the description still gives the shape; it also covers routing, date filtering, cost, and no-charge-on-failure. Nothing an agent needs to invoke this 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 the schema already documents n, q, since and until; baseline would be 3. The description adds value beyond it by telling the agent that plain phrases work as well as keywords and that since/until filter on publish date (useful for news queries).

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 ("Runs a web search") plus the exact return shape {query, results:[{title,url,snippet}]}. It explicitly distinguishes itself from research.answer, so an agent can choose between the two 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?

States when to use it ("raw links to read yourself") and names the alternative with the condition that selects it ("use research.answer for a written answer"). It also adds a topical-use hint: since/until "suits recent news".

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