This server provides read-only access to Wealthville's Solana & EVM DeFi intelligence, enabling AI agents to evaluate liquidity pools using AI-generated verdicts and composite scores. No wallet access or signing is required.
get_pool_score: Retrieve a verdict (ENTER/HOLD/EXIT/AVOID) and composite Wealthville Score (0–100) for a specific liquidity pool using its Solana base58 address, EVM 0x address, or DefiLlama pool UUID.
get_top_pools: Fetch a ranked list of the best liquidity pools by Wealthville Score, filtered by chain (Solana, EVM, or specific EVM chains like Ethereum or Base), updated within the last 6 hours.
get_track_record: Access Wealthville's live, immutable signal performance history, including per-action hit rates, IL-adjusted 7-day PnL, and recent resolved signals (including misses) — useful for assessing reliability.
get_signals_feed: Retrieve the latest published trading signals (ENTER/EXIT/RISK_OFF calls) with narrative context and confidence levels.
The server integrates with AI agents and tools like Claude, Solana Agent Kit, and ElizaOS, and maintains a transparent, immutable track record of past performance.
Provides a plugin for Solana Agent Kit to integrate Wealthville's data into Solana-based agents.
Official connectors for the Wealthville public data API — liquidity-pool Enter/Hold/Exit verdicts and the composite Wealthville Score (0–100) for Solana + EVM pools, backed by a public, immutable, miss-inclusive track record.
Package | For | Install |
Claude, Cursor, any MCP client |
| |
Solana Agent Kit v2 agents |
| |
ElizaOS agents |
|
All three are thin, read-only wrappers over four public GET endpoints — no wallet access, nothing to sign, no key required (a free partner key raises the rate limit).
claude mcp add wealthville -- npx -y @wealthville/mcp-serverThen ask Claude: "Is Czfq3xZZDmsdGdUyrNLtRhGc47cXcZtLG4crryfu44zE a good pool to LP into?"
Related MCP server: Sol MCP — Solana Token Risk & Signals
curl https://wealthville.net/api/v1/scores/top?limit=5
curl https://wealthville.net/api/v1/track-record?days=30Docs: wealthville.net/developers · OpenAPI: /api/v1/openapi.json · Methodology: /learn/wealthville-score
Every published signal is frozen at publish time and outcome-labeled after the fact — the track record includes misses and cannot be retro-edited.
Outcomes are measured after impermanent loss, not raw APR.
The same engine allocates Wealthville's own on-chain vault capital.
MIT licensed. Wealthville data is a data product, not financial advice.
Get the Wealthville verdict (ENTER/HOLD/EXIT/AVOID) and scores (enter/hold/exit + composite Wealthville Score, 0-100) for one liquidity pool. Use before recommending or opening any LP position. Accepts a Solana pool address (base58) or an EVM 0x address / DefiLlama pool UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| pool_address | Yes | Pool address: Solana base58, EVM 0x, or DefiLlama UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds value by detailing return values (verdict, scores) and accepted address formats, but doesn't disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with core action and result, then usage instruction and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with one parameter and rich annotations, description covers all necessary information: what it returns, when to use, and acceptable inputs. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter fully described in schema (100% coverage). Description repeats address format info, adding little extra meaning beyond the schema. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves Wealthville verdict and scores for a liquidity pool, with specific verdict types and score range. Distinguishes from siblings like get_top_pools by being pool-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'before recommending or opening any LP position,' providing clear usage context. Accepts multiple address formats, aiding proper invocation. No explicit alternatives but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest published Wealthville signals (ENTER/EXIT/RISK_OFF calls with narrative and confidence). Use for "any new LP signals?" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many signals (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds return content details but no behavioral traits beyond annotations. Consistent, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence defines function, second sentence usage context. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter, no output schema. Description adequately covers purpose and return content. No gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with parameter 'limit' fully described in schema (integer, min/max, description). Description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the latest published Wealthville signals' and specifies types (ENTER/EXIT/RISK_OFF) with narrative and confidence. Distinct from sibling tools which focus on pool scores, top pools, and track record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for "any new LP signals?" questions', providing clear context for when to use. No explicit when-not, but purpose is narrow enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List liquidity pools ranked by composite Wealthville Score (0-100), freshly scored within the last 6 hours. Good for "what are the best pools right now?" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | "solana" (default), "evm" (all EVM chains), or one EVM chain e.g. "ethereum", "base" | |
| limit | No | How many pools (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds crucial context beyond annotations: composite score range, freshness guarantee (6-hour scoring window). No contradictions with readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with good annotations. Missing output format details but not critical given schema coverage and clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with defaults (chain default solana, limit default 25). Description adds no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists liquidity pools ranked by Wealthville Score (0-100), freshly scored within 6 hours. Directly addresses user question and distinguishes from sibling tools like get_pool_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an example query ('what are the best pools right now?') but does not explicitly recommend alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Wealthville's live signal track record: per-action hit rates, IL-adjusted 7-day PnL, and recent resolved signals — misses included (the ledger is immutable at publish time). Use when asked whether Wealthville scores can be trusted, or for the system's recent performance.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral context: the ledger is immutable (data is final) and misses are included, giving the agent a clear picture of data fidelity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and then provide usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes what the tool returns (hit rates, PnL, resolved signals). The single parameter is well-documented. It lacks explicit mention of pagination or limits, but for a simple windowed query, the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'days' with min/max constraints. The description adds the default value (30 days), which is not present in the schema, improving semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves Wealthville's live signal track record, enumerating specific data points (hit rates, PnL, resolved signals). It distinguishes from sibling tools like get_pool_score and get_signals_feed by focusing on performance trust metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use when asked whether Wealthville scores can be trusted, or for the system's recent performance.' This directly guides the AI agent on when to invoke this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_pool_scoreget_signals_feedget_top_poolsget_track_recordScored across 4 tools
Each tool serves a unique purpose: pool scoring, top pools listing, track record, and signals feed. No overlap in functionality.
All tools follow a consistent 'get_' prefix with a clear noun phrase (e.g., get_pool_score, get_top_pools), making them predictable and easy to understand.
With 4 tools, the server is well-scoped for its purpose of Solana DeFi intelligence and AI scoring. Each tool is essential and no unnecessary redundancy.
The tool set covers core functionality: scoring a single pool, browsing top pools, reviewing historical performance, and receiving new signals. Minor omission could be a search filter for pools, but not critical for the domain.
DeFi pool yield+security intelligence & token/contract risk scanner. USDC on Base via x402.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Solana & Base DeFi intelligence for AI agents over x402: decisions, risk, signed receipts.
Crypto structure scores, MemeSniper meme filter with real hit-rate, token & stock financials.
