record-mcp

check_trace

Read-onlyIdempotent

Validate a single RECORD trace against schema, behavioral, and regulatory rules, returning pass/warn/fail status, severity counts, and violation details with citations and remediation.

Instructions

Check one RECORD trace for violations.

Runs schema conformance, behavioral rules (human oversight, escalation, temporal, provenance, integrity) and per-regulation field-gap analysis. Returns status (pass / warn / fail), counts by severity, and every violation with its JSON-pointer path, evidence, regulatory citations, and remediation. Use check_trace_chain for several traces.

Input Schema

Name	Required	Description	Default
`path`	No	Path to a .json (object or array) or .jsonl file. Only available when the server runs over stdio.
`trace`	No	A RECORD trace as a JSON object (or JSON string). Omit when using `path`.
`frameworks`	No	Only evaluate rules citing these framework ids (see list_frameworks), and run their field-gap analyses. Default: all rules; gap analyses chosen from each trace's authority_basis.
`include_gaps`	No	Include per-regulation missing-field (GAP.*) violations.
`input_format`	No	'record' for RECORD documents, 'openinference' for OpenInference span dicts (converted with record-py's adapt_span).	record
`min_severity`	No	Drop violations below this severity.	info

Output Schema

Name	Required	Description
`index`	Yes	Position of the trace in the input.
`counts`	Yes
`errors`	No	Checks that crashed on this input (not violations).
`status`	Yes
`record_id`	Yes
`violations`	Yes
`schema_valid`	Yes
`gap_regulations`	No	record-py GapAnalyzer regulations evaluated.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it enumerates the rule families evaluated and describes the return payload (status, severity counts, violation paths, evidence, citations, remediation).

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

Conciseness5/5

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

Three tight sentences, front-loaded with the core action, followed by scope of analysis, return shape, and the sibling alternative. No filler sentences.

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?

With an output schema present and full parameter documentation, the description needs only enough to orient the agent, and it supplies purpose, analysis scope, return summary, and tool routing. Nothing needed to invoke it correctly is missing.

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 every parameter (path, trace, frameworks, include_gaps, input_format, min_severity) is already documented with defaults and enums. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 ('Check one RECORD trace for violations') and spells out exactly which analyses run (schema conformance, behavioral rules, field-gap analysis) and what comes back. It explicitly contrasts with the sibling 'check_trace_chain for several traces', so an agent can route 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?

The closing sentence names the alternative tool and the condition that selects it ('for several traces'), giving clear routing guidance. It does not state exclusions such as when to skip gap analysis or when trace vs. path input is preferred, but the schema covers those.

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

Deploy Server