Emboss

Read a filled form back

read_form

Idempotent

Read the values out of a filled PDF form, labelled by field, with a completeness verdict when the form is known. Give the filled PDF (pdf_url: public https link, or pdf_base64) and, when you know it, form_id. Returns every form box in the file with its value and whether it is filled; when the form is recognised, each value also carries its label and whether it was required, plus a completeness verdict. Nothing is stored: read-back never keeps your file. Billed as one read; the first 5 each month are free. Pass dry_run=true to rehearse this call without doing it: nothing is stored, charged or sent, and no AI is used. The answer says whether the real call would succeed or be refused, what it would cost, and what a rehearsal cannot check.

Input Schema

Name	Required	Description	Default
`dry_run`	No
`form_id`	No
`pdf_url`	No
`pdf_base64`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "form_id": "11111111-2222-3333-4444-555555555555",
-    "pdf_url": "https://example.com/filled/building-permit.pdf"
-  }
-]New value: +[
+  {
+    "form_id": "11111111-2222-3333-4444-555555555555",
+    "pdf_url": "https://example.com/filled/building-permit.pdf"
+  },
+  {
+    "dry_run": true,
+    "form_id": "11111111-2222-3333-4444-555555555555",
+    "pdf_url": "https://example.com/filled/building-permit.pdf"
+  }
+]

addedInput schema / properties / dry_run

Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}

Changed1 schema field changedOct 10, 2026

addedInput schema / examples

Added value: +[
+  {
+    "form_id": "11111111-2222-3333-4444-555555555555",
+    "pdf_url": "https://example.com/filled/building-permit.pdf"
+  }
+]

First observedSep 16, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Even with annotations present, the description adds substantial behavioral context: read-back does not store the file, the call is billed as one read with five free per month, and dry_run rehearses without storing, charging, sending, or using AI. It also explains what a dry run can and cannot verify, which is unusually complete for invocation safety.

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 front-loaded with purpose, inputs, returns, storage, billing, and dry-run semantics, and every sentence contributes useful information. It is slightly dense and repeats some return-value detail despite an output schema, but not enough to be wasteful.

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 four optional parameters, an output schema, and annotations, the description covers the essential invocation context: accepted PDF sources, optional form_id, no-storage behavior, billing implications, and dry-run behavior. There is no significant missing information 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.

Parameters5/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: pdf_url is a public HTTPS link, pdf_base64 is an alternative PDF input, form_id is optional context when known, and dry_run=true rehearses the call with no side effects. This fully compensates for the sparse schema annotations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: reading values out of a filled PDF form, labelled by field, with optional completeness verdict. This is clearly distinct from creation/filling tools, but it does not explicitly distinguish itself from closely related siblings like get_form, verify_form, or inspect_pdf.

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

Usage Guidelines3/5

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

It explains that a filled PDF is required via pdf_url or pdf_base64 and that form_id should be supplied when known, which implies when this tool is appropriate. However, it gives no explicit guidance on when to use read_form instead of verify_form or get_form, leaving the alternative-selection decision implicit.

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

All Emboss 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.