A court agent needs current docket state for Claude. Which approach fits?

Court agents need current docket state; hard-coding docket logic or snapshots into prompts fails as soon as hearings, filings, or dispositions change. The correct approach is to reject prompt-embedded docket logic when an MCP tool can query the live court system, so Claude retrieves authoritative status per turn under proper authorization. Caching the docket snapshot in the system prompt with nightly sync to balance freshness and latency still guarantees stale answers between syncs—a filing, continuance, or disposition entered in the morning is invisible to every conversation until the next nightly refresh, and 'balancing' freshness this way just picks a fixed window of wrongness instead of querying live state. Bundling representative docket records into prompt context to ground responses in recent case activity fails the same way: 'representative' and 'recent' are not 'current'—a hand-picked or periodically refreshed sample of records can omit the exact case a litigant is asking about, or show it in a state that has since changed. Storing docket status in a local cache to reduce latency on commonly requested queries fails because a cache is exactly the kind of non-live snapshot the correct answer rejects—a filing or continuance recorded after the cache was last refreshed leaves Claude citing a docket state that looks fresh but is already wrong.

Exam caveat: live MCP access requires authorization, audit logging, and careful minimization of what case data enters the model context; public and sealed matters must be scoped differently. Operational check: change a docket field in the source system, query via MCP without editing the prompt, confirm Claude sees the update, verify the system prompt contains no frozen or periodically-synced docket tables, and confirm unauthorized roles cannot invoke the docket tool.