Skip to main content
Glama

Rug-pull check

robinhood_token_safety
Read-only

Check a Robinhood Chain token for rug-pull risk before swapping: get a 0-100 score, red flags, good signs, and a plain-English verdict.

Instructions

TypeAI rug-pull check for a Robinhood Chain token: a 0-100 risk score and level, red flags (honeypot, taxes, unlocked liquidity, mintable supply, holder concentration...), good signs, and a plain-English verdict. Run this before any swap.

Input Schema

NameRequiredDescriptionDefault
tokenYesToken symbol, name or 0x contract address on Robinhood Chain, e.g. TORCH

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description's burden is lighter. It still adds real value by disclosing the shape of the result (0-100 score, level, red flags, good signs, plain-English verdict) — important because there is no output schema. Auth needs and rate limits are unstated.

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 sentence, front-loaded with the purpose, then the return contents, then the call-to-action. Dense but no filler. The parenthetical flag list is long yet each item clarifies the tool's detection scope.

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 no output schema, the description appropriately spends its words on expected return contents, which is the main gap it must cover. Missing are failure modes (unknown token, ambiguous symbol) and whether the score is cached or real-time — minor for a read-only lookup.

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?

The single parameter has 100% schema coverage, including accepted forms (symbol, name, or 0x address) and an example, so the schema does the heavy lifting. The description adds nothing about the parameter beyond what the schema documents; the parenthetical example 'TORCH' belongs only in the schema.

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 ('rug-pull check for a Robinhood Chain token') and enumerates exactly what the result contains: risk score, flags, good signs, verdict. This clearly separates it from siblings like robinhood_token_info, which reads as informational rather than risk-evaluating.

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 explicit timing guidance ('Run this before any swap'), which effectively routes the agent away from robinhood_swap_quote/prepare_swap until this has run. It doesn't name an alternative or state when the check can be skipped, so it stops short of full when/when-not coverage.

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