Skip to main content
Glama
Neurobyteio

AgentRisk MCP

Official
by Neurobyteio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AgentRisk MCP

Stop your AI agent from getting rekt. The pre-trade safety net it didn't know it needed — until it almost bought a honeypot. Live sell simulation across every DEX on Base (Uniswap V2/V3/V4, Aerodrome), catching traps a static code scan will never see.

What it does

An MCP server that gives any MCP-compatible agent (Claude, Cursor, and others) a check_token_risk tool. Before your agent trades a token on Base, it can call this tool to get:

  • Honeypot detection

  • Deployer wallet freshness

  • Brand impersonation checks

  • On-chain LP-lock verification

  • Live sell simulation across Uniswap V2/V3/V4 and Aerodrome

  • A risk score, risk level, and clear should-trade decision

Related MCP server: Crest Counterparty Intelligence

Install

npm install -g agentrisk-mcp

Usage with Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "agentrisk": {
      "command": "npx",
      "args": ["-y", "agentrisk-mcp"]
    }
  }
}

Pricing

Paid per call via the x402 protocol, 0.15 USDC on Base, no API key, no subscription. Free public checks at agentrisk.dev (3 free scans per wallet).

Links

Website: https://agentrisk.dev API repo: https://github.com/Neurobyteio/agentrisk

Available Tools

1 tool
check_token_riskA

Checks whether a token on Base is safe to trade before buying or swapping. Runs honeypot detection, deployer wallet history, brand impersonation checks, on-chain LP-lock verification, and a live sell simulation across every DEX on Base (Uniswap V2/V3/V4, Aerodrome). Returns a risk score, risk level, and a clear should-trade decision with structured reasons. Requires x402 payment (0.15 USDC on Base) unless the wallet still has free trial checks remaining.

ParametersJSON Schema
NameRequiredDescriptionDefault
token_addressYesBase ERC-20 contract address (0x...)

TDQS

A4.5/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 burden. It discloses the internal checks (honeypot, deployer history, impersonation, LP-lock, live sell simulation), the return value (risk score/level/should-trade decision with structured reasons), and the cost (0.15 USDC via x402, free trials). This is comprehensive transparency beyond a typical tool description.

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?

The description is three dense sentences: purpose first, then method details, then payment terms. No filler, and the most important decision-relevant info (safe to trade, payment) is prominently placed.

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?

For a single-parameter tool with no output schema, the description fully covers what input is needed, what operations will be performed, what result shape to expect, and the cost constraint. An agent can decide whether to use it and invoke it correctly. The only minor omission is how the x402 payment is initiated, but that is likely handled outside the tool call.

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 schema already documents token_address as 'Base ERC-20 contract address (0x...)' with 100% coverage. The description reinforces the Base network context but adds no new parameter-level meaning, so it stays at the schema-coverage baseline of 3.

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?

The description opens with a clear verb (checks), resource (token on Base), and purpose (safe to trade before buying or swapping). It then enumerates the specific checks performed, making the scope concrete. No sibling differentiation is needed because no sibling tools exist.

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?

The description explicitly states when to use: before buying or swapping a Base token. It does not mention alternatives or exclusions, but with no sibling tools that is not a significant gap. The payment requirement also implies a usage consideration, which is useful context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedcheck_token_risk
Deploy Server
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

TDQS

A4.5/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is uniquely defined.

Naming Consistency5/5

The tool name follows a clear verb_noun pattern ('check_token_risk'), and with only one tool there are no inconsistent naming conventions to flag.

Tool Count3/5

A single tool feels thin for a server, even though the tool itself is comprehensive and well-scoped. It sits at the borderline of being too few, but the tool's depth partially compensates for the lack of additional tools.

Completeness5/5

For the stated purpose of token risk checking on Base, the tool covers a wide range of critical checks including honeypot detection, deployer history, impersonation, LP-lock verification, and live sell simulation. It provides a clear decision, leaving no obvious dead end within its domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • basescope

    chasdaddy
    A
    license
    A
    quality
    D
    maintenance
    basescope is a read-only onchain safety layer for AI agents: it answers "is this token/contract/approval safe?" on Base and EVM chains (honeypot/rug checks, risky-approval detection, verified-source lookup, balances, ENS/Basenames, gas, prices), with no private keys and no required API keys.
    13
    7 npm
    1
    MIT