A
licenseNot graded
qualityC
maintenanceToken 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.
1
MIT
vetagent
by dev.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 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- jakegu1/vetagent
- GitHub Stars
- 0
- Server Listing
- VetAgent
TDQS
A4.4/5.0
Scored across 3 tools
Disambiguation4/5
The three tools have mostly distinct roles: discovery, liquidity snapshot, and full risk verdict. assess_token_risk and get_token_liquidity overlap on liquidity/price data, but the descriptions clarify that one returns an actionable safety verdict while the other returns a status-bearing snapshot.
Naming Consistency5/5
All tool names use consistent snake_case with a clear verb-led pattern: assess_token_risk, find_new_hot_pools, get_token_liquidity. The verbs vary appropriately by action but remain predictable and readable.
Tool Count5/5
Three tools is small but well matched to a focused token-risk server: discovery, liquidity lookup, and deep risk assessment. Each tool earns its place without redundancy.
Completeness4/5
The set covers the core workflow of finding a token, checking liquidity, and assessing risk with a verdict. Some material coverage gaps are explicitly acknowledged, such as holder concentration and Solana sell simulation, but the main single-token vetting path is complete enough for agents to use.
Available Tools
3 toolsassess_token_riskAssess Token RiskARead-onlyIdempotentInspect
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 | Default |
|---|---|---|---|
| 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 PoolsARead-onlyInspect
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 | |
| status | Yes | Completeness only: ok means both listings were observed; partial means only one usable listing was observed. This is not a token risk verdict or a safety endorsement. |
| 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.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), but the description adds a genuine behavioral caveat not captured anywhere else: new pools are inherently high risk and inclusion is not a safety endorsement. It doesn't discuss rate limits or result volatility, so not a 5.
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?
Two tight sentences with the core capability front-loaded and the risk/routing message second. Minor redundancy from enumerating return fields that an output schema already defines, but no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the return-field list is slightly redundant, but the description still delivers everything an agent needs to call it correctly and interpret the risk posture. Absent detail on error handling or pagination is minor for a read-only discovery tool.
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 50% – chain is documented, limit is not – and the description adds no parameter meaning, only return fields. The limit param is largely self-explanatory from min/max/default, so the 3 baseline for partial schema coverage is appropriate rather than a penalty.
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?
States a specific verb (scan) and resource (newest/most active trading pools) and enumerates the returned fields, making it clearly distinct from assess_token_risk and get_token_liquidity. An agent can identify this as the discovery/scan tool without opening the 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?
Explicitly scopes the tool ('Discovery only') and routes the agent to the correct next step and sibling: 'pass token_address straight to assess_token_risk for anything you intend to act on.' Both when-to-use and the alternative are named with the selecting condition.
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 LiquidityARead-onlyIdempotentInspect
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.
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 | |
| liquidity_reserve_check | No | The positive upstream estimate was retained, but its reserve amounts could not be checked. Absence of this marker makes no verification claim. |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Extremely thorough disclosure well beyond the annotations. It enumerates every status value (ok, unavailable, not_found, unpriced, drained) with precise semantic meaning, and explicitly clarifies what a missing liquidity_reserve_check marker does NOT assert. This tells the agent exactly what the tool does and does not guarantee — strong behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, but the status enumeration is long and repetitive. Each status is valuable, but the phrasing ('this is NOT a report of zero liquidity', 'which does NOT mean') could be tightened. It earns most of its length but is not concise.
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 an output schema exists, the description doesn't need to restate return fields. For a read-only snapshot tool, the description covers all the semantic nuances an agent needs: status meanings, the reserve-check marker, and the absence-of-verification caveat. Nothing material is missing.
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 both parameters are documented in the schema; baseline 3 applies. The description adds no parameter-specific guidance (e.g., when chain_hint is needed or how address format varies by chain) beyond what the schema already states.
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?
States a specific verb+resource ('liquidity snapshot') and enumerates exactly what fields are returned (price, 24h volume, pair count, chains). Distinguishes itself clearly from assess_token_risk and find_new_hot_pools by being a point-in-time snapshot rather than risk analysis or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains how to interpret the status field ('ok' means usable upstream data, not verified reserves), which implicitly tells the agent when the numbers are trustworthy. But it never names an alternative tool or states conditions for choosing this over assess_token_risk.
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.
2 tool updates
- Changed
find_new_hot_pools2 fields changed- added
Output schema / properties / statusAdded value: +{ + "description": "Completeness only: ok means both listings were observed; partial means only one usable listing was observed. This is not a token risk verdict or a safety endorsement.", + "enum": [ + "ok", + "partial" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "chain", - "network", - "count", - "scanned", - "sources_ok", - "sources_failed", - "pools" -]New value: +[ + "status", + "chain", + "network", + "count", + "scanned", + "sources_ok", + "sources_failed", + "pools" +]
- Changed
get_token_liquidity1 field changed- added
Output schema / properties / liquidity_reserve_checkAdded value: +{ + "description": "The positive upstream estimate was retained, but its reserve amounts could not be checked. Absence of this marker makes no verification claim.", + "enum": [ + "not_checkable" + ], + "type": "string" +}
1 tool update
- Changed
get_token_liquidity2 fields changed- changed
Output schema / properties / price_usd / typePrevious value: -"number"New value: +[ + "number", + "null" +] - changed
Output schema / properties / volume_24h_usd / typePrevious value: -"number"New value: +[ + "number", + "null" +]
3 tool updates
- Changed
assess_token_risk6 fields changed- added
Output schema / properties / checked_atAdded value: +{ + "description": "When this answer was made, ISO-8601 UTC.", + "type": "string" +} - added
Output schema / properties / driverAdded value: +{ + "description": "The signal that decided the verdict: {name, category}. null when nothing above ok fired.", + "type": [ + "object", + "null" + ] +} - added
Output schema / properties / evidence_max_age_secondsAdded value: +{ + "description": "Age of the oldest evidence used; 0 when every source answered live.", + "type": "integer" +} - added
Output schema / properties / next_actionAdded value: +{ + "enum": [ + "retry", + "abstain" + ], + "type": "string" +} - added
Output schema / properties / retry_after_secondsAdded value: +{ + "type": "integer" +} - added
Output schema / properties / unknown_kindAdded value: +{ + "description": "Present only when risk_level is unknown.", + "enum": [ + "infrastructure", + "coverage", + "mixed" + ], + "type": "string" +}
- Changed
find_new_hot_pools1 field changed- added
Output schema / properties / checked_atAdded value: +{ + "description": "When this answer was made, ISO-8601 UTC.", + "type": "string" +}
- Changed
get_token_liquidity1 field changed- added
Output schema / properties / checked_atAdded value: +{ + "description": "When this answer was made, ISO-8601 UTC.", + "type": "string" +}
1 tool update
- Changed
assess_token_risk1 field changed- changed
Input schema / properties / chain_hint / descriptionPrevious 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 update
- Changed
find_new_hot_pools1 field changed- changed
Output 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 update
- Changed
get_token_liquidity3 fields changed- changed
Output schema / properties / liquidity_usd / typePrevious value: -"number"New value: +[ + "number", + "null" +] - added
Output schema / properties / served_staleAdded 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" +} - changed
Output schema / properties / status / enumPrevious value: -[ - "ok", - "not_found", - "unavailable" -]New value: +[ + "ok", + "not_found", + "unpriced", + "drained", + "unavailable" +]
3 tool updates
- First observed
assess_token_risk - First observed
find_new_hot_pools - First observed
get_token_liquidity
Related MCP Connectors
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Rug-pull, token-safety and honeypot risk checks for Solana and EVM tokens. $0.01 per call.
Solana pre-trade safety for agents: rug check, honeypot sell-sim, drainer scan, tx preflight.
Related MCP Servers
- AlicenseAqualityAmaintenanceOn-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.152 npm1MIT
AgentRisk MCPofficial
AlicenseAqualityCmaintenanceEnables 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.13 npmMIT- FlicenseBqualityCmaintenanceEnables AI agents to perform token security audits, honeypot detection, liquidity analysis, and risk scoring to avoid crypto scams.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.