vetagent

Server Details

Pre-trade token safety check for AI agents. Simulates a sell before you buy, then returns one low/medium/high/unknown verdict with the signals behind it: sellability, buy/sell tax, liquidity depth, pair age, same-ticker impersonation, owner powers from bytecode. Ethereum, BSC, Base, Solana. Fail-closed - a check that cannot run answers unknown, never low. Publishes its own measured error rate with the benchmark harness in the repo. Free, no signup, no API key, MIT.

Ownership verified

Status: Healthy
Uptime: 100.0% over 23 days
Last Tested: 2026-09-28 09:08
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: jakegu1/vetagent
GitHub Stars: 0
Server Listing: VetAgent

TDQS

A4.7/5.0

Scored 2026-09-21 04:40 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: assess_token_risk evaluates safety, find_new_hot_pools discovers new pools, and get_token_liquidity snapshots liquidity for a specific token. Even where data overlaps (prices, liquidity), the focus and input/output are unambiguous.

Naming Consistency5/5

All three tool names follow the same verb_noun pattern in snake_case: assess_token_risk, find_new_hot_pools, get_token_liquidity. This makes the set predictable and easy to navigate.

Tool Count5/5

Three tools is within the ideal 3-15 range and each tool earns its place: discovery, risk assessment, and liquidity checking are the core operations for token vetting. The scope feels tight rather than padded.

Completeness4/5

The toolset covers the essential workflow: find a candidate pool, assess its risk, and verify liquidity. Minor gaps exist such as no direct holder-analysis or historical-price tool, but those are explicitly noted as outside the server's stated scope.

Available Tools

3 tools

assess_token_riskAssess Token RiskA

Read-onlyIdempotent

Inspect

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'.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	Token contract address: ERC-20 (0x + 40 hex) or Solana (base58)
`verbose`	No	Return full upstream evidence. Off by default to save tokens.
`chain_hint`	No	Optional chain name (ethereum / bsc / base / polygon / arbitrum / solana). Strongly recommended: Ethereum forks such as PulseChain inherit contract addresses, so the same address exists on several chains at wildly different prices. Without it, an answer covers one chain -- the one holding the most depth -- and names it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`driver`	No	The signal that decided the verdict: {name, category}. null when nothing above ok fired.
`address`	Yes
`signals`	Yes
`evidence`	No
`checked_at`	No	When this answer was made, ISO-8601 UTC.
`confidence`	Yes	How complete the input data was — not how safe the token is.
`risk_level`	Yes	'unknown' means a critical check could not be completed. It is NOT a low-risk result and must not justify a trade.
`risk_score`	Yes	0-100; higher is more dangerous
`next_action`	No
`unknown_kind`	No	Present only when risk_level is unknown.
`recommendation`	No
`retry_after_seconds`	No
`evidence_max_age_seconds`	No	Age of the oldest evidence used; 0 when every source answered live.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context: it explains what 'unknown' means, what data_gaps and unknown_kind contain, that 'confidence' measures input completeness not safety, and that the tool reports observable on-chain risk only. It also discloses that silence about an extension means it was considered, not unread. This is rich, non-redundant behavioral disclosure.

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 but every sentence earns its place: it packs chain-specific coverage, exclusions, verdict semantics, and caveats into a dense but organized structure. The most important usage guidance is front-loaded ('BEFORE buying, holding, or recommending a token'). It could arguably be tightened, but the density of critical information justifies the length.

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 the tool's complexity (multi-chain, multiple risk signals, nuanced 'unknown' semantics), the description is remarkably complete. It explains what the tool covers per chain, what it does not cover, how to interpret the verdict, and what the output schema's key fields mean. The output schema exists and the description complements it without repeating it. An agent has everything needed to decide when to call this tool and how to interpret its result.

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 100%, so the schema already documents all three parameters. The description adds meaningful context beyond the schema: it explains why chain_hint is strongly recommended (Ethereum forks inherit contract addresses), and it clarifies that without chain_hint the answer covers the chain with the most depth. It also adds the nuance that verbose returns full upstream evidence. This goes beyond the baseline 3 for full schema coverage.

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 specific verb and resource ('Safety check to run BEFORE buying, holding, or recommending a token') and immediately states the actionable outputs: verdict, 0-100 risk score, and individual signals. It clearly distinguishes itself from siblings by emphasizing it is a risk assessment rather than pool discovery or liquidity lookup. The scope is explicit: it covers on-chain risk only and names what it does not cover.

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?

