Skip to main content
Glama

Get one verified bot

get_bot
Read-onlyIdempotent

Return one entry from the bot catalog by exact id. Output is that entry alone, not wrapped in entries or count: id, name, maker, description, protocols (strings), url, license (string or null), license_verified, license_url (string or null), verified_at (YYYY-MM-DD), http_status (integer or null), archive_url (string or null), funds_or_keys, and notes. funds_or_keys is true when the software can access a wallet or keys. Parameter id is required. It must equal list_bots entries[].id. Catalog ids are lowercase letters, digits, and hyphens. Example: lnget. Do not include the bot: prefix that list_changes uses; strip it first. A missing id is rejected as invalid input. An unknown id returns isError with text No bot with id . A failed read of /bots.json returns isError. The text is the Error message (Fetch failed when the HTTP status is not OK), or Bot lookup failed. when the failure is not an Error. Use get_bot instead of list_bots when you already have one id. Use list_bots instead when you need the catalog, the count, the disclaimer, or the inclusion rule, or when you do not know the id. Use search_sources instead for papers and docs about agents. Listed, not endorsed. Free, no auth.

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": {
      "id": "<id>"
    },
    "name": "get_bot"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesRequired. Exact entries[].id from list_bots. Catalog ids are lowercase letters, digits, and hyphens. Example: lnget. Do not include the bot: prefix that list_changes uses; strip it first. A missing id is invalid input. Any other string that is not in the catalog returns isError text No bot with id <id>.

Output Schema

NameRequiredDescriptionDefault
idYes
urlYes
nameYes
makerYes
notesYes
licenseYes
protocolsYes
archive_urlYes
descriptionYes
http_statusYes
license_urlYes
verified_atYes
funds_or_keysYes
license_verifiedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that list_changes uses."New value: +"Required. Exact entries[].id from list_bots. Catalog ids are lowercase letters, digits, and hyphens. Example: lnget. Do not include the bot: prefix that list_changes uses; strip it first. A missing id is invalid input. Any other string that is not in the catalog returns isError text No bot with id <id>."
  2. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that changes_since uses."New value: +"Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that list_changes uses."
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the description isn't obligated to re-state safety. It adds genuinely new behavioral context: unwrapped return shape, the missing-id vs unknown-id distinction, the specific isError texts, and the upstream /bots.json failure modes. The full enumeration of return fields is somewhat redundant given an output schema exists.

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

Conciseness3/5

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

Front-loaded with purpose and the usage routing sentence is well placed. However, the long comma-separated enumeration of every return field plus the duplicated id rules from the schema take up substantial space that the output schema and input schema already cover, diluting the value-dense parts.

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?

For a single-parameter lookup tool it covers everything an agent needs: exact id contract, unwrapped output expectation, both input-validation and lookup failure outcomes with literal error strings, and upstream fetch failure. Nothing required 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.

Parameters3/5

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

Schema coverage is 100% and the schema already spells out the exact-id semantics, the lowercase/digit/hyphen format, the lnget example, the bot: prefix stripping, and the error on unknown ids. The description largely restates it, adding no syntax or format detail beyond the schema; baseline 3 is right.

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 (return one bot catalog entry by exact id) and explicitly contrasts with list_bots and search_sources. An agent can distinguish it from every sibling 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 Guidelines5/5

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

Names concrete alternatives and the exact conditions that select them: use get_bot when you already have one id; use list_bots for the catalog/count/disclaimer/inclusion rule or when the id is unknown; use search_sources for papers and docs. Exclusions and preconditions are explicit.

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