Skip to main content
Glama
Sign In
PROVE IT

PROVE IT

Official
by ark-forge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

proveit_submit

Submit a verdict and proof-backed assertions for a task, validate the submission format, and optionally preview it with a dry run.

Instructions

Submit your verdict and assertions for one task. Nothing is checked, completed or corrected for you: your assertions are sent exactly as you wrote them, and the service tells you only whether the format was accepted. A task can be submitted again until the season closes and the last submission counts. Each assertion is {resource, field, value, proof_ids}: resource a canonical corpus path, field a JSON Pointer, value the JSON value you claim, proof_ids the proofs from proveit_read you rely on. Verdicts: conforme, non_conforme, indeterminable. The rules are in the specification, not here: https://proveit.arkforge.tech/challenges/prove-it/specification/section-5.txt . Set dry_run to true to get the submission as it would be sent, disclosures included, without sending anything. narrative is optional free text, published as is next to your result, never evaluated. Refused when the season is closed (except with dry_run).

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": {
      "task_id": "<task_id>",
      "verdict": "<verdict>",
      "assertions": "<assertions>"
    },
    "name": "proveit_submit"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNo
task_idYes
verdictYes
narrativeNoOptional free text, published as is next to your result, never evaluated.
assertionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it states nothing is checked or corrected, assertions are transmitted verbatim, the service only confirms format acceptance, last-write-wins across resubmissions, refusal on closed seasons, and that narrative is published publicly as-is and never evaluated. That last point is a genuine disclosure an agent could not infer elsewhere.

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 most important constraint ('nothing is checked... sent exactly as you wrote them') before mechanics. It is a single dense paragraph and could be broken into structure for scanning, but nearly every sentence adds distinct information rather than restating the schema.

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?

For a five-parameter mutation tool with no annotations and no output schema, the description covers validation behavior, idempotence/resubmission semantics, failure conditions, enum values, and the public visibility of narrative. An agent has everything needed to call it correctly and to set expectations about the response.

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?

With only 20% schema description coverage, the description compensates well: it defines the four assertion sub-fields (canonical corpus path, JSON Pointer, claimed JSON value, proof_ids), enumerates the three verdict values, and explains dry_run and narrative behavior. Only task_id is left implicit, which is a minor gap given how much else is covered.

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?

Opens with a specific verb and resource: 'Submit your verdict and assertions for one task.' It also implicitly separates this tool from proveit_read by describing proof_ids as 'the proofs from proveit_read you rely on,' so an agent understands the read-then-submit relationship without opening either schema.

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?

Gives clear operational context: resubmission is allowed until the season closes and the last submission counts, dry_run is the way to preview, and the call is refused when the season is closed (except with dry_run). It does not spell out when NOT to use it (e.g. before proofs exist) and defers the substantive rules to an external spec URL, but the practical guidance is strong.

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

Deploy Server

Other Tools