Explains contracts, letters and tax notices clause by clause. Text, PDF or photos. Not legal advice.
Scored across 2 tools
The two tools occupy clearly separate roles: explain_document starts an analysis, get_explanation polls for the result of a still-running one. The description of explain_document even points to get_explanation for the async case, so an agent cannot reasonably confuse them.
Both names follow the same verb_noun convention (explain_document, get_explanation) with consistent snake_case. The pairing of a start verb and a fetch verb reads predictably.
Two tools is on the thin side, but here the second exists only because the operation is long-running, so the surface is genuinely minimal rather than redundant. A cancel or list operation could arguably join it, keeping it just short of perfect.
The submit-and-poll lifecycle fully covers the stated purpose of explaining a document, including the OCR/PDF input paths. Minor gaps remain: no way to cancel an in-flight analysis or delete/retrieve past results, but agents can work around these.
Explains a contract, official letter, tax assessment or terms-and-conditions document in plain language, clause by clause. The document can be sent as plain text, as a base64-encoded PDF, or as base64-encoded photos of its pages — exactly one of the three. Scans and phone photos without a text layer are read by OCR, so a photographed letter works as well as a typed one. Returns every relevant clause with the original wording, a plain language version and why it matters, plus a short summary. It explains what the document says — it does not give legal advice, does not review the document and does not recommend a course of action. Plain text takes 20 to 60 seconds, a scan or photo longer because of OCR. If it is still running when this call returns, use get_explanation with the returned analysis_id.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The document as a base64-encoded PDF, for a file that has no usable text layer or whose layout matters. Up to 8 MB decoded. | ||
| text | No | The full text of the document to explain. | |
| images | No | Photos or scans of the document pages, base64-encoded, in page order. JPEG, PNG, HEIC or WebP, up to 15 images and 8 MB decoded in total. | |
| language | No | Language the explanation should be written in (ISO 639-1). Defaults to English. The document itself may be in any language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry readOnlyHint and openWorldHint, and the description adds substantive behavioral context beyond them: OCR handling for scans and photos, per-mode latency, async completion semantics, and firm exclusions (no legal advice, no review, no recommendation). This is well past what the annotations disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then inputs, then behavior, then output shape and timing. Dense but every sentence carries actionable information; slightly long, though nothing is clearly expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in to describe the return shape (clauses with original wording, plain-language version, why it matters, plus a summary). Combined with async and OCR notes, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds a genuine cross-parameter rule the schema cannot express: exactly one of pdf/text/images must be supplied. It also explains the rationale for choosing pdf (no usable text layer, layout matters) versus OCR'd images.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (explains) and resource (contract, official letter, tax assessment, T&Cs), and scopes it clause-by-clause. It also distinguishes itself from its only sibling by stating when the call defers to get_explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the three accepted input modes and the constrainable 'exactly one of the three', plus the fallback path ('use get_explanation with the returned analysis_id'). It also gives expected latency for each mode so an agent can pick sensibly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the result of an explain_document call that was still running. Pass the analysis_id it returned.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_id | Yes | The analysis_id returned by explain_document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, non-mutating read. The description adds that the operation is the retrieval half of an async pair, but says nothing about whether the result persists, how long it is available, or how to detect completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the single required input. Efficient, with only slight redundancy against the schema's own parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description covers what the tool returns (the explanation result) and where the input comes from. The main omission is any hint about the shape of the returned explanation or how to tell a still-running state from a finished one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, so the schema already fully documents analysis_id. The description only restates that the id comes from explain_document, adding no format or syntax detail beyond the structured field. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (fetches) and resource (the result of an explain_document call), and ties it directly to the sibling explain_document by naming the analysis_id it returns. It does not explicitly say it is also used for completed explanations, which the title implies, leaving a small ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use it after an explain_document call that was still running, passing the analysis_id it returned. It does not spell out the polling pattern (call repeatedly until complete) or when to stop, which is a minor gap for an async-result fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_document3 fields changedInput schema / properties / imagesAdded value: +{
+ "description": "Photos or scans of the document pages, base64-encoded, in page order. JPEG, PNG, HEIC or WebP, up to 15 images and 8 MB decoded in total.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 15,
+ "type": "array"
+}Input schema / properties / pdfAdded value: +{
+ "description": "The document as a base64-encoded PDF, for a file that has no usable text layer or whose layout matters. Up to 8 MB decoded.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "text"
-]explain_documentget_explanationContract review that keeps your contracts: cited answers, Word redlines, key-date alerts.
Grounded, quoted readings of privacy policies and terms of service. Not legal advice.
Lease analysis: flag illegal/risky clauses by jurisdiction (ontario, bc, nyc, texas, general).
Contract drafting, statute-cited US state law requirements, non-compete checks, risk analysis.
Add one secure layer between your agents and this server.
