Skip to main content
Glama

Rokha

by ai.rokha
OverviewDiscussionsAdmin

Signet — request an action (deploy / pay / trade)

signet_action

Step 3: DO it. Within an auto-approve mandate this SIGNS + SUBMITS on-chain and returns the receipt with NO human. SOLANA (chain 501, a mandate with a session_address): pay/transfer payload {to, amount} in base units (lamports), or {to, amount, mint} for an SPL token — the tx is simulated before signing and refuses honestly (target must be in the mandate's allowlist; value must equal amount; caps metered). On a plain wallet connection it returns an unsigned_tx for you to sign — then signet_submit. Over the mandate's limit it escalates to the owner. deploy payload: {name, symbol} → a real coin via the launch pad (EVM testing adapter). x402 (buy a paid HTTP resource): action_type 'x402', target = the resource URL, value = your USDC CEILING (base units) for this call — Signet does the 402 → pay → retry round trip, pays the exact price under your ceiling from the mandate's session wallet (Solana exact-scheme, USDC), and returns the resource; the unspent headroom is released. Requires Authorization: Bearer .

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesmust match a mandate you granted
chainNo
valueNovalue moved, wei (for pay/transfer)
targetNothe contract/recipient (for pay/transfer/call)
payloadNothe action detail — deploy: {name, symbol}; pay: {to, amount}
action_typeYes
human_summaryYesone line: exactly what this does

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds significant behavioral context beyond the sparse annotations: simulation before signing, refusal conditions, cap metering, x402 retry round trip, headroom release, and escalation. Since annotations only provide readOnlyHint/destructiveHint, the description carries the burden and does so richly.

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?

Dense but organized: each section (mandate, Solana, wallet, deploy, x402) adds necessary operational detail. Front-loaded with the main purpose. Slightly long but justified by the tool's complexity.

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?

Covers auth requirement, chain specifics, payload schemas, and return behavior (receipt, unsigned_tx, resource). Missing explicit guidance for trade/mint/sign/call action types, but the tool's complexity makes the description largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema describes 5 of 7 params, and the description adds crucial semantics: value as lamports/wei/USDC ceiling, target as recipient/URL, payload formats for each action_type, and chain 501 for Solana. This exceeds the schema detail and clarifies ambiguous fields.

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 action: 'SIGNS + SUBMITS on-chain and returns the receipt'. Distinguishes itself from signet_submit by describing when it returns an unsigned_tx. Enumerates concrete payload formats for deploy, pay/transfer, and x402.

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 on a plain wallet connection it returns unsigned_tx and then directs the agent to signet_submit. Also describes escalation to owner over mandate limit and auto-approve behavior, giving clear conditions for use. It doesn't compare against all sibling signet tools like approve/deny/grant, but provides sufficient routing guidance.

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

All Rokha 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