A court filing tool updates dockets via Claude. Which description quality fits?

Court filing tools that update live dockets must describe exact required arguments and side effects so Claude knows what must be supplied and what will change in the system of record. Explicit descriptions reduce wrong-parameter calls, clarify whether a call is read-only or mutating, and make consequential writes visible before invocation in clerk-supervised workflows. Summarizing prior docket filings in the description to aid retrieval during planning does not specify the required arguments or side effects of the update, so Claude still has to guess field names, formats, and whether the call mutates the live docket, which increases defective filings. Detailing response formatting rules for docket entry display in the tool description concerns how results are shown, not what arguments are required or what side effects occur, so it does not make the live-docket write visible to Claude or the clerk before invocation. Defining docket update arguments in the system prompt while keeping the tool description concise means Claude lacks the required-argument schema at the point of tool selection and invocation, inviting wrong-parameter calls and misuse under time pressure. Exam caveat: description quality complements—not replaces—authorization checks; a well-described write tool still needs role-based access, confirmation for filings, and immutable audit trails required in court operations. Operational check: review the tool description for required fields and stated side effects, attempt a call missing a required argument and confirm rejection with a structured error, ensure clerks see a preview of docket mutations before final commit, and verify the description never claims the tool is read-only if it writes.