Skip to main content
Glama

get eval evidence

get_eval_evidence
Read-onlyIdempotent

Download a signed evidence bundle for a completed eval run with verdicts, judge calibration, sample lineage, refusals, and audit attestation to share with reviewers or auditors as one verifiable JSON.

Instructions

Download the forwardable proof bundle for a DONE eval run — verdict, frozen judge calibration and certificate, per-sample verdict lineage, refusal ledger events and an audit hash-chain attestation, optionally with the embedded CI-gate decision — so a customer can hand a reviewer or auditor one signed JSON that links claim to instrument to data. GET /v1/evals/{id}/evidence (API-key scope: read). Returns: 200 bundle (snake_cased): {signature|null, unsigned?:true (when no signing secret is configured), bundle_v:1, generated_at, run:{id, workspace_id, name, eval_kind, status:"DONE", created_at, sample_count, baseline_model, candidate_models, judge_model, rubric_type, sample_filters, assertions}, results (verdict verbatim), gate:{params, verdict}|null (only when at least one gate param was given), instrument:{judge_model, judge_prompt, criterion_snapshot, certificate|null, note|null}, samples:{count, note, lineage:[{sample id, every verdict with the ordering that measured it ("ab"/"ba" pairwise halves, "abs" absolute, "sim" screening similarity), prompt/answers only with with_content}]}, content:{included, reason}, refusals:{window_days, scope, count, complete, events:[{kind, subject, reason, created_at}]}, attestation:{ok, checked_rows, head_seq, problems:[{seq, kind, detail}], acknowledged, window:{since, until, from_seq}|null, chain_head:{seq, last_hash}|null, statement}}. Notes: 404 for a run outside this key's workspace. 412 {code:"precondition_failed"} for any run that is not DONE (PENDING/RUNNING/ERROR/CANCELLED) — fail closed like the gate; poll until DONE. with_content silently degrades (never errors) when request logging is off. Read-only, no spend.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe eval run id (must be DONE).
modelNoRestrict the embedded gate checks to one arm/model key.
min_win_rateNo0..1. Embed the same gate evaluation as GET /v1/evals/{id}/gate: every candidate's win-rate CI lower bound must clear this. Values outside 0..1 or non-numeric are ignored.
with_contentNoPass the literal string "true" to include sampled prompts and generated answers in samples.lineage. Honoured only when the workspace has request logging (content storage) enabled; otherwise lineage stays ids/verdicts only and content.reason explains why. Default: false.
min_pass_rateNo0..1. Criterion runs: corrected pass-rate CI lower bound (observed CI when the judge is unvalidated) must clear this.
noninferiority_marginNo0..1. The certified switch test (see get_eval_gate).
min_assertion_pass_rateNo0..1. Exact all-assertions pass rate must clear this.
Install Server

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, idempotent, and not destructive, and the description adds substantial behavioral context: 'Read-only, no spend,' 404/412 error specifics, silent degradation of with_content when logging is off, unsigned bundles when no signing secret exists, and 'fail closed like the gate.' No contradiction with annotations exists.

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?

The description is long, but the length is largely justified by the absence of an output schema: the detailed return payload must live somewhere. It front-loads purpose and uses compact, structured formatting for the response fields. Some redundancy exists (e.g., 'Read-only, no spend' overlaps with annotations), but the density is mostly earned.

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 tool's complexity, seven parameters, and no output schema, the description is remarkably complete: it specifies the exact response shape, conditional fields, error codes, silent degradation behavior, and authentication scope. An agent has enough information to invoke the tool correctly and interpret the response.

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 description coverage is 100%, so the baseline is 3. The description mentions with_content degrading and gate parameters being embedded, but it does not add much beyond the schema's own parameter descriptions. It is adequate but not additive.

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 names a specific action ('Download the forwardable proof bundle') and a specific resource ('a DONE eval run'), then enumerates the bundle's contents in detail. It clearly differentiates this from sibling tools like get_eval_samples or get_eval_gate by emphasizing the audit/attestation purpose.

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?

The description states when the tool applies ('for a DONE eval run', 'hand a reviewer or auditor') and gives operational guidance: poll until DONE, fail closed, 404 outside workspace. It does not explicitly name alternatives or say when not to use this versus get_eval_gate or get_eval_samples, but the purpose and conditions are clear enough for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/omnia-v/errorbar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server