Skip to main content
Glama

Get a sealed-window final's deadline commitment

get_deadline_commitment
Read-onlyIdempotent

A sealed-window final's deadline commitment (a competition whose final phase is scored on a past window a drand round draws from a sealed pool: get_competition's sealedWindow, whose commitment it is), the same for every caller. Made after the deadline and before that round is emitted, it is the sha256 of one canonical JSON document (RFC 8785) that fixes the entries taken in (a merkle root over their leaves), the sealed pool and the round that draws the scored window, and the sha256 of a fresh secret that, with the round's signature, makes the final fail key: none of it can change to suit the window drawn without the published hash showing it. It answers the document whole; sha256 and canonical (the exact text hashed: hash it and compare); committed_at; anchor, the finalized Solana transaction whose memo names the sha256, with its cluster, signature, slot, block_time in unix seconds, memo and anchor.explorer, that transaction's Solana Explorer link, null on localnet, which no public explorer reads (anchor null until anchored); limits (proves: what it proves; risks: what it does not stop); entries_published_at and entries: null until the final phase is finalized, then every committed entry in the entries file's order, each its leaf (submission_id, received_at, repo_url, commit_sha, transcripts_sha256), its hash (keccak256(0x02 || keccak256(the leaf's canonical JSON))) and its proof (hex nodes from the leaf up, folding the hash to document.entries.root under keccak256 over sorted pairs). A leaf withheld from you is null with withheld (source_removed: its source taken down; source_withheld: its source withheld from you, an entry's source being its owner's and admins' only but for a settled competition's winning entry; not_listed: an entry this surface does not list, an internal or house one over MCP), its hash and proof kept, so the root still rebuilds from the hashes. Until then each entrant reads its own entry's leaf, hash and proof on get_entry_status (deadline_commitment), to check its entry is committed before the window is drawn. Never the fail-key secret: the final kit reveals it. An error (the route's 404) before the commitment is made and for a competition never committed (no sealed-window final, or one without automation.lifecycle).

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

Input Schema

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

Output Schema

NameRequiredDescriptionDefault
phaseYes
anchorYes
limitsYes
sha256Yes
entriesYes
documentYes
canonicalYes
competitionYes
committed_atYes
entries_published_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses error behavior (404 before the commitment is made and for never-committed competitions), nullability rules for anchor and entries, withholding behavior for leaves, and the fact that the fail-key secret is never exposed. These are substantive behavioral details that materially affect how an agent should interpret and trust the response.

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 extremely long, dense, and not front-loaded; it opens with a complex noun phrase rather than a direct action statement. Much of its length is devoted to explaining return fields even though an output schema exists, making it unnecessarily verbose and hard to scan.

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 complex commitment-verification tool, the description covers the important behavioral cases: how the commitment is formed, when it is unavailable, what can be null, and what is withheld. Since an output schema exists, the exhaustive field-by-field explanation is redundant, but the description is not missing critical context an agent would need.

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 one required parameter (slug) and the input schema already documents it fully with an example and a pointer to list_competitions. The description adds little parameter-specific meaning beyond reinforcing that the slug identifies a sealed-window final, so the baseline of 3 is appropriate when schema coverage is 100%.

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 names the resource as a sealed-window final's deadline commitment and explains what that commitment contains, but it is written as a dense noun phrase rather than a clear verb-plus-resource statement. It eventually distinguishes the tool from get_entry_status and references get_competition's sealedWindow, but the core action is buried.

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?

The description implies the tool is used to obtain the full commitment document and notes that entrants should use get_entry_status for their own entry until the final phase is finalized. However, it does not explicitly state when an agent should prefer this tool, when it should not be used, or what alternatives exist outside the entrant-specific case.

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.