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

shillbot_complete_task

Read-onlyIdempotent

[READ] Single-call "what do I do next?" wrapper that collapses the multi-step Shillbot task lifecycle into one ask-then-execute loop. Pass a task_id; the tool reads the current on-chain + Firestore state, figures out whether you're the AGENT (claimer) or CLIENT (campaign owner) for this task, and returns a structured next_action block with the exact next tool to call and its arguments. The lifecycle has unavoidable external waits (T+7d oracle window for YouTube, client review, challenge window) — this tool surfaces them as wait actions with a not_before timestamp instead of a tool call. Re-call after each step (or after the wait elapses). Returns done when the task is Finalized.

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>"
    },
    "name": "shillbot_complete_task"
  }
}

Input Schema

Name	Required	Description	Default
`network`	No	Solana network: "mainnet" (default) or "devnet". Mismatched network = the on-chain accounts won't be found.
`task_id`	Yes	The task identifier (format: `<campaign_id>:<task_uuid>`) of any task in your lifecycle — the tool answers "what do I do next" for it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it explains that the tool reads on-chain + Firestore state, detects the caller's role, surfaces external waits with not_before timestamps, returns exact next tool/args, and terminates with done. This is rich behavioral context with no contradiction.

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 each sentence adds distinct information: role detection, next_action return, wait semantics, re-call behavior, and terminal done state. It is somewhat long for a single paragraph but stays front-loaded with the core 'what do I do next' purpose.

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?

Without an output schema, the description compensates by explaining the return shape at the level of next_action, wait, and done. It covers the complex lifecycle behavior and external-wait cases; exact JSON field names are not enumerated, but the agent has enough to call and interpret the result.

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?

The input schema already covers both task_id and network with 100% coverage, so description doesn't need to carry parameter docs. It adds a small usage nuance ('any task in your lifecycle') but nothing that materially changes the semantic 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?

Description names a specific behavior: a read-only 'what do I do next?' wrapper that determines the next lifecycle action for a task_id and returns a structured next_action block. It distinguishes itself from siblings such as shillbot_approve_task or shillbot_get_task_details by positioning itself as the orchestrator that collapses the multi-step lifecycle.

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 clearly says to pass a task_id and to re-call after each step or after a returned wait elapses, which specifies the operating rhythm. It doesn't explicitly name exclusions or alternatives, but the orchestrator framing and references to lifecycle waits make the intended use obvious relative to the task-specific sibling tools.

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 tools Inspect

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.