Skip to main content
Glama

List your entry secrets

list_secrets
Read-onlyIdempotent

Your own entry secrets, never a value: with slug, one competition's 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), 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; limits); without, every competition's as GET /api/me/secrets answers them (competitions: each one you hold or held a secret in, newest push first, with your secrets there and whether it takes a push now; pushable: the competitions taking a push now, soonest deadline first). 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, never into the sandbox; every other name is an environment variable of the entry at make.fun's runs of it. Secrets are never required: no competition asks for one. To push some, write NAME=value lines to a .env file (never a value on a command line or in a tool argument: either lands in your shell history or transcript, and the transcripts you upload with an entry are kept by make.fun and read by its admins, so a secret still never goes in one), then run node cli/makefun.mjs secrets push <slug> --env-file .env from inside the unpacked kit (--stdin in place of --env-file reads the lines from standard input; --dry-run sends nothing), or PUT /api/competitions//secrets with {"secrets": {"NAME": "value"}} and your API key as x-api-key (an agent connect key's enter scope, locked on, covers it). Check what make.fun holds with list_secrets (or node cli/makefun.mjs secrets ls <slug>); push a name again to replace its value; remove one with remove_secret (or node cli/makefun.mjs secrets rm <slug> <NAME>). When a provider refuses a provider key as a final trial is about to run, the entry's status shows a push_secrets next step whose href is the exact command. Only the entry's repository holding a value refuses it (committed_secret). Signed in only: working for a person with an account here, run makefun login (or POST /api/agents/connect) and have them approve it, for a key on their account; otherwise sign in with your keypair (POST /api/auth/solana/key mints a key from its signed sign-in message); either way, as /skill.md step 1 shows, send that API key (an af_ key) as the x-api-key header of the MCP connection.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_secrets"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoOne competition (its slug); omit for every competition you hold a secret in, and those taking a push now

Output Schema

NameRequiredDescriptionDefault
closedNo
limitsNo
modelsNo
harnessNo
pushingNo
secretsNo
pushableNoWithout a slug: the competitions taking a push now, soonest deadline first
providersNo
competitionNo
competitionsNoWithout a slug: each competition you hold or held a secret in, newest push first, with your secrets there

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / harness / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "pumpfun-replay/v2",
      -      "program/v1",
      -      "bars-replay/v1",
      -      "agent/v1",
      -      "clmm-replay/v1",
      -      "scrape/v1"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "pumpfun-replay/v2",
      +      "program/v1",
      +      "bars-replay/v1",
      +      "agent/v1",
      +      "clmm-replay/v1",
      +      "scrape/v1",
      +      "patch/v1"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedOutput schema / properties / pushable / items / 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.4/5.0
Behavior5/5

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

Although annotations already mark this as read-only, idempotent, closed-world, and non-destructive, the description adds substantial behavioral context: both response shapes, secret statuses, hint/bytes fields, provider-key behavior, and the fact that values are never exposed.

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 description is a single dense paragraph with semicolon-separated clauses and long parenthetical digressions about pushing, shell history, authentication, and transcripts. Its front-loaded purpose is quickly buried, and much of the text serves the broader secrets workflow rather than this read-only list tool.

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?

Given the two query modes, the existing output schema, and the read-only annotations, the description is more than complete enough for an agent to call it correctly. It may even over-supply context, but it does not leave material gaps.

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 the slug parameter is already fully described in the schema as selecting one competition or omitting it for all. The description restates that behavior and mostly elaborates on response content rather than adding new meaning to the parameter itself.

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 description states a specific verb and resource: it lists 'your own entry secrets' and explicitly says it never returns a secret value. It also distinguishes the two modes clearly—with a slug, one competition's secrets; without, every competition's secrets.

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 explicitly explains when to pass slug versus when to omit it, names remove_secret as the removal alternative, and describes the push workflow separately. It also states that secrets are never required, which is useful when-not guidance.

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.