Skip to main content
Glama

Rug-check a Robinhood Chain token

rugcheck_robinhood
Read-only

Risk score (0-100) for an ERC-20 token on Robinhood Chain (chain id 4663): verified source, upgradeable proxy, owner, mint/blacklist/fee functions, holder concentration (contracts such as pools are left out) and, when known, the Uniswap v4 pool hook. Automated on-chain checks, not financial advice.

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": {
      "token": "<token>"
    },
    "name": "rugcheck_robinhood"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokenYesToken contract address (0x...)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description goes further by disclosing exactly which on-chain traits are inspected, that holder concentration excludes contracts such as pools, and that the Uniswap v4 hook is only included 'when known' (a coverage caveat). It stops short of stating latency, caching, rate limits, or how the score is composed, which keeps it below 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence front-loads the deliverable (risk score 0-100) and chain scope before the factor list and the disclaimer. No sentence is redundant and nothing is buried.

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?

With one parameter, no output schema, and safety annotations present, the description covers what is needed: scope, chain, scoring inputs, and an explicit disclaimer. The only residual gap is the exact response shape (whether per-factor detail is returned alongside the score), which is not explained.

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% for the single required address parameter, so the baseline is 3. The description adds real meaning by pinning the token to chain id 4663, telling the agent that an address from another chain is invalid input — context the regex pattern cannot convey.

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 states a specific resource and operation: a 0-100 risk score for an ERC-20 token on Robinhood Chain (chain id 4663), and enumerates the factors scored (verified source, proxy, owner, mint/blacklist/fee functions, holder concentration, Uniswap v4 hook). The explicit chain id implicitly separates it from the sibling 'rugcheck', but no sibling is named, so an agent must infer which chain the other rugcheck targets.

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?

There is no when-to-use or when-not-to-use guidance and no reference to alternatives such as 'rugcheck' for other chains or 'safe_buy'/'latest_launches_robinhood' in a token-screening flow. 'Automated on-chain checks, not financial advice' is a disclaimer, not usage guidance, so the agent gets no routing help.

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.

Resources