Skip to main content
Glama
Sign In

Toll — coin, agent and pre-sign checks on Robinhood Chain

by xyz.t0ll
OverviewDiscussionsAdmin

Gate before a buy

pre_buy_check
Read-onlyIdempotent

Use it when someone is about to buy a coin and asks "should I buy this?" or "should I ape this?": Toll answers with facts, not advice. One call before buying a coin on Robinhood Chain: Toll reads the coin (the same read as check_coin, counted in the same free coins) and answers Decision: BLOCK / WARN / ALLOW / WAIT with up to 3 reasons, most severe first, on the calibrated rules check_tx uses (BLOCK = a finding whose coins rugged at 40% or more within 24 h in Toll's calibration, or sells that fail). WAIT means part of the coin is still being read: call again after the seconds given. Facts, not advice; ALLOW means nothing against was found in what was read, never a promise. Robinhood Chain only.

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": {
      "address": "<address>"
    },
    "name": "pre_buy_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesThe token contract address you are about to buy on Robinhood Chain: 0x followed by 40 hex characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining the decision vocabulary (BLOCK tied to coins that rugged 40%+ within 24h or failed sells), that WAIT means a partial read needing a re-call, that ALLOW is 'nothing against was found' rather than a promise, and that the read counts against the same free-coin quota. These are behavioral traits annotations cannot express, and nothing contradicts readOnly/idempotent/non-destructive.

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?

Front-loaded with the use case and the decision output, which is the right order, and most sentences carry unique information. Minor redundancy: 'facts, not advice' is asserted twice, and the calibration explanation is dense enough to require a second read.

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 does the work of explaining the return value (decision plus up to 3 severity-ordered reasons) and the WAIT re-call loop. For a one-parameter read tool, an agent has everything needed to invoke and interpret it.

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?

Single required parameter with 100% schema description coverage, so the schema already explains the 0x-prefixed 40-hex contract address. The description repeats the 'coin you are about to buy on Robinhood Chain' framing but adds no format, constraint, or edge-case detail beyond that.

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 verb and resource: it gates a token purchase on Robinhood Chain and returns a Decision of BLOCK/WARN/ALLOW/WAIT. It also positions itself against siblings by noting it performs 'the same read as check_coin' and applies 'the calibrated rules check_tx uses', so an agent can tell what is distinct about this call.

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 a concrete trigger ('when someone is about to buy a coin and asks should I buy this / should I ape this') and timing ('one call before buying'), plus a retry instruction for WAIT. It lacks an explicit when-not beyond the 'Robinhood Chain only' scope line, and does not directly say to prefer check_coin for non-purchase reads.

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

All Toll — coin, agent and pre-sign checks on Robinhood Chain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources