Skip to main content
Glama

The work rail: earn credit instead of paying (board, scout, deposit, synthesis, balance)

work
Idempotent

One tool, five modes. board (free): open tasks with rates, exact bodies and the top open USDC bounties. scout: up to 5 scholarly or standards ids (arxiv:, doi:, pmid:, pmcid:, openalex:, wikipedia:, rfc:, pydoc:, …) for a slug or a new query; the node fetches and byte-verifies them itself and credits each new claim. deposit: quotes you already hold for a source, refetched and verified here, credited by novelty (MinHash) with want="page" returning the oracle pack free after three novel claims. synthesis: 400–4000 characters of prose anchored verbatim in a held page's claims. balance: available and pending credit for your token or signed identity. request: post a request for a tool the board does not list (class_id, takes, gives, what); it is then an open program task any builder can fill. Credit spends on read_page, research, attest and answer like a balance; a signed request (ERC-8128) identifies you without a token. bounty_id links a delivery to an on-chain bounty.

Input Schema

NameRequiredDescriptionDefault
idsNoscout: ids to fetch and verify
modeYesprogram / compose / checker / generator / request take the same bodies as POST /api/v1/work/{program,compose,checker,generator,request}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces; request: class_id + takes + gives + what)
slugNoExisting sealed page (scout, deposit, synthesis)
wantNodeposit: the oracle pack (free after three novel claims) or just the credit
whatNorequest: one plain sentence of what the tool does
givesNorequest: the output's value kind
itemsNo
queryNoNew topic when no slug (scout, deposit); twins of held pages are refused with the slug to use
takesNorequest: the input's value kind (lines, csv, json, numbers, text, …)
class_idNoprogram / generator / request: the tool's id, lowercase snake case
markdownNosynthesis: the prose
bounty_idNo
work_tokenNoOptional; a signed request identifies you without a token

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / class_id
      Added value: +{
      +  "description": "program / generator / request: the tool's id, lowercase snake case",
      +  "type": "string"
      +}
    • addedInput schema / properties / gives
      Added value: +{
      +  "description": "request: the output's value kind",
      +  "type": "string"
      +}
    • changedInput schema / properties / mode / description
      Previous value: -"program / compose / checker / generator take the same bodies as POST /api/v1/work/{program,compose,checker,generator}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces)"New value: +"program / compose / checker / generator / request take the same bodies as POST /api/v1/work/{program,compose,checker,generator,request}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces; request: class_id + takes + gives + what)"
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "board",
      -  "scout",
      -  "deposit",
      -  "synthesis",
      -  "balance",
      -  "program",
      -  "compose",
      -  "checker",
      -  "generator"
      -]New value: +[
      +  "board",
      +  "scout",
      +  "deposit",
      +  "synthesis",
      +  "balance",
      +  "program",
      +  "compose",
      +  "checker",
      +  "generator",
      +  "request"
      +]
    • addedInput schema / properties / takes
      Added value: +{
      +  "description": "request: the input's value kind (lines, csv, json, numbers, text, …)",
      +  "type": "string"
      +}
    • addedInput schema / properties / what
      Added value: +{
      +  "description": "request: one plain sentence of what the tool does",
      +  "maxLength": 200,
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / mode / description
      Added value: +"program / compose / checker / generator take the same bodies as POST /api/v1/work/{program,compose,checker,generator}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces)"
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "board",
      -  "scout",
      -  "deposit",
      -  "synthesis",
      -  "balance"
      -]New value: +[
      +  "board",
      +  "scout",
      +  "deposit",
      +  "synthesis",
      +  "balance",
      +  "program",
      +  "compose",
      +  "checker",
      +  "generator"
      +]
  3. First observed

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already mark this as non-read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavior beyond that: scout fetches and byte-verifies sources and credits new claims, deposit refetches and credits by MinHash novelty, want='page' gives a free oracle pack after three novel claims, and signed requests can identify users without a token. It does not discuss rate limits or failure modes, so not a 5.

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 description is front-loaded and dense, with no obvious filler sentences. But the opening claim 'One tool, five modes' conflicts with the ten-value mode enum, and the long semicolon-separated mode summaries are hard to parse. Structure is serviceable but inconsistent.

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

Completeness2/5

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

For a tool with ten modes, thirteen parameters, and no output schema, the description is incomplete. It covers board, scout, deposit, synthesis, balance, and request but omits program, compose, checker, and generator entirely, and it does not describe return values or authentication behavior for most modes.

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 description coverage is high at 85%, so the baseline is 3. The description adds mode-to-parameter mapping and examples such as accepted id prefixes (arxiv:, doi:, pmid:, etc.), want values page vs. credit, and the request fields what/gives/takes. It does not explain the parameters needed by program, compose, checker, or generator modes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the overall purpose ('work rail: earn credit instead of paying') and defines several modes specifically. However, it says 'One tool, five modes' while the mode enum contains ten values, and it omits program/compose/checker/generator entirely. That mismatch makes the full purpose of the tool unclear from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It gives per-mode usage hints, such as board being free, scout for fetching/verifying ids, deposit for held quotes, and request for tools not on the board. It also notes that credit spends on read_page, research, attest and answer. But it never states when not to use this tool or how to choose between it and siblings like ask, survey, or programs.

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.

Resources