Skip to main content
Glama
Sign In

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

by io.github.corsur
OverviewDiscussionsAdmin

shillbot_get_attestation

Read-onlyIdempotent

[READ] Fetch a portable VOW v1 attestation for a Verified Shillbot task. Pass exactly one of task_pda (on-chain base58 — canonical, third-party verifiable) or task_id (orchestrator doc id, first-party). Returns the signed score/hash fields plus verifier_instructions; re-read the named PDA to verify — MCP does not sign. Footgun: the capture window is between verify_task and finalize_task — closed accounts return 409 (permanently unavailable).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "shillbot_get_attestation"
  }
}

Input Schema

NameRequiredDescriptionDefault
networkNoSolana network the task lives on: "mainnet" (default) or "devnet". Mismatched network = account not found = 409.
task_idNoFirestore doc id `<campaign_id>:<task_uuid>` (first-party path). Pass exactly one of task_id or task_pda.
task_pdaNoOn-chain Task PDA, base58 — the canonical VOW identifier, derivable from the public TaskCreated event (third-party path). Pass exactly one of task_id or task_pda.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotent, non-destructive, and open-world. The description adds meaningful behavioral detail: MCP does not sign the attestation, closed accounts return 409 permanently, and callers must re-read the PDA to verify. This goes well beyond the annotation signals and directly prevents misuse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficient. It front-loads the operation, states the main selection rule, summarizes the return contents, and ends with a high-value footgun. Every sentence carries operational information; no filler exists.

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

Completeness5/5

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

Despite lacking an output schema, the description tells the agent what the return contains, how to verify the result, which failure mode to expect (409), and when in the task lifecycle the call is valid. Combined with full schema coverage and strong annotations, this is complete enough for correct invocation.

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%, and the schema already explains task_pda, task_id, and network semantics thoroughly. The description restates the 'exactly one' constraint and canonical vs first-party distinction, but these are largely duplicated from the schema, so it adds limited new parameter-level meaning.

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 is specific: it names the verb ('Fetch'), the resource ('a portable VOW v1 attestation for a Verified Shillbot task'), and the exact identifier modes. It is clearly distinct from all sibling tools such as shillbot_get_task_details, shillbot_verify_task, and shillbot_finalize_task.

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?

The description gives strong contextual guidance: pass exactly one of task_pda or task_id, and the valid capture window is between verify_task and finalize_task. It does not explicitly name an alternative tool or state 'use X instead of Y', but the lifecycle condition effectively tells an agent when this tool applies.

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