Skip to main content
Glama
parkyucheol-del

AlphaPipeline

by parkyucheol-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

security.contract_health_audit

Audit a token contract's LP lock and burn status via GoPlus to check if liquidity is locked, burned, or concentrated in unlocked wallets before trusting it.

Instructions

Audit LP lock/burn status for a token contract (GoPlus): lp_locked_pct,
lp_burned_pct, top_unlocked_holder_pct (largest single non-locked holder)
and top5_unlocked_holder_pct (top 5 non-locked holders summed, catches
multi-wallet concentration the single-holder field misses), rolled up
into a liquidity_health category (LOCKED / PARTIALLY_LOCKED / UNLOCKED /
NO_LP_DATA). A key rug-pull signal that get_token_risk does not cover.

Use this to check whether a token's liquidity is locked, burned, or freely
held by a single wallet before trusting it - complements, not replaces,
get_token_risk (honeypot/tax/mint checks). Deliberately does NOT include any
qualitative "suspicious transaction" judgment, only GoPlus's own numbers, and
has no fallback if GoPlus fails (Honeypot.is does not expose LP lock data).

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

Returns:
    On success: {"success": true, "lp_locked_pct", "lp_burned_pct",
        "liquidity_health", ...}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

NameRequiredDescriptionDefault
chain_idYes
contract_addressYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.3

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it names the upstream source (GoPlus), discloses the deliberate scope exclusion (no qualitative 'suspicious transaction' judgment), and warns there is no fallback when GoPlus fails. It stops short of stating auth/permission requirements or rate limits, but for a read-only audit the gaps are minor.

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?

Well front-loaded: purpose and the sibling differentiation come first, with Args/Returns clearly sectioned. The parenthetical explaining why top5 catches multi-wallet concentration is slightly verbose but justifies its place by clarifying a non-obvious field.

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?

Despite no output schema, the description documents both the success shape (field names plus the liquidity_health category values) and the failure shape (error.type/message). An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully – and it does, documenting both required params with format hints ('EVM chain id, e.g. 8453 for Base' and 'Token contract address (0x...)'). This is meaning genuinely absent from the bare 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?

Opens with a specific verb+resource ('Audit LP lock/burn status for a token contract') and enumerates the exact fields it returns. It explicitly positions itself against get_token_risk, so an agent can distinguish it from security.token_risk and security.token_diagnostic without opening any schema.

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?

States exactly when to use it ('check whether a token's liquidity is locked, burned, or freely held by a single wallet before trusting it') and how it relates to the alternative ('complements, not replaces, get_token_risk'). It even names the trigger condition for the sibling (honeypot/tax/mint checks), which is textbook routing guidance.

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