Medical Chronologies for AI Legal Agents: API and MCP

AI agents are increasingly handed real legal work: drafting a demand letter, prepping a deposition outline, triaging a new intake file. Every one of those tasks needs a trustworthy read of the underlying medical records before the agent can do anything useful with them. Guessing at what a scanned PDF says is not an option in a legal context, so the chronology engine is built to be called as a tool, not just used through a browser.

Why an agent can't just read the PDF itself

A general-purpose language model can technically attempt to read a medical record PDF directly, but it has no way to guarantee page-level citation, no consistent event schema across different providers' note formats, and no built-in gap detection. Every one of those is exactly what a legal work product needs to be usable: an agent-drafted demand letter that can't point to the specific page supporting a claim isn't something an attorney can safely rely on or file.

Chartely's engine solves that by doing the extraction once, consistently, with a fixed output schema (ExtractedEvent, ChronologyMeta, TreatmentGap) that an agent can parse deterministically, rather than re-deriving structure from unstructured model output every time.

Calling the chronology API directly

The REST API takes a PDF (multipart upload) or raw extracted text (JSON body) and returns a full chronology result synchronously: a single POST to /api/v1/chronology with a bearer key, a PDF attached, and the response comes back before the next step in the agent's task needs it. Any anonymous caller can try it at a throttled rate before setting up an account.

The response is a single JSON object matching the ChronologyResult shape: meta (patient reference, provider and facility counts, first and last event date), the full events array with a pageRef on every entry, treatment gaps, a drafted narrative, and an overall confidence score. An agent can walk the events array directly to build a timeline view, or hand the narrative straight into a drafting step.

Calling it as an MCP tool

For agents built on the Model Context Protocol, the same engine is exposed as a hosted MCP server with three tools: build_chronology (a full record set to a full result), extract_medical_events (a lighter-weight call when only the event list is needed), and get_chronology (retrieve a previously built chronology by id). Adding the server to an agent's config is a single URL and an optional bearer-token header, no local process to install or run.

From there, an agent working a case can call build_chronology mid-task the same way it would call any other tool, no custom parsing logic, no prompt engineering around "please extract the dates from this document."

Why page citations matter even more for agent output

When an agent drafts a demand letter section from a chronology event, it can (and should) carry the page citation forward: "per the emergency department note dated [date], page 14 of the records..." That's what turns an agent's output from something that needs to be entirely re-verified by hand into something a paralegal can spot-check against the specific pages cited.

What agents typically do with the result

• Populate a case timeline view directly from the events array, no separate parsing step.
• Flag treatment gaps automatically for a paralegal to review and explain before a demand letter goes out.
• Feed the narrative field into a drafting step for a demand letter or case summary, with citations preserved.
• Compare a new supplemental record set's events against an existing chronology to spot what's new.

None of this requires custom extraction logic per agent. The schema is fixed, the citations are built in, and the anonymous tier means an agent can be tested against it before any account or billing setup is needed.

Handling errors and low-confidence results

An agent calling the tool needs a plan for the response that isn't a clean success, and the engine is built to make that plan simple: a failed extraction returns a typed error with a specific code (an unreadable file, an unsupported type, a file that doesn't look like medical records at all) rather than a vague failure or a hallucinated partial result. A successful extraction still carries a warnings array and a confidence score, so an agent can set its own threshold, escalate to a human for review below a certain confidence, and proceed automatically above it.

That combination, typed errors instead of silent failure, and a graded confidence signal instead of a binary pass or fail, is what makes it reasonable to wire this into an unattended agent workflow rather than something that always needs a human standing by the console.