MCP server for Deepnets — Solana trading intelligence (token safety, holder graphs, funding-network detection, social research, watchlist, trending).
Pay per call in USDC on Solana via x402. No API key. No signup.
// Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
// Cursor: ~/.cursor/mcp.json
{
"mcpServers": {
"deepnets": {
"command": "npx",
"args": ["-y", "@deepnets/mcp-server"],
"env": {
"SOLANA_PRIVATE_KEY": "your-base58-private-key"
}
}
}
}Then restart your MCP client. The Deepnets tools (token_safety, token_holder_graph, wallet_details, etc.) appear automatically.
Related MCP server: SolSentry MCP
Set SOLANA_PRIVATE_KEY in the server's env block (above) to a base58 private key — the standard export from Phantom or solana-keygen. The key stays in the MCP server's process: it's used only to sign x402 payments and is never sent to the model or returned in any tool output.
Fund that wallet with ~$1 USDC on Solana. That's enough for ~100 token-safety calls. Network fees are sponsored by the payment facilitator, so you don't need any SOL — just USDC. The server settles each call automatically; no further action needed.
Tip: use a dedicated low-balance wallet for this, not your main one. Only keep as much USDC in it as you're comfortable spending on API calls.
Discovered at startup from https://api.deepnets.ai/.well-known/x402 — every endpoint becomes one MCP tool, so this server stays in sync with the API automatically. Sample:
Tool | Description | Price |
| Overall risk level, holder concentration, mintable/freezable flags, critical risks | $0.01 |
| Price, market cap, holder count, liquidity | $0.01 |
| Funding-source graph: wallets + edges + exchange attributions | $0.01 |
| Wallet activity, holdings, network position | $0.05 |
| Funding-network breakdown by address | $0.05 |
| Deepest holder analysis, including individual holders | $0.15 |
Full list: https://api.deepnets.ai/.well-known/x402.
Env var | Default | Purpose |
| (required) | Base58 private key used to sign x402 payments (Phantom / |
| public mainnet RPC | Optional: a dedicated Solana RPC for signing payments (recommended to avoid public-RPC rate limits) |
|
| Override for staging / local-dev |
git clone https://github.com/scifantastic/deepnets-mcp
cd deepnets-mcp
npm install
npm run dev # runs src/index.ts via tsx
npm run build # compiles to dist/Questions, bugs, or feature requests: open an issue at github.com/scifantastic/deepnets-mcp/issues.
MIT
List of recently flagged Solana tokens (DANGEROUS or RISKY safety level) with reasons.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is paid ($0.01 in USDC via x402), which is important behavioral context beyond the schema. However, it does not mention whether this is a read-only operation, rate limits, or what happens if payment fails. With no annotations, the description carries the burden, and it partially meets it.
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?
The description is concise and front-loaded with the core purpose, followed by the pricing note. It is two sentences with no wasted words, though the pricing note could arguably be separated into a cost field if one existed.
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 zero-parameter list tool, the description is mostly complete: it states what is returned and the cost. However, it lacks details on the output structure (e.g., fields like token address, risk level, reason) and whether the list is sorted or paginated. The pricing disclosure is a strong addition, but the missing output details leave a gap.
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 tool has zero parameters, so there is no parameter semantics to clarify. The description correctly indicates no inputs are needed, and the schema coverage is 100%. Baseline 4 for zero-parameter tools is 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?
The description clearly states the tool returns a list of recently flagged Solana tokens with safety levels and reasons, which distinguishes it from sibling tools like token_safety or token_safety_history. It could be slightly more explicit about the output format, but the core purpose is clear.
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?
The description implies this is for viewing recently flagged tokens, but it does not explicitly state when to use this tool versus alternatives like token_safety or token_safety_history. The pricing note is useful context but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of /api/token-details. Full holder breakdown with networks, individual holders, and exchange distribution. Pass analysis to fetch a historical snapshot.
Price: $0.15 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It does add useful context: the call costs $0.15, payment is via USDC on Solana through x402, and it summarizes the returned breakdown. However, the instruction to 'Pass `analysis`' is vague and references a parameter not present in the schema, leaving behavior partially unclear.
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?
The description is compact and front-loaded with the core breakdown, then pricing. The historical snapshot sentence is the only weak part because it does not align with the schema, but overall the structure is efficient.
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 one-parameter tool, the description provides enough to attempt a call: the mint address, the expected breakdown content, and the price/payment mechanism. But there is no output schema and the optional `analysis` behavior is underspecified, leaving a meaningful completeness gap.
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 schema already documents `mint` at 100% coverage, so the baseline is 3. The description adds a reference to a non-existent `analysis` parameter, which actively confuses the parameter model instead of enriching it.
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 a holder-analysis purpose: full holder breakdown with networks, individual holders, and exchange distribution. It also identifies the underlying endpoint via the alias note. However, it does not differentiate itself from the sibling `token_details` tool, so the separation is imperfect.
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?
There is no guidance on when to use `holder_analysis` versus alternatives like `token_details` or `token_holder_graph`. The alias note is informational but does not help an agent choose between siblings, and no exclusions or preferred contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding-network overview: tokens bundled or created by a wallet network, with holder percentages and risk levels.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| networkAddress | Yes | Top funding-network address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It implies a read-only overview and adds a concrete behavioral trait: the tool costs $0.01, payable in USDC on Solana via x402. However, it does not mention caveats like rate limits, data freshness, failure modes, or authorization requirements.
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 short sentences: the first conveys the tool's purpose and output, the second states the essential billing detail. No filler words or redundant restatements of the tool name.
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 single-parameter overview tool, the description covers the output areas, the parameter's role, and the payment requirement. It lacks explicit sibling differentiation and return-format details, but that is a minor gap given no output schema and a simple schema.
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 schema already describes networkAddress as a top funding-network address in base58, and coverage is 100%. The description's reference to a wallet network adds mild context but does not materially deepen parameter semantics beyond the schema.
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 states a clear subject ('funding-network overview') and the main output contents: tokens bundled or created by a wallet network, holder percentages, and risk levels. It is specific enough to distinguish this tool from some siblings, though it does not explicitly contrast it with network_details_wallets or holder_analysis.
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?
The description gives no guidance on when to prefer this tool over sibling tools such as network_details_wallets, token_stats, or holder_analysis. It mentions the pricing/payment requirement, but that is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All wallets belonging to a funding network (by topFundingSource), with exchange labels and tags.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| networkAddress | Yes | Top funding-network address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that this is a read-style lookup and usefully discloses the $0.01 paid access via x402, but it does not mention pagination, result limits, ordering, error behavior, or prerequisites beyond the network address.
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?
The description is two sentences with no filler, front-loading the core result and then stating the cost. Every sentence earns its place and the structure is immediately scannable.
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 one-parameter list tool with no output schema or annotations, the description gives the essential result fields but leaves gaps around response shape, pagination, and how it relates to sibling tools like wallet_details_children. It is adequate for a simple call, but not fully complete.
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 schema already describes networkAddress as 'Top funding-network address (base58)' with 100% coverage, so the baseline is a 3. The phrase 'by topFundingSource' adds slight clarification that the address is interpreted as the top funding source, but the description provides no further format or example details.
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 returns all wallets belonging to a funding network, identified by topFundingSource, and includes exchange labels and tags. It is specific enough to be distinguished from single-wallet tools like wallet_details, though it does not explicitly name sibling alternatives.
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?
The description implies when to use it: whenever the agent needs the set of wallets underlying a funding network. However, it gives no explicit guidance on when not to use it or which sibling, such as wallet_details_children, would be more appropriate, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Streamflow vesting contracts for a token: locked supply and unlock schedule.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the key fact that the tool is priced at $0.01 (paid in USDC via x402), which is important for usage. It also states what data is returned (locked supply and unlock schedule). However, it does not explicitly confirm read-only behavior, error handling, or any rate limits, and the pricing could be seen as a separate operational detail rather than a behavioral trait. The disclosure is partial but adds value beyond the schema.
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?
The description is concise with two sentences, each earning its place. The first sentence explains the core function, and the second provides essential pricing information. It is front-loaded with the primary purpose and avoids redundancy. There is no fluff or repetition of schema 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 one-parameter tool with no output schema, the description provides sufficient context: it names the resource (vesting contracts), specifies the output data (locked supply and unlock schedule), and mentions the payment requirement. While it does not elaborate on error cases or return format, the simplicity of the tool and the clear output description make it reasonably complete. The pricing note adds operational context not present in schema or siblings.
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 schema already provides 100% coverage for the single parameter, describing it as 'Solana mint address (base58)'. The description adds no additional meaning about the parameter beyond referencing 'a token' in the first sentence. Since the schema is complete, the description does not need to compensate, so a baseline score of 3 is 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?
The description clearly identifies the tool's function: retrieving Streamflow vesting contracts (locked supply and unlock schedule) for a given token. It distinguishes itself from sibling tools like token_stats or token_safety by focusing specifically on vesting data. However, it lacks an explicit verb (e.g., 'get', 'fetch'), making the action slightly implicit, though the meaning is clear.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of conditions like 'use when you need vesting schedules' or exclusions like 'for other token data, use token_stats'. The description simply states what it does without contextualizing it among the siblings, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tibane staking stats for a token: total staked supply and number of stakers.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key non-obvious behavior: the tool costs $0.01 paid in USDC on Solana via x402. It also names the returned metrics, implying a read-only stats call, though it omits data-source freshness and failure behavior.
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 short sentences: the first states purpose and outputs, the second adds the essential payment constraint. No filler or repetition.
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 one-parameter read tool with no output schema, the description covers the purpose, the two result metrics, and the payment requirement. It does not specify whether staked supply is in raw units or decimal-adjusted, which is a minor gap.
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 is 100%, so the schema already documents the only parameter (mint as a Solana base58 address). The description adds no parameter-specific meaning beyond restating that this is for a token.
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 identifies the resource (Tibane staking stats for a token) and the exact outputs (total staked supply, number of stakers), which separates it from generic token_stats or holder tools. It lacks an explicit verb like 'get' or 'fetch', but the intent is unambiguous.
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?
The phrase 'staking stats for a token' implies when to use it, but there is no explicit guidance about when to prefer this over siblings such as token_stats or streamflow_locks. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full holder breakdown for a token: every detected wallet-funding network with member wallets + ownership %, top individual holders, exchange-funded distribution, rugger tags, and lock/stake flags. Pass analysis to fetch a historical snapshot.
Price: $0.15 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does disclose cost and payment method, and mentions a historical snapshot option, but it also references passing an 'analysis' parameter that is not in the schema, which is misleading. It lacks details on authentication, response format, or error handling, making the behavior unclear.
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?
The description is relatively short and front-loaded with the main content, but it includes a redundant and misleading mention of 'analysis' that adds no value. The price line is useful but could be integrated better. Overall, it's compact but not optimally efficient due to the phantom parameter.
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 tool with one parameter and no output schema, the description covers the main content but misses critical operational details: no mention of authentication requirements, response format, error handling, or rate limits. The phantom 'analysis' parameter further reduces completeness and could cause incorrect usage.
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 schema has only 'mint' with 100% coverage, so baseline is 3. However, the description introduces a non-existent 'analysis' parameter, which actively misleads the agent about how to call the tool. It adds no value beyond the schema for 'mint' and creates confusion.
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 the tool provides a 'full holder breakdown' and enumerates specific components (networks, ownership %, top holders, etc.), which is a specific verb+resource. It distinguishes itself from siblings like token_safety or token_holder_graph through its content, though it doesn't explicitly name alternatives, so it's not a 5.
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?
The description gives context about what it returns but provides no guidance on when to use this tool versus its many siblings. It doesn't mention alternatives, conditions, or exclusions, leaving the agent to infer use cases from the content alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding-source graph for a token: nodes are wallets, edges are first-funding relationships, labeled with exchange attributions where known.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does usefully disclose the output structure and the monetary cost of $0.01 via x402, which is important contextual behavior. However, it does not state whether the operation is read-only, how first-funding is computed, what happens if the mint is invalid, or whether any authentication or balance is required.
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?
The description is compact and front-loads the core purpose and graph semantics before adding pricing details. Every sentence contributes distinct information, and there is no filler or redundant restatement of the tool name.
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 single-parameter tool with no output schema verdict, the description gives a reasonable picture of what the agent receives: a graph with wallets and funding relationships. The pricing and payment route are unusual and helpful to include. It could be more complete by explaining the response format or first-funding definition, but the essential call-time information is present.
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 description coverage is 100%, so the baseline is 3. The description's reference to 'a token' aligns with the mint parameter but does not add new semantic detail beyond the schema's existing 'Solana mint address (base58)' explanation. The description therefore neither improves nor harms parameter 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 identifies the tool's output as a funding-source graph for a token, with nodes as wallets, edges as first-funding relationships, and exchange attributions. It distinguishes itself from sibling tools like token_stats or holder_analysis by emphasizing graph structure rather than aggregate stats or list-like data, though it does not use an explicit verb like 'get' or 'build'.
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?
No explicit guidance is given about when to use this tool versus alternatives. The description implies it is for exploring funding sources, but it does not mention when a user should prefer it over holder_analysis, token_details, or network_details_wallets. There are no exclusion criteria or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Token safety analysis for a Solana mint: overall risk level, wallet-network concentration, bundle detection, mintable/freezable flags, critical risks, and warnings. Returns the most recent cached analysis.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58, 32–44 chars; pump.fun tokens end in "pump") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the result is the most recent cached analysis and that the call costs $0.01 in USDC via x402. It does not mention rate limits, authentication requirements, or failure modes, but for a read-only safety lookup these are less critical.
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?
The description is tight and information-dense: it front-loads the purpose, lists the output categories, and adds the cached result and pricing details in separate sentences. Every sentence earns its place with no filler.
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 one-parameter tool with no output schema, the description covers the essential context: what analysis is returned, what categories it includes, that it is cached, and how much it costs. It is complete enough to call correctly, though explicit differentiation from token_safety_history would make it stronger.
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 has 100% coverage and already documents the mint parameter with address format, character length, and the pump.fun suffix convention. The description adds no extra parameter-level meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-plus-resource pattern: 'Token safety analysis for a Solana mint' and enumerates concrete output aspects like wallet-network concentration and bundle detection. It is clear about what the tool returns, though it does not explicitly contrast itself with token_safety_history or other sibling tools.
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?
The context for use is implied: call this when you need token safety analysis for a Solana mint. However, there is no explicit guidance about when to prefer this over token_safety_history, holder_analysis, or flagged_tokens. The cached-analysis note hints at a current-only view, but exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical safety analyses for a token. Each snapshot records overall risk, warnings, critical risks, and holder metrics at that point in time.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is paid ($0.01 via x402) and that it returns historical snapshots, which is useful. However, it does not mention whether this is a read-only operation, any rate limits, or what happens if the token has no history. The pricing disclosure is a positive behavioral detail, but other behavioral aspects are missing.
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?
The description is concise and front-loaded with the core purpose. The pricing sentence is a necessary disclosure for a paid tool and is placed at the end, which is acceptable. No wasted words, though the pricing could be considered secondary to the main purpose.
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 single-parameter tool with no output schema, the description covers the purpose and the paid nature. However, it lacks details about the response format, pagination, or how to handle tokens without history. Given the tool's simplicity, this is adequate but not complete.
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 description coverage is 100%, so the schema already documents the mint parameter as a Solana mint address (base58). The description does not add additional parameter semantics beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns historical safety analyses for a token, with each snapshot containing risk, warnings, critical risks, and holder metrics. This is a specific verb-resource pairing that distinguishes it from the sibling tools like token_safety (current safety) and holder_analysis (holder 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?
The description implies usage for retrieving historical safety data but does not explicitly state when to use this tool versus token_safety or holder_analysis. It mentions the snapshot contents, which helps an agent infer the use case, but there is no explicit when/when-not guidance or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate stats for a Solana token: price, market cap, volume windows, holder count, liquidity.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the call costs $0.01 paid in USDC via x402, which is valuable before invoking. However, it omits other behavioral details such as return format, freshness, failures, or whether the stats are synchronous, leaving part of the burden unmet.
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?
The description is compact: the first sentence front-loads the core stats, and the second sentence conveys the payment requirement. Minor deduction for the ambiguous label 'Price:' for the tool's cost, since 'price' is also one of the returned stats.
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 single-parameter tool with no output schema, the description names both the returned stat categories and the payment requirement, which is enough to make a correctly formed call. It could be stronger with explicit output structure or sibling routing, but those are modest gaps at this 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 is 100%, and the schema already describes mint as a Solana mint address in base58. The description adds no parameter-level detail beyond saying 'Solana token,' 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource, 'Aggregate stats for a Solana token,' and enumerates the concrete stats returned: price, market cap, volume windows, holder count, and liquidity. It does not explicitly differentiate token_stats from siblings like token_details or holder_analysis, but the aggregation framing and stat list make the intended scope reasonably clear.
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?
No guidance is given on when to use this tool versus token_details, holder_analysis, holder_graph, or other siblings. The only additional line is a payment note, which does not help an agent choose among tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paginated trending Solana tokens enriched with deepnets safety overlay (risk level, holder count, lockup %, charity tag). Sortable across multiple views (trending, volume, market_cap, gainers, losers, new_tokens, price, txns, liquidity, holders) over 5m / 1h / 4h / 24h windows, with optional filters for liquidity, market cap, holders, volume, age, and lockup.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it covers a lot: pagination, sorting/filtering options, multiple time windows, and a paid x402/USDC price. It does not detail the pagination format or response shape, but it does disclose the most important non-obvious trait, that the tool costs money.
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?
The description is one information-dense sentence plus a concise pricing line, with the most important identifying content front-loaded. The long list of sort views is necessary to convey scope, though it borders on a run-on.
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?
Despite listing many capabilities, the description is not complete enough for a tool with an empty input schema and no output schema: it never says how pagination, sorting, or filters should be expressed, and the payment flow is only summarized. An agent cannot reliably turn the advertised sort and filter behavior into a valid invocation.
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 has zero properties, and the rule for 0-param tools sets a baseline of 4; there are no parameter names or types the description must clarify. The description alludes to 'optional filters' without schema support or names, so it cannot earn a 5.
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 names a concrete resource: paginated trending Solana tokens with a safety overlay, and lists included fields (risk level, holder count, lockup %, charity tag). It lacks a verb like 'get' and doesn't explicitly differentiate itself from siblings such as token_stats or token_safety, so it falls just short of a 5.
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?
The sortable views and time windows (trending, volume, market_cap, gainers, 5m/1h/4h/24h) make it clear this is a market-overview/discovery tool, so usage is implied. However, it never says when to prefer trending over sibling tools like token_stats or flagged_tokens, nor does it give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wallet profile: funding source, network membership, exchange attribution, tags, and tokens created by this wallet.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Solana wallet address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that this is a wallet profile lookup and importantly notes the $0.01 payment via x402, which is a relevant cost/behavioral detail. However, it does not mention response format, failure modes, rate limits, or authentication requirements beyond the payment mechanism.
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?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence adds a distinct, useful pricing detail. Nothing is verbose, though it could be slightly more action-oriented.
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 one-parameter read tool, the description is mostly sufficient: it states what data will be returned and the cost. However, with no output schema, it does not describe the response structure, and it does not address prerequisites such as whether the address must be verified or whether the x402 payment flow requires any additional input from the agent.
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 schema already covers the single parameter fully with 'Solana wallet address (base58)', so the description does not need to add much. The description's reference to 'this wallet' adds little beyond the schema. With 100% schema coverage, the baseline of 3 is 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?
The description identifies what the tool returns: a wallet profile with funding source, network membership, exchange attribution, tags, and tokens created by the wallet. It is reasonably specific and suggests a read-oriented lookup, though it lacks an explicit verb such as 'retrieve' or 'get' and does not strongly distinguish itself from wallet_details_children.
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?
The description provides no explicit guidance on when to use this tool instead of sibling tools like wallet_details_children, network_details_wallets, or holder_analysis. The listed data categories imply a use case, but there is no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wallets directly funded by a given address - one-hop children in the funding tree.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Solana wallet address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is paid ($0.01 in USDC via x402) and clarifies the one-hop scope. However, it does not describe return format, potential errors, or any additional behavioral traits such as rate limits or authentication requirements.
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?
The description is concise: two sentences that front-load the purpose and then mention the price. There is no waste, and the key information is presented efficiently.
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 the low complexity (one parameter, no output schema) and lack of annotations, the description covers the core purpose and price but omits details about the response structure and edge cases. It is adequate but not comprehensive.
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 schema fully describes the single parameter (address with base58 format). The description adds no additional parameter-level meaning, so a baseline score of 3 is appropriate given 100% schema coverage.
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 the tool returns wallets directly funded by a given address, specifying 'one-hop children in the funding tree.' This distinguishes it from siblings like wallet_details (likely a single wallet) and network_details_wallets, providing a precise purpose.
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?
The description does not explicitly indicate when to use this tool over alternatives. It states what it does but lacks guidance on conditions or exclusions, leaving the agent to infer usage from the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The active deepnets watchlist - high-volume tokens that passed the safety screen, with current safety data.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does mention the paid nature ($0.01 via x402) and that the data is current, which adds useful context. However, it does not describe return format, freshness limits, pagination, or any side effects.
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?
The description is two sentences with no wasted words. The core purpose is front-loaded, and the pricing/payment detail is separated clearly. It earns its length without 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 the tool has no parameters and no output schema, the description covers the essential content and cost. It could be more complete by stating what fields or token data will be returned, but it is adequate for a simple watchlist lookup.
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 tool has zero parameters)Skip? The schema coverage is trivially 100%, and the description adds relevant context about what the watchlist contains)Skip? For a no-parameter tool, the description sufficiently explains the semantics.
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 identifies the tool as a watchlist of high-volume tokens that passed a safety screen, with current safety data. It is specific enough to distinguish it from sibling tools like flagged_tokens or trending, though it lacks an explicit verb.
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?
The description implies usage for retrieving safe high-volume tokens but provides no explicit guidance on when to choose this tool over siblings such as token_safety, flagged_tokens, or trending. No when-to-use or when-not-to-use context is given.
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.3.0flagged_tokensholder_analysisnetwork_detailsnetwork_details_walletssocial_researchstreamflow_lockstibane_stakingtoken_detailstoken_holder_graphtoken_safetytoken_safety_historytoken_statstrendingwallet_detailswallet_details_childrenwatchlistScored across 16 tools
holder_analysis is explicitly an alias of token_details, creating an exact duplicate that will cause tool misselection. Additionally, token_holder_graph, network_details, network_details_wallets, and wallet_details_children have subtle boundary distinctions around funding networks and wallet relationships.
Most tools follow a predictable snake_case noun-phrase pattern grouped by entity (token_, network_, wallet_). Minor deviations like holder_analysis instead of token_holder_details and network_details_wallets instead of network_wallets break the pattern slightly.
At 16 tools the surface is slightly heavy, and holder_analysis is a redundant alias that inflates the count. The remaining tools are individually relevant to the token-research domain, so the count is only borderline rather than excessive.
The toolset covers the core token research workflow comprehensively: stats, current and historical safety, holder and network breakdowns, wallet attribution, vesting/staking, social research, and token lists. There are no obvious dead ends or major missing operations for a read-only analytics server.
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Solana token/wallet rug-risk scoring. Free scan; $2 SOL unlocks full wallet report. No signup.
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Solana wallet & token reputation lookup. Risk verdict, score, DefiLlama TVL, Rugcheck.
social_researchA
AI-generated social research: Twitter/X activity, Telegram presence, website analysis, mentions, sentiment, and entity verification.
Price: $0.01 (paid in USDC on Solana via x402).
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal that the research is AI-generated and that the tool costs $0.01 paid via x402 in USDC, which is meaningful operational context. It does not disclose how results are delivered, potential latency, failure modes, or whether the operation is purely read-only.
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?
The description is compact and front-loaded with the tool's purpose, followed by a concise list of research areas. The price and payment method sentence is essential because it informs the agent that the call is paid, so every sentence earns its place.
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?
With only one fully documented parameter and no output schema, the description gives enough context for an agent to invoke the tool correctly: provide a mint and expect AI-generated social research across several listed dimensions. It could be more explicit about the exact response format, but the listed categories provide a reasonable expectation of the output.
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 fully documents the only parameter, 'mint', as a Solana mint address in base58, so schema coverage is 100%. The description adds no extra meaning about the parameter, but also does not need to because the schema is sufficient.
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 identifies the tool's resource as social research for a token mint and enumerates concrete content areas such as Twitter/X activity, Telegram presence, website analysis, mentions, sentiment, and entity verification. It distinguishes itself from sibling tools by focusing on social/sentiment data, but lacks a direct action verb like 'retrieve' or 'analyze'.
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?
The use case is implied by the listed social-research outputs: an agent can infer this tool is appropriate when social signals or sentiment are needed. However, there is no explicit statement of when to use this tool versus the many sibling tools, nor any exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.