doc2json

Server Details

Turn PDFs and photos into typed JSON with your own schema. Missing values come back null.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-31 08:23
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A3.7/5.0

Scored 2026-10-30 20:50 across 6 tools

Disambiguation5/5

Each tool maps to a distinct operation: CRUD-like schema management (create/get/list/update), document parsing, and identity/credit lookup. The boundaries between create_schema, get_schema, list_schemas, and update_schema are clear despite their shared resource. parse_document and whoami are unmistakably separate operations.

Naming Consistency4/5

Five tools follow a clean verb_noun snake_case pattern (create_schema, get_schema, list_schemas, update_schema, parse_document). The only deviation is whoami, which is a common idiomatic name but breaks the pattern slightly.

Tool Count5/5

Six tools is well-scoped for a schema-driven document extraction server, with each tool earning its place. There is no bloated surface or missing obvious counterpart beyond what completeness covers.

Completeness3/5

Schema lifecycle covers create, read, list, and update, but there is no delete_schema, leaving a dead end for cleanup. More importantly, parse_document's description mentions extracting invoice fields but does not indicate how a saved custom schema is selected, creating a surface-level gap between schema management and parsing.

Available Tools

6 tools

create_schemaBInspect

Save a named extraction schema in this workspace. A schema is {"type":"object","properties":{...}}. Each property is {"type":T} where T is one of any, null, boolean, string, number, date, array, object. An optional description, at most 400 characters, tells the model how to read that field. An optional required array lists the keys that must be present. A date is a string yyyy-mm-dd. An array adds "items" (one node). An object adds "properties" and may add "required". At most 4 levels below the root, 100 keys, and 16384 bytes.

Name	Required	Description	Default
`name`	Yes	Lowercase letters, digits, underscores, and hyphens. No spaces.
`schema`	Yes	A schema is {"type":"object","properties":{...}}. Each property is {"type":T} where T is one of any, null, boolean, string, number, date, array, object. An optional description, at most 400 characters, tells the model how to read that field. An optional required array lists the keys that must be present. A date is a string yyyy-mm-dd. An array adds "items" (one node). An object adds "properties" and may add "required". At most 4 levels below the root, 100 keys, and 16384 bytes.

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It thoroughly documents the payload format and hard limits (4 levels, 100 keys, 16384 bytes), which is real behavioral context, but it says nothing about permissions, overwrite/conflict behavior on an existing name, or what the call returns.

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?

Purpose is front-loaded in the first sentence, and the remaining sentences are dense constraint statements rather than filler. The main waste is restating the schema parameter's description word-for-word, but the content itself is load-bearing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a deeply nested object parameter and no output schema, the format spec is complete, but the agent still lacks the create/update boundary and conflict semantics. Adequate, not complete.

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?

Schema coverage is 100%, so both parameters are already documented in the schema, and the description's schema-format text is a verbatim duplicate of the schema's own description field. It adds no meaning beyond the structured data; baseline 3 applies.

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?

"Save a named extraction schema in this workspace" gives a specific verb (save) and resource (named extraction schema) with scope. It does not explicitly distinguish itself from update_schema or get_schema, so an agent must infer that this is the creation path.

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

Usage Guidelines2/5

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

There is no statement of when to use this versus update_schema (the obvious alternative when a schema already exists), nor what happens if the name collides. The only usage signal is the word "Save," which leaves the create-vs-update decision to inference.

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

get_schemaAInspect

Read one saved extraction schema by name.

Name	Required	Description	Default
`name`	Yes	Lowercase letters, digits, underscores, and hyphens. No spaces.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, but 'Read' unambiguously declares a non-mutating operation. However, the description says nothing about behavior when the name does not exist (error vs empty), which matters for a lookup tool with zero annotation coverage.

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?

A single front-loaded sentence with zero waste; the verb and scope land immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool this is nearly sufficient, but with no output schema the description never indicates what is returned (the schema definition object, presumably) or how missing names are handled.

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?

