KushBitx AgentProof

Token Risk

token_risk

Read-onlyIdempotent

Token-risk report for one Base ERC-20 contract. Checks whether the token can be sold (honeypot simulation), buy/sell/transfer tax, owner privileges (mint, pause, blacklist, balance changes, proxy upgrades), holder concentration and DEX liquidity. Returns ALLOW, WARN, BLOCK or INCOMPLETE with scored findings and per-check coverage. INCOMPLETE means required evidence was unavailable, never zero risk. Read-only: never signs or trades. Paid tool: 0.001 USDC per call on Base via x402 (exact scheme). An unpaid call returns the payment requirement and charges nothing.

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

Input Schema

Name	Required	Description	Default
`chain`	Yes	Blockchain network.
`address`	Yes	Base token contract address.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/destructive annotations: it discloses x402 exact-scheme pricing at 0.001 USDC on Base, that unpaid calls return the payment requirement and charge nothing, and that INCOMPLETE means missing evidence rather than zero risk. It also states it never signs or trades, reinforcing the safety profile with concrete operational detail.

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?

Front-loads what is checked, then the verdict vocabulary, then the INCOMPLETE caveat, then payment terms — every sentence carries distinct, load-bearing information with no restatement of the name or title.

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?

With no output schema, the description carries the return contract itself: ALLOW/WARN/BLOCK/INCOMPLETE plus scored findings and per-check coverage. Combined with the payment and read-only disclosures, an agent has everything needed to decide and to interpret the result.

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?

Schema coverage is 100% with a pattern-constrained address and a single-value chain enum, so the schema already does the work. The description adds only that the scope is one Base ERC-20 contract, which marginally reinforces the enum but adds no format or syntax detail beyond the schema.

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?

States a specific verb and resource — a token-risk report for one Base ERC-20 contract — and enumerates the exact dimensions checked (honeypot simulation, taxes, owner privileges, holder concentration, DEX liquidity). It does not name or differentiate against siblings like quick_check or preflight, so an agent must infer the split between the quick and full risk paths.

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

Usage Guidelines3/5

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

Implied usage is clear from the checks and verdicts (run this before interacting with a token), and it explains the INCOMPLETE case and the unpaid-call behavior. However, it never says when to pick this over quick_check or preflight, which are the obvious cheaper alternatives in the sibling set.

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

All KushBitx AgentProof tools Inspect

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

Need Help?