Skip to main content
Glama

ton_gram

GRAM/TON network snapshot: GRAM price + USD₮-on-TON stablecoin footprint (holders, supply) — the size of the 1B-user Telegram economy. Send {}. [x402 paid tool — price $0.002; POST /api/ton/gram]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions the tool is paid ($0.002, POST) but does not state whether it is read-only or describe any side effects. 'Send {}' is ambiguous and does not clarify safety.

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?

The description mixes core purpose with marketing fluff ('size of the 1B-user Telegram economy') and technical metadata (price, endpoint). It is somewhat verbose for a zero-parameter tool but still front-loaded with the main action.

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?

For a snapshot tool with no output schema, the description sufficiently explains what data is returned (price, holders, supply). However, it lacks details on data format, units, or whether it's a single value or time series, leaving room for agent confusion.

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?

Since there are no parameters, the schema coverage is trivially 100%. The description does not need to add parameter meaning; baseline 4 applies as per scoring rules.

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?

The description clearly states the tool provides a snapshot of GRAM price and USD₮ stablecoin footprint (holders, supply), distinguishing it from simpler siblings like ton_price or ton_jetton_holders. However, the inclusion of 'Send {}' is confusing and the exact output format is vague.

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

Usage Guidelines2/5

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

The description hints at an economic context ('1B-user Telegram economy') but provides no explicit guidance on when to use this tool versus alternatives like ton_price or ton_jetton_holders. No when-not or prerequisite information is given.

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.