Skip to main content
Glama

Submit Tier 0 answers and receive a score report

submit_eval

Submit Tier 0 answers for automatic scoring. Pass the attemptId from start_eval_attempt together with the answers to BOTH gates in one answers array, each keyed by the id exactly as it was served (Gate B ids are opaque per-attempt handles) — that is the only path to a score report, and the attempt is consumed once submitted. Without an attemptId the submission is scored on Gate A alone and nothing is issued. Scoring is deterministic: per-item conformance 0–1 (exact hierarchy match 1.0, adjacent code 0.5), weighted mean per gate. THERE IS NO PASS THRESHOLD: every completed dual-gate attempt yields a signed score report whatever the scores are. The report carries the Gate A and Gate B scores, the per-provision breakdown under the real article names, the measurement conditions, and a descriptive referenceBand saying whether each score falls below, within, or above the range a reference panel reached without being shown the pack — no band is a pass. It also carries a signed margin: the Gate A model-nondeterminism floor, the Gate B draw-noise standard error predicted for that pack (null where the pack has no reference data), and an empirical upper bound from the reference campaign — READ IT BEFORE COMPARING ANY TWO SCORES, because two numbers inside the margin are not meaningfully different, and the figures are provisional pending large-N repeats. Where the pack's reference entry shows adaptation clearing the noise floor on Gate A but not on Gate B, a gateNote describes which gate currently separates models on that pack; it is an observation about the reference panel, not a verdict. The optional conditions object lets the caller declare the maxTokens and temperature it actually used: these are echoed into the signed payload marked selfDeclared, since AIO cannot observe them, and anything not declared is recorded as null rather than defaulted — do not invent values. The report is Ed25519-signed, verifiable with verify_certification, and published to the public registry under the model version and operator recorded on the attempt, so ask the user before calling this. The 0.7 gate figure and 0.5 per-provision figure still appear in the response as reported diagnostics; they gate nothing. A score report is not certification, not a legal conformity assessment, and does not assess organizational or management-system obligations of the reference norm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packIdNoRequired without an attemptId, e.g. "eu-ai-act". With one, cross-checked against the attempt.
answersYesOne entry per item. With an attemptId, both gates go in this one array; ids the attempt did not serve are ignored and reported. Unanswered items score zero.
attemptIdNoThe attempt id from start_eval_attempt. Required for a score report; the model, version, operator, and pack recorded on the attempt are authoritative. Omit it to score Gate A only.
modelNameNoRequired without an attemptId. With one, optional and cross-checked against the attempt.
conditionsNoSelf-declared runner conditions, echoed into the signed report under `conditions.runner` with `selfDeclared: true`. Declare only what the runner actually used — AIO cannot check these, so the signature attests that you stated them, not that they happened. Omit a key you do not know: it is recorded as null (undeclared) and nothing is defaulted in its place.
operatorUrlNoOptional http(s) URL of the operator. Published in the registry.
modelVersionNoRequired without an attemptId. With one, optional and cross-checked against the attempt.
operatorNameNoRequired without an attemptId. The organization accountable for operating the model.
operatorEmailNoRequired without an attemptId. Recorded, never published in the registry.
registrationIdNoOptional id returned by register_for_certification. Recorded but not verified.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses: the attempt is consumed; report is signed and published to a public registry; there is no pass threshold; scores must be compared only outside the margin; figures are provisional; conditions are self-declared and unverifiable. It also disclaims certification status. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long (~600 words), it is well structured and mostly front-loaded with the essential flow. Some redundancy around the no-pass-threshold message ('no band is a pass', 'they gate nothing', 'is not certification') but these each nuance the point, so the length is defensible for the tool's complexity.

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?

The description covers prerequisites, input semantics, output report contents, interpretation guidance (margin), side effects, and limitations (provisional, not certification). With no output schema, it fully describes the return payload. It also addresses edge cases like missing reference data and undeclared conditions, making it suitable for an agent to invoke correctly with minimal additional info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds key semantics beyond the schema: explains how `answers` must interleave Gate A and Gate B ids, the opaque per-attempt handles, ignored ids, and zero-scoring for unanswered items; explains `conditions` are unverifiable and undeclared keys become null; clarifies `attemptId` is required for a report and params are cross-checked against the attempt. Given 100% schema coverage, this is substantial value-added.

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?

First sentence uses the specific verb 'Submit' with a concrete resource ('Tier 0 answers') and the title clarifies the deliverable ('score report'). It clearly distinguishes from siblings like start_eval_attempt and verify_certification by explaining the exact path to a score report and the consequence of omitting attemptId.

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?

Explicitly instructs to pass attemptId from start_eval_attempt and states this is 'the only path to a score report'. It warns about side effects (publication, attempt consumption) and says 'ask the user before calling this'. Also clarifies when Gate A-only scoring occurs and points to verify_certification for signature verification.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: fetching items vs. distributions, listing vs. fetching specific entities, and distinct submission endpoints for benchmark, eval, and RFC comments. Even the two 'get items' tools (bench vs. eval) are clearly differentiated by their descriptions and use cases.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores. Verbs are grouped by action type (get_, list_, submit_, start_, register_, verify_, search_), and the patterns are predictable and uniform across the set.

Tool Count4/5

At 17 tools, the set is slightly above the ideal 3-15 range but each tool serves a distinct purpose. The breadth of the domain (papers, RFCs, standards packs, benchmarks, evaluation, certification, vocabulary, search) justifies the count, and no tool feels redundant.

Completeness4/5

The tool surface covers the major workflows: listing and fetching resources, starting and submitting evaluation attempts, registering and verifying certifications, and submitting benchmark/RFC responses. Minor gaps exist, such as no direct tool to cancel an evaluation attempt or list a specific benchmark run by id, but these are edge cases and the core lifecycle is well-covered.