Skip to main content
Glama
Sign In
telegraph-mcp

telegraph-mcp

Official
by telegraphprotocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Ask one miner

telegraph_ask_miner

Ask a specific miner by ID or slug instead of letting the node choose, sending a question with intent or calling its endpoint directly with method and payload. No fallback miner is tried.

Instructions

Ask one specific miner (by id or slug from telegraph_find_miners) instead of letting the node pick. Send a question (with intent when the miner serves several), or call one of its endpoints directly with endpoint, method and payload (the raw answer comes back). No fallback miner is tried. Paid like telegraph_ask, at that miner's price.

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": {
      "miner": "<miner>"
    },
    "name": "telegraph_ask_miner"
  }
}

Input Schema

NameRequiredDescriptionDefault
minerYesMiner id or slug.
intentNoOptional exact intent, e.g. CRYPTO_PRICE_USD (see telegraph_find_intents). Only that intent's miners answer.
methodNoDirect call: HTTP method (default GET).
paramsNoOptional params for the intent, as telegraph_intent lists them, e.g. {"location": "Lahore"}. Needs intent.
payloadNoDirect call: the body or query fields the endpoint takes.
endpointNoDirect call: the miner's endpoint path, e.g. /query (telegraph_find_miners lists them).
questionNoThe question, in plain words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.3/5.0
Behavior4/5

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

The annotations only cover safety flags, and the description genuinely adds operationally relevant behavior: no fallback miner is attempted, the call is paid at that miner's own price, and the raw endpoint answer is returned unprocessed. These are non-obvious consequences an agent needs before committing. It does not describe failure behavior when the chosen miner is unavailable, which keeps it off a 5.

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 dense sentences, front-loaded with the distinguishing scope before the operational details (no fallback, price). Every sentence carries information, though the heavy parenthetical stacking makes it slightly harder to parse than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter tool with nested objects, an open-world flag, and no output schema, the description covers what matters: miner selection source, the two calling conventions, cost, and the absence of fallback. It leaves out error behavior for unreachable miners and whether intent is required when using question, minor gaps against an otherwise solid definition.

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%, so the baseline is 3, but the description adds real semantic structure the schema does not convey: it explains that the seven parameters form two distinct modes (question/intent/params versus endpoint/method/payload) and that the raw answer comes back in the direct-call case. That mode distinction is the main source of invocation error and the description addresses it.

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?

The description gives a concrete verb and resource ('Ask one specific miner') and immediately scopes it with 'by id or slug from telegraph_find_miners instead of letting the node pick,' which sharply distinguishes it from the sibling telegraph_ask that auto-selects a miner. An agent can choose 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.

Usage Guidelines4/5

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

It states the two invocation modes explicitly (send a question, optionally with intent, versus direct endpoint/method/payload call) and contrasts with the node-picking alternative. It also references telegraph_find_miners and telegraph_find_intents for obtaining the required identifiers, but it never spells out a negative case such as 'do not use when you don't care which miner answers' beyond the implicit contrast.

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

Deploy Server

Other Tools