Crypto Token Risk MCP Server: Trust Scores for Agents

A crypto token risk MCP server gives an AI assistant tools that score or flag tokens for safety, so it can say a contract looks risky before you interact with it. These scores are useful as a first filter. They are heuristics, not guarantees, and they should feed a manual check rather than replace it.

What the listing describes

BusinessMCP’s finance MCP server list includes Zarq Crypto Risk, from the maintainer agentidx, described as crypto token safety evaluation with trust scores and structural risk signals, and seven tools. Its directory page is agentidx-zarq-risk. The listing does not say how scores are calculated, what data they use or how often they update, so we cannot assess its accuracy, and we are not endorsing it. Ask for the methodology before leaning on any score.

What “structural risk” can mean

Different tools define risk differently, but common categories of signal include the following. Treat these as examples of what to look for, not as a description of any particular server.

Signal	Why it can matter	What a human should check
Contract verification	Unverified code cannot be inspected	Whether source is published on an explorer
Holder concentration	A few wallets may control supply	The holder distribution and exchange or team wallets
Admin or mint permissions	Someone may be able to change rules or create supply	Contract functions and ownership status
Liquidity depth	Thin liquidity makes exit difficult	Pool size and who owns the liquidity tokens
Age and activity	Brand-new tokens have no track record	Deployment date and transaction history

An on-chain explorer server can supply several of these facts directly. The Blockscout MCP page lists tools for contract metadata, token transfers and holdings, which is the raw material for a manual check. See our article on blockchain data servers for how those fit.

Key takeaway: treat a trust score as the start of a due-diligence checklist. It is a summary someone else computed, with assumptions you may not be able to see.

A sensible way to use a risk server

1. Ask for the signals, not just the score. A number without reasons is not actionable.
2. Cross-check two or three signals yourself on an explorer: is the contract verified, who holds the supply, can an owner change things?
3. Compare tools. If two sources disagree, find out why.
4. Record the date. Risk changes as holders and contracts change.
5. Keep position sizes small for anything you cannot verify.

The assistant can help with the checklist. For example, ask it to list what it could verify and what it could not, and to say when data is missing rather than guessing.

Why scores can mislead

False comfort. A high score invites relaxation. Scams are designed to look clean, and a contract can pass structural checks while the project is still deceptive.

False alarms. Legitimate projects sometimes retain admin controls for good reasons, and a flag is not an accusation.

Opaque methods. If you cannot see how a score is built, you cannot judge what it misses.

Stale data. Holdings and permissions change. A score from last week may be wrong today.

Injected text. Token names and descriptions are written by the deployer. If they appear in tool results, they can contain instructions aimed at the assistant. That is the result-borne injection described in BusinessMCP’s MCP prompt injection guide, which recommends treating tool results as untrusted data. See prompt injection for finance agents.

Pairing with other tools carefully

A risk server is an analysis tool. It should sit upstream of any decision, not wired to automatic action. If you also use market data or indicators, see technical analysis servers, and keep execution out of the same session, as argued in crypto trading MCP servers. The general overview in our crypto MCP server explainer shows how the categories relate.

Checklist before you act on a token

• Is the contract source verified, and have you looked at what it can do?
• Who holds most of the supply?
• How deep is the liquidity, and who controls it?
• When was it deployed, and what does its history look like?
• What did two independent sources say?
• Could you afford to lose the whole amount?

Limits

We have not tested the listed server, and nothing here evaluates any token. This is not investment advice. Crypto assets are volatile, scams are common, and losses can be total and irreversible. Use independent sources and, where appropriate, professional advice.

Reading a risk report critically

When an assistant returns a risk summary, run it through a few quick questions. Does it name specific, checkable facts, such as “the owner can mint new tokens” or “the top ten holders control a stated share”? Or is it vague, such as “this token appears risky”? Specific claims can be verified on an explorer in minutes. Vague ones tell you little.

Does it say when it could not determine something? A report that never admits uncertainty is less trustworthy than one that says “could not retrieve holder data”. Ask the assistant to list unknowns explicitly.

Does the report reflect the current state? Ask for the date of the data. Token permissions can be renounced or changed, and liquidity can be removed, so a stale report can be dangerously wrong.

When to walk away

If a token fails basic checks, such as unverified code with owner mint rights and nearly all supply in a few wallets, the correct response is usually to do nothing. No score, however favourable elsewhere, should override a failed basic check you can see yourself.

Keeping a watchlist honestly

If you track several tokens, resist asking the assistant for a ranking. Ranking implies precision the data does not have. Instead, ask for a table of facts per token: verification status, owner permissions, top-holder share, liquidity size and deployment date, each with a note on where it came from. You can then compare the tokens yourself and see exactly which facts drive your concern.