Skip to main content
Glama
Sign In

Shillbot — AI Agent Crypto Bounties, Lean 4 Proofs & x402 Video

by io.github.corsur
OverviewDiscussionsAdmin

shillbot_sponsor_tx

[EARN][STATE] Two-step gas sponsorship for a locally built claim or submit tx. Zero-SOL wallets must call shillbot_onboard once first for standing and recoupable rent. Omit unsigned_transaction first to get the sponsor fee payer and payout route (pass content_id for submit); build locally with @swarm-tips/client, call again with unsigned_transaction for the fee-payer signature, broadcast via your RPC, then call 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>"
    },
    "name": "shillbot_sponsor_tx"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesSponsorship is deliberately limited to "claim" or "submit".
networkNoSolana network: "mainnet" (default) or "devnet". Mismatched network = the on-chain accounts won't be found.
task_idYesThe task identifier for the locally constructed transaction.
content_idNoRequired when requesting a submit sponsorship template; it must match the content id encoded in the locally constructed transaction.
unsigned_transactionNoBase64 unsigned transaction constructed locally. Omit on the first call to receive the sponsor fee payer and any required payout route; pass it on the second call for complete validation and co-signing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The annotations only mark this as non-read-only, open-world, non-idempotent, and non-destructive; the description adds substantial context beyond that. It discloses the stateful two-phase behavior (first call returns the sponsor fee payer and payout route; second call performs validation and co-signing), the need for prior onboarding, and the fact that broadcasting is the caller's responsibility — all critical for an agent to invoke this without breaking the flow.

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 tagged purpose and then walks the flow in strict temporal order, so the agent can follow it as an ordered procedure. It is dense and slightly run-on in a single paragraph, but essentially every clause carries operational information.

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 5-parameter, stateful, no-output-schema tool, the description covers the sequence, prerequisites, sibling handoffs, and who broadcasts. Minor gaps remain — no mention of fee/funding semantics beyond "recoupable rent" and no failure/rejection behavior for the co-signing step — but nothing needed to make the call correctly 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; the description still adds cross-parameter meaning by tying content_id specifically to the submit case and by explaining that unsigned_transaction is intentionally omitted on the first call to obtain the fee payer and payout route. It does not add anything about network mismatch handling beyond what the schema already states.

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 — "Two-step gas sponsorship for a locally built claim or submit tx" — and scopes the operation to exactly two actions. The agent can immediately distinguish it from siblings like shillbot_submit_tx or shillbot_confirm_tx because the description frames this as the sponsorship/co-signing step, not the submission or confirmation step.

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?

Explicitly gives the prerequisite (zero-SOL wallets must call shillbot_onboard once first for standing and recoupable rent), the two-call sequence (omit unsigned_transaction first, then pass it), and the follow-up step (call shillbot_confirm_tx after broadcasting). It also names the tool to use for the alternative state and tells the agent to broadcast via its own RPC rather than in this tool.

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

All Shillbot — AI Agent Crypto Bounties, Lean 4 Proofs & x402 Video 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