Extract schema-guaranteed JSON from PDFs, images and messy text. 50 free credits, no card.
Scored across 6 tools
Each tool targets a distinct operation: credit checking, schema discovery/inference, file parsing, text parsing, and validation. parse_document and parse_text are clearly separated by input type, and the free utility tools have unambiguous purposes.
Five of six tools follow the verb_noun snake_case pattern (check_credits, list_schemas, parse_document, etc.), but validate is a bare verb without a noun object. The style is otherwise consistent and predictable.
Six tools is well-scoped for a data parsing server. Each tool earns its place in the extraction workflow, and there is no redundancy or sprawl.
The set covers the full extraction lifecycle: discover built-in schemas, infer custom schemas, parse document or text inputs, validate results, and check remaining credits. Custom schemas are passed inline, so no save or delete operations are needed.
Return the number of extraction credits remaining on the authenticated API key. Free — does not consume a credit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly discloses that the call is free and does not consume a credit, implying a non-destructive read operation. This is sufficient for a simple, parameterless status tool, though it could mention failure modes like invalid API keys.
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 concise sentences with no fluff. The core action is front-loaded, and the cost-related note is a valuable second sentence that earns its place.
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 parameterless, read-only status tool with no output schema, the description is complete: it names the return value (a number), identifies the auth context, and clarifies the cost behavior. Nothing essential is missing.
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?
The tool has zero parameters, so the baseline is 4. The description adds the meaningful context that the operation is tied to the authenticated API key and returns a remaining count, which is all the parameter semantics needed.
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 and resource: returns the number of extraction credits remaining on the authenticated API key. This clearly distinguishes it from sibling tools like parse_document or list_schemas.
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?
The description gives clear context for when to call this tool: to check remaining credits on the authenticated key. It also notes the tool is free and does not consume a credit, which is relevant usage guidance. No exclusions are needed since no sibling overlaps with this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given one sample document's text, propose a reusable JSON Schema for that document type. Use this when no built-in schema_id fits: infer a schema once, review it, then reuse it as schema on parse_document / parse_text across many documents for consistent output. Returns the JSON Schema plus a flat field list and an inferred doc_type. Costs 1 credit per successful call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | A single representative sample of the document type, as text. | |
| doc_type | No | Optional hint for what kind of document this is, e.g. "purchase order", "lab report". | |
| instructions | No | Optional guidance on which fields matter or how to shape the schema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the return payload (JSON Schema plus flat field list and inferred doc_type) and the cost ('1 credit per successful call'). It does not discuss failure behavior or idempotency, but for a non-destructive inference tool the disclosed behavior is solid.
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?
Three sentences, each contributing distinct value: the core behavior, the usage context, and the return/cost details. The most decision-relevant information is front-loaded.
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?
Despite having no output schema, the description explicitly states what the call returns. It also warns about credit cost and connects the result to downstream tools. For a 3-parameter tool with rich schema descriptions, this is complete.
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%, so the input schema already documents all three parameters. The description references `text` but does not add semantic detail beyond the schema; baseline 3 is appropriate.
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?
The description states a specific verb and resource: infer a reusable JSON Schema from one sample document's `text`. It clearly distinguishes the tool from siblings like parse_document/parse_text by positioning it as the schema-inference step that precedes them, and from list_schemas by the 'when no built-in schema_id fits' condition.
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?
'Use this when no built-in schema_id fits' gives an explicit selection condition, and 'reuse it as `schema` on parse_document / parse_text' tells the agent exactly how the result fits the larger workflow. This is strong routing guidance with little left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the built-in schema templates you can pass to parse_document as schema_id (invoice, receipt, resume, etc.), each with its id and the fields it extracts. Free — does not consume a credit and needs no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the call is free (no credit) and needs no API key, addressing cost and auth. It also states what is returned: a list of templates, each with id and fields. This is sufficient for a read-only list operation, though it does not detail pagination or ordering, which are minor for this simple tool.
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 sentences, no fluff. The first sentence front-loads the core purpose and result, the second adds cost and auth details. Every word earns its place, and the description is appropriately sized for a tool with zero parameters.
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 zero-parameter, no-output-schema tool, the description is complete. It specifies what is returned (id and fields), how it is used (passed to parse_document as schema_id), and the cost/auth implications. There is no ambiguity about calling it correctly. The only minor omission is whether the list is exhaustive, but that is not critical for an agent's decision.
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?
The tool has zero parameters, so the baseline is 4. The description adds value by clarifying that the returned schema ids are meant to be passed as schema_id to parse_document, which is not in the schema itself. Since there are no parameters, the description's role in parameter semantics is limited but still fulfills the baseline.
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?
The description clearly states the tool's purpose: to return built-in schema templates for parse_document. It specifies the resource (schema templates), the target use (as schema_id), and provides concrete examples (invoice, receipt, resume). This unambiguously distinguishes it from sibling tools like parse_document (which parses) and infer_schema (which creates custom schemas).
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?
The description implies when to use it: before calling parse_document with a schema_id, you need to know available templates. It also notes that it is free and requires no API key, which is useful context. However, it does not explicitly contrast with alternatives like infer_schema for custom schemas or validate, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract clean, schema-guaranteed JSON from a PDF or image. Provide the document via url or base64. Pass an optional JSON schema to constrain the output shape, and instructions to guide extraction. Returns the extracted data plus a confidence score and a review_needed flag. Costs 1 credit per successful call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public http(s) URL of the PDF or image to parse. | |
| base64 | No | Base64-encoded document bytes (alternative to `url`). Provide `media_type` alongside it. | |
| redact | No | When true, PII (emails, SSNs, card numbers, phones, etc.) is masked in the output before it leaves the server. | |
| schema | No | Optional JSON Schema describing the exact output shape you want. When provided, the returned `data` conforms to it. | |
| schema_id | No | Optional named template to use instead of a hand-written schema, e.g. "invoice", "receipt", "resume". Call the list_schemas tool for the full set. Ignored when `schema` is provided. | |
| media_type | No | MIME type for `base64` input, e.g. application/pdf, image/png, image/jpeg. | |
| instructions | No | Optional natural-language guidance for what to extract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It adds useful context by stating there is a per-call credit cost, that cost applies only to successful calls, and that the output includes a confidence score and review_needed flag. It does not discuss failure modes or side effects, but for a read-oriented parsing tool this is substantial disclosure.
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?
The description is two tightly packed sentences with no filler. It front-loads the core purpose, then covers input, output, and cost in order of importance.
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 or annotations, the description correctly summarizes return values and the important credit cost. It omits nothing critical for invocation because the input schema already documents all seven parameters and their relationships, though it could have explicitly guided users between schema, schema_id, and instructions.
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%, so the baseline is 3 and the schema already documents all parameters. The description reiterates that url/base64 are input alternatives and that schema/instructions are optional, but it does not add much meaning beyond the schema's own parameter descriptions.
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?
The description uses a specific verb ('Extract') and resource ('PDF or image') and states the result is 'clean, schema-guaranteed JSON'. It distinguishes itself from parse_text by explicitly framing the input as PDF/image rather than text.
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?
The description clearly says the tool is for PDFs or images and supports url or base64 input, plus optional schema and instructions. It does not explicitly name when to use parse_text, infer_schema, or validate instead, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract clean, schema-guaranteed JSON from raw/messy text you already have — scraped web content, email bodies, chat logs, OCR output, or pasted tables. Pass the text in text. Use this instead of parse_document when you don't have a file. Optional JSON schema (or schema_id) constrains the output shape and instructions guides extraction. Returns the extracted data plus a confidence score and a review_needed flag. Costs 1 credit per successful call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The raw text to extract structured data from. | |
| redact | No | When true, PII (emails, SSNs, card numbers, phones, etc.) is masked in the output before it leaves the server. | |
| schema | No | Optional JSON Schema describing the exact output shape you want. When provided, the returned `data` conforms to it. | |
| schema_id | No | Optional named template to use instead of a hand-written schema, e.g. "invoice", "receipt", "resume". Call the list_schemas tool for the full set. Ignored when `schema` is provided. | |
| instructions | No | Optional natural-language guidance for what to extract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it discloses the return shape (data plus confidence score and review_needed flag) and the credit cost per successful call. It does not mention error cases or rate limits, but those are not central to this tool's behavior.
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?
The description is four sentences, front-loaded with the core purpose, and every sentence adds value: use case, argument passing, sibling alternative, optional parameters, output, and cost. No filler or repetition of schema fields.
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?
Given no annotations and no output schema, the description covers the crucial return information and cost. It also explains the primary alternative, which is important for tool selection. It leaves out edge cases like schema validation failure, but overall the agent has enough to call it correctly.
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 is 3. The description adds modest conceptual framing ('schema constrains the output shape', 'instructions guides extraction') but mostly paraphrases the schema property descriptions. No parameter semantics beyond the schema are provided.
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?
The first sentence states a specific verb and resource: 'Extract clean, schema-guaranteed JSON from raw/messy text you already have.' It also lists concrete input types and explicitly distinguishes itself from parse_document ('Use this instead of parse_document when you don't have a file'), so an agent can tell them apart.
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?
The description gives a direct routing rule: use this over parse_document when there is no file. It also explains optional schema/schema_id/instructions usage in context, giving the agent enough to know when each control is relevant. It does not cover every sibling, but the named alternative is the key one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a JSON object conforms to a JSON schema (or a built-in schema_id template) and get back a valid flag plus per-field errors. Use this to verify data you already hold — a prior parse result, your own output, or an upstream feed — before acting on it or spending a credit. Deterministic, free, and needs no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The JSON value to validate. | |
| schema | No | JSON Schema to validate against. Takes precedence over schema_id. | |
| schema_id | No | Built-in template id to validate against instead of a hand-written schema (invoice, receipt, resume, etc.). Call list_schemas for the full set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is 'Deterministic, free, and needs no API key,' which covers safety, cost, and authentication behavior. It also describes the return shape ('valid flag plus per-field errors'). It could be more explicit about error handling for malformed schemas, but overall it is strong for a no-annotation tool.
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?
The description is three well-organized sentences: core action, usage context, and behavioral traits. It is front-loaded with the primary function, each sentence earns its place, and there is no redundant or vague wording.
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?
Given no output schema and no annotations, the description covers the essential return information ('valid flag plus per-field errors'), when to use it, and cost/auth behavior. It does not mention what happens if both schema and schema_id are provided, but that detail is already in the input schema. Overall it is sufficiently complete for a validation 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 description coverage is 100%, so the baseline is 3. The description references 'schema' and 'built-in schema_id template', but the input schema already explains precedence and template usage. No additional semantic meaning is added beyond what the schema provides, so the baseline score stands.
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?
The description states a specific verb+resource: 'Check whether a JSON object conforms to a JSON schema (or a built-in schema_id template)' and explicitly describes the output ('valid flag plus per-field errors'). It clearly distinguishes itself from sibling tools like parse_document, infer_schema, and list_schemas by focusing on validation of already-held data.
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?
The description gives clear usage context: 'Use this to verify data you already hold — a prior parse result, your own output, or an upstream feed — before acting on it or spending a credit.' It tells the agent when to use the tool and even hints at cost-related motivation. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
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.
check_creditsinfer_schemalist_schemasparse_documentparse_textvalidateTurn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Turn messy text into strict JSON schemas agents can trust (invoice, receipt, contact, resume).
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
DocForge turns documents into structured data. Upload a PDF, image, or Office file and get fielded JSON back with per-field confidence scores. 95 templates (invoices, receipts, bank statements, ID docs), custom JSON Schema mode, auto-detect, natural-language instructions. Keyless demo tool included. Free 7-day trial.
Add one secure layer between your agents and this server.
