Skip to main content
Glama

doc2json

by com.manoonlabs
OverviewDiscussionsAdmin

parse_document

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.

Input Schema

NameRequiredDescriptionDefault
textNoThe 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.
schemaNoThe 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_base64NoBase64-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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema 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"
+}
  2. Changed2 schema 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"
+}
  3. First observed

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.

All doc2json toolsInspect
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