RugShield
Server Details
Parallel Solana token risk and transaction safety for AI agents. Paid MCP tools inspect tokens and unsigned transactions; the HTTP risk panel queries compatible advisors in parallel and returns an indicative consensus. x402-compatible clients pay USDC automatically, with no signup or API key.
- Status
- Healthy
- Uptime
- 100.0% over 40 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 5 tools
The two paid checks are clearly separated by input type (token mint vs. serialized unsigned transaction) and the transaction tool explicitly says it is not for a mint alone. The lifecycle tools (get_job_result, retry_failed_job) and the free quote are distinct, though quote_solana_risk_panel overlaps conceptually with check_solana_token_risk since both concern Solana token risk, requiring the agent to read carefully which one actually initiates analysis.
All five names use consistent snake_case verb_noun forms (check_*, get_*, quote_*, retry_*) with no casing or style mixing. Minor deviation is that resource phrasing varies in depth (check_solana_token_risk vs. quote_solana_risk_panel vs. get_job_result), but the pattern remains readable and predictable.
Five tools is a tight, well-scoped surface for a risk-checking server: two check endpoints plus three job/payment lifecycle helpers. Nothing feels padded, though the set is arguably minimal given the async-payment complexity described.
The core lifecycle is covered (initiate check, poll result, retry failure), but quote_solana_risk_panel returns an HTTP URL that no tool can invoke or pay, so the paid-panel path dead-ends inside MCP. The referenced GET /v1/advisors endpoint also has no corresponding tool, leaving agents without a way to discover valid advisor aliases.
Available Tools
5 toolscheck_solana_token_riskAInspect
Use before buying a pump.fun token when you have its Solana mint address. Returns advisory flags evaluated on selected historical tokens; no flags does not mean safe. Optional idempotency_key is random 32-byte base64url. A signed call waits up to 20 seconds for analysis and can settle without a key. If still processing, echo the unpaid job_id with the same proof and mint when ready. get_job_result reports processing and retry_after_s for free; the result appears there only after settlement. Costs $0.01 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Base58 Solana token mint address to check before buying; not a transaction or token symbol. | |
| job_id | No | Accepted job ID to echo with the original payment proof and identical inputs when recovering a call made without idempotency_key. | |
| prefer_async | No | If work is queued or running, return a job status instead of waiting for completion. Poll get_job_result for free, then retry this tool with the same payment proof and inputs when ready; payment does not settle while processing. | |
| idempotency_key | No | Optional canonical base64url encoding of 32 random bytes. Reuse with the original payment proof and identical inputs to recover a lost reply. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: advisory-only semantics ('no flags does not mean safe'), $0.01 USDC x402 cost, a 20-second wait bound, settlement behavior, async recovery via echoed job_id, and the free polling path. This is unusually complete 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and caveat, and each sentence carries a distinct fact (cost, timeout, recovery). It is dense and run-on, mixing payment, async, and idempotency mechanics into one block, which slightly hurts readability.
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 no annotations and no output schema, the description covers return semantics, cost, timing, and the async recovery loop adequately. It does not describe the shape of the returned flags in detail, but that 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 all four parameters, and the description largely repeats them (base64url idempotency key, echo job_id). It adds only marginal workflow context, 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?
States a specific verb and resource: check a Solana token mint for risk flags before buying. The token-vs-transaction scope implicitly distinguishes it from check_solana_transaction, but no sibling is named, so it falls short of a clean 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?
Explicitly says when to use it ('before buying a pump.fun token when you have its Solana mint address') and routes the agent to get_job_result for free polling. It does not state when not to use it or name check_solana_transaction as the alternative for transaction-level checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_solana_transactionAInspect
Use before signing an unsigned Solana transaction, not for a token mint alone. Provide a real unsigned Solana transaction serialized as base64, with optional signer and expected intent. Malformed input is rejected before payment. Simulation returns ALLOW, WARN or BLOCK with reasons and balance changes. Optional idempotency_key is random 32-byte base64url. A signed call waits up to 20 seconds for analysis and can settle without a key. If still processing, echo the unpaid job_id with the same proof and arguments when ready. get_job_result reports processing and retry_after_s for free; the result appears there only after settlement. Costs $0.01 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Optional expected action object. Supported keys: max_sol_out (nonnegative SOL amount), expected_mints_in (array of base58 Solana token mint addresses), allowed_recipients (array of base58 Solana addresses). No other keys. | |
| job_id | No | Accepted job ID to echo with the original payment proof and identical inputs when recovering a call made without idempotency_key. | |
| signer | No | Optional base58 Solana address that must be a required transaction signer; omit to use the fee payer. | |
| transaction | Yes | Real unsigned Solana transaction (legacy or v0), serialized as base64; not a token mint or example placeholder. | |
| prefer_async | No | If work is queued or running, return a job status instead of waiting for completion. Poll get_job_result for free, then retry this tool with the same payment proof and inputs when ready; payment does not settle while processing. | |
| idempotency_key | No | Optional canonical base64url encoding of 32 random bytes. Reuse with the original payment proof and identical inputs to recover a lost reply. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: malformed input is rejected before payment, cost is $0.01 USDC via x402, a signed call waits up to 20 seconds, payment does not settle while processing, and a keyless call can still settle. These are exactly the behavioral traits an agent needs and cannot infer from 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?
Front-loaded with the use case and mostly tight, but the payment/async/idempotency mechanics make it dense and multi-clause. Nearly every sentence earns its place, though it is longer than ideal for a single tool.
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?
The schema alone cannot communicate the async and payment flow, and there is no output schema, so the description supplies the return semantics (ALLOW/WARN/BLOCK with reasons and balance changes; job_id when processing). Nothing an agent needs to invoke or follow up is missing.
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 baseline is 3, but the description adds real meaning beyond the schema: how job_id is echoed with the same proof/arguments, and how idempotency_key enables recovery of a lost reply. It also clarifies that settlement can occur without a key, which the schema alone does not convey.
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?
States a specific verb and resource ('check ... unsigned Solana transaction') and immediately bounds scope ('before signing', 'not for a token mint alone'), which differentiates it from the token-risk sibling. An agent can tell what this tool operates on and when it applies 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('before signing an unsigned Solana transaction'), a when-not ('not for a token mint alone'), and routes follow-up work to the correct sibling ('get_job_result reports processing ... for free'). The recovery path via echo of job_id is also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_resultAInspect
Poll an accepted job for free. A paid job reports processing, ready, or failed without revealing its result before settlement; retry_after_s gives the next polling delay, capped at two minutes. An uncertain payment reports needs_review with no automatic retry: keep the job ID and contact support without another payment. After confirmed settlement, retrieve the saved result. Read agent_guidance.payment and agent_guidance.analysis separately. Legacy charged:null means unconfirmed, not free. Historical saved replies remain unchanged; this free status tool exposes current state explanations.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID returned by a paid check or accepted queued request. Poll for status without another payment; a settled result is available here. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Legacy opaque job identifier. |
| code | No | Error code when the tool cannot fulfill this request. |
| kind | No | Stored job kind when exposed; production paid checks use token_risk, tx_guard or risk_panel. |
| error | No | |
| eta_s | No | Estimated queue delay, not a completion deadline. |
| job_id | No | Opaque server-returned job identifier; preserve it exactly. |
| result | No | Conditional result. Paid results are released only after confirmed settlement; token/transaction jobs expose the saved paid response envelope, while prepaid panels expose their analysis object when ready. Legacy non-purchase jobs may expose their result directly. Absence never proves no charge. |
| status | No | Analysis and payment are separate facts. ready/done can mean work finished while its paid result is still withheld; needs_review can concern payment or analysis. Read agent_guidance.payment and analysis. |
| charged | No | Legacy: true confirms settlement, false reports no settled charge for this attempt, null means unconfirmed. Never infer a refund or no charge from null. |
| message | No | |
| prepaid | No | |
| created_at | No | |
| status_url | No | Free GET path for this existing job; no settlement or analysis restart. |
| next_action | No | |
| status_tool | No | Free tool to observe the existing retry; normally get_job_result. |
| instructions | No | |
| retry_after_s | No | Free polling delay, not a deadline or instruction to authorize payment. |
| agent_guidance | Yes | Optional additive agent instructions; does not replace x402 headers or the original result. |
| delivery_state | No | Legacy ledger state when returned by a job/retry observation. |
| payment_status | No | Legacy ledger or error field. Use agent_guidance.payment for the explicit charge outcome. |
| receipt_header | No | Stored receipt when available. This is not a new payment proof to authorize or replay. |
| payment_receipt | No | Decoded receipt when available after settlement; historical encoded receipts may remain only in receipt_header. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so: it is free and non-charging, paid jobs withhold results until settlement, retry_after_s is capped at two minutes, needs_review means uncertain payment with no automatic retry, and legacy charged:null means unconfirmed rather than free. These are exactly the non-obvious traits an agent would otherwise guess wrong on.
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?
Front-loaded with the core action and cost model, then layers state semantics. It is dense but mostly earns its sentences; the trailing 'Historical saved replies remain unchanged' clause is the weakest and reads as a caveat bolted onto an otherwise tight description.
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?
Covers the full polling lifecycle, all four payment/status outcomes, backoff behavior, and the needs_review escalation path, which is ample for a one-parameter tool. Return values are covered by the existing output schema, so the remaining gap is only that agent_guidance.payment and agent_guidance.analysis are referenced without saying what each contains.
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 single job_id parameter is already documented in the schema as coming from a paid check or accepted queued request. The description reinforces the 'poll without another payment' lifecycle but never names or adds syntax to job_id, so the schema does the work and baseline 3 applies.
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?
States a specific verb and resource ('Poll an accepted job') plus its economic scope ('for free'), and immediately distinguishes it from the paid path by noting a paid job won't reveal its result before settlement. An agent can tell this apart from retry_failed_job and the paid check tools without opening a schema.
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?
Gives concrete when-to-use guidance: poll while processing, back off per retry_after_s, retrieve the saved result only after confirmed settlement, and on needs_review keep the job ID and contact support rather than paying again. It stops short of naming retry_failed_job as the alternative when a job has failed, leaving that routing implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_solana_risk_panelAInspect
Free quote for the paid HTTP panel of parallel Solana risk advisors. Pass a Solana mint and optionally comma-separated public advisor aliases from GET /v1/advisors and a CAIP-2 token chain. Returns a canonical HTTP URL and estimated total in USDC; does not call or pay advisors. The URL's HTTP 402 payment quote is authoritative. Request it without a proof, then prepay the exact original URL with a compatible x402 HTTP client. A confirmed prepayment returns 202 with job_id/status_url: poll status_url for free; no second signed request or payment is needed. Failed paid panels require support review; there is no automatic refund.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Base58 Solana token mint address to analyze through the paid HTTP panel. | |
| chain | No | Optional CAIP-2 network ID of the token being analyzed, not the payment network. Defaults to Solana mainnet; other token chains are currently unsupported. | |
| advisors | No | Optional comma-separated public advisor aliases from free GET /v1/advisors; omit to select all enabled advisors compatible with the token chain. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it declares the tool is free, does not contact or pay advisors, that the URL's HTTP 402 quote is authoritative, that success returns 202 with job_id/status_url, that polling is free with no second signed request, and that failed panels require support review with no automatic refund. These are non-obvious operational traits an agent could not derive from 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?
Purpose and the 'does not call or pay advisors' caveat are front-loaded, and every sentence carries operational content. The middle section is dense and slightly run-on, packing the payment/polling flow into long clauses, but nothing is padding.
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?
There is no output schema and no annotations, yet the description covers the return shape (URL + USDC estimate), the payment handshake, the async job_id/status_url polling path, and failure/refund handling. An agent has enough to invoke this correctly and follow through the paid flow.
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 mint, chain, and advisors parameters are already documented. The description largely restates them, adding only the provenance hint that aliases come from GET /v1/advisors; it adds no format or constraint detail beyond the schema baseline.
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?
States a specific verb and resource ('Free quote for the paid HTTP panel of parallel Solana risk advisors') and immediately bounds scope with 'does not call or pay advisors,' which cleanly separates it from sibling check_solana_token_risk. The return value (canonical HTTP URL + estimated USDC total) is named in the same breath.
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?
Gives a concrete usage sequence: request without a proof, then prepay the exact original URL with an x402 client, then poll status_url for free rather than re-requesting. It does not name sibling tools (check_solana_token_risk, get_job_result) as explicit alternatives, so routing is inferred from the described workflow rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry_failed_jobAInspect
Retry a failed paid job for free. Transaction and token checks each have one manual retry per job ID; if it still fails, keep the job ID and contact rugshield@fastsoftware.uk for review. There is no automatic refund.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of a failed paid transaction or token check. Retry that job for free after get_job_result reports failure. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Legacy opaque job identifier. |
| code | No | Error code when the tool cannot fulfill this request. |
| kind | No | Stored job kind when exposed; production paid checks use token_risk, tx_guard or risk_panel. |
| error | No | |
| eta_s | No | Estimated queue delay, not a completion deadline. |
| job_id | No | Opaque server-returned job identifier; preserve it exactly. |
| result | No | Conditional result. Paid results are released only after confirmed settlement; token/transaction jobs expose the saved paid response envelope, while prepaid panels expose their analysis object when ready. Legacy non-purchase jobs may expose their result directly. Absence never proves no charge. |
| status | No | Analysis and payment are separate facts. ready/done can mean work finished while its paid result is still withheld; needs_review can concern payment or analysis. Read agent_guidance.payment and analysis. |
| charged | No | Legacy: true confirms settlement, false reports no settled charge for this attempt, null means unconfirmed. Never infer a refund or no charge from null. |
| message | No | |
| prepaid | No | |
| created_at | No | |
| status_url | No | Free GET path for this existing job; no settlement or analysis restart. |
| next_action | No | |
| status_tool | No | Free tool to observe the existing retry; normally get_job_result. |
| instructions | No | |
| retry_after_s | No | Free polling delay, not a deadline or instruction to authorize payment. |
| agent_guidance | Yes | Optional additive agent instructions; does not replace x402 headers or the original result. |
| delivery_state | No | Legacy ledger state when returned by a job/retry observation. |
| payment_status | No | Legacy ledger or error field. Use agent_guidance.payment for the explicit charge outcome. |
| receipt_header | No | Stored receipt when available. This is not a new payment proof to authorize or replay. |
| payment_receipt | No | Decoded receipt when available after settlement; historical encoded receipts may remain only in receipt_header. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does a good job: free retry, one manual retry per job ID, no automatic refund, and contact escalation if it still fails. It does not disclose auth, rate-limit, or side-effect details, so it is not fully exhaustive.
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?
Three tight sentences, with the core action front-loaded. Every sentence adds a real constraint: free retry, retry limit, escalation path, and no automatic refund.
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 a single required parameter, full schema coverage, and an output schema, the description supplies the otherwise missing behavioral context needed to call the tool correctly. It covers purpose, limits, failure handling, and refund policy.
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 baseline is 3. The description adds useful meaning beyond the schema by clarifying that job_id refers to a failed paid transaction or token check and that each job ID gets only one manual retry.
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 specific verb and resource: retry a failed paid job for free. It also scopes the tool to failed transaction/token checks and makes clear this is a retry action, distinguishing it from sibling result/check tools such as get_job_result.
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?
It gives a clear condition for use: retry a failed paid job, after get_job_result reports failure, with one manual retry per job ID. It also provides a fallback if the retry fails. It does not explicitly compare against the check/quote siblings for non-failure situations.
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
get_job_result1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "status" + ] + }, + { + "required": [ + "code", + "message" + ] + } + ], + "description": "Free job observation or a tool error. Conditional fields preserve historical job variants. Paid panel failure can require analysis review even when payment is settled; payment and analysis are separate. Read agent_guidance.payment and analysis. A missing receipt or result does not prove no charge or refund.", + "properties": { + "agent_guidance": { + "description": "Optional additive agent instructions; does not replace x402 headers or the original result.", + "properties": { + "analysis": { + "properties": { + "explanation": { + "type": "string" + }, + "result_available": { + "type": "boolean" + }, + "status": { + "enum": [ + "not_started", + "waiting_for_payment", + "queued", + "running", + "processing", + "completed", + "failed", + "review_required", + "not_reported" + ], + "type": "string" + } + }, + "required": [ + "status", + "result_available", + "explanation" + ], + "type": "object" + }, + "code": { + "type": "string" + }, + "documentation": { + "type": "string" + }, + "examples": { + "items": { + "type": "object" + }, + "type": "array" + }, + "instructions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "next_action": { + "type": "string" + }, + "payment": { + "properties": { + "background_reconciliation_available": { + "const": false, + "type": "boolean" + }, + "charge_outcome": { + "enum": [ + "not_applicable", + "not_charged", + "charged", + "unconfirmed" + ], + "type": "string" + }, + "explanation": { + "type": "string" + }, + "legacy_charged_note": { + "type": "string" + }, + "new_authorization_allowed": { + "type": "boolean" + }, + "next_action": { + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "not_started", + "not_settled", + "confirmation_pending", + "settled", + "reconciliation_required", + "unconfirmed" + ], + "type": "string" + } + }, + "required": [ + "status", + "charge_outcome", + "explanation", + "next_action" + ], + "type": "object" + }, + "payment_allowed": { + "description": "Advisory only; server preflight enforces input validity.", + "type": "boolean" + }, + "payment_status": { + "enum": [ + "settled", + "not_charged", + "unknown" + ], + "type": "string" + }, + "request_example": { + "description": "Recommended NEXT action. A blueprint is not executable until its required original context or actual inputs are supplied. No signing or payment is performed by returning this object.", + "properties": { + "body_fields": { + "type": "object" + }, + "effects": { + "properties": { + "analysis": { + "enum": [ + "none", + "read_operation_schema", + "read_existing_job", + "request_free_token_analysis", + "read_advisor_catalog", + "resume_or_recover_existing_job", + "start_or_complete_analysis", + "attempt_free_retry" + ], + "type": "string" + }, + "payment": { + "enum": [ + "none", + "may_settle_original_authorization", + "may_settle_reviewed_authorization" + ], + "type": "string" + } + }, + "required": [ + "payment", + "analysis" + ], + "type": "object" + }, + "executable": { + "type": "boolean" + }, + "explanation": { + "type": "string" + }, + "method": { + "type": "string" + }, + "new_authorization_allowed": { + "type": "boolean" + }, + "payment_proof_required": { + "type": "boolean" + }, + "request_source": { + "type": "string" + }, + "requires": { + "items": { + "type": "string" + }, + "type": "array" + }, + "type": { + "enum": [ + "http", + "mcp", + "original_context", + "original_request", + "manual", + "none" + ], + "type": "string" + }, + "url": { + "type": "string" + }, + "url_template": { + "type": "string" + } + }, + "required": [ + "type", + "executable", + "explanation", + "effects", + "payment_proof_required", + "new_authorization_allowed" + ], + "type": "object" + }, + "schema": { + "type": "string" + } + }, + "type": "object" + }, + "charged": { + "description": "Legacy: true confirms settlement, false reports no settled charge for this attempt, null means unconfirmed. Never infer a refund or no charge from null.", + "type": [ + "boolean", + "null" + ] + }, + "code": { + "description": "Error code when the tool cannot fulfill this request.", + "type": "string" + }, + "created_at": { + "type": "number" + }, + "delivery_state": { + "description": "Legacy ledger state when returned by a job/retry observation.", + "type": "string" + }, + "error": { + "type": "string" + }, + "eta_s": { + "description": "Estimated queue delay, not a completion deadline.", + "type": "number" + }, + "id": { + "description": "Legacy opaque job identifier.", + "type": "string" + }, + "instructions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "job_id": { + "description": "Opaque server-returned job identifier; preserve it exactly.", + "type": "string" + }, + "kind": { + "description": "Stored job kind when exposed; production paid checks use token_risk, tx_guard or risk_panel.", + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "type": "string" + }, + "payment_receipt": { + "description": "Decoded receipt when available after settlement; historical encoded receipts may remain only in receipt_header.", + "properties": { + "network": { + "type": "string" + }, + "success": { + "type": "boolean" + }, + "transaction": { + "type": "string" + } + }, + "type": "object" + }, + "payment_status": { + "description": "Legacy ledger or error field. Use agent_guidance.payment for the explicit charge outcome.", + "enum": [ + "reserved", + "prepared", + "claiming", + "uncertain", + "settled", + "unknown" + ], + "type": "string" + }, + "prepaid": { + "type": "boolean" + }, + "receipt_header": { + "description": "Stored receipt when available. This is not a new payment proof to authorize or replay.", + "type": [ + "string", + "null" + ] + }, + "result": { + "description": "Conditional result. Paid results are released only after confirmed settlement; token/transaction jobs expose the saved paid response envelope, while prepaid panels expose their analysis object when ready. Legacy non-purchase jobs may expose their result directly. Absence never proves no charge." + }, + "retry_after_s": { + "description": "Free polling delay, not a deadline or instruction to authorize payment.", + "minimum": 1, + "type": "integer" + }, + "status": { + "description": "Analysis and payment are separate facts. ready/done can mean work finished while its paid result is still withheld; needs_review can concern payment or analysis. Read agent_guidance.payment and analysis.", + "enum": [ + "awaiting_payment", + "queued", + "running", + "processing", + "done", + "ready", + "failed", + "payment_processing", + "needs_review" + ], + "type": "string" + }, + "status_tool": { + "description": "Free tool to observe the existing retry; normally get_job_result.", + "type": "string" + }, + "status_url": { + "description": "Free GET path for this existing job; no settlement or analysis restart.", + "type": "string" + } + }, + "required": [ + "agent_guidance" + ], + "type": "object" +}
- Changed
retry_failed_job1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "status" + ] + }, + { + "required": [ + "code", + "message" + ] + } + ], + "description": "Free retry admission or a tool error. Only failed token_risk and tx_guard jobs have one manual retry; risk_panel jobs are ineligible and require support review. A failed status alone does not prove retry eligibility. Read agent_guidance.payment and analysis. A missing receipt or result does not prove no charge or refund.", + "properties": { + "agent_guidance": { + "description": "Optional additive agent instructions; does not replace x402 headers or the original result.", + "properties": { + "analysis": { + "properties": { + "explanation": { + "type": "string" + }, + "result_available": { + "type": "boolean" + }, + "status": { + "enum": [ + "not_started", + "waiting_for_payment", + "queued", + "running", + "processing", + "completed", + "failed", + "review_required", + "not_reported" + ], + "type": "string" + } + }, + "required": [ + "status", + "result_available", + "explanation" + ], + "type": "object" + }, + "code": { + "type": "string" + }, + "documentation": { + "type": "string" + }, + "examples": { + "items": { + "type": "object" + }, + "type": "array" + }, + "instructions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "next_action": { + "type": "string" + }, + "payment": { + "properties": { + "background_reconciliation_available": { + "const": false, + "type": "boolean" + }, + "charge_outcome": { + "enum": [ + "not_applicable", + "not_charged", + "charged", + "unconfirmed" + ], + "type": "string" + }, + "explanation": { + "type": "string" + }, + "legacy_charged_note": { + "type": "string" + }, + "new_authorization_allowed": { + "type": "boolean" + }, + "next_action": { + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "not_started", + "not_settled", + "confirmation_pending", + "settled", + "reconciliation_required", + "unconfirmed" + ], + "type": "string" + } + }, + "required": [ + "status", + "charge_outcome", + "explanation", + "next_action" + ], + "type": "object" + }, + "payment_allowed": { + "description": "Advisory only; server preflight enforces input validity.", + "type": "boolean" + }, + "payment_status": { + "enum": [ + "settled", + "not_charged", + "unknown" + ], + "type": "string" + }, + "request_example": { + "description": "Recommended NEXT action. A blueprint is not executable until its required original context or actual inputs are supplied. No signing or payment is performed by returning this object.", + "properties": { + "body_fields": { + "type": "object" + }, + "effects": { + "properties": { + "analysis": { + "enum": [ + "none", + "read_operation_schema", + "read_existing_job", + "request_free_token_analysis", + "read_advisor_catalog", + "resume_or_recover_existing_job", + "start_or_complete_analysis", + "attempt_free_retry" + ], + "type": "string" + }, + "payment": { + "enum": [ + "none", + "may_settle_original_authorization", + "may_settle_reviewed_authorization" + ], + "type": "string" + } + }, + "required": [ + "payment", + "analysis" + ], + "type": "object" + }, + "executable": { + "type": "boolean" + }, + "explanation": { + "type": "string" + }, + "method": { + "type": "string" + }, + "new_authorization_allowed": { + "type": "boolean" + }, + "payment_proof_required": { + "type": "boolean" + }, + "request_source": { + "type": "string" + }, + "requires": { + "items": { + "type": "string" + }, + "type": "array" + }, + "type": { + "enum": [ + "http", + "mcp", + "original_context", + "original_request", + "manual", + "none" + ], + "type": "string" + }, + "url": { + "type": "string" + }, + "url_template": { + "type": "string" + } + }, + "required": [ + "type", + "executable", + "explanation", + "effects", + "payment_proof_required", + "new_authorization_allowed" + ], + "type": "object" + }, + "schema": { + "type": "string" + } + }, + "type": "object" + }, + "charged": { + "description": "Legacy: true confirms settlement, false reports no settled charge for this attempt, null means unconfirmed. Never infer a refund or no charge from null.", + "type": [ + "boolean", + "null" + ] + }, + "code": { + "description": "Error code when the tool cannot fulfill this request.", + "type": "string" + }, + "created_at": { + "type": "number" + }, + "delivery_state": { + "description": "Legacy ledger state when returned by a job/retry observation.", + "type": "string" + }, + "error": { + "type": "string" + }, + "eta_s": { + "description": "Estimated queue delay, not a completion deadline.", + "type": "number" + }, + "id": { + "description": "Legacy opaque job identifier.", + "type": "string" + }, + "instructions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "job_id": { + "description": "Opaque server-returned job identifier; preserve it exactly.", + "type": "string" + }, + "kind": { + "description": "Stored job kind when exposed; production paid checks use token_risk, tx_guard or risk_panel.", + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "type": "string" + }, + "payment_receipt": { + "description": "Decoded receipt when available after settlement; historical encoded receipts may remain only in receipt_header.", + "properties": { + "network": { + "type": "string" + }, + "success": { + "type": "boolean" + }, + "transaction": { + "type": "string" + } + }, + "type": "object" + }, + "payment_status": { + "description": "Legacy ledger or error field. Use agent_guidance.payment for the explicit charge outcome.", + "enum": [ + "reserved", + "prepared", + "claiming", + "uncertain", + "settled", + "unknown" + ], + "type": "string" + }, + "prepaid": { + "type": "boolean" + }, + "receipt_header": { + "description": "Stored receipt when available. This is not a new payment proof to authorize or replay.", + "type": [ + "string", + "null" + ] + }, + "result": { + "description": "Conditional result. Paid results are released only after confirmed settlement; token/transaction jobs expose the saved paid response envelope, while prepaid panels expose their analysis object when ready. Legacy non-purchase jobs may expose their result directly. Absence never proves no charge." + }, + "retry_after_s": { + "description": "Free polling delay, not a deadline or instruction to authorize payment.", + "minimum": 1, + "type": "integer" + }, + "status": { + "description": "Analysis and payment are separate facts. ready/done can mean work finished while its paid result is still withheld; needs_review can concern payment or analysis. Read agent_guidance.payment and analysis.", + "enum": [ + "awaiting_payment", + "queued", + "running", + "processing", + "done", + "ready", + "failed", + "payment_processing", + "needs_review" + ], + "type": "string" + }, + "status_tool": { + "description": "Free tool to observe the existing retry; normally get_job_result.", + "type": "string" + }, + "status_url": { + "description": "Free GET path for this existing job; no settlement or analysis restart.", + "type": "string" + } + }, + "required": [ + "agent_guidance" + ], + "type": "object" +}
5 tool updates
- Changed
check_solana_token_risk4 fields changed- added
Input schema / properties / idempotency_key / descriptionAdded value: +"Optional canonical base64url encoding of 32 random bytes. Reuse with the original payment proof and identical inputs to recover a lost reply." - added
Input schema / properties / job_id / descriptionAdded value: +"Accepted job ID to echo with the original payment proof and identical inputs when recovering a call made without idempotency_key." - added
Input schema / properties / mint / descriptionAdded value: +"Base58 Solana token mint address to check before buying; not a transaction or token symbol." - added
Input schema / properties / prefer_async / descriptionAdded value: +"If work is queued or running, return a job status instead of waiting for completion. Poll get_job_result for free, then retry this tool with the same payment proof and inputs when ready; payment does not settle while processing."
- Changed
check_solana_transaction6 fields changed- added
Input schema / properties / idempotency_key / descriptionAdded value: +"Optional canonical base64url encoding of 32 random bytes. Reuse with the original payment proof and identical inputs to recover a lost reply." - added
Input schema / properties / intent / descriptionAdded value: +"Optional expected action object. Supported keys: max_sol_out (nonnegative SOL amount), expected_mints_in (array of base58 Solana token mint addresses), allowed_recipients (array of base58 Solana addresses). No other keys." - added
Input schema / properties / job_id / descriptionAdded value: +"Accepted job ID to echo with the original payment proof and identical inputs when recovering a call made without idempotency_key." - added
Input schema / properties / prefer_async / descriptionAdded value: +"If work is queued or running, return a job status instead of waiting for completion. Poll get_job_result for free, then retry this tool with the same payment proof and inputs when ready; payment does not settle while processing." - added
Input schema / properties / signer / descriptionAdded value: +"Optional base58 Solana address that must be a required transaction signer; omit to use the fee payer." - added
Input schema / properties / transaction / descriptionAdded value: +"Real unsigned Solana transaction (legacy or v0), serialized as base64; not a token mint or example placeholder."
- Changed
get_job_result1 field changed- added
Input schema / properties / job_id / descriptionAdded value: +"Job ID returned by a paid check or accepted queued request. Poll for status without another payment; a settled result is available here."
- Changed
quote_solana_risk_panel3 fields changed- added
Input schema / properties / advisors / descriptionAdded value: +"Optional comma-separated public advisor aliases from free GET /v1/advisors; omit to select all enabled advisors compatible with the token chain." - added
Input schema / properties / chain / descriptionAdded value: +"Optional CAIP-2 network ID of the token being analyzed, not the payment network. Defaults to Solana mainnet; other token chains are currently unsupported." - added
Input schema / properties / mint / descriptionAdded value: +"Base58 Solana token mint address to analyze through the paid HTTP panel."
- Changed
retry_failed_job1 field changed- added
Input schema / properties / job_id / descriptionAdded value: +"Job ID of a failed paid transaction or token check. Retry that job for free after get_job_result reports failure."
3 tool updates
- Changed
check_solana_token_risk4 fields changed- removed
Input schema / properties / idempotency_key / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / idempotency_key / typeAdded value: +"string" - removed
Input schema / properties / job_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / job_id / typeAdded value: +"string"
- Changed
check_solana_transaction9 fields changed- removed
Input schema / properties / idempotency_key / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / idempotency_key / typeAdded value: +"string" - added
Input schema / properties / intent / additionalPropertiesAdded value: +true - removed
Input schema / properties / intent / anyOfRemoved value: -[ - { - "additionalProperties": true, - "type": "object" - }, - { - "type": "null" - } -] - added
Input schema / properties / intent / typeAdded value: +"object" - removed
Input schema / properties / job_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / job_id / typeAdded value: +"string" - removed
Input schema / properties / signer / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / signer / typeAdded value: +"string"
- Changed
quote_solana_risk_panel4 fields changed- removed
Input schema / properties / advisors / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / advisors / typeAdded value: +"string" - removed
Input schema / properties / chain / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / chain / typeAdded value: +"string"
2 tool updates
- Changed
check_solana_token_risk2 fields changed- added
Input schema / properties / idempotency_keyAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Idempotency Key" +} - added
Input schema / properties / job_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Job Id" +}
- Changed
check_solana_transaction2 fields changed- added
Input schema / properties / idempotency_keyAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Idempotency Key" +} - added
Input schema / properties / job_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Job Id" +}
1 tool update
- Added
quote_solana_risk_panel
4 tool updates
- First observed
check_solana_token_risk - First observed
check_solana_transaction - First observed
get_job_result - First observed
retry_failed_job
Related MCP Connectors
Pay-per-call Solana token risk intelligence: 8 tools via x402. From $0.005 USDC, no API key.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Pay-per-call ($0.005-$0.03 USDC) market, on-chain, and prediction-market data API for AI agents and trading bots via x402 — no signup, no API key. Remote MCP server, 28 tools: token security (honeypot/liquidity/counterfeit checks), Hyperliquid oracle-gap risk, kimchi premium, funding APR, DEX slippage, Polymarket arbitrage/liquidity audits, Hyperliquid HIP-4 odds.
Related MCP Servers
AlicenseNot gradedqualityCmaintenanceGives AI trading agents machine-readable trust and risk verdicts on Solana by checking whether a wallet's realized PnL makes it worth copying, where its funds came from, whether a token is structurally safe, and what a given trade size would really cost in slippage. Exposes these four checks as MCP tools callable against a hosted x402 pay-per-call API, so agents can hard-stop bad trades without RPC keys, signup, or local setup.1MIT- AlicenseAqualityCmaintenanceOn-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.130 npm2MIT
- AlicenseAqualityCmaintenanceEnables MCP hosts and AI agents to request pay-per-call token risk assessments for contract addresses across Base, Ethereum, and Solana, returning a verdict, 0–100 risk score, six market-structure signals, and an analyst summary, with payment handled via x402 USDC on Base.1MIT
- AlicenseNot gradedqualityFmaintenanceMCP server for real-time Solana token risk analysis. Cross-references RugCheck.xyz, DexScreener, and GoPlus Security to generate three-layer reports: machine verdict → LLM analysis → raw on-chain evidence. Live on Solana mainnet with USDC micropayments ($0.02/audit). Give any AI agent the ability to check if a token is safe before trading.2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.