BotInfo — Advanced Robot Market Data

Get BotInfo's sourced evidence on a robot

robot_evidence

Read-onlyIdempotent

Get the findings of BotInfo's public evidence page on a robot model: what the maker's own spec sheets, SDK code, CVE records, government rules and purchase records show, each finding with its source URLs (code pinned to a commit), the date it was read, and a grade (checked = reopened by a second reviewer; our data; our inference). Use it when someone is deciding whether to buy, run or build on a robot and needs dated, citable facts rather than marketing claims. Text is quoted verbatim from the public page (CC BY 4.0, credit BotInfo.ai with the page link). If no page exists for the model, the reply lists the robots that have one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "robot": "<robot>"
    },
    "name": "robot_evidence"
  }
}

Input Schema

Name	Required	Description	Default
`robot`	Yes	Robot model, e.g. 'Unitree G1' or 'g1'

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare a safe, read-only, idempotent, open-world read, so the bar is lower, yet the description still adds substantial context: findings are quoted verbatim, carry source URLs with code pinned to a commit and a read date, and are graded by reviewer status. It also discloses the licensing/attribution obligation (CC BY 4.0, credit BotInfo.ai with the page link) and the empty-result behavior, none of which 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.

Conciseness4/5

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

Three sentences, front-loaded with the verb and resource, then the use case, then licensing and fallback. The grade taxonomy parenthetical is dense but informative; a small amount of nesting could be trimmed without loss.

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, so the description carries the return-value burden and does so: each finding includes source URLs, commit pinning, read date, and a grade, plus what happens when no page exists. For a one-parameter read tool this leaves nothing an agent needs missing.

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

Parameters3/5

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

The single parameter is fully documented in the schema (100% coverage) with an example including an abbreviated form ('Unitree G1' or 'g1'). The description adds only that the model may lack a page, which concerns results rather than parameter syntax, so the baseline 3 applies.

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 and resource: get the findings of BotInfo's public evidence page on a robot model, and enumerates what those findings cover (spec sheets, SDK code, CVE records, government rules, purchase records). This is clearly distinct from siblings like lookup_robot or check_us_legality, which the agent can rule out 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.

Usage Guidelines4/5

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

Gives an explicit use case: when someone is deciding whether to buy, run or build on a robot and needs dated, citable facts rather than marketing claims. It also describes the fallback path when no page exists. It stops short of naming which sibling to use instead for adjacent needs (e.g. legality checks or pricing), so it is clear context rather than full routing guidance.

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

All BotInfo — Advanced Robot Market Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?