Zovo Document Compare

Compare two documents

compare_documents

Read-onlyIdempotent

Use this when the user wants to compare two documents for differences, compare two versions of a contract, lease, policy or any text, or wants a redline comparison. Put the full text of each version into original_text and revised_text word for word (do not summarize, shorten or fix it); if the user shares screenshots or images of pages, transcribe their text word for word into those fields. For uploaded Word .docx, text PDF or .txt files, pass them in original_file and revised_file. Returns each changed word with the paragraph number, flags changes to numbers, negations and modal verbs (shall, may, must) as material, and makes a redline PDF, an Excel change list and a Word file with tracked changes. Only whitespace and quote style are normalized. Does not read scanned PDFs, does not compare formatting, headers or footers, and does not give legal advice. Do not use for comparing spreadsheets or data tables.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "compare_documents"
  }
}

Input Schema

Name	Required	Description
`show`	No	Redline PDF content: "full" (default, the whole revised document with changes marked) or "changes" (only the changed paragraphs).
`page_size`	No	PDF page size: "Letter" (default) or "A4".
`revised_file`	No	The REVISED version as an uploaded file: Word .docx, text PDF or .txt, e.g. contract-v2.pdf.
`revised_name`	No	Optional label for the revised version, e.g. "Lease v2 (landlord edits)". Default: the file name or "Revised".
`revised_text`	No	The REVISED (newer) version, pasted in full and word for word, e.g. "1. The Tenant may pay rent of $1,250 on the first day of each month.\n2. ...". Leave empty when revised_file is given.
`original_file`	No	The ORIGINAL version as an uploaded file: Word .docx, text PDF or .txt, e.g. contract-v1.docx.
`original_name`	No	Optional label for the original, e.g. "Lease v1 (March)". Default: the file name or "Original".
`original_text`	No	The ORIGINAL (older) version, pasted in full and word for word, e.g. "1. The Tenant shall pay rent of $1,200 on the first day of each month.\n2. ...". Keep paragraphs on separate lines. Leave empty when original_file is given.

Output Schema

Name	Required	Description	Default
`notes`	Yes
`counts`	Yes
`changes`	Yes
`redline`	Yes
`revised`	Yes
`summary`	Yes
`original`	Yes
`downloads`	Yes
`identical`	Yes
`page_size`	Yes
`normalized`	Yes
`changes_shown`	No
`material_changes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the concrete outputs (redline PDF, Excel change list, Word file with tracked changes), the materiality rule (changes to numbers, negations, modal verbs flagged), the normalization scope (only whitespace and quote style), and hard limitations (no scanned PDFs, no formatting/header/footer comparison, no legal advice). The annotations only say read-only/idempotent; the description supplies the behavioral substance an agent needs.

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?

Front-loaded with the trigger condition, then inputs, outputs, and exclusions in a logical order; nearly every clause carries operational information. It is dense — 'word for word' is repeated several times and the negative constraint list is long — but nothing is mere filler.

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?

For an 8-parameter, nested-object tool with an output schema, the description covers what the agent must know: what inputs are acceptable, which fields to fill, what gets produced, and what the tool refuses. It redundantly narrates outputs, but that is helpful rather than harmful.

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 already 100%, yet the description still adds real meaning: text fields must contain the document verbatim ('do not summarize, shorten or fix it'), screenshots must be transcribed, and file fields are the path for .docx/.txt/text PDFs. It does not explain how to combine text and file inputs for each side, or how show/page_size interact with the redline output, leaving some interpretation to the schema.

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?

Opens with a specific verb and resource: 'compare two documents for differences', and enumerates the concrete use case (contract/lease/policy versions, redline). The purpose is unambiguous and cannot be confused with any other operation, and there are no siblings to disambiguate against.

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?

Explicit when-to-use phrasing ('Use this when the user wants to compare...') plus input-routing guidance (paste text into original_text/revised_text vs. pass uploads via original_file/revised_file, transcribe screenshots). It also states when NOT to use it: 'Do not use for comparing spreadsheets or data tables.'

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

All Zovo Document Compare tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?