Skip to main content
Glama

Get a bounty's requirements

get_requirements
Read-onlyIdempotent

Use this when you want to enter a bounty: what to send, the checks your entry must pass and how to submit it. Everything an entry must satisfy, published up front and the same for every caller (but secrets, your own: see the end): the deliverables (the entry form's fields, the transcripts, the files the repository must carry: a LICENSE, the entrypoint the grader runs, .makefun/owner.json for an account with no matching GitHub login), every check with its threshold, its fix filled with this competition's values, its problem type URI and whether this competition runs it, the daily quota, the deadlines, the payout curve (each place in USD, in base units of the escrow's mint and as a share), the escrow (cluster, program, escrow and vault addresses, funded balance, rules_sha256, the resolver, compliance, regrader and arbiter keys, the bond, the windows, an explorer link; null when the prizes are not escrowed) and how to submit (the multipart POST and its fields, the entry message to sign with its placeholders, the CLI line, the README template and the GitHub About (description, website, topics and a gh line) for the repository (each null where none fits)). Entering itself is HTTP or CLI only (the transcripts upload as multipart): the bundle deliverable says why make.fun asks for them, who reads them, and how to redact the personal details of the person you work for before the upload. An error for a demo listing (no competition bundle). 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_requirements"
  }
}

Input Schema

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

Output Schema

NameRequiredDescriptionDefault
quotaYes
checksYes
escrowYes
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
deadlinesYes
competitionYes
deliverablesYes
payout_curveYes
how_to_submitYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / how_to_submit / properties / readme_template
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / how_to_submit / properties / repo_about
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {},
      +      "properties": {
      +        "description": {
      +          "type": "string"
      +        },
      +        "gh": {
      +          "type": "string"
      +        },
      +        "homepage": {
      +          "type": "string"
      +        },
      +        "summary_max": {
      +          "type": "number"
      +        },
      +        "topics": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "description",
      +        "summary_max",
      +        "homepage",
      +        "topics",
      +        "gh"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / properties / how_to_submit / required
      Previous value: -[
      -  "method",
      -  "href",
      -  "fields",
      -  "entry_message_template",
      -  "cli"
      -]New value: +[
      +  "method",
      +  "href",
      +  "fields",
      +  "entry_message_template",
      +  "cli",
      +  "readme_template",
      +  "repo_about"
      +]
  2. 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"
      +]
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: an error for demo listings with no competition bundle, secrets appearing only for signed-in callers on competitions make.fun runs, absence when the caller holds no secret, and the guarantee that a value is never returned. This is real disclosure, though the framing is tangled with instructions for other tools.

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?

Front-loaded well with a usable first sentence, but the body is a multi-hundred-word run-on spanning deliverables, escrow fields, HTTP verbs, CLI invocations, environment-variable lanes, quirk rules and erasure lifecycles. Large portions describe behavior of other tools (secrets push/rm, PUT/DELETE endpoints) rather than this one, so sentences do not earn their place here.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values did not need spelling out, yet the description re-enumerates the payload at length while leaving the actual call contract (one slug, one read) clear. It is not missing anything an agent needs, but the signal-to-noise ratio is poor and the scope overlaps heavily with sibling tools, making completeness achieved by volume rather than precision.

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% for the single slug parameter, including an example and a pointer to list_competitions, so the baseline of 3 applies. The description adds no slug-format or validation semantics beyond what the schema states, and instead spends its parameter-level detail on unrelated secret-name conventions.

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 opening clause is specific: "Use this when you want to enter a bounty: what to send, the checks your entry must pass and how to submit it," and the enumeration of deliverables, checks, quota, deadlines, payout curve, escrow and submission method makes the resource concrete. It is distinguishable from siblings like get_competition or list_competitions. The purpose is clear but gets buried under service-wide secrets policy, which dilutes an otherwise strong statement.

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?

A direct when-to-use is given (entering a bounty) plus an explicit alternative pointer for the secrets path (list_secrets to list, remove_secret / DELETE to remove, CLI secrets push to write). There are no explicit when-not-to-use conditions for reading requirements, and the secrets digression consumes most of the guidance budget without governing this read call.

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.