VetAgent

Overview Schema Source Related Servers Score Discussions Admin

Assess Token Risk

assess_token_risk

Read-onlyIdempotent

Check a token before buying, holding, or recommending. Simulates a sell to uncover honeypots, taxes, liquidity issues, and owner powers, then returns a 0-100 risk score and verdict.

Instructions

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: sell simulation (honeypot detection, buy/sell/transfer taxes), liquidity depth, trading-pair age, cross-chain presence, whether the contract is open source, and on Solana the mint/freeze authority and holder concentration — plus the aggregate verdicts of upstream security scanners. 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. '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'.

Input Schema

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

Output Schema

TableJSON Schema

Name	Required	Description
`address`	Yes
`signals`	Yes
`evidence`	No
`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
`recommendation`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedv0.1.0Sep 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations only declare the tool read-only, idempotent, and non-destructive. The description goes far beyond this by explaining the critical semantics of 'unknown', the meaning of 'confidence', the data_gaps output, and the tool's blind spots (off-chain risk, team behavior, governance rugs). This is exactly the kind of behavioral context an agent needs to avoid misusing the result.

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 front-loaded with the tool's purpose and return value, then moves through coverage, critical caveats, and limitations. It is somewhat long but earns its length given the safety-critical nature of the tool. A small amount of redundancy exists between 'Reports observable on-chain risk only' and the later 'cannot see off-chain risk' phrasing.

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, the presence of an output schema, and the safety-sensitive use case, the description provides everything needed: what checks are performed, how to interpret non-obvious outputs like 'unknown' and 'confidence', and what the tool cannot detect. No critical operational context 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?

The input schema already provides 100% parameter descriptions, including detailed guidance on chain_hint and verbose. The tool description does not add new parameter-level meaning, but it doesn't need to because the schema field descriptions are already thorough. This matches the baseline for high 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 clearly identifies the tool as a pre-trade safety check that outputs a risk verdict, a 0-100 score, and supporting signals. It names the specific resource (token) and the action (assess risk), and the coverage list makes its scope unambiguous.

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 tells the agent when to use the tool: before buying, holding, or recommending a token. It also gives important when-not guidance: 'unknown' must not justify a trade, 'low' means no fatal signal found, and off-chain risks are out of scope. It does not explicitly compare against sibling tools like get_token_liquidity or find_new_hot_pools, but the usage context is otherwise clear.

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

Install Server