The description explicitly says when to use it ('BEFORE buying, holding, or recommending a token') and provides strong exclusions: no sell simulation on Solana or the four other EVM chains, no holder concentration on any chain. It also explains the meaning of 'unknown' and warns it must not be used to justify a trade. This is far beyond typical usage guidance and gives an agent clear decision rules.

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

find_new_hot_poolsFind New Hot PoolsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	Chain name, e.g. solana / ethereum / base / bsc	solana
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`chain`	Yes
`count`	Yes	How many pools are in `pools`. NOT how many were examined -- that is `scanned`. This field reported the fetched total beside a shorter list until 2026-09-08, so a caller reading it believed it had seen twenty pools when it had three.
`pools`	Yes
`network`	Yes	The upstream's own name for the chain, which differs from `chain` (eth vs ethereum).
`scanned`	Yes	How many distinct pools were examined before the limit was applied. Always >= count.
`checked_at`	No	When this answer was made, ISO-8601 UTC.
`sources_ok`	Yes	Which of the two upstream listings answered. Both means a full scan.
`served_stale`	No	Present only when an upstream was unreachable and cached data was used. Each entry names the source and its age in seconds.
`sources_failed`	Yes	Which listings did NOT answer. A non-empty array means this is a PARTIAL scan: a smaller `scanned` here is a coverage gap, not a quiet market. Treat it as missing information, not as absence.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the non-destructive nature. The description adds a crucial caveat about the high risk of new pools, which goes beyond the annotations and is essential for safe usage. This extra context justifies a high score.

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 concise, with the main purpose in the first sentence and essential risk guidance in the second. It front-loads the critical information and avoids unnecessary detail, making it easy for the agent to parse quickly.

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 the tool's simplicity (2 optional parameters, output schema provided, clear annotations), the description covers all necessary aspects: purpose, usage caveats, and follow-up actions. The agent has complete information to invoke the tool correctly and handle results.

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 description does not detail the parameters 'chain' and 'limit', but the input schema provides descriptions for both (e.g., 'Chain name' and a range for limit). With 50% schema coverage, the description does not compensate much, but since parameters are optional and well-schematized, the baseline of 3 is appropriate.

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 clearly states the tool's function: scanning a chain for the newest and most active trading pools, and lists the specific data returned (name, token_address, price, liquidity, volume, age). It effectively differentiates itself from siblings like assess_token_risk and get_token_liquidity by focusing on discovery of new pools, not risk assessment or individual token queries.

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?

The description explicitly warns that appearing in the list is not a safety endorsement and instructs the agent to pass token_address to assess_token_risk for anything to act on. This provides clear guidance on when and how to use the tool versus its sibling, ensuring appropriate follow-up actions.

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

get_token_liquidityGet Token LiquidityA

Read-onlyIdempotent

Inspect

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 real data. '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.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Token contract address
`chain_hint`	No	Optional chain name; disambiguates forks that share addresses

Output Schema

ParametersJSON Schema

Name	Required	Description
`chains`	No
`status`	Yes
`address`	Yes
`price_usd`	No
`checked_at`	No	When this answer was made, ISO-8601 UTC.
`pairs_total`	No
`served_stale`	No	Present only when an upstream was unreachable and this answer used cached data. Each entry names the source and how many seconds old it was.
`liquidity_usd`	No
`volume_24h_usd`	No

TDQS

A4.5/5.0

Behavior5/5

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