Schema coverage is 100% and the schema itself documents the name format constraints (lowercase, pattern, max length). The description only echoes 'by name' and adds no syntax or format guidance beyond the schema, so baseline 3 applies.

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?

States a specific verb ('Read') and resource ('one saved extraction schema') and scopes it to a single item by name, which implicitly contrasts with list_schemas. It stops short of naming siblings explicitly, but the singleton scope is clear.

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?

'By name' implies the caller already knows the identifier, hinting at lookup-after-list. There is no explicit statement of when to prefer this over list_schemas or what to do if the name is unknown, so usage must be inferred.

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

list_schemasAInspect

List the extraction schemas saved in this workspace.

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden; 'List ... saved in this workspace' implies a read-only, non-destructive enumeration, which is the main safety signal an agent needs. However, it says nothing about permissions, pagination/limits, ordering, or whether archived/private schemas are included.

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?

A single front-loaded sentence with no filler; the resource and its scope are established immediately. Nothing could be cut without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description is the only source of return-value information, and it does not say whether full schema definitions, names, or IDs come back. That omission affects whether an agent needs a follow-up get_schema call, so the definition is only minimally sufficient.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent parameter discussion.

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?

States a specific verb ('List') and resource ('extraction schemas') plus a scope qualifier ('saved in this workspace'), which distinguishes it from create_schema/update_schema/get_schema by implication. It never explicitly contrasts with the sibling get_schema, so an agent must infer that this returns the collection rather than one schema.

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?

The workspace scoping implies discovery use, but there is no explicit 'use this when you need to enumerate before calling get_schema' guidance and no stated exclusions or alternatives. A reasonable inference is available, but nothing is spelled out.

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

parse_documentAInspect

Extract invoice fields from a PDF, PNG, JPEG, or text file sent as base64 in file_base64, or from plain text sent in text (10 MB and 10 pages on Free, 25 MB and 50 pages on paid). 1 credit per page; an image is 1 page; text is 1 credit per 3,000 characters. Nothing is stored. Send exactly one of file_base64 or text. The result has status and values.

Name	Required	Description
`text`	No	The document as plain text, for example a pasted invoice or email. 1 credit per 3,000 characters (started), at least 1. At most 30,000 characters on Free and 150,000 on paid plans. The text is not stored. Send this or file_base64, not both.
`schema`	No	The name of a schema saved in this workspace, or a literal schema object. A schema is {"type":"object","properties":{...}}. Each property is {"type":T} where T is one of any, null, boolean, string, number, date, array, object. An optional description, at most 400 characters, tells the model how to read that field. An optional required array lists the keys that must be present. A date is a string yyyy-mm-dd. An array adds "items" (one node). An object adds "properties" and may add "required". At most 4 levels below the root, 100 keys, and 16384 bytes.
`file_base64`	No	Base64-encoded PDF, PNG, JPEG, or UTF-8 text file (.txt, .md, .csv, .eml). At most 10 MB and 10 pages on Free, 25 MB and 50 pages on paid plans. Each page costs 1 credit; an image is 1 page; text is 1 credit per 3,000 characters. The bytes are not stored. Send this or text, not both.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description does real work: it discloses the credit cost model (per page, per 3,000 chars), size/page limits per tier (10 MB/10 pages Free vs 25 MB/50 pages paid), and that 'Nothing is stored'. It doesn't state auth requirements or what 'status' values can occur, but the pricing and no-retention disclosures are the substantive behavioral facts 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?

A single dense paragraph front-loads the purpose and formats before costs and constraints. It repeats limit figures that also live in the schema, which is mild duplication, but no sentence is wasted for a standalone reader.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by saying 'The result has status and values.' It covers inputs, exclusivity, cost, and limits, so an agent can call it correctly. Only the possible values of 'status' remain unspecified.

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?

Schema coverage is 100%, so the schema already documents text, schema, and file_base64 in depth. The description mostly restates those constraints (limits, credit math) and adds the one genuinely beyond-schema rule ('Send exactly one'), so baseline 3 is appropriate.

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?

