Skip to main content
Glama
Sign In

RugShield 402

by io.github.ak10082247-max
OverviewDiscussionsAdmin

rugshield_pre_swap_scan

Read-only

Simulates buy/sell orders via state overrides to detect honeypots, compute exact transfer taxes in bps, and verify pool liquidity depth. Cost: 0.010 USDC on Base & Solana Mainnet.

Input Schema

NameRequiredDescriptionDefault
token_addressYesTarget ERC-20 contract address on Base (0x...) or Solana SPL Mint

Output Schema

NameRequiredDescriptionDefault
tokenNoNormalized token address
symbolNoVerified ticker symbol
risk_scoreYesComposite risk score (0.0 safe to 1.0 extreme risk)
buy_tax_bpsNoBuy tax in basis points
is_honeypotYesWhether token prevents selling
risk_factorsNoIdentified risk vectors
sell_tax_bpsNoSell tax in basis points
liquidity_usdNoVerified USD liquidity
recommendationYesExecution verdict

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "buy_tax_bps": {
+      "description": "Buy tax in basis points",
+      "type": "integer"
+    },
+    "is_honeypot": {
+      "description": "Whether token prevents selling",
+      "type": "boolean"
+    },
+    "liquidity_usd": {
+      "description": "Verified USD liquidity",
+      "type": "number"
+    },
+    "recommendation": {
+      "description": "Execution verdict",
+      "enum": [
+        "SAFE",
+        "CAUTION",
+        "DANGER_HONEYPOT"
+      ],
+      "type": "string"
+    },
+    "risk_factors": {
+      "description": "Identified risk vectors",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "risk_score": {
+      "description": "Composite risk score (0.0 safe to 1.0 extreme risk)",
+      "type": "number"
+    },
+    "sell_tax_bps": {
+      "description": "Sell tax in basis points",
+      "type": "integer"
+    },
+    "symbol": {
+      "description": "Verified ticker symbol",
+      "type": "string"
+    },
+    "token": {
+      "description": "Normalized token address",
+      "type": "string"
+    }
+  },
+  "required": [
+    "is_honeypot",
+    "risk_score",
+    "recommendation"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / token_address / description
      Previous value: -"Target ERC-20 contract address on Base (0x...)"New value: +"Target ERC-20 contract address on Base (0x...) or Solana SPL Mint"
  3. Changed2 schema fields changed
    • removedInput schema / properties / chain_id
      Removed value: -{
-  "default": 8453,
-  "type": "integer"
-}
    • removedInput schema / properties / simulate_sell
      Removed value: -{
-  "default": true,
-  "type": "boolean"
-}
  4. First observed

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly and non-destructive behavior; the description correctly reinforces this by explaining the mechanism (simulation via state overrides, so no real swap occurs). It also adds cost (0.010 USDC) and supported chains (Base, Solana Mainnet), which are valuable behavioral facts not in the annotations. An output schema exists, so return values need not be described.

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?

Two compact sentences: the core behavior is front-loaded, and the cost/chain constraint is isolated. Dense but not padded; only minor gain from splitting the long first sentence.

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 one-parameter, read-only scan with an output schema and clear annotations, this covers the essentials: mechanism, what it detects, cost, and supported chains. The main omission is sibling differentiation, which an agent needs in this crowded tool family.

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 description coverage is 100% and the single token_address parameter is fully documented in the schema as a Base ERC-20 or Solana SPL Mint. The description reinforces the chain scope but adds no format or validation detail beyond the schema, so baseline 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 specific verbs and resources: simulates buy/sell orders via state overrides, detects honeypots, computes transfer taxes in bps, verifies liquidity depth. This is clear and concrete, but it never distinguishes itself from sibling tools like check_honeypot, analyze_liquidity, or rugshield_audit_swap_simulation_proof, which appear to overlap heavily.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'pre_swap' framing implies the usage context (checking a token before trading), and the cost line implies a paid scan. However, there is no explicit when-to-use/when-not guidance and no mention of when to prefer check_honeypot or analyze_liquidity instead, leaving the agent to infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All RugShield 402 toolsInspect
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