Skip to main content
Glama

extract_document

Extract text from PDFs and images as structured Markdown. Handles complex layouts, tables, handwriting, and math notation. Pay per page with Bitcoin Lightning.

Instructions

Extract text from PDFs and images as clean Markdown. Uses Mistral OCR — handles complex layouts, tables, handwriting, multi-column documents, and mathematical notation. Preserves document hierarchy in structured Markdown. 10 sats/page. Pay per request with Bitcoin Lightning — no API key or signup needed. Requires create_payment with toolName='extract_document' and quantity=pageCount for multi-page PDFs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paymentIdYesValid payment ID (must be paid)
documentBase64YesBase64 encoded PDF or image
modelIdNoOptional. Omit for default model.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided. Description discloses cost (10 sats/page) and payment flow, but lacks details on size limits, supported languages, error handling, or whether operation is destructive. Adequate but not exhaustive.

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?

Four sentences, front-loaded with purpose, then capabilities, cost, and prerequisite. No redundant information.

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?

Covers key aspects: purpose, capabilities, cost, payment prerequisite. Lacks output format detail (though Markdown is mentioned) and error handling. No output schema to compensate, but overall sufficient for typical use.

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?

Schema covers 100% of parameters with descriptions. Description adds value by explaining the paymentId must be obtained via create_payment and that documentBase64 is base64 encoded, beyond schema details.

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?

The description clearly states it extracts text from PDFs and images as clean Markdown, specifying handling of complex layouts, tables, handwriting, etc. This distinguishes it from siblings like analyze_image or convert_file.

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 mentions prerequisite payment via create_payment with toolName and quantity, and that no API key is needed. Does not compare to alternatives like convert_file for document extraction, but the context is clear.

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