Skip to main content
Glama

Extend MCP

Extract structured data from a document

extract_data

Extract specific structured values (totals, line items, dates, names, tables) from a document (extract group) using a saved extractor, an inline JSON Schema, or schema-less inference. If the user says "OCR" but wants specific values out, use this tool; for the raw text/markdown of the pages use parse_document instead. Provide exactly one of extractor or config, or omit both for schema-less inference (guided by config.extractionRules when config has no schema; not usable with package). If a saved extractor turns out not to exist, rerun THIS tool without the extractor (schema-less) — do not fall back to parse_document for value extraction. For one merged result across 2-50 related documents, pass package instead of file. detail: "full" returns per-field source citations and confidence — the only way to prove where a value came from (provenance); parsing cannot cite. Creates an extract run: may return status: "running" with a runId — normal, not an error; poll it with get_extract_run. Follow any llmContext guidance included in results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoThe document to extract from. Mutually exclusive with package. Exactly one of id/url/text — e.g. { "url": "https://..." } or { "id": "file_..." }, never a bare string.
configNoInline extraction config: { schema?, extractionRules?, baseProcessor?, advancedOptions?, parseConfig? }. Writing schema by hand? ALWAYS call get_documentation with https://docs.extend.ai/extraction/schema.md FIRST and follow the returned dialect — the rules below are only a summary (field-naming best practices: https://docs.extend.ai/extraction/best-practices/field-names-and-prompt-crafting.md). schema is a JSON Schema: root "type": "object"; primitives nullable via a type array (["string","null"]); objects/arrays keep a plain "type" (never a nullable array) and objects always need "properties"; max depth 5; enums include null; no anyOf/oneOf/allOf/patterns. Date/currency/signature fields add "extend:type" alongside a normal type. A currency field is exactly: { "type": "object", "extend:type": "currency", "properties": { "amount": { "type": ["number", "null"] }, "iso_4217_currency_code": { "type": ["string", "null"] } } } — never a bare number. Omit schema for schema-less mode (no docs needed): extractionRules then doubles as schema-generation instructions.
detailNo"concise" (default): status, output, failure fields, dashboardUrl. "full": adds config, confidence/citations, usage, timestamps.
packageNoMulti-document corpus (2-50 files, id/url only) extracted into one merged result. Mutually exclusive with file; not usable with schema-less mode.
metadataNoArbitrary key-value metadata stored on the run.
priorityNoQueue priority (1-100).
extractorNoSaved extractor to run. Mutually exclusive with config; omit both for schema-less inference.
environmentYes"TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment).
waitSecondsNoMax seconds to block waiting on the run (clamped to the server wait budget).
workspaceIdYesTarget workspace (ws_...). Must be a granted workspace — get_me lists the accepted values.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNo
filesNo
runIdYes
outputNoExtracted values (PROCESSED only).
statusYesTerminal status, or "running" (resume via the get tool).
runTypeNo
llmContextNo
dashboardUrlNo
failureReasonNo
failureMessageNo

TDQS

A4.8/5.0
Behavior5/5

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

Discloses key runtime behavior beyond annotations: the call 'Creates an extract run' and may return status "running" with a runId — 'normal, not an error; poll it with get_extract_run'. It also flags that detail:"full" is 'the only way to prove where a value came from (provenance)' and instructs agents to follow any llmContext guidance. These traits are consistent with annotations (readOnlyHint=false, idempotentHint=false), so no contradiction exists.

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?

Every sentence earns its place — there is no filler, and the core purpose and primary sibling distinction are front-loaded. However, the operational details (mode rules, package handling, detail/provenance, polling, llmContext) are packed into a dense single block without internal grouping, making it harder to scan; a 5 would require clearer structural organization.

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?

For a highly complex tool (10 parameters, nested objects, three execution modes, async runs, an output schema), the description covers every operational decision an agent faces: mode selection, sibling routing, error recovery when an extractor is missing, polling on 'running' status, provenance via detail:"full", and llmContext handling. The output schema covers return-value structure, so no further documentation is needed.

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 description coverage is 100%, so the baseline is 3. The description adds genuine relational meaning beyond the schema by stating cross-parameter constraints: 'exactly one of extractor or config, or omit both,' 'schema-less ... not usable with package,' and 'package instead of file' for 2-50 documents. These mode-selection semantics materially help an agent choose the right parameter combination, which justifies a 4.

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?

Opens with a specific verb+resource: 'Extract specific structured values (totals, line items, dates, names, tables) from a document,' and enumerates the three execution modes (saved extractor, inline JSON Schema, schema-less inference). It explicitly distinguishes itself from parse_document ('for the raw text/markdown of the pages use parse_document instead'), so an agent can tell the two apart immediately.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance and names alternatives with conditions: 'If the user says "OCR" but wants specific values out, use this tool; ... use parse_document instead.' It also states the mode-selection rule ('Provide exactly one of extractor or config, or omit both'), the file-vs-package condition, and an error-recovery path ('rerun THIS tool without the extractor ... do not fall back to parse_document'). This is exemplary routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource+action combination, and the descriptions actively disambiguate potential overlaps (e.g., extract_data vs parse_document, detect_form_fields vs edit_pdf, get_file vs get_file_upload). The consistent verb_noun prefix pattern makes the semantic boundary of every tool immediately recognizable.

Naming Consistency4/5

The dominant verb_noun pattern is highly consistent across all nine domains (list_*, get_*, create_*, update_*, delete_*, run_*, get_*_run, get_*_batch, publish_*_version). Minor deviations exist: deploy_workflow_version vs publish_*_version for the same freeze-a-draft concept, and get_form_detection_run doesn't mirror its detect_form_fields counterpart.

Tool Count2/5

86 tools is a very heavy agent-facing surface, well past the 25+ threshold. The count is inflated by the near-identical 13-tool lifecycle repeated across extract, classify, and split (each with list/get/create/update/publish/runs/batches/versions), and while each tool has a distinct purpose, the sheer volume makes selection harder.

Completeness4/5

Core lifecycles are thoroughly covered: create → update → publish → run (single and batch) → poll → cancel → delete-run → list runs/versions. Notable gaps include no delete tool for extractors, classifiers, splitters, workflows, or evaluation sets, and edit/form-detection runs have no list endpoint (documented workaround: keep run IDs). These are hygenic gaps that don't block primary workflows.

Resources