States a specific verb ('Extract invoice fields') and resources (PDF, PNG, JPEG, text), and the sibling tools (create_schema, get_schema, etc.) are schema-management operations that are clearly distinct from a one-shot document extraction tool. An agent can immediately tell this is the extraction endpoint versus schema CRUD.

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

Usage Guidelines4/5

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

Explicitly states the mutually-exclusive input rule ('Send exactly one of file_base64 or text'), which is the key selection decision. It doesn't name when NOT to use it or point to an alternative extraction path, but the sibling set is unrelated CRUD, so the context is clear enough.

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

update_schemaBInspect

Rename a saved schema, replace its definition, or both. A schema is {"type":"object","properties":{...}}. Each property is {"type":T} where T is one of any, null, boolean, string, number, date, array, object. An optional description, at most 400 characters, tells the model how to read that field. An optional required array lists the keys that must be present. A date is a string yyyy-mm-dd. An array adds "items" (one node). An object adds "properties" and may add "required". At most 4 levels below the root, 100 keys, and 16384 bytes.

Name	Required	Description
`name`	Yes	The current name.
`schema`	No	A schema is {"type":"object","properties":{...}}. Each property is {"type":T} where T is one of any, null, boolean, string, number, date, array, object. An optional description, at most 400 characters, tells the model how to read that field. An optional required array lists the keys that must be present. A date is a string yyyy-mm-dd. An array adds "items" (one node). An object adds "properties" and may add "required". At most 4 levels below the root, 100 keys, and 16384 bytes.
`newName`	No	Lowercase letters, digits, underscores, and hyphens. No spaces.

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose concrete limits (depth 4, 100 keys, 16384 bytes, 400-char descriptions), which help an agent pre-validate. However, it omits the mutation semantics that matter most: whether passing 'schema' fully overwrites the existing definition, whether the old name is released on rename, whether this requires ownership, and what happens if the name does not exist.

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

Conciseness2/5

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

The purpose is front-loaded in one good sentence, but the remaining text is a near-verbatim duplicate of the 'schema' parameter description already present in the input schema. Roughly half the description is redundant, displacing space that could have described mutation semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description establishes what changes and the structural constraints, which is enough to construct a valid call. It is incomplete on the consequences: overwrite behavior, failure modes, and whether renaming preserves or drops the schema body, and it does not state the at-least-one-of constraint on schema/newName.

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?

Schema description coverage is 100%, so the schema already documents all three parameters, and the description's schema-format block is a verbatim copy of the 'schema' parameter description rather than added meaning. Nothing extra is said about 'name' (current name) or the interaction between name and newName. Baseline 3 applies.

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?

Opening sentence gives a specific verb set and resource: rename a saved schema, replace its definition, or both. It clearly separates this from create_schema/get_schema by framing it as modification of an existing saved schema, though it never names the siblings explicitly.

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?

The 'rename, replace, or both' phrasing implies that at least one of the optional parameters (newName/schema) must be supplied and that two distinct modes exist, which is useful usage signal. But there is no explicit when-to-use guidance, no statement of prerequisites (does the schema have to already exist?), and no routing versus create_schema for the case where the name is wrong.

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

whoamiAInspect

Return the workspace and token for the bearer credential, and the credits left this month.

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool reads the bearer credential and returns the token and monthly credits, which is useful behavioral context, but it does not state that the operation is read-only, whether the token is sensitive, or any permission constraints.

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?

The description is a single front-loaded sentence that states exactly what is returned. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should identify the return values; it lists workspace, token, and remaining credits. That is adequate for a zero-parameter identity/account tool, though it does not explain formats or the sensitivity of the token.

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?

The tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not create any parameter confusion.

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 uses a specific verb ('Return') and names the exact resources returned: workspace, token, and remaining monthly credits. It is clearly different from the schema/document siblings, but it does not explicitly contrast itself with any named alternative.

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?

Usage is implied by the description: it is the tool for inspecting the current bearer credential's workspace, token, and credit balance. However, it gives no explicit when-to-use guidance, exclusions, or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 30, 2026

