Skip to main content
Glama
telegraph-mcp

telegraph-mcp

Official

Find miners

telegraph_find_miners
Read-only

Find AI miners for a specific intent, ranked with status, price, and rank, or search miners by matching name or description keywords. Returns up to 100 results and is free.

Instructions

Miners for an intent, best-ranked first, with status, price and rank; or miners whose name or description match some words. Free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "telegraph_find_miners"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMost miners to return (default 20).
intentNoIntent name; lists that intent's miners with their rank.
searchNoWords every listed miner must match (slug, name, description).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description sensibly spends its words elsewhere: it discloses result ordering (best-ranked first), the returned fields (status, price, rank), and that the call is free. That is meaningful behavioral context beyond the annotations, though it does not say what happens when no parameters are supplied.

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?

A single dense sentence with the primary resource and behavior front-loaded and a semicolon separating the two modes. No filler, though the packing into one clause chain makes the two modes slightly harder to parse than separate sentences would.

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

Completeness3/5

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

With no output schema, naming the returned fields compensates usefully, and the ordering behavior is covered. However, all parameters are optional yet the description never explains the no-argument default, which is the main gap for a discovery tool with three optional inputs.

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 description coverage is 100%, so all three parameters are already documented including the default limit of 20. The description reinforces the intent-versus-search distinction but adds no syntax, matching, or combination semantics beyond the schema, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (miners) with two clear retrieval modes: by intent, or by name/description word match. The returned fields (status, price, rank) are also named. It does not name a sibling to differentiate from, notably telegraph_ask_miner and telegraph_ranking, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied by the two parameter-driven modes; the description never says when to use intent lookup versus keyword search, nor when to use this instead of telegraph_ask_miner or telegraph_ranking. There are no exclusions or prerequisites, leaving the agent to infer routing.

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