Skip to main content
Glama

submit_exam_answers

Not for clinical use. Orinyx checks medication claims against cited FDA label text for testing and evaluation only. Do not use its results to diagnose, treat, prescribe or make patient care decisions. Use synthetic test data only. FOR AN ORINYX EXAM ONLY: record your answers. answers is a list with exactly one answer field each: {caseId, claims} for a transcript case, {caseId, replyText} for a patient-message case (the reply exactly as the product would send it; an empty string is recorded as unreadable), or {caseId, codes} for an encounter-note case (ICD-10-CM diagnosis codes as strings like "E11.9", at most 25, no CPT or HCPCS; an empty list is a valid answer; never send a date, the case has its date of service). Claims are the medication claims exactly as the exam transcript states them, including any that look wrong, each {rawText, drug, claimType, structuredValue}. Claim types and their structuredValue keys are listed with each case; a contraindication the clinician says does not apply is {condition, asserted: false}. An empty claims list is a valid answer. This is how the exam is scored, not documentation or clinical guidance: in real use a medication statement that looks wrong is carried and raised with the clinician. Use only the transcript's words, never real patient data. An answer cannot be changed once recorded, and how Orinyx judged it is not shown until the report.

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": {
      "run_id": "<run_id>",
      "answers": "<answers>"
    },
    "name": "submit_exam_answers"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYes
answersYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full load and does so well: it discloses that an answer cannot be changed once recorded, that the system's judgment is hidden until the report, that empty claims and empty code lists are valid answers, and that unreadable replies are recorded as such. Those irreversibility and scoring-visibility behaviors are exactly what an agent needs before making an irreversible write.

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

Conciseness3/5

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

The core payload guidance is dense and front-loaded, but the safety boilerplate is restated three times ('Not for clinical use', 'Do not use its results', 'never real patient data' / 'Use only the transcript's words'). Those repetitions dilute an otherwise efficient definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter submission tool with an output schema present, the description covers the answer payload formats, valid empty values, immutability, and scoring opacity. The only real gap is the unexplained `run_id`, which is presumably self-evident from the exam flow but not stated.

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 description coverage is 0%, so the description must compensate, and it does for `answers`: it specifies the three mutually exclusive shapes ({caseId, claims}, {caseId, replyText}, {caseId, codes}), the ICD-10-CM format and 25-code cap with no CPT/HCPCS, and the {rawText, drug, claimType, structuredValue} claim structure. `run_id` is never explained, leaving one required parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb+resource ('FOR AN ORINYX EXAM ONLY: record your answers') and scopes the tool to exam submission rather than verification. It never explicitly contrasts with siblings like finish_exam or get_verification, so the differentiation is implied by the exam framing rather than called out.

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?

It gives clear when-to-use ('FOR AN ORINYX EXAM ONLY') and several when-not constraints (not clinical use, no real patient data, synthetic test data only). It lacks an explicit 'if you want X, use sibling Y instead' routing statement for finish_exam/get_exam_report.

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.