Changedparse_document2 fields changed

changedInput schema / properties / file_base64 / description

Previous value: -"Base64-encoded PDF, PNG, or JPEG. At most 10 MB and 10 pages on Free, 25 MB and 50 pages on paid plans. Each page costs 1 credit; an image is 1 page. The bytes are not stored."New value: +"Base64-encoded PDF, PNG, JPEG, or UTF-8 text file (.txt, .md, .csv, .eml). At most 10 MB and 10 pages on Free, 25 MB and 50 pages on paid plans. Each page costs 1 credit; an image is 1 page; text is 1 credit per 3,000 characters. The bytes are not stored. Send this or text, not both."

addedInput schema / properties / text

Added value: +{
+  "description": "The document as plain text, for example a pasted invoice or email. 1 credit per 3,000 characters (started), at least 1. At most 30,000 characters on Free and 150,000 on paid plans. The text is not stored. Send this or file_base64, not both.",
+  "type": "string"
+}

1 tool updateOct 30, 2026

Changedparse_document2 fields changed

removedInput schema / properties / document

Removed value: -{
-  "description": "Base64-encoded PDF, PNG, or JPEG. At most 10 MB and 10 pages on Free, 25 MB and 50 pages on paid plans. Each page costs 1 credit; an image is 1 page. The bytes are not stored.",
-  "type": "string"
-}

addedInput schema / properties / file_base64

Added value: +{
+  "description": "Base64-encoded PDF, PNG, or JPEG. At most 10 MB and 10 pages on Free, 25 MB and 50 pages on paid plans. Each page costs 1 credit; an image is 1 page. The bytes are not stored.",
+  "type": "string"
+}

6 tool updatesOct 30, 2026
- First observedcreate_schema
- First observedget_schema
- First observedlist_schemas
- First observedparse_document
- First observedupdate_schema
- First observedwhoami

Related MCP Connectors

Document to JSON – PDF Invoice/Statement/Contract ParserOAuth
io.github.fashionmascherine-svg
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Finance AI & Machine Learning
28
https://mcp.apify.com/?actors=opportunity-biz/document-to-json-mcp
AIDataParser A
io.github.shibley
PDFs, images and messy text to schema-guaranteed JSON. try_parse runs a real extraction, no key.
AI & Machine Learning Data Platforms
91
https://aidataparser.com/v1/mcp
DatanemOAuth
com.datanem
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
AI & Machine Learning Data Platforms Image & Video Processing
1
https://datanem.com/mcp
extendOAuth
ai.extend
Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
Research & Data
1
https://mcp.extend.ai/mcp

Related MCP Servers

AIDataParser MCP server
Data Platforms AI & Machine Learning
shibley
A
license
Not graded
quality
C
maintenance
Enables conversion of PDFs, images, and messy text into schema-guaranteed JSON, with tools for schema inference, validation, and credit management.
Updated a month ago (2026-10-01 09:13 UTC)
MIT
pdf-extract-mcp
Data Platforms Research & Data
Pranavdmg20
A
license
A
quality
C
maintenance
Provides deterministic, schema-driven structured data extraction from PDF documents via regex/heuristic matching, enabling repeatable, inspectable, and cost-free field extraction without LLM API calls.
Updated 2 months ago (2026-08-26 12:08 UTC)
3
MIT
doc-extract
Research & Data
AlanAAG
F
license
Not graded
quality
B
maintenance
Enables reading entire PDF documents into validated structured JSON, including tables, key-values, and markdown, with read-only extraction tools and layout reconstruction.
Updated 2 months ago (2026-08-25 08:08 UTC)
-
StructureAI MCP Server
Data Platforms Research & Data App Automation
avatrix1
A
license
A
quality
D
maintenance
Extracts structured JSON data from unstructured text using predefined schemas for receipts, invoices, resumes, and emails. It allows users to transform messy text into organized data through built-in or custom-defined fields.
Updated 8 months ago (2026-03-08 20:49 UTC)
1
MIT

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?