Skip to main content
Glama

Toll

Many coins at once

check_coins
Read-only

Up to 20 Robinhood Chain coins in one call, answered only from checks Toll already holds (read in the last 24 h): for each coin the verdict word (AGAINST / CAREFUL / CLEAR / INCOMPLETE) with its tally and how old the read is, or "not read yet". Reads nothing new and uses no free coin. For a coin not read yet, call check_coin or pre_buy_check.

Input Schema

NameRequiredDescriptionDefault
addressesYesToken contract addresses on Robinhood Chain, 1 to 20 (0x followed by 40 hex characters each)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses the 24-hour cache window, that stale entries return "not read yet", the exact verdict vocabulary (AGAINST / CAREFUL / CLEAR / INCOMPLETE) with tally and read age, and that no credits are consumed. This is the kind of context annotations cannot convey.

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?

One dense paragraph, front-loaded with the scope and the cache-only constraint before the return shape and the fallback route. Every clause carries information, though the parenthetical about the 24 h window slightly interrupts the flow.

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?

No output schema exists, so the description carries the return contract and does so fully: verdict word, tally, and read age per coin, plus the "not read yet" state. Combined with the cache/no-cost behavior, an agent has everything needed to call and interpret it.

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 address format is already documented; the description nevertheless adds the meaningful cap of 20 coins per call. That cap conflicts with the schema's maxItems: 100, which could confuse an agent about the true limit, costing it a point.

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 concrete verb and resource: return verdicts for up to 20 Robinhood Chain coins in one call, served only from Toll's existing cached checks. It also distinguishes itself from single-coin siblings by naming check_coin and pre_buy_check as the route for unread coins.

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?

Explicitly says it reads nothing new, spends no free coin, and that unread coins should go to check_coin or pre_buy_check. The one gap is that it never states the batch-scan scenario is preferable to looping check_coin, so the choice for a single coin remains implied rather than stated.

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.