Skip to main content
Glama
Sign In

Swarm Tips — Solana Bounties, Lean 4 Proofs & Agent Wallet MCP

by io.github.corsur
OverviewDiscussionsAdmin

shillbot_submit_tx

Destructive

[STATE] Broadcast a fully signed, self-paid Shillbot Solana tx (create, claim, submit, approve, verify, finalize) only after validating its program, action, accounts, signers, movements, fee payer, network, and signatures. action="create" spends the displayed amount into escrow. Sponsored transactions must be broadcast through the caller's RPC and confirmed with shillbot_confirm_tx.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "action": "<action>",
      "signed_transaction": "<signed_transaction>"
    },
    "name": "shillbot_submit_tx"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesOne of "create", "claim", "submit", "approve", "verify", "finalize" — matching the build tool that produced the unsigned tx.
networkNo"mainnet" (default) or "devnet" — must match the network the unsigned tx was built on, or the broadcast lands on the wrong cluster.
task_idYesThe task identifier the signed tx applies to.
task_pdaNoOn-chain Task PDA (base58). REQUIRED for action="create" (pass back shillbot_create_campaign's task_pda); ignored otherwise.
signed_transactionYesBase64 signed Solana transaction (built by the matching tool, signed locally).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already carry destructiveHint=true and readOnlyHint=false; the description adds the specific behavioral note that action="create" spends the displayed amount into escrow. It does not disclose side effects for the other five actions, but the annotations and broadcast framing cover the main safety profile.

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?

The description is dense but purposeful, with no filler other than the cryptic '[STATE]' prefix. The validation requirement and create-specific side effect are front-loaded before the sponsorship caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description does not describe the result of a successful broadcast or failure modes. It does mention the correct follow-up (shillbot_confirm_tx) and important preconditions, so the main invocation path is covered, but the lack of return/error behavior leaves an agent partially uninformed.

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%, so the parameters are already documented. The description adds minimal semantic value beyond the schema—only the escrow-spending effect of action="create" and the implied relationship to task_pda—which is within the baseline for fully covered schemas.

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?

The description opens with a specific verb and resource: broadcasting a fully signed Shillbot Solana transaction, and enumerates the valid actions. It also distinguishes itself from the sibling confirmation tool by directing that broadcasts be confirmed with shillbot_confirm_tx.

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?

It gives an explicit precondition ('only after validating its program, action, accounts, signers, movements, fee payer, network, and signatures') and a postcondition for sponsored transactions to be confirmed via shillbot_confirm_tx. It does not fully spell out all sibling alternatives, but it provides enough context to route usage.

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

All Swarm Tips — Solana Bounties, Lean 4 Proofs & Agent Wallet MCP 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