Skip to main content
Glama

Save a brief to the account and check it

save_brief

Save a draft to your proofread.law account and check its case citations in one call, returning flagged issues and a report id for the edit-and-recheck loop.

Instructions

Save a brief (or any draft that cites cases) to the user's proofread.law account and check its citations in the same call. Use it when the user asks to keep a draft and come back to it, or to start the edit-and-recheck loop: save once, then after each round of edits call update_brief with the id. Returns the brief id, the coverage statement, counts per tier, one line per row that needs attention (red = check this: the register holds something concrete that disagrees; orange = cannot verify: nothing to check against, not evidence either way), and a report id for render_report. Only call it when the user wants the draft saved; to check without saving, use check_citations. Each call saves a new brief and counts as one check. Cannot: resolve Westlaw (WL) or Lexis identifiers, check statutes, regulations or secondary sources, or say whether a case is still good law. A red row means 'check this', never 'this case does not exist'; an orange row means the register has nothing to check against, which is not evidence either way. Saving is opt-in: nothing is saved unless save_brief or update_brief is called (check_citations and check_document never save anything). A saved brief is stored encrypted in the user's proofread.law account until delete_brief removes it, and needs an API key (PROOFREAD_API_KEY, or one from sign_up).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe full text of the brief, as written (paragraphs, footnotes, the whole draft).
titleNoA name the user will recognise in list_briefs, e.g. 'Motion to dismiss, Smith v. Jones'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond annotations by explaining non-idempotency (each call saves a new brief), opt-in saving, encryption, API key requirement, and the precise meaning of red/orange rows. It also lists limitations (cannot resolve WL/Lexis, statutes, etc.) and clarifies red means 'check this', not 'case does not exist'. No contradiction with annotations.

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

Conciseness4/5

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

The description is long but each sentence carries distinct value: purpose, usage, return format, limitations, semantics, opt-in, storage, and auth. It front-loads the core purpose and flows logically. While it could be tightened, the density is justified by the tool's complexity.

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 no output schema, the description thoroughly explains the return values (brief id, coverage statement, tier counts, attention rows with red/orange meaning, report id) and includes auth, storage, opt-in, and limitations. Nothing critical is missing for an agent to call it correctly.

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?

The input schema already fully documents both parameters (100% coverage) with clear descriptions. The tool description adds no additional parameter-level semantics; it focuses on behavior and usage. Baseline 3 is appropriate given the schema's completeness.

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?

The description clearly states a specific verb (save), resource (brief to account), and an additional action (check citations). It distinguishes from siblings by explicitly naming check_citations as the alternative for checking without saving, leaving no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use instructions: when the user wants to keep a draft or start the edit-and-recheck loop, and when-not: only when saving is desired, with the alternative tool named. It also maps the workflow with update_brief for subsequent edits.

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