The description goes well beyond the readOnly/openWorld/idempotent annotations by explaining the full status semantics: 'unavailable' means upstream failure, not zero liquidity; 'not_found' means no pair exists; 'unpriced' means unknown depth; 'drained' means empty pools. This is rich behavioral context that directly prevents misinterpretation.

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 front-loaded with a one-sentence summary, then each status definition earns its place by preventing serious misinterpretation. It is moderately long but not bloated, and every sentence adds necessary operational context.

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 an output schema present, the description does not need to explain return fields, but it goes further by explaining the critical status values that affect how the output should be interpreted. It is complete for an agent to invoke the tool and handle its response correctly.

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%, so the schema already documents both 'address' and 'chain_hint' adequately. The description does not add much parameter-specific meaning beyond referencing the token and its chains, so the baseline of 3 is appropriate.

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 names a specific verb and resource: a liquidity snapshot for a token's primary trading pair, including price, 24h volume, pair count, and chains. It clearly differentiates from siblings by focusing on liquidity data rather than risk assessment or hot-pool discovery.

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?

It gives clear context for when to use the tool: when the agent needs liquidity snapshot data, including price, volume, pair count, and chains. It also instructs the agent to check the 'status' field before interpreting numbers, which is practical usage guidance. It does not explicitly exclude alternatives like assess_token_risk, but the domain is clear enough.

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.

3 tool updatesSep 14, 2026

Changedassess_token_risk6 fields changed

addedOutput schema / properties / checked_at

Added value: +{
+  "description": "When this answer was made, ISO-8601 UTC.",
+  "type": "string"
+}

addedOutput schema / properties / driver

Added value: +{
+  "description": "The signal that decided the verdict: {name, category}. null when nothing above ok fired.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / evidence_max_age_seconds

Added value: +{
+  "description": "Age of the oldest evidence used; 0 when every source answered live.",
+  "type": "integer"
+}

addedOutput schema / properties / next_action

Added value: +{
+  "enum": [
+    "retry",
+    "abstain"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / retry_after_seconds
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / unknown_kind

Added value: +{
+  "description": "Present only when risk_level is unknown.",
+  "enum": [
+    "infrastructure",
+    "coverage",
+    "mixed"
+  ],
+  "type": "string"
+}

Changedfind_new_hot_pools1 field changed

addedOutput schema / properties / checked_at

Added value: +{
+  "description": "When this answer was made, ISO-8601 UTC.",
+  "type": "string"
+}

Changedget_token_liquidity1 field changed

addedOutput schema / properties / checked_at

Added value: +{
+  "description": "When this answer was made, ISO-8601 UTC.",
+  "type": "string"
+}

1 tool updateSep 14, 2026

Changedassess_token_risk1 field changed

changedInput schema / properties / chain_hint / description

Previous value: -"Optional chain name (ethereum / bsc / base / polygon / arbitrum / solana). Strongly recommended: Ethereum forks such as PulseChain inherit contract addresses, so the same address exists on several chains at wildly different prices."New value: +"Optional chain name (ethereum / bsc / base / polygon / arbitrum / solana). Strongly recommended: Ethereum forks such as PulseChain inherit contract addresses, so the same address exists on several chains at wildly different prices. Without it, an answer covers one chain -- the one holding the most depth -- and names it."

1 tool updateSep 9, 2026

Changedfind_new_hot_pools1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Discovery only, never an endorsement. Call assess_token_risk on token_address before saying anything about a pool's risk.",
+  "properties": {
+    "chain": {
+      "type": "string"
+    },
+    "count": {
+      "description": "How many pools are in `pools`. NOT how many were examined -- that is `scanned`. This field reported the fetched total beside a shorter list until 2026-09-08, so a caller reading it believed it had seen twenty pools when it had three.",
+      "type": "integer"
+    },
+    "network": {
+      "description": "The upstream's own name for the chain, which differs from `chain` (eth vs ethereum).",
+      "type": "string"
+    },
+    "pools": {
+      "items": {
+        "properties": {
+          "kind": {
+            "enum": [
+              "new",
+              "trending"
+            ],
+            "type": "string"
+          },
+          "liquidity_usd": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "pool_age_days": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "pool_id": {
+            "type": "string"
+          },
+          "price_usd": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "token_address": {
+            "description": "The base token. This is the field to hand to assess_token_risk -- pool_id is not an address, and passing it produced six empty answers before the discovery-to-vetting seam was fixed.",
+            "type": "string"
+          },
+          "volume_24h_usd": {
+            "type": [
+              "number",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "pool_id",
+          "name",
+          "token_address",
+          "kind"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "scanned": {
+      "description": "How many distinct pools were examined before the limit was applied. Always >= count.",
+      "type": "integer"
+    },
+    "served_stale": {
+      "description": "Present only when an upstream was unreachable and cached data was used. Each entry names the source and its age in seconds.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sources_failed": {
+      "description": "Which listings did NOT answer. A non-empty array means this is a PARTIAL scan: a smaller `scanned` here is a coverage gap, not a quiet market. Treat it as missing information, not as absence.",
+      "items": {
+        "enum": [
+          "new",
+          "trending"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "sources_ok": {
+      "description": "Which of the two upstream listings answered. Both means a full scan.",
+      "items": {
+        "enum": [
+          "new",
+          "trending"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "chain",
+    "network",
+    "count",
+    "scanned",
+    "sources_ok",
+    "sources_failed",
+    "pools"
+  ],
+  "type": "object"
+}

1 tool updateSep 6, 2026

Changedget_token_liquidity3 fields changed

changedOutput schema / properties / liquidity_usd / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

addedOutput schema / properties / served_stale

Added value: +{
+  "description": "Present only when an upstream was unreachable and this answer used cached data. Each entry names the source and how many seconds old it was.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "not_found",
-  "unavailable"
-]New value: +[
+  "ok",
+  "not_found",
+  "unpriced",
+  "drained",
+  "unavailable"
+]

3 tool updatesSep 6, 2026
- First observedassess_token_risk
- First observedfind_new_hot_pools
- First observedget_token_liquidity

Related MCP Connectors

Token risk x402
com.ogenalabs
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Blockchain Cryptocurrency
1
rugcheck-ai B
io.github.MrWizardlyLoaf
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Blockchain Cryptocurrency
21
solidus A
dev.fly.solidus-x402
Solana pre-trade safety for agents: rug check, honeypot sell-sim, drainer scan, tx preflight.
Blockchain Cryptocurrency Security
32
Automaton Token Safety B
io.github.baianomarceloeduardo-jpg
Base L2 token safety for AI agents: honeypot scans, swap simulation, approval and liquidity risk.
201

Related MCP Servers

safeagent-token-safety
Blockchain Cryptocurrency
Aigen-Protocol
A
license
Not graded
quality
C
maintenance
Token safety oracle for AI agents. Honeypot detection, 17 scam pattern checks, LP lock verification across 6 EVM chains. Score 0-100 with risk flags. ERC Token Safety Score standard.
Updated 6 months ago (2026-04-05 04:46 UTC)
1
MIT
Cabal-Hunter
Blockchain Cryptocurrency Security
paulf280-ui
A
license
A
quality
A
maintenance
On-chain Solana token safety for trading agents — traces coordinated wallet funding, same-block Jito bundles, serial-rug deployers and live coordinated dumps into one Exit-Liquidity Risk verdict before a swap. Free tier, then $0.02 USDC/query via x402.
Updated 7 days ago (2026-09-21 10:57 UTC)
1
184 npm
1
MIT
AgentRisk MCPofficial
Cryptocurrency Blockchain
Neurobyteio
A
license
A
quality
C
maintenance
Enables AI agents on Base to call a check_token_risk tool before trading, providing honeypot detection, LP-lock verification, brand impersonation checks, and live sell simulation across Uniswap V2/V3/V4 and Aerodrome with a clear risk score and should-trade decision.
Updated 22 days ago (2026-09-06 14:10 UTC)
1
9 npm
MIT
crypto-inspector-mcp
Cryptocurrency Blockchain
rabbit385
F
license
B
quality
C
maintenance
Enables AI agents to perform token security audits, honeypot detection, liquidity analysis, and risk scoring to avoid crypto scams.
Updated a month ago (2026-08-21 10:12 UTC)
1
-

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.

Server Details

TDQS

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

safeagent-token-safety

Cabal-Hunter

AgentRisk MCPofficial

crypto-inspector-mcp

Glama MCP Gateway

Resources