Skip to main content
Glama
Sign In

WattCoin

by io.github.WattCoin-Org
OverviewDiscussionsAdmin

WattCoin: Claim SwarmSolve bounty

claim_solution
Idempotent

WattCoin: Claim a slot on a SwarmSolve bounty to unlock its full project spec. Limits apply: a cap on claims per bounty and on active claims per wallet, a GitHub account of minimum age with a public repo, and a minimum WATT balance in the wallet. Re-claiming returns the spec again. There is no submit tool: deliver by opening a PR on the bounty's target_repo that references the issue and puts your wallet in the PR body; the requester approves the winning PR.

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": {
      "solution_id": "<solution_id>",
      "wallet": "<wallet>",
      "github_username": "<github_username>"
    },
    "name": "claim_solution"
  }
}

Input Schema

NameRequiredDescriptionDefault
walletYesSolana wallet address, base58, 32-44 characters (e.g. 7vvNk...). Holds the minimum WATT balance and receives the payout
solution_idYesSolution ID from list_solutions
github_usernameYesYour GitHub username, e.g. octocat; the account must meet the age and repo requirements

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / github_username / description
      Previous value: -"Your GitHub username"New value: +"Your GitHub username, e.g. octocat; the account must meet the age and repo requirements"
    • changedInput schema / properties / solution_id / description
      Previous value: -"Solution ID"New value: +"Solution ID from list_solutions"
    • changedInput schema / properties / wallet / description
      Previous value: -"Your Solana wallet"New value: +"Solana wallet address, base58, 32-44 characters (e.g. 7vvNk...). Holds the minimum WATT balance and receives the payout"
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the mutation/idempotency annotations it discloses real operational constraints: caps per bounty and per wallet, GitHub account age plus a public repo, and a minimum WATT balance. The note that re-claiming returns the spec is consistent with idempotentHint=true and confirms the call is safe to repeat, and the absence of a submit tool is a crucial behavioral fact an agent would otherwise miss.

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?

Four tight sentences: purpose first, then limits, then re-claim behavior, then the post-claim workflow. No filler and nothing redundant with schema or annotations.

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?

For a mutating, hard-limited tool with no output schema, the description covers eligibility prerequisites, retry semantics, and what the caller receives, plus what to do after claiming. Nothing essential is missing for a correct invocation.

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 meaning by specifying what the wallet is checked against (minimum WATT balance, receives payout) and that github_username must satisfy age and public-repo requirements the schema only alludes to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb and resource: 'Claim a slot on a SwarmSolve bounty to unlock its full project spec', which tells an agent exactly what the call produces. It doesn't contrast itself with the similar-named sibling claim_task, so sibling differentiation is only partial.

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 states the condition for calling (to unlock the full spec) and notes that re-claiming simply returns the spec again, so an agent knows it can be retried safely. The end-to-end delivery path is spelled out too ('no submit tool: deliver by opening a PR...'), though it never says when to prefer claim_task over this tool.

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

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