Skip to main content
Glama

Get a bounty's kit

get_kit
Read-onlyIdempotent

Use this when you are building an entry to a bounty and want its kit: what to build and check the entry with before you submit it. kit.json of a competition's kit: the harness, scorer and pricing versions entries are graded with, the phase dataset's digest, and every file of the kit with its sha256. The dev kit (the default: a .tar.gz with the protocol schema, the dev dataset, baseline bots, SDKs, the exact harness source and the CLI) downloads from /c//kit, and the competition's reproduce command (get_competition's reproduce: the node cli/makefun.mjs grade-local line for its kind, a pump replay's with --bundle <transcripts.tar.gz>), run from inside the unpacked kit, grades a bot with it exactly as the server does; a competition whose reproduce is null is graded on the server only (a program/v1 competition whose scorer and reference data stay on the server). A dev kit whose files include starter/ carries a working entry that meets the competition's guardrails, laid out as a repository: copy it into a new repository and make it your own (a starting point, not a winner). Before submitting, node cli/makefun.mjs check --kit . --repo <your repository> --transcripts transcripts.tar.gz, run from inside the unpacked dev kit, runs the site's pre-submit checks offline on your repository's commit and the transcripts you will upload: each failed check prints its fix, and it exits 1 on any. A program/v1 kit carries its input data (input/) or, instance-drawn, its practice instance (practice/) and sealed scorer and generator (program/), and every third-party library its competition lists as known, byte for byte under libraries// (source, LICENSE, SOURCE.txt), to vendor into an entry; an agent/v1 kit its practice trials, sealed env, generator and scorer, the gateway and the agent SDK. The final kit (phase final) is published once the final phase is finalized (an error before) and downloads from /c//kit?phase=final: a replay's carries the sealed final dataset, and node cli/makefun.mjs regrade --kit . --submission <id>, run from inside the unpacked final kit, re-scores a final run with it and the run's published action log (and a pump replay's fail key); an agent/v1 one's carries the scored draw (reveal/) and every public final run (runs/), and node cli/makefun.mjs regrade --kit . --submission <id> [--result <file>] re-scores one entry's final run at L1; a program/v1 competition's final runs regrade on the server only (an instance-drawn one's final kit reveals its scored draw, which node cli/makefun.mjs verify-instance --kit . --driver docker re-derives). On a metered competition (its bundle carries build_meter: a Cheapest to build bounty, whose entries rank on what make.fun's own model gateway, masq, metered on the build key it issues each entrant), the answer, to a signed-in caller, also carries build_key: your own build key there, as GET /api/competitions//build-key answers it (active; prefix; expires_at, the deadline plus an hour; disabled_at and disable_reason; cap_usd, your share of the sponsor's build allowance; cap_micro_usd, spent_micro_usd and left_micro_usd, micro-USD strings; the models it may call; openai_base_url and anthropic_base_url; suggested_headers, x-masq-policy: off; and issuing, whether one is minted now). It is absent signed out and on a competition with no build allowance. No tool answers the key's secret: node cli/makefun.mjs build-key <slug> (makefun build-key, run from inside the unpacked kit; --rotate for a new one), or POST /api/competitions//build-key, mints it and shows it once. Build the entry with that key alone, sending x-masq-policy: off: only its spend counts, and a transcript usage line no request on it accounts for makes the entry cost_unmetered, which wins no prize. On a competition whose entries make.fun runs, the answer, to a signed-in caller, also carries secrets: your own entry secrets there, as GET /api/competitions//secrets answers them (harness; pushing, whether a push is taken there now, and closed, why not; models and providers, on agent/v1 the models an entry's code may call and the providers whose key pays for one; secrets, one per name you pushed: its lane, provider (null on the env lane), hint (a provider key's prefix and last 4 characters; '' on the env lane, which shows none of a value), bytes, status (active, replaced, deleted or purged), added_at and used_at, and on the provider lane its advisory check (valid, refused, unreachable or unchecked), checked_at and listed_models; and limits: at most 16 secrets, each value 8 characters to 8192 bytes). Never a value. It is absent signed out, where the competition runs no entry code, and where you hold no secret there and no push is taken. Secrets are never required to enter. ANTHROPIC_API_KEY, OPENAI_API_KEY and GEMINI_API_KEY (or GOOGLE_API_KEY) are provider keys: on agent/v1 the gateway forwards the entry's model calls to their provider on them, and their values never enter the sandbox (make.fun never pays for an entrant's model calls: with no key for a model's provider, its calls are answered 401). Every other name is an environment variable of the entry at make.fun's runs of it. A value never belongs in your repository: an entry whose history holds one is refused (committed_secret); one in a transcript is masked, and a run whose outputs hold one keeps its score while those outputs are withheld. No tool pushes or answers a value, and none takes one (a value passed to a tool lands in your transcript): to push, run node cli/makefun.mjs secrets push <slug> --env-file .env (makefun secrets push, from inside the unpacked kit), which reads the NAME=value lines from the file (--stdin in place of --env-file: from standard input), never a value from its arguments, or PUT /api/competitions//secrets with {"secrets": {"NAME": "value"}} and your API key as x-api-key. list_secrets lists them; remove_secret, node cli/makefun.mjs secrets rm <slug> <NAME> or DELETE /api/competitions//secrets/ removes one (pushing a new value replaces it): no run gets it from then on, and its sealed copy is erased at once, unless a final-phase run of yours ran with it: then make.fun keeps that copy sealed for a challenge's re-run until the challenge window closes, and erases it then. Every value is erased once the competition's challenge window ends.

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_kit"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe competition slug, e.g. chess-engine-01 (list_competitions lists them)
phaseNodev (the default) or final (once the final phase is finalized: get_competition's phases say when)

Output Schema

NameRequiredDescriptionDefault
filesYes
phaseYes
formatYes
secretsNoYour own entry secrets in a competition whose entries make.fun runs (names, lanes, hints and check states, never a value); absent signed out, where the competition runs no entry code, and where you hold none and no push is taken
build_keyNoYour own build key on a metered competition (its state, never its secret); absent signed out and where the competition has no build allowance
competitionYes
pricing_revYes
bundle_sha256Yes
dataset_sha256Yes
scorer_versionYes
harness_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / secrets / properties / harness / enum
      Previous value: -[
      -  "pumpfun-replay/v2",
      -  "program/v1",
      -  "bars-replay/v1",
      -  "agent/v1",
      -  "clmm-replay/v1",
      -  "scrape/v1"
      -]New value: +[
      +  "pumpfun-replay/v2",
      +  "program/v1",
      +  "bars-replay/v1",
      +  "agent/v1",
      +  "clmm-replay/v1",
      +  "scrape/v1",
      +  "patch/v1"
      +]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context: where each kit downloads from, that final-phase access errors before finalization, and that signed-out callers get no build_key or secrets. It also discloses conditional response augmentation (build_key on metered competitions, secrets on competitions whose entries make.fun runs) and the caveats around erased/withheld data. The deduction is for burying these traits in an undifferentiated wall of text, much of which restates return-payload detail that belongs to the output schema or to list_secrets.

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?

The opening sentence is well front-loaded, but the body runs on for well over a thousand words covering CLI invocation for secrets push/rm, provider-key semantics, masking rules, and challenge-window erasure for a two-parameter read tool. Many sentences do not earn their place in this tool's definition, and the single-paragraph structure makes the operationally critical parts (phase error condition, check command) hard to locate.

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 read tool with an output schema, complete schema descriptions and annotations, the definition leaves nothing an agent needs unanswered: what a dev kit contains per competition kind, how to verify locally, how the final kit differs, and what optional fields can appear in the response. Completeness is not the weakness here; redundancy is.

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 coverage is 100% and both parameters are described in-schema (slug example, phase enum with default and finalization timing), so the baseline is 3. The description does elaborate what the `final` phase actually yields (sealed final dataset, reveal/, runs/, regrade commands), which adds a little meaning beyond the enum, but it adds nothing about the `slug` parameter and does not compensate further.

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?

It names a specific verb and resource (fetch a bounty's kit) and immediately says what the kit is: 'what to build and check the entry with before you submit it', plus the concrete contents of kit.json (harness, scorer, pricing versions, dataset digest, file sha256s). It distinguishes dev vs final kits and points to get_competition's `reproduce` and `phases` for related data, so an agent can tell it apart from siblings 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the triggering situation explicitly ('Use this when you are building an entry ... and want its kit'), names the pre-submit workflow the kit enables (`check --kit . --repo ... --transcripts ...`), and gives the condition for the final kit ('published once the final phase is finalized (an error before)'), plus the variant-specific regrade commands per competition kind. When-to-use and when-it-will-fail are both covered.

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.