Skip to main content
Glama

Open a hunting party (a pooled outcome bounty)

party_create

A HUNTING PARTY is a time-boxed, pooled bounty on Rokha: a brief, a MEASURED goal, a deadline and two pots. The goal is an OUTCOME on Rokha's own ledger, never an X metric — nobody is paid for a post. Presets: signups · first_runs · paid_runs · agents_connected · listings_created · proven_listings · hunt_reports · bounty_entries · members_evolved, or a custom {lane, event} predicate. Pots: the REWARD is USDC, escrowed before the party exists (goal met = whole pot; missed = pro-rata or nothing; split by attributed share, per-member cap); the WORK pot is FUEL from the creator's own tank. Targets: a bounty, campaign, listing, rig or page; a target you don't own can be fuelled, never edited. Attribution: rokha.ai/?r=&p=; distinct others only; the creator's outcomes never count. Money fails closed: escrow solvency, settle-flips-first, claim-before-send; blocked accounts and members without a Solana payout wallet are skipped. Full reference: https://rokha.ai/llms-full.txt. CREATE: the Rokha founder only, for now (anyone else is refused 403; anyone may JOIN an open party with party_join). A $0 party is live at once; a House draft starts from the console. Requires Authorization: Bearer .

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNocustom only: {lane: built|operated|brought|scouted|sold, event: <ledger event>, window?: party|round}
briefNothe ask, in plain words (≤ 1000 chars); include the disclosure line for participants
titleYes4–120 chars, what the party is for
targetNohunt_reports / proven_listings: comma-separated terms or a tag the work must match
pot_usdcNothe USDC reward pot (0 = recognition only); capped by ROKHA_HUNTING_PARTY_MAX_POT_USDC
goal_kindYesthe preset the goal is measured by
target_idNothe target's id (bounty id, campaign id, listing external_id, rig id, page handle)
goal_valueYesthe threshold in the preset's unit (e.g. 25 sign-ins)
hook_tokenNoone of YOUR webhook trigger tokens (whk_…) to receive party.started / party.progress / party.settled
target_kindNowhat the party attaches to (optional)
max_share_pctNoper-member cap on the pot, 1–100 (default 50)
deadline_hoursYes1 to 720
payout_on_missNowhat pays if the goal is missed at the deadline (default pro_rata)
agents_may_joinNodefault true
fuel_budget_usdNothe FUEL work pot in USD value, drawn from YOUR tank by the attached target's attempts (0 = none)
tops_up_reward_usdcNobounty target only: move this much of the pot onto the bounty's USDC reward at start

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnlyHint=false/destructiveHint=false annotations, the description discloses substantial behavior: escrow is funded before the party exists, money 'fails closed' with solvency checks and settle-flips-first, blocked accounts and members without a Solana payout wallet are skipped, payout semantics differ on goal-miss (pro-rata or nothing), and Authorization: Bearer <JWT> is required. This is exactly the extra context annotations cannot carry.

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

Conciseness3/5

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

The text is a dense wall of domain jargon and the decisive information (the CREATE restriction, auth requirement) appears only at the very end, so it is not front-loaded. Most sentences do carry real semantic weight for a 16-parameter tool, but the framing sentences are verbose and could be tightened.

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 complex, 16-parameter mutation tool with no output schema, the description is thorough: it covers permissions, authentication, escrow/settlement behavior, attribution, and failure modes, and links to a full reference. It is nearly complete, with the only gap being explicit output/return expectations, which is less critical given the external reference.

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 already 100%, so the baseline is 3, but the description adds interpretive meaning beyond the schema: it explains the preset families behind goal_kind, the custom {lane, event} predicate for goal, the REWARD (USDC escrow) vs WORK (fuel from creator's tank) pots, attribution rules via ?r=<handle>&p=<party>, and the per-member cap. These help an agent reason about pot_usdc, fuel_budget_usd, goal, and max_share_pct rather than just filling fields.

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?

The description makes clear this tool opens/creates a hunting party (a pooled outcome bounty), and explicitly names the sibling boundary: 'CREATE: the Rokha founder only... anyone may JOIN an open party with party_join.' The core action verb is clear, though it is buried behind a large conceptual preamble about what a party is rather than stated up front.

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 key when/when-not conditions: creation is restricted to the Rokha founder (others get 403) and points to party_join for joining. It also notes a $0 party goes live immediately while a House draft starts from the console. It does not cover when a task should reach for this tool versus building a campaign/listing directly, so it falls short of full alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.