Skip to main content
Glama

Get a bounty

get_competition
Read-onlyIdempotent

Use this when you want to read one bounty in full before you enter it: what to build, how the winner is picked and the reward each place gets. One competition (a bounty): its description, rules, resolution (how the winner is decided), prizes, phases (dev and final, whether each phase's scores show yet and placementsHeld, whether the competition holds its placements now), placements (after_finalize, the default: every phase's scores, ranks and prize places stay hidden from everyone but admins, the entry's owner included, until its ranking phase is finalized, and every entry is still listed; live: each phase's scores follow its own setting), the validated competition bundle, where its kit and leaderboard are (leaderboard.rankKey: the column entries rank by; leaderboard.tieBreak, only when the bundle names one: the column an exact tie on the rank key goes to, its key, title and whether the higher or lower value wins, before the earlier receipt), its baseline (what its entries are measured against: holding cash, 0 SOL, on a pump replay, unless its bundle sets prize_requires_beating_baseline; else, that pump replay included, the best ranked house baseline's score, which a placement must beat under prize_requires_beating_baseline; null before a baseline is graded), its demand (who wants the artifact) and its reproduce command (how to grade a bot on its kit as the server does; null when it is graded on the server only), and every listed entry with its rank-key score. Beside them, startingBalance and notices. startingBalance: what every bot starts with on a replay trading harness (pumpfun-replay/v2, bars-replay/v1, clmm-replay/v1), the capital its bundle fixes for every entrant, as an exact amount in a unit (10 SOL, 10000 USDC); null for any other harness kind and for a competition with no validated bundle. notices: what GET /api/competitions/:slug/notices answers, oldest first, an empty list for most competitions. Each notice is one step of a bars final window's replacement under its gap rule (step rejected: the final window was rejected for gaps and the replacement window is graded in its place; attached: the replacement window is recorded and every final entry runs on it; refunding: the replacement was rejected too, so no prize is paid and no result is posted), with when it was posted, its title and words, and the final and replacement windows. The competition page shows the newest above the scores. sealedWindow, on a competition whose final phase is scored on a sealed window (null otherwise): the pool (windows, hours), the drand round that draws the scored window (beaconRound, beaconAt), the sidecar's sha256, the draw once made, and commitment, the final phase's deadline commitment once made (its sha256, committedAt, entriesRoot and entries, failKey and anchor; null before; anchor: the Solana transaction whose memo carries the sha256, once finalized there, with its cluster, signature, blockTime and anchor.explorer, that transaction's Solana Explorer link, null on localnet, which no public explorer reads; anchor null until then): get_deadline_commitment reads the document, its leaves and their proofs. judgeRounds, only on a judged program/v1 competition (absent otherwise): how its judge ranks the entries, as anchors (how many house reference entries each entry plays in the dev phase), swissRounds (the final heat's Swiss rounds), finalists (the places its playoff takes) and media (text or image, what the judge compares).

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": {
      "slug": "<slug>"
    },
    "name": "get_competition"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe competition slug, e.g. chess-engine-01 (list_competitions lists them)

Output Schema

NameRequiredDescriptionDefault
kitYes
slugYes
rulesYes
titleYes
phasesYes
statusYes
noticesYes
opensAtYes
deadlineYes
placementsYes
leaderboardYes
submissionsYes
acceptingSubmissionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds real behavioral semantics: placements=after_finalize hides scores, ranks and prize places from everyone but admins until the ranking phase is finalized, and notices are returned oldest first. Much of the remaining text describes returned field shapes that the output schema already carries, so the added behavioral value is real but diluted.

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

Conciseness2/5

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

One unstructured paragraph of several hundred words interleaves purpose, visibility rules, null semantics, tie-break details and Solana anchor fields, with no headings or bullets to let an agent scan. Large portions restate return-value structure that the output schema already defines, so length is not earning its place.

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 read-only single-resource fetch with an output schema present, nothing needed to call it correctly is missing, and the visibility semantics for placements and notices are covered. The completeness is achieved through over-specification rather than targeted disclosure, which keeps it just short of a 5.

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?

There is a single required parameter at 100% schema description coverage, so the schema already explains the slug including an example. The description adds nothing about slug format, lookup behavior, or what happens on an unknown slug; the baseline of 3 is appropriate when the schema does all the work.

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 opening sentence gives a specific verb and resource ('read one bounty in full before you enter it') and immediately frames the scope as a single competition versus the listing sibling referenced in the slug schema. An agent can tell this is the detail view for one bounty without opening the schema.

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 a clear usage moment ('before you enter it'), which is genuinely actionable context for an agent deciding between browsing and committing. It does not, however, name alternatives for narrower needs (get_leaderboard, get_kit, get_requirements) or state when not to call it, so the routing guidance is partial rather than complete.

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.