Skip to main content
Glama
parkyucheol-del

AlphaPipeline

by parkyucheol-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

security.token_risk

Check a token contract for honeypot and scam risks before buying. Get buy/sell tax, mintability, ownership status, and a summarized risk level with flags.

Instructions

Check a token contract for honeypot/scam risk before buying: is_honeypot,
buy/sell tax, mintability, open-source status, ownership renouncement,
holder count, individual GoPlus risk signals (cannot_buy, cannot_sell_all,
hidden_owner, transfer_pausable, selfdestruct, is_blacklisted,
slippage_modifiable, owner_percent - all feed into risk_flags), is_proxy
and trading_cooldown (informational only, not flagged - both are common in
legitimate contracts), and a summarized risk_level (LOW/MEDIUM/HIGH/UNKNOWN).
Data source: GoPlus Security, falling back to Honeypot.is (the GoPlus-only
fields above are always null on the fallback path).

Use this right before entering a position on an unfamiliar or newly-listed
token. Do NOT treat a null field as "safe" - it means that field could not
be determined; check risk_level and risk_flags instead. This tool does not
cover LP lock/burn status - use get_contract_health_audit for that, or
get_token_diagnostic to get both in one call.

Args:
    chain_id: EVM chain id, e.g. 8453 for Base.
    contract_address: Token contract address (0x...).

Returns:
    On success: {"success": true, "is_honeypot", "buy_tax_pct", "sell_tax_pct",
        "risk_level", "risk_flags", ...}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chain_idYes
contract_addressYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.3

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the GoPlus/Honeypot.is fallback, explains that fallback-only fields are null, warns not to treat null as safe, and identifies which fields are informational vs risk-flagged. It also documents the success/failure return envelope.

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?

The description is long because the tool has many output fields, but information is front-loaded and organized into purpose, data source, usage guidance, args, and returns. A few clauses could be tightened, but none are filler.

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?

Given no output schema and no annotations, the description covers everything an agent needs: purpose, when to use, how to interpret nulls, data source fallbacks, limitations/alternatives, argument semantics, and the success/failure return shape. There are no obvious gaps for calling this tool correctly.

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 0%, so the Args section must explain the parameters. It correctly describes chain_id as an EVM chain id with a concrete Base/8453 example and contract_address as a 0x... token address. This is sufficient for correct invocation, though it does not go into broader constraints such as supported chain lists or address canonicalization.

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 action ('check a token contract for honeypot/scam risk') on a concrete resource and immediately lists what it evaluates. It also distinguishes itself from adjacent siblings like security.contract_health_audit and security.token_diagnostic by naming what they cover instead.

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

Usage Guidelines5/5

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

Explicitly says when to use the tool: 'right before entering a position on an unfamiliar or newly-listed token.' It also gives a clear negative condition, noting LP lock/burn status is not covered and directing the agent to get_contract_health_audit or get_token_diagnostic instead.

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

Deploy Server

Other Tools