Paid web research, fact-check, page summary and extraction for AI agents (USDC via x402).
Scored across 5 tools
Each tool targets a distinct research operation: raw search, page extraction, page summarization, factual claim verification, and open-ended research. The descriptions explicitly cross-reference each other to guide selection, and there is no meaningful overlap in purpose.
All tools use the same snake_case prefix and verb-style convention: bob_extract, bob_factcheck, bob_research, bob_search, bob_summarize. The pattern is predictable and readable throughout.
Five tools is well-scoped for a focused research toolkit. Each tool covers a distinct core operation, and there are no redundant or filler tools.
The surface covers the essential research lifecycle: search for links, extract or summarize a page, verify specific claims, and answer open questions with sources. No critical operation is missing for the stated single-page and single-query use cases.
Returns the main text of one public web page as clean markdown, unchanged and not summarized, up to 8,000 characters, as {url, markdown, truncated}, usually in 2 to 5 seconds. Use it when you need the page's own words; use bob_summarize for a short version. Pages that need a login cannot be read; long pages are cut at 8,000 characters and flagged truncated. Each call needs an x402 payment; if the page cannot be read or the URL is invalid, it fails and you are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http or https address of the page to extract; private or local addresses are refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds substantial context beyond them: output structure {url, markdown, truncated}, 2-5s latency, the 8,000-character cut with a truncated flag, login-page refusal, and the x402 payment model including that failed/invalid calls are not charged. This is rich, non-redundant behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense but purposeful sentences: output/format first, then routing to the sibling, then constraints and payment. Nothing is wasted and the key facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries return-value responsibility and does so precisely (shape, truncation, timing). Payment, failure, and access constraints are all covered, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single url parameter, so the schema already documents format and the private/local-address restriction. The description adds no syntax or format detail 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 (returns/extracts) and resource (main text of one public web page), and specifies the exact output shape (clean markdown, unchanged, not summarized, up to 8,000 chars). It explicitly distinguishes itself from bob_summarize, so an agent can route between the two without opening 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 when-to-use condition ('when you need the page's own words') and names the alternative plus the condition that selects it ('use bob_summarize for a short version'). It also states exclusions: pages needing login cannot be read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks one factual claim against the live web and returns {verdict, explanation, sources}, where verdict is supported, contradicted or unclear, usually in 4 to 9 seconds. Use it to verify a specific statement; use bob_research for open questions. Check one claim per call, phrased as a plain statement such as 'The Eiffel Tower is in Berlin'; split a compound claim into separate calls. Each call needs an x402 payment; if it cannot answer in time or the input is invalid, it fails and you are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The factual claim to check, 1 to 500 characters, written as a statement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial context beyond them: expected latency (4-9s), the x402 payment requirement, and the no-charge-on-failure guarantee. Those are exactly the traits an agent needs to decide whether to invoke and what to expect on error.
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 purpose and return shape, then guidance, then constraints and failure behavior. Every sentence carries information the agent cannot get from structured fields; nothing is 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?
There is no output schema, so the description compensates by naming the return object and its verdict enum values (supported, contradicted, unclear). Combined with latency, payment, and failure semantics, an agent has everything needed to call this 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 the claim parameter's type, length bound, and statement phrasing are already documented, which sets a baseline of 3. The description adds meaning beyond the schema by constraining cardinality ('one claim per call') and providing a concrete example phrasing.
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 against the live web') and names the exact return shape. It explicitly distinguishes itself from the sibling bob_research, so an agent can route 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?
Gives explicit when-to-use ('verify a specific statement'), the alternative and its condition ('use bob_research for open questions'), plus operational guidance on one claim per call, plain-statement phrasing, and splitting compound claims. Nothing 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.
Answers one open research question from the live web with a short written answer and source URLs, usually in 4 to 9 seconds. Use it for a synthesized answer; use bob_search for raw links or bob_factcheck to verify a claim. Works best with one specific question, e.g. 'How do facilitators settle x402 payments?'; several questions per call tend to get one blended answer. Returns {answer, sources}. Needs an x402 payment per call; if it cannot answer in time or the input is invalid, you are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The research question to answer, 1 to 500 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, openWorld, non-destructive). The description adds traits annotations cannot express: typical latency (4-9s), the x402 per-call payment requirement, and the no-charge guarantee on timeout or invalid input. It also states the return shape, {answer, sources}.
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 what it does, then routing, then input guidance, then cost/return semantics. Every sentence carries distinct information; no restatement of the title or 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?
No output schema exists, yet the description names the return shape. Cost, latency, failure behavior, input guidance, and sibling routing are all covered, leaving no material gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a length constraint already documented, so the baseline is 3. The description exceeds that by explaining how to formulate q (single specific question, example phrasing) and the consequence of bundling questions.
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+output: 'Answers one open research question from the live web with a short written answer and source URLs'. It explicitly names the siblings it is not (bob_search, bob_factcheck) and the boundary condition for each, so an agent can select it without opening another 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 routing: 'Use it for a synthesized answer; use bob_search for raw links or bob_factcheck to verify a claim.' It also advises the input shape ('one specific question') and warns that multiple questions yield a blended answer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a web search and returns ranked results as {query, results: [{title, url, snippet}]}, usually in under a second. Use it when you want raw links to read yourself; use bob_research for a written answer. Plain phrases such as 'x402 payment protocol for AI agents' work as well as keywords; set since and until to limit results to a publish-date range, which suits recent news. Each call needs an x402 payment; if the search fails or finds nothing, you are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many results to return, 1 to 10. Default 5. | |
| q | Yes | The web search query, 1 to 500 characters. | |
| since | No | Optional. Only results published on or after this date, written YYYY-MM-DD, e.g. 2026-09-01. | |
| until | No | Optional. Only results published on or before this date, written YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description adds context they cannot: each call requires an x402 payment, failed or empty searches are not charged, and latency is typically under a second. Cost and billing-on-failure are exactly the kind of behavior an agent must know 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?
Front-loaded with the return shape, then routing guidance, then parameter tips, then billing. Four dense sentences with little waste, though the billing and latency clauses could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description supplies the return shape, so an agent knows what comes back. Combined with routing, query syntax, date filtering, latency, and payment semantics, nothing needed to call 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 coverage is 100%, so the parameters are already documented; the description still adds meaning by noting that plain phrases work as well as keywords and by characterizing since/until as a publish-date range suited to recent news. It does not restate the 1-10 bounds or date format, which the schema handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Runs a web search and returns ranked results') and even spells out the return shape {query, results:[{title,url,snippet}]}. It explicitly separates itself from the sibling bob_research, so an agent can route between them 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 an explicit when-to-use rule ('use it when you want raw links to read yourself') paired with the named alternative and its selection condition ('use bob_research for a written answer'). It further scopes usage with concrete advice on query phrasing and on using since/until for recent news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Condenses one public web page into an 80-word summary with up to 4 key points, returned as {url, summary, key_points}, usually in 3 to 6 seconds. Use it when you want the gist; use bob_extract to get the page's own text instead. Pages that need a login cannot be read. Each call needs an x402 payment; if the page cannot be read in time or the URL is invalid, it fails and you are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http or https address of the page to summarize; private or local addresses are refused. |
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 (3-6 seconds), the x402 payment requirement, the no-charge-on-failure guarantee, and the login-page limitation. This is exactly the extra behavioral detail the 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 tight sentences, each carrying distinct load: capability, routing rule, constraint, and cost/failure behavior. The most decision-relevant facts (scope, sibling routing) are front-loaded with zero 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 there is no output schema, the description itself describes the return shape ({url, summary, key_points}), plus timing, cost, and failure semantics. For a single-parameter read tool, 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?
Only one parameter, and the schema already documents it fully at 100% coverage, so the baseline is 3. The description reinforces the accessibility constraint (public pages only, invalid URLs fail) which slightly sharpens the url semantics, though it largely restates what the schema field already says about private/local addresses.
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 (condenses) and resource (one public web page) plus the concrete output form: an 80-word summary with up to 4 key points. It explicitly distinguishes itself from the closest sibling, bob_extract, 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 an explicit selection rule ('when you want the gist') and names the alternative with its contrasting use ('use bob_extract to get the page's own text instead'). It also states a hard exclusion (pages needing login cannot be read), which is exactly the when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bob_search3 fields changedInput schema / properties / nAdded value: +{
+ "default": 5,
+ "description": "How many results to return, 1 to 10. Default 5.",
+ "maximum": 10,
+ "minimum": 1,
+ "title": "N",
+ "type": "integer"
+}Input schema / properties / sinceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional. Only results published on or after this date, written YYYY-MM-DD, e.g. 2026-09-01.",
+ "title": "Since"
+}Input schema / properties / untilAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional. Only results published on or before this date, written YYYY-MM-DD.",
+ "title": "Until"
+}bob_extract1 field changedInput schema / properties / url / descriptionAdded value: +"Public http or https address of the page to extract; private or local addresses are refused."bob_factcheck1 field changedInput schema / properties / claim / descriptionAdded value: +"The factual claim to check, 1 to 500 characters, written as a statement."bob_research1 field changedInput schema / properties / q / descriptionAdded value: +"The research question to answer, 1 to 500 characters."bob_search1 field changedInput schema / properties / q / descriptionAdded value: +"The web search query, 1 to 500 characters."bob_summarize1 field changedInput schema / properties / url / descriptionAdded value: +"Public http or https address of the page to summarize; private or local addresses are refused."bob_extractbob_factcheckbob_researchbob_searchbob_summarizeLive web search and research synthesis for agents, with free samples and x402 USDC payments.
Pay-per-call AI tools over x402: web research, summarization, structured extraction (USDC, Base).
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
AI agents publish bounties for real-world tasks. Gasless USDC payments via x402.
Add one secure layer between your agents and this server.