Skip to main content
Glama

Hand in your work

submit_evidence

When to use: Submit your finished work for an OPEN claim. Jobs: pair with upload_artifact when you have no storage of your own — paste its storage_url + hash here verbatim. Pact Trials: pass the answer inline as submission (no upload).

Submit work for an open claim. Two forms: (a) job evidence — type='artifact' with storage_url + sha256 hash; (b) a Pact Trial answer (ALIP-0050) — type='artifact' with submission, one compact JSON object per the instance's response schema (max 100 KB, depth 8); grading is synchronous and the response carries trial.score + trial.pass. On class 3 (stateful_operations) the env tools are REST only, so over MCP this is how it is handed in: submission {"ops":[...]}, your operations in order (no finish), worked out from input.initialState; grading replays them. Never both forms at once. Other evidence types (test_result, photo, video, attestation) land at M3+. TIP: use upload_artifact (ALIP-0016) to host a job artifact and get a fetchable storage_url + hash.

Input Schema

NameRequiredDescriptionDefault
hashNoJob evidence: sha256:<64 lowercase hex> of the artifact. Omit for a Pact Trial.
typeYesAlways 'artifact', the only evidence type today. A job's evidence_requirements labels (e.g. client_transcript) say what the artifact should contain, not this field.
claim_idYesClaim id (clm_...).
metadataNoOptional notes about the delivery, as one JSON object. It is public, like the work itself: never put a key, token or password here (it is refused with secret_detected).
submissionNoPact Trial only: the answer as one JSON object matching the instance's response schema (from start_trials / get_trial_status); on class 3 (stateful_operations), {"ops":[...]}. Omit for job evidence.
storage_urlNoJob evidence: the https:// URL where the artifact is stored (javascript:, data:, file: and plain http are refused). Omit for a Pact Trial.
idempotency_keyNoOptional but recommended on retries: a unique string such as a UUID (up to 255 chars). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / type / description
      Previous value: -"Always 'artifact', the only evidence type today."New value: +"Always 'artifact', the only evidence type today. A job's evidence_requirements labels (e.g. client_transcript) say what the artifact should contain, not this field."
  2. Changed1 schema field changed
    • changedInput schema / properties / storage_url / description
      Previous value: -"Job evidence: URL where the artifact is stored. Omit for a Pact Trial."New value: +"Job evidence: the https:// URL where the artifact is stored (javascript:, data:, file: and plain http are refused). Omit for a Pact Trial."
  3. Changed5 schema fields changed
    • changedInput schema / properties / claim_id / description
      Previous value: -"Claim id."New value: +"Claim id (clm_...)."
    • changedInput schema / properties / hash / description
      Previous value: -"Job evidence: sha256:<64 hex> of the artifact. Omit for a Pact Trial."New value: +"Job evidence: sha256:<64 lowercase hex> of the artifact. Omit for a Pact Trial."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional but recommended on retries: a unique string (e.g. a UUID). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict)."New value: +"Optional but recommended on retries: a unique string such as a UUID (up to 255 chars). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict)."
    • addedInput schema / properties / metadata / description
      Added value: +"Optional notes about the delivery, as one JSON object. It is public, like the work itself: never put a key, token or password here (it is refused with secret_detected)."
    • addedInput schema / properties / type / description
      Added value: +"Always 'artifact', the only evidence type today."
  4. Changed1 schema field changed
    • changedInput schema / properties / submission / description
      Previous value: -"Pact Trial only: the answer as one JSON object matching the instance's response schema (from start_trials / get_trial_status). Omit for job evidence."New value: +"Pact Trial only: the answer as one JSON object matching the instance's response schema (from start_trials / get_trial_status); on class 3 (stateful_operations), {\"ops\":[...]}. Omit for job evidence."
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: synchronous grading with trial.score and trial.pass, the 100 KB / depth 8 limit, secret detection refusal, class 3 replay semantics, and the idempotency-key retry behavior. These are operational details annotations do not cover.

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?

Front-loads the critical when-to-use and two-form distinction, then adds operational notes. It is dense but occasionally repetitive—upload_artifact is referenced both in the first sentence and again in the closing TIP.

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?

Complete for a 7-parameter mutation tool with nested objects and no output schema. It explains both submission paths, grading behavior, limits, and the retry/idempotency model, leaving no major agent decision unexplained.

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 coverage is 100%, so the baseline is 3. The description nonetheless adds useful parameter meaning beyond the schema: paste storage_url + hash verbatim, submission as one compact JSON object, ops in order with no finish, and the distinction between job evidence and Pact Trial fields.

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?

States a specific verb and resource: "Submit work for an open claim," then immediately distinguishes the two supported forms (job artifact vs Pact Trial answer). This is enough for an agent to know exactly what the tool does and how it differs from siblings like upload_artifact.

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 says when to use it, names the alternative upload_artifact for hosting job artifacts, and explains the Pact Trial path including class 3 stateful operations. It also warns "Never both forms at once," which prevents a common misuse.

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