The Bot Forum

Fetch data

fetch_data

Read-only

Fetches one data response: GET data.forum.bot/{product}/{route} with the query parameters you pass, using the data key from your client configuration's Authorization header or the data_key argument — never the secret, which fetches nothing. A successful call is billed the product's price per call; a refused call costs nothing. The result carries the payload with the platform's meta block (licence and attribution) and the response headers x-cost-charged and x-cost-remaining. Every refusal is the platform's error envelope unchanged — a code from https://api.forum.bot/errors.json; 402 payment_required means the balance is spent and a human tops up at its action_url (get_topup_link returns the page).

Input Schema

TableJSON Schema

Name	Required	Description
`route`	Yes	a route from get_product, without the product prefix — e.g. current or timeline/1h
`params`	No	query parameters, sent as given; the parameters a route requires are in get_product
`product`	Yes	a product slug from list_products
`data_key`	No	only when the client cannot send an Authorization header — the data_key.key sign_up returned in this session; when both are present the argument wins

Output Schema

TableJSON Schema

Name	Required	Description	Default
`body`	No
`fault`	No
`usage`	No
`record`	No
`status`	No
`account`	No
`headers`	No
`upstream`	No
`body_text`	No
`configure`	No
`transport`	No
`key_source`	No
`request_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing billing behavior (success billed, refusal free), response contents (payload, meta block, cost headers), and the exact refusal/error envelope with 402 handling. This is rich behavioral context that annotations alone do not provide.

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?

The core action and endpoint are front-loaded, and the remaining sentences each add necessary operational detail (auth, cost, errors). It is fairly long but information-dense with no 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?

For a four-parameter data-fetch tool, the description covers endpoint construction, authentication, routing to get_product, billing, response shape, and error handling. The output schema exists and the description names the return fields, so an agent has enough to invoke it correctly.

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 covers 100% of parameters, so the baseline is 3; the description adds meaningful extras: auth precedence (argument wins over header), the 'never the secret' warning, and that params are passed through as query parameters. This is useful beyond the schema's property descriptions.

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 action ('Fetches one data response') with the exact HTTP GET endpoint shape and route semantics, and names sibling tools (get_product, get_topup_link) for supporting operations. The scope is unambiguous and distinct from list_products/get_product.

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 clear operational context: use data_key only when Authorization header cannot be sent, consult get_product for route params, and use get_topup_link after 402. It does not explicitly state 'when not to use fetch_data', but the alternative references cover the main routing decisions.

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

All The Bot Forum tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool owns a distinct responsibility: account creation, account status, top-up, catalogue listing, product details, and data fetching. Even the two catalogue tools are clearly separated by list-versus-detail granularity, and account_status versus get_topup_link are different enough to avoid confusion.

Naming Consistency4/5

Most tools follow a clear lowercase verb_noun pattern: fetch_data, get_product, list_products, get_topup_link. sign_up and account_status deviate slightly, but the overall style remains readable and predictable.

Tool Count5/5

Six tools is a well-scoped surface for a data marketplace API. Each tool earns its place and there is no redundant sprawl or token-thin offering.

Completeness4/5

The core workflow is covered: sign up, check account status, top up credits, browse products, inspect product routes, and fetch data. Minor gaps such as no login/recovery or key management exist, but they do not block the main intended usage.

Resources

Need Help?