Pre-sign Solana tx guard for agents: ALLOW/WARN/BLOCK verdict, x402 USDC pay-per-call.
Scored across 1 tool
There is only one tool, so there is no risk of confusing it with another operation. Its purpose is clearly and narrowly defined as a pre-signing Solana transaction safety check.
The single tool uses a clear snake_case verb_noun-like naming pattern: shield_guard_check. Although there is no broader naming set to compare against, the name is readable and follows a consistent convention.
The server is intentionally narrow, and the one tool is substantive rather than trivial. However, a single-tool surface is thin by general MCP standards and leaves little room for adjacent safety operations such as batch checks or simulation.
For the stated domain of pre-signing transaction safety checks, the tool covers key outcomes (NO_MATCH, WARN, BLOCK), plain-language reasons, signed receipts, x402 payment checks, and error handling. Minor gaps may exist around batch or policy-management workflows, but the core lifecycle is well covered.
Use this before an agent or wallet signs a Solana transaction. Decodes the unsigned or signed transaction and returns NO_MATCH (no known-bad pattern matched; not a safety guarantee), WARN, or BLOCK, with plain-language reasons and a signed receipt. Pass an x402 quote to also check a payment transaction against it (overpay, approve-instead-of-transfer, unchecked Transfer, wrong payee). Errors return ERROR and are never charged. Price $0.009 USDC (x402, Solana).
| Name | Required | Description | Default |
|---|---|---|---|
| tx | Yes | Base64 wire transaction (also accepts an RPC getTransaction result). | |
| caps | No | Optional spend caps you declare; any violation returns BLOCK. Keys: max_amount (int base units per outflow), max_amounts ({mint|'SOL': int}), max_total (int per asset), allowed_payees ([pubkey]; owners' ATAs match), allowed_assets ([mint|'SOL']), allow_approvals (bool, default false). | |
| quote | No | x402 quote the tx pays: {asset, amount, pay_to | pay_to_token_account, decimals?, token_program?}. | |
| strict | No | Escalate HIGH-risk token approvals (unlimited or third-party delegate) from WARN to BLOCK. Default false. | |
| wallet | No | Your own pubkey; only this key is treated as 'you'. | |
| simulate | No | Simulate against Solana mainnet (Helius RPC, sigVerify off, recent blockhash replaced, never submitted). Default true; false = static checks only. If simulation fails the verdict is at least WARN, except plain System/Token/ATA/ComputeBudget/Memo transactions with no unresolved lookup tables, which are fully decoded statically. Third-party unlimited approvals BLOCK by default. Response includes risk_score (0-100), basis (simulated|static) and top_reason. | |
| cap_base_units | No | Hard per-payment cap enforced even if the quote asks for more. | |
| known_addresses | No | Optional: pubkeys you have recently paid or received from. A recipient that only looks like one of these (same first/last characters) is flagged as address poisoning. |
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: NO_MATCH is explicitly caveated as not a safety guarantee, errors return ERROR and are never charged, and the price is disclosed. It further gives simulation semantics (default true, failure escalates to WARN) and default BLOCK behavior for third-party unlimited approvals.
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-loads the essential usage and verdict semantics in the opening sentences, then adds quote behavior and pricing. Dense but no filler; the pricing sentence is the only item that could arguably be shortened.
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 an 8-parameter tool with nested objects and no output schema, the description explains the verdict scale, receipt, risk_score/basis/top_reason fields, error behavior, and cost. It stops short of detailing receipt contents or ERROR conditions in depth, but the schema fully documents every parameter.
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 baseline is 3, but the description adds real meaning by explaining what passing an x402 quote enables (overpay, approve-instead-of-transfer, unchecked Transfer, wrong payee checks) and that tx supports unsigned or signed wire transactions. Other parameters are left entirely to the already-complete 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?
States a specific verb and resource: decodes a Solana transaction and returns NO_MATCH/WARN/BLOCK verdicts before signing. The concrete return values and receipt output leave no ambiguity about what the tool does, and there are no siblings to confuse it with.
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 to use it before an agent or wallet signs a Solana transaction, which is a clear triggering condition. It also explains the optional quote-driven payment check, though it does not state when *not* to use it or name alternatives (none exist here).
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.
shield_guard_check1 field changedInput schema / properties / simulate / descriptionPrevious value: -"Simulate against Solana mainnet (Helius RPC, sigVerify off, recent blockhash replaced, never submitted). Default true; false = static checks only. If simulation fails the verdict is at least WARN, never NO_MATCH."New value: +"Simulate against Solana mainnet (Helius RPC, sigVerify off, recent blockhash replaced, never submitted). Default true; false = static checks only. If simulation fails the verdict is at least WARN, except plain System/Token/ATA/ComputeBudget/Memo transactions with no unresolved lookup tables, which are fully decoded statically. Third-party unlimited approvals BLOCK by default. Response includes risk_score (0-100), basis (simulated|static) and top_reason."shield_guard_checkPre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Dry-run Solana txs before agents sign: exact balance changes, intent match, token traps. 25 free/day
Solana wallet forensics SDK, x402 pay-per-call, AI agents.
Add one secure layer between your agents and this server.
