Skip to content

dev.vetagent/vetagent

by vetagent.dev · remote · no sign-in to list tools · v0.2.0 · published by dev.vetagent

Pre-trade safety check for AI agents: honeypot, tax, liquidity and rug risk before you buy.

Changes · 1

3 tools: 1 change things and 2 only read.

Scanned Oct 21, 2026

1 check matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http vetagent https://vetagent.dev/mcp

Findings

Matches of fixed checks, with the text they matched.

1 info
  • The description is 2,174 characters long, over the 2,000 this check looks for.

    Matched text

    description ends: "...'low' as 'no fatal signal found in the checks that ran', never as 'safe to buy'."

    What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

3 tools

Changes things 1Claude Code: ask
  • assess_token_riskSafety check to run BEFORE buying, holding, or recommending a token.1 finding

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.

    Findings

    • Info

      The description is 2,174 characters long, over the 2,000 this check looks for.

      Matched text

      description ends: "...'low' as 'no fatal signal found in the checks that ran', never as 'safe to buy'."

      What this check looks for
    Description, as the server wrote it
    Safety check to run BEFORE buying, holding, or recommending a token. Returns an actionable verdict (low / medium / high / unknown), a 0-100 risk score, and the individual signals behind it. Covers on every chain: liquidity depth, trading-pair age, cross-chain presence, same-ticker impersonation. Covers on Ethereum, BSC and Base only: sell simulation (honeypot detection, buy/sell/transfer taxes), whether the contract is open source, and the aggregate verdicts of upstream security scanners. Covers on Solana: the mint/freeze authority, the RugCheck score, and the SPL Token-2022 extension block -- non-transferable, frozen-by-default, transfer fee (with its cap), permanent delegate, transfer hook, pausable, close authority, scaled balances and interest-bearing balances. Every other extension the report carries is named in the answer with the reason it is not scored, so silence about one means it was considered, not that it went unread. No sell simulation runs on Solana, nor on the four other EVM chains accepted as a chain_hint (polygon, arbitrum, optimism, avalanche): nothing there tests whether a holder can sell, so the answer comes back 'unknown' rather than 'low'. No holder concentration on any chain -- on EVM it needs an oracle the benchmark holds out, and on Solana the upstream omits holders. IMPORTANT: risk_level 'unknown' means a critical check could not be completed. It is NOT a low-risk result and must not be used to justify a trade; evidence.data_gaps lists exactly what was missing, and unknown_kind says whose gap it is: 'infrastructure' and 'mixed' mean an upstream of ours failed and come with next_action 'retry' and retry_after_seconds (in a 'mixed' answer the rest was worked out without that upstream, so the retry can change any of it); 'coverage' comes with 'abstain'. 'confidence' measures how complete the input data was, not how safe the token is. Reports observable on-chain risk only. Not financial advice, does not size positions, and cannot see off-chain risk such as team behaviour, social engineering, or a rug executed through governance. Treat 'low' as 'no fatal signal found in the checks that ran', never as 'safe to buy'.

    Annotations the server declares

    • readOnlyHint: true
    • openWorldHint: true
    • destructiveHint: false
    • idempotentHint: true
Only reads 2Claude Code: allow
  • find_new_hot_poolsScan a chain for the newest and most active trading pools, returning name, token_address, price, liquidity, 24h volume and pool age.No findings

    Why it is in this group

    • The name "find_new_hot_pools" says "find": a word for reading.
    Description, as the server wrote it
    Scan a chain for the newest and most active trading pools, returning name, token_address, price, liquidity, 24h volume and pool age. Discovery only. New pools carry inherently high risk and appearing here is NOT a safety endorsement — pass token_address straight to assess_token_risk for anything you intend to act on.

    Annotations the server declares

    • readOnlyHint: true
    • openWorldHint: true
    • destructiveHint: false
    • idempotentHint: false
  • get_token_liquidityLiquidity snapshot for a token's primary trading pair: price, 24h volume, pair count and the chains it trades on.No findings

    Why it is in this group

    • The name "get_token_liquidity" says "get": a word for reading.
    Description, as the server wrote it
    Liquidity snapshot for a token's primary trading pair: price, 24h volume, pair count and the chains it trades on. Check 'status' before using the numbers. 'ok' means usable upstream data, not independently verified reserves or executable sell depth. The optional liquidity_reserve_check marker says 'not_checkable' when a positive selected estimate has no computable reserve cap. A missing marker never asserts that reserves, prices or an exit trade were independently verified. 'unavailable' means the upstream request failed, which does NOT mean the token has no liquidity. 'not_found' means no trading pair exists for this address at all. 'unpriced' means pairs exist but no source has costed them, so liquidity_usd is null and the depth is unknown -- this is NOT a report of zero liquidity. 'drained' means every pool on the token's own chain reports its depth and every one is empty: there is nothing to sell into.

    Annotations the server declares

    • readOnlyHint: true
    • openWorldHint: true
    • destructiveHint: false
    • idempotentHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 0.2.0. Values in angle brackets are yours to fill in.

claude mcp add --transport http vetagent https://vetagent.dev/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__vetagent__get_token_liquidity",
      "mcp__vetagent__find_new_hot_pools"
    ],
    "ask": [
      "mcp__vetagent__assess_token_risk"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as vetagent. Review it before you use it.