Turn PDFs and images into typed fields — invoices, receipts, IDs and custom models — via Mindee OCR.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 4 tools
Each tool maps to a distinct step in the extraction workflow: listing models, submitting a document, checking job status, and fetching inference results. The overlap between submit polling and later job/inference retrieval is explicitly clarified in the descriptions.
All tools share the same mindee_ prefix and follow a consistent verb_noun pattern: extract_document, get_inference, get_job, list_models. There are no mixed conventions or ambiguous names.
Four tools are well-scoped for a focused document-extraction integration, with each tool earning its place in the lifecycle. There is no filler or redundant surface.
The tool set covers the core lifecycle: discover models, submit an extraction, poll a job, and retrieve the final inference. No obvious operational dead ends exist for the stated document-extraction purpose.
Submit a document (PDF or image) to a Mindee extraction model and return the structured fields. Provide EITHER document_url (a public URL) OR file_base64 (+ filename). This enqueues an inference and polls until it completes (up to ~30s); if it is still processing it returns a job_id you can poll with mindee_get_job then read with mindee_get_inference. NOTE: consumes Mindee API credits (paid, billed per page). V2 API: POST /v2/inferences/enqueue.
| Name | Required | Description | Default |
|---|---|---|---|
| rag | No | Enable Retrieval-Augmented Generation for the model, if configured. | |
| alias | No | Your own reference tag echoed back in the job/result. | |
| polygon | No | Return bounding-box polygons for fields. | |
| filename | No | Filename for file_base64 uploads, e.g. 'invoice.pdf'. | |
| model_id | Yes | Extraction model id (from mindee_list_models). | |
| raw_text | No | Also return the full OCR raw text of the document. | |
| confidence | No | Return per-field confidence levels (Certain/High/Medium/Low). | |
| file_base64 | No | Base64-encoded document bytes, files up to about 2.3 MB (use document_url for larger ones). Use this OR document_url; set `filename` too. | |
| webhook_ids | No | Webhook ids to notify on completion (async flows). | |
| document_url | No | Public URL of the document to process. Use this OR file_base64. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag non-readonly, open-world, non-idempotent, non-destructive behavior. The description adds meaningful context beyond annotations: paid per-page credit consumption, enqueue-and-poll behavior with a ~30s window, and job_id handoff to sibling tools. It does not explain whether duplicate submissions create duplicate billable inferences, which would be useful given idempotentHint=false.
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?
Front-loads the core action and return value, then gives input mode, async behavior, cost warning, and endpoint in compact sequence. Every sentence contributes operational detail; the endpoint reference is technical but relevant for an API-integrated agent.
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 10-parameter extraction submission with no output schema, the description covers return shape at a high level, async completion behavior, polling alternatives, input source options, and cost implications. Nothing essential for correct invocation appears 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?
Schema description coverage is 100%, so the baseline is 3; the description still adds value by centralizing the critical mutual exclusivity of document_url and file_base64 and pairing file_base64 with filename. It does not cover optional flags like rag, polygon, confidence, raw_text, or alias, but those are clearly documented in the schema.
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/resource combination: submit a PDF/image to a Mindee extraction model and return structured fields. It also distinguishes the async handoff path from the sibling tools (mindee_get_job, mindee_get_inference), so an agent can separate this from polling/read tools.
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?
Explicitly states the alternative input modes (document_url OR file_base64 + filename) and the async escalation path when processing exceeds ~30s. It also warns that calls consume paid credits, giving clear when-to-use context and a cost-related caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the structured result of a completed inference by id, returned as a compact map of extracted fields (plus raw_text if it was requested). V2 API: GET /v2/inferences/{inference_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the full unshaped API response instead of the compact fields map. Default false. | |
| inference_id | Yes | Inference id (from a Processed job's result_url, or from mindee_extract_document). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds real value on top: the return shape (compact fields map plus raw_text when requested) and the underlying V2 endpoint. It stops short of mentioning auth needs, rate limits, or error behavior for non-completed inferences.
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 tight sentences, front-loaded with the action and return shape, with the API reference appended as supporting detail. No filler.
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, the description usefully sketches what comes back (extracted fields map, optional raw_text) and where the id originates. It could say more about behavior on unfinished/invalid inferences, but for a simple read tool this is close to 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 both parameters are already documented, including the raw flag and where the id comes from. The description only alludes to 'raw_text if it was requested' and adds no syntax or format detail beyond the schema 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?
States a specific verb and resource ('Fetch the structured result of a completed inference by id') and even names the return shape, which cleanly separates it from mindee_extract_document (initiates extraction) and mindee_get_job (polls status).
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?
Implies usage via 'completed inference' and the parameter note pointing to mindee_extract_document, but never explicitly states when to call this versus mindee_get_job or what to do if the job is still pending. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the processing status of an enqueued document by job id. Status is Waiting | Processing | Processed | Failed. When Processed, the response carries a result_url; pass that inference id to mindee_get_inference. V2 API: GET /v2/jobs/{job_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job id returned by mindee_extract_document (when it times out) or an enqueue call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already covering safety, the description adds meaningful behavior: the four status values, the fact that a Processed response carries result_url, and the underlying V2 endpoint. It lacks details on polling frequency or failure recovery, but it materially exceeds the annotations.
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, front-loaded with the tool's purpose, then status values, then the follow-up action and endpoint. Every sentence contributes and there is no filler.
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 read-only, single-parameter job status tool with no output schema, the description covers what it returns (statuses, result_url) and what to do next (mindee_get_inference). An agent has everything needed 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 description coverage is 100% and the single parameter's origin is already documented by the schema. The description adds no syntax, format, or constraint beyond what the schema provides, so the baseline of 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?
States a specific verb and resource — checking processing status of an enqueued document by job id — with the status lifecycle. It routes to mindee_get_inference for results and the schema ties the job_id to mindee_extract_document, so it is clearly distinguishable from siblings.
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?
Implies usage when a job id exists (returned by extract timeout or enqueue) and explicitly directs the agent to mindee_get_inference once Processed. It does not state when *not* to use this tool or what to do in failure states, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the document-extraction models available to your Mindee account (id, name, type). Use a model's id as the model_id for mindee_extract_document. V2 API: GET /v2/search/models.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional case-insensitive name filter, e.g. 'invoice'. | |
| model_type | No | Optional model type filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds account-scoped availability ('available to your Mindee account'), the returned fields, and the V2 API endpoint, but does not mention pagination or rate limits.
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 compact sentences that front-load the tool's purpose and usage link, then append the API endpoint detail. Every clause earns its place with no redundancy.
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 simple read-only list tool with no output schema, the description covers what is returned, account scoping, and the downstream workflow. It lacks pagination or ordering details, which is a minor gap for a list endpoint.
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 both optional filters (name, model_type) are already documented in the schema. The description adds no additional filter syntax or semantics beyond what the schema provides, making the baseline 3 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?
States a specific verb ('List') and resource ('document-extraction models'), names the returned fields (id, name, type), and explicitly connects it to sibling mindee_extract_document via model_id. An agent can distinguish it from siblings without opening the schema.
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?
Explains the downstream use of the returned id for mindee_extract_document, which implies when to call this tool. It does not state when not to use it or name competing alternatives, so it falls short of a full when/when-not routing guide.
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.
mindee_extract_document2 fields changedInput schema / properties / file_base64 / descriptionPrevious value: -"Base64-encoded document bytes. Use this OR document_url; set `filename` too."New value: +"Base64-encoded document bytes, files up to about 2.3 MB (use document_url for larger ones). Use this OR document_url; set `filename` too."Input schema / properties / file_base64 / maxLengthAdded value: +3145728Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Convert documents to structured JSON (invoices, receipts, contracts) in 2 seconds
Extract invoices, receipts and contracts into structured JSON. EU-hosted, per-field confidence.
Add one secure layer between your agents and this server.
