RugShield

check_solana_token_risk

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.

Input Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 30, 2026

addedInput schema / properties / idempotency_key / description

Added value: +"Optional canonical base64url encoding of 32 random bytes. Reuse with the original payment proof and identical inputs to recover a lost reply."

addedInput schema / properties / job_id / description

Added value: +"Accepted job ID to echo with the original payment proof and identical inputs when recovering a call made without idempotency_key."

addedInput schema / properties / mint / description

Added value: +"Base58 Solana token mint address to check before buying; not a transaction or token symbol."

addedInput schema / properties / prefer_async / description

Added 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."

Changed4 schema fields changedSep 29, 2026
- removedInput schema / properties / idempotency_key / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / idempotency_key / type
```
Added value: +"string"
```
- removedInput schema / properties / job_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / job_id / type
```
Added value: +"string"
```

Changed2 schema fields changedSep 28, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}

addedInput schema / properties / job_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Job Id"
+}

First observedSep 25, 2026

TDQS

A4.1/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All RugShield tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?