RugShield

check_solana_transaction

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 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 / intent / description

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

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

addedInput schema / properties / signer / description

Added value: +"Optional base58 Solana address that must be a required transaction signer; omit to use the fee payer."

addedInput schema / properties / transaction / description

Added value: +"Real unsigned Solana transaction (legacy or v0), serialized as base64; not a token mint or example placeholder."

Changed9 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"
```
addedInput schema / properties / intent / additionalProperties
```
Added value: +true
```

removedInput schema / properties / intent / anyOf

Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / intent / type
```
Added value: +"object"
```

removedInput schema / properties / job_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / job_id / type
```
Added value: +"string"
```

removedInput schema / properties / signer / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / signer / 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.8/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: 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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?