docuprox-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOCUPROX_API_KEY | Yes | Your DocuProx API key | |
| DOCUPROX_BASE_URL | Yes | Base URL of the DocuProx API (e.g. https://api.docuprox.com/v1) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| process_jobA | Submit a document (image, PDF, or zip) for asynchronous processing via DocuProx. Reads the file from disk and uploads it as multipart/form-data. Returns a job_id you can track with job_status or poll_job. |
| process_agentA | Submit a document for SYNCHRONOUS agentic extraction via DocuProx. Reads the file from disk, uploads as multipart/form-data, and waits for the result. Returns the extracted data directly (no job polling needed). Credits are deducted and refunded on failure. |
| job_statusB | Check the current status of an asynchronous DocuProx processing job. Returns the job_id and status string (e.g. NEW, UNZIP FILE, UNZIP FILE SUCCESS, UNZIP FILE FAILED,PROCESS IMAGE, PROCESS IMAGE SUCCESS,PROCESS IMAGE FAILED,SUCCESS,FAILED). |
| job_resultsA | Fetch the extracted results of a completed asynchronous DocuProx processing job. Requires a valid job_id and optionally a format ('json' or 'csv'). |
| poll_jobA | Poll an asynchronous DocuProx job until it reaches a terminal status (COMPLETED, FAILED, or ERROR) or a timeout is reached. Useful to block until a job is done without manual retries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The tools are mostly distinct: process_job and process_agent both submit documents but differ clearly by async vs sync behavior, and job_status vs poll_job are differentiated as one-time check vs blocking wait. Minor ambiguity exists between job_status and poll_job since both relate to job progress, but the descriptions adequately clarify their purposes.
Names are readable and use snake_case, but the pattern is mixed: process_job, process_agent, and poll_job are verb_noun, while job_status and job_results are noun_noun. This inconsistency is noticeable but not chaotic, and each name still conveys its intended function reasonably well.
With 5 tools, the server is well-scoped for its purpose: async submission, status checking, polling, result retrieval, and sync submission. Each tool serves a discrete workflow step without unnecessary redundancy.
The toolkit covers both asynchronous and synchronous processing flows end-to-end: submit, track, wait, and retrieve results. There are no obvious dead ends for the core document-processing use case, and the missing ability to cancel or delete jobs is not essential to the stated purpose.