DeepMark

Confirm Exam Paper Draft

paper_confirm

Idempotent

Mint the exam paper from a job parked at awaiting_confirmation (created via paper_create). Materialises the ExamPaper, questions, and mark schemes from the extraction draft, synchronously. Optionally override the detected identity (title/subject/board/year); omit to use what extraction detected. Idempotent — confirming an already-committed job returns its paper. Returns the exam_paper_id.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`job_id`	Yes	ID of the ingestion job to confirm. Must be parked at awaiting_confirmation (poll ingestion_get first).
`metadata`	No	Optional identity overrides. Omit to mint the paper with the identity detected during extraction. `total_marks` is always derived from the question marks — never supplied here.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Terminal status of the paper (complete).
`outcome`	Yes	"created" on first confirm, "already committed" on re-confirm.
`view_with`	Yes	The tool to inspect the paper with (paper_get).
`exam_paper_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

addedInput schema / properties / metadata / properties / assessment_date

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "When this cohort SAT the paper, as YYYY-MM-DD. Never detected — it is a fact about a school, not about the paper — so it is only ever set here. Omit when nobody has said."
+}

First observedJul 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds substance beyond them: it names exactly what is materialised (ExamPaper, questions, mark schemes) and that the operation is synchronous. It also explains the concrete idempotency behaviour (returning the already-committed paper's id), which the hint alone does not convey.

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-loaded with the action and precondition, then overrides, then idempotency. It is dense but every clause carries information; the sentences are long and could be split, which is the only minor cost.

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 synchronous mint operation with a nested optional override object and an existing output schema, the description covers precondition, side effects, idempotency, override semantics and the return identifier. Nothing needed to call it correctly is missing.

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, but the description adds real meaning: the whole metadata block is optional ('omit to use what extraction detected') and it clarifies that total_marks is always derived and never supplied, and that assessment_date is never detected. These are semantics the schema only partially states.

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+resource ('Mint the exam paper from a job parked at awaiting_confirmation') and immediately distinguishes itself from the sibling paper_create by naming the upstream creator. An agent can tell exactly what this does and how it differs from paper_get/paper_list.

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 states the precondition (job parked at awaiting_confirmation, created via paper_create) and routes the agent to ingestion_get for polling. It also covers the override-vs-omit decision, so both when-to-use and how-to-configure are given.

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

All DeepMark tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?