Skip to main content
Glama
Data-Alchemy-Labs

proofread-mcp

by Data-Alchemy-Labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Save an edited brief and re-check it

update_brief

Save an edited brief version and re-check flagged citations, showing resolved, new, and unchanged rows. Use recheck to re-run the check on saved text without editing.

Instructions

Save an edited version of a brief saved in the user's proofread.law account and re-check it. This is the loop for fixing flagged citations: edit the text (the citation, case name or quotation a row points at, or take the citation out), call update_brief with the whole edited text, and read the changes: which flags were resolved (flagged before, not flagged now), which flags are new, how many rows are unchanged, and then every row that still needs attention. Repeat until every remaining row has been reviewed by the user. Send the full text, not a diff or an excerpt: it becomes the latest version, and the previous version is kept (get_brief lists the versions). recheck=true re-runs the check on the saved text without editing it, e.g. after the register was updated. A changed text or a recheck counts as one check and keeps a new version; a title alone renames the brief without a check and is not counted. 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
idYesThe brief id from save_brief or list_briefs.
textNoThe whole edited text of the brief. It replaces the latest version; the previous one is kept.
titleNoA new name for the brief.
recheckNoRe-run the check on the saved text without editing it, e.g. after the register was updated.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavior not in annotations: it creates a new version and keeps the previous one, saving is opt-in and encrypted, check counts, red/orange row semantics, and the caveat that 'red row means check this, never this 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.

Conciseness5/5

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

Description is long but every sentence earns its place. It front-loads the core purpose and loop, then covers edge cases (recheck, title-only, versions, limitations, red/orange semantics, opt-in saving, encryption, API key). It is densely packed with actionable information and avoids redundancy.

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?

Given the tool's complexity (4 params, no output schema, many behavioral nuances), the description is remarkably complete. It explains the full workflow, versioning behavior, check counting, limitations, row semantics, saving policy, and security. An agent has everything needed to call it correctly and interpret results despite no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that 'text' must be the whole edited text (not a diff or excerpt), that it replaces the latest version, and that recheck=true re-runs without editing. It also emphasizes sending full text, which the schema doesn't explicitly state. This goes beyond the baseline.

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 states a specific action ('Save an edited version') and resource ('brief'), and immediately positions it as the loop for fixing flagged citations, distinguishing it from siblings like check_citations and save_brief. It clearly tells the agent what it is for and how it differs from related tools.

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?

The description gives explicit when-to-use guidance (the loop for fixing flagged citations, repeat until user has reviewed every row), when not to use it (Cannot resolve Westlaw/Lexis identifiers, check statutes/regulations/secondary sources), and when to use recheck. It also distinguishes from save_brief (opt-in saving) and check_citations (never saves).

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

Deploy Server

Other Tools