Skip to main content
Glama

Bob Research Tools

bob_research

Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesThe research question to answer, 1 to 500 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / q / description
      Added value: +"The research question to answer, 1 to 500 characters."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources