Loading ToolBench
Agent toolkit and OpenClaw skill for interacting with the RIFT contest protocol
The rift-agent-kit exposes 15 tools for interacting with the RIFT contest protocol on Solana. Tool naming is consistent (all verb_noun with 'rift_' prefix) and descriptions are present and reasonably detailed. However, several critical gaps emerge: (1) Parameter descriptions in schemas are sparse or missing depth, most input schemas contain only basic type and description, with no constraints (enums, ranges, formats) documented. (2) No output schemas are documented anywhere, the code returns structured objects but LLMs have no contract for what fields to expect, breaking the pattern of structured responses. (3) Parameters like 'contestId' (number), 'fundingAmount' (string|number union), and 'params'/'metadata' (generic objects) lack validation rules, constraints, or guidance on expected formats. (4) No error handling guidance is visible, tools do not return actionable recovery hints on failure. (5) Stateful blob handling (prepare_submission → commit_submission + reveal_submission) requires agents to preserve and correctly pass opaque Base64-encoded JSON blobs; this is error-prone and underdocumented. (6) Generic object parameters like 'params' and 'metadata' in create_contest and create_and_fund_contest offer no schema guidance, agents must guess what fields to include. These gaps prevent LLMs from using the tools confidently and force trial-and-error discovery.
Claim the reward for the backend signer wallet after contest finalization.
Commit a prepared review blob for a submitter wallet during the review phase.
Commit a prepared submission blob during the commit phase.
Create a new RIFT contest and fund its reward pool. Funding burns 1% on-chain.
Create a contest on RIFT without funding it yet.
Finalize a contest once it has reached the ended state.
Generic object parameters ('params', 'metadata') lack schema definition. Agents cannot determine what fields to pass. rift_create_contest and rift_create_and_fund_contest accept 'params' as object with no nested schema, forces agents to guess structure.
No output schemas documented. Tools return structured objects (protocol config, contests, submissions) but LLMs have no contract for response fields, types, or nesting. This breaks the pattern of structured responses and forces LLMs to parse JSON by trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Fund an existing contest reward pool. The protocol burns 1% of the gross amount on-chain.
Fetch a single contest by contestId and return status, phase, reward pool, and counters.
Read the current protocol configuration and global contest counters from Solana.
Join a contest as the backend signer wallet by staking RIFT.
List contests from the RIFT protocol directly from on-chain data.
Prepare a review blob that contains the hidden salt needed for commit-reveal review flow.
Prepare a commit-reveal submission payload. Agents must keep the returned blob and use it later for both commit and reveal.
Reveal a prepared review blob for a submitter wallet during the review phase.
Reveal a prepared submission blob during the reveal phase.
Numeric and string parameters lack constraints. 'contestId' (number) has no range; 'fundingAmount' accepts string|number with no validation guidance; 'score' (0-1,000,000 per description) lacks min/max in schema. Agents can pass invalid values without immediate feedback.
Opaque blob parameters ('preparedSubmission', 'preparedReview') require agents to preserve and correctly pass Base64-encoded JSON. No schema documents the blob structure (SerializedPreparedSubmission, SerializedPreparedReview exist in code but not in tool definitions). This is fragile and error-prone.
No error handling guidance. Tools do not document failure modes, recovery steps, or actionable error messages. If a commit fails (wrong phase, invalid contestId, etc.), LLMs have no guidance on what to try next.
Tool naming compounds multiple actions (rift_create_and_fund_contest). Split into separate, single-responsibility tools so agents can compose them flexibly. Current naming signals the tools do >1 thing.
Parameter descriptions are brief (10 - 30 chars) and lack actionable guidance. E.g., 'Contest ID' does not explain format, constraints, or where to find one.
No pagination or result limits documented. rift_list_contests returns all contests, no limit param, no pagination guidance. If protocol has thousands of contests, response could exhaust context window.