Doc2x MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap in waiting/submission pairs that could cause confusion. For example, doc2x_convert_export_wait and doc2x_convert_export_result both relate to export jobs, and the distinction between waiting and checking status might not be immediately clear. However, the descriptions help clarify their roles, and the overall set is well-organized around parsing and conversion workflows.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout, using a doc2x_ prefix with verb_noun combinations (e.g., convert_export_submit, parse_pdf_status). All names use snake_case uniformly, and the naming scheme clearly indicates the action and resource involved, making the set predictable and easy to navigate.
Tool Count5/5
With 13 tools, the count is well-scoped for a PDF/document processing server. Each tool serves a specific function in parsing, converting, and managing tasks, with no obvious bloat or redundancy. The tools cover submission, waiting, status checking, and result handling, which is appropriate for the domain's asynchronous nature.
Completeness4/5
The tool set provides comprehensive coverage for PDF and image parsing, conversion, and result retrieval, including synchronous and asynchronous operations. Minor gaps exist, such as the lack of tools for deleting or managing tasks beyond status checks, but these are not critical for core workflows. The surface supports end-to-end processing from submission to download, with only slight omissions in task lifecycle management.
Average 4/5 across 13 of 13 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the tool's 'best-effort' nature and two-step process (system unzip first, then write zip file), which adds useful context beyond the basic operation. However, it doesn't cover critical aspects like error handling, permissions needed for output_dir, or what 'materialize' entails in terms of file structure or overwrites.
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?
The description is appropriately sized with two concise sentences. The first sentence front-loads the core purpose, and the second adds behavioral context without redundancy. Every sentence earns its place by clarifying the operation and fallback mechanism, though it could be slightly more structured (e.g., bullet points for steps).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of handling zip files and base64 encoding, with no annotations and no output schema, the description is incomplete. It misses key details: what 'materialize' means (extract? copy?), error responses, output format, or success indicators. For a tool with 2 parameters and significant behavioral nuance, this leaves the agent under-informed about execution and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that convert_zip_base64 is a base64-encoded zip file to materialize and output_dir is the target directory, adding meaning beyond the schema's minimal type constraints. However, it doesn't detail format expectations (e.g., zip structure, encoding standards) or directory requirements (e.g., must exist), leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: materializing a base64-encoded zip file into an output directory. It specifies the verb 'materialize' and the resource 'convert_zip (base64)', which distinguishes it from sibling tools focused on conversion, parsing, or downloading. However, it doesn't explicitly differentiate from all siblings (e.g., doc2x_download_url_to_file might also handle files), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a 'best-effort' approach with system unzip as a fallback, but doesn't specify prerequisites, error conditions, or comparisons to sibling tools like doc2x_convert_export_result. Without explicit when/when-not instructions, the agent lacks context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'latest export result' suggesting it retrieves data (read operation) and that uid 'may contain an escaped URL', adding some context. But it doesn't disclose behavioral traits like error handling, rate limits, authentication needs, or what 'result' entails (e.g., format, size).
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?
The description is a single, efficient sentence with zero waste—front-loaded with the core action ('Get'), specifies the resource and constraint, and includes a helpful note about the uid. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with full schema coverage and no output schema, the description is minimally adequate. It clarifies the tool's purpose and uid source, but as a read operation with no annotations, it should ideally explain more about the result (e.g., what data is returned) to compensate for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the uid parameter fully. The description adds marginal value by noting the uid 'may contain an escaped URL', but doesn't provide additional syntax or format details beyond the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'latest export (convert) result', specifying it's for a parsed PDF uid. It distinguishes from siblings like doc2x_convert_export_submit (which submits) and doc2x_convert_export_wait (which waits), but doesn't explicitly contrast with status-checking tools like doc2x_parse_pdf_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a parse task (uid from doc2x_parse_pdf_submit) and for getting results, not submitting or waiting. However, it lacks explicit when-not-to-use guidance or clear alternatives among siblings (e.g., vs. doc2x_parse_pdf_status for parse status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the file 'will be overwritten if it exists,' which is a critical behavioral trait not covered elsewhere. However, it doesn't address other aspects like error handling, network timeouts, or authentication needs, which are important for a download operation.
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?
The description is a single, efficient sentence that front-loads the core action ('Download a Doc2x-provided URL') and includes essential details without waste. Every word contributes to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a download operation with 2 parameters), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and key behavior (overwriting), but lacks details on return values, error cases, or performance considerations, which could aid an AI agent in robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 fully documents the parameters (url and output_path). The description adds minimal value by hinting at the URL source ('from doc2x_convert_export_result') and the overwrite behavior, but this doesn't significantly enhance the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and the resource ('a Doc2x-provided URL to a local file path'), making the purpose evident. However, it doesn't explicitly differentiate this tool from its siblings (e.g., doc2x_materialize_convert_zip might also handle file outputs), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing a specific sibling tool ('doc2x_convert_export_result') as a source for the URL, providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other download or file-handling tools) or any prerequisites, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the synchronous behavior and return format (raw JSON with convert_zip), which is useful. However, it lacks details on error handling, performance expectations (e.g., timeouts for large images), or authentication needs, leaving gaps for a mutation-like tool.
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?
The description is a single, efficient sentence that front-loads the core action and output. Every word earns its place, with no redundancy or unnecessary details, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is minimally adequate. It covers the purpose and output format but lacks context on errors, limitations (e.g., supported image types beyond png/jpg implied by schema), or integration with sibling tools, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the 'image_path' parameter (type, constraints, path resolution). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('parse an image layout synchronously') and the resource ('image'), specifying it returns raw Doc2x result JSON. It distinguishes from siblings like 'doc2x_parse_image_layout_submit' (async) and 'doc2x_parse_image_layout_wait_text' (text-focused), but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for synchronous parsing of image layouts, but lacks explicit guidance on when to use this vs. alternatives like 'doc2x_parse_image_layout_submit' (async) or 'doc2x_parse_pdf_*' tools. It mentions 'convert_zip when present' as a feature, but no clear when-not scenarios or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns information for debugging, which implies it is a read-only, non-destructive operation. However, it lacks details on potential side effects, authentication needs, rate limits, or output format. The description adds basic context but does not fully compensate for the absence of annotations.
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?
The description is a single, efficient sentence that front-loads key information ('Debug helper') and clearly states the action and purpose. There is no wasted language, and it effectively communicates the tool's role in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (0 parameters, no output schema), the description is somewhat complete for a debugging utility. However, without annotations or an output schema, it lacks details on what the returned config and API key source entail, such as format or structure. This leaves gaps in understanding the tool's full behavior and output.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter-specific information, which is appropriate. A baseline of 4 is applied as per the rules for zero parameters, since the schema fully covers the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Debug helper' that 'return[s] resolved config and API key source for troubleshooting.' It specifies the verb ('return'), resource ('resolved config and API key source'), and context ('for troubleshooting'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools, which are focused on conversion, download, and parsing operations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for troubleshooting'), suggesting this tool should be used when debugging issues, but it does not provide explicit guidance on when to use it versus alternatives or any exclusions. No sibling tools appear to serve a similar debugging purpose, so the implication is adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving status/result for an async task, which implies a read-only operation, but does not detail potential behaviors like error handling, rate limits, authentication needs, or what the result format might be. For a tool with zero annotation coverage, this is insufficient transparency.
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?
The description is a single, efficient sentence that front-loads the key information ('Get status/result') and includes essential context (e.g., 'async image-layout parse task by uid'). There is no wasted verbiage, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an async task status tool with no annotations and no output schema, the description is incomplete. It lacks details on what the status/result includes (e.g., progress indicators, error messages, or output data format), which is critical for an agent to use this tool effectively. The description does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the uid parameter fully documented in the schema as a string from doc2x_parse_image_layout_submit. The description adds minimal value by reinforcing the uid's purpose but does not provide additional semantics beyond what the schema already covers, aligning with the baseline score for high schema coverage.
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 the specific action ('Get status/result') and resource ('existing async image-layout parse task by uid'), distinguishing it from siblings like doc2x_parse_image_layout_submit (which submits tasks) and doc2x_parse_image_layout_sync (which performs synchronous parsing). It precisely identifies the tool's function without being vague or tautological.
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?
The description implies usage context by specifying 'existing async image-layout parse task by uid' and referencing doc2x_parse_image_layout_submit as the source of the uid, which guides when to use this tool. However, it does not explicitly state when not to use it or name alternatives like doc2x_parse_image_layout_wait_text, leaving some room for improvement in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the asynchronous job-starting behavior, the need for subsequent polling, and the critical parallelization constraint. However, it lacks details about authentication requirements, rate limits, or error handling that would be valuable for a mutation tool.
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?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides critical usage guidance. There is zero wasted language, and the most important information (the parallelization warning) is appropriately emphasized.
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?
For a mutation tool with no annotations and no output schema, the description does well by explaining the asynchronous workflow and critical constraints. However, it doesn't describe what the export job actually produces (e.g., file format details, output location) or potential error conditions, leaving some gaps in understanding the complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description adds no parameter-specific information beyond what's in the schema. It mentions 'uid+format' which maps to the 'uid' and 'to' parameters, but provides no additional context about parameter meanings, interactions, or usage examples. The schema does most of the work, resulting in a baseline score.
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 the specific action ('Start an export (convert) job') and resource ('for a parsed PDF uid'), distinguishing it from sibling tools like doc2x_convert_export_wait and doc2x_convert_export_result which handle subsequent polling/result retrieval. It explicitly names the verb and target resource with precision.
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?
The description provides explicit guidance on when to use this tool ('After this, poll with doc2x_convert_export_wait or doc2x_convert_export_result') and when not to use it ('Do NOT call doc2x_convert_export_submit twice for the same uid+format in parallel'), clearly differentiating it from alternatives and specifying critical exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the asynchronous nature of the operation, the return format, and the required follow-up workflow. However, it doesn't mention potential limitations like file size restrictions, supported image formats beyond png/jpg (implied by schema), or error conditions.
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?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first explains what the tool does and returns, the second provides critical workflow guidance. No wasted words.
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?
Given the tool's complexity (async workflow requiring follow-up calls), no annotations, and no output schema, the description does well by explaining the async nature and required subsequent steps. However, it doesn't describe what the parse task actually produces or potential error scenarios, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 the specific action ('Create an async image-layout parse task') and resource ('image-layout'), distinguishing it from siblings like doc2x_parse_image_layout_sync (synchronous version) and doc2x_parse_image_layout_status (status check). It explicitly mentions the return value format '{uid}' and subsequent required calls.
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?
The description provides explicit guidance on when to use this tool versus alternatives: it specifies this is an async task that requires follow-up calls to doc2x_parse_image_layout_wait_text or doc2x_parse_image_layout_status with the returned uid. This clearly distinguishes it from the synchronous sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavioral traits: it creates a task (implying asynchronous processing), returns a UID for tracking, and outlines the expected workflow (monitoring with status tool, waiting only if explicitly requested). However, it doesn't mention error handling, rate limits, or authentication needs.
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?
The description is perfectly concise and front-loaded: the first sentence states the core purpose and return value, the second provides critical workflow guidance. Every sentence earns its place with essential information, no wasted words.
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?
Given the tool's complexity (asynchronous task creation with 1 parameter), no annotations, and no output schema, the description does well: it explains the purpose, workflow, and return value. However, it lacks details on error cases, timeouts, or what the UID represents structurally, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the pdf_path parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain file size limits or format requirements). Baseline 3 is appropriate when schema does the heavy lifting.
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 the specific action ('Create a Doc2x PDF parse task') and resource ('for a local file'), distinguishing it from siblings like doc2x_parse_pdf_status (monitor) and doc2x_parse_pdf_wait_text (wait). It explicitly identifies the tool's role in initiating parsing tasks.
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?
The description provides explicit guidance on when to use this tool ('Create a Doc2x PDF parse task') versus alternatives: 'Prefer calling doc2x_parse_pdf_status to monitor progress/result; only call doc2x_parse_pdf_wait_text if the user explicitly asks to wait/return merged text.' This clearly defines the tool's place in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: waiting until success, caching/reuse logic with uid/pdf_path, and the two-step process (submit then wait if needed). It mentions returning merged text but lacks details on error handling, timeout behavior, or output format specifics, which keeps it from a perfect score.
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?
The description is efficiently structured in two sentences: the first states the core purpose, and the second explains the parameter logic. Every phrase adds value, with no redundant or vague language, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is adequate but incomplete. It covers the core purpose and parameter interplay well, but lacks details on error cases, timeout handling, output format, or performance implications (e.g., what 'wait' entails). For a tool with no output schema, more on return values would be helpful.
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 57% (4 of 7 parameters have descriptions), so the description must compensate. It adds meaningful context for uid and pdf_path by explaining their interaction (prefer uid, reuse cached uid or submit new task), which goes beyond the schema's basic descriptions. However, it doesn't address poll_interval_ms, max_wait_ms, join_with, or the output-limiting parameters, leaving some gaps.
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 the tool's purpose with specific verbs ('wait', 'return merged text') and resource ('PDF parse task'), distinguishing it from siblings like doc2x_parse_pdf_submit (which submits) and doc2x_parse_pdf_status (which checks status). It explicitly mentions waiting for success and returning text, which is unique among the parse-related tools.
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?
The description provides explicit guidance on when to use this tool vs. alternatives: it advises preferring uid to avoid re-submission and explains the fallback behavior with pdf_path. It distinguishes from siblings by implying this is for waiting on parse tasks, not submitting or checking status, though it doesn't name specific alternatives beyond the uid reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that the tool waits for job completion, explains backward compatibility behavior (will submit once then wait if formula_mode is provided for non-in-process jobs), and implies polling behavior through the existence of poll_interval_ms and max_wait_ms parameters. However, it doesn't explicitly describe error handling or timeout behavior.
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?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by usage guidance and backward compatibility explanation. Every sentence earns its place with no wasted words, making it highly efficient while remaining comprehensive.
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?
For a complex tool with 8 parameters, no annotations, and no output schema, the description does remarkably well. It covers purpose, workflow, key parameter relationships, and backward compatibility. The main gap is lack of explicit information about return values or error conditions, but given the tool's waiting nature and sibling tools available, this is somewhat mitigated.
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?
With only 25% schema description coverage, the description compensates significantly. It explains the relationship between uid and to parameters (from doc2x_convert_export_submit), clarifies the backward compatibility behavior with formula_mode, and mentions the expected workflow. While it doesn't detail all 8 parameters, it provides crucial context for the most important ones beyond what the sparse schema offers.
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 the tool's purpose with a specific verb ('Wait for') and resource ('an export job'), distinguishing it from siblings like doc2x_convert_export_submit (which submits jobs) and doc2x_convert_export_result (which likely retrieves results). It explicitly identifies this as a waiting operation for export job completion.
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?
The description provides explicit usage guidance: 'Prefer calling doc2x_convert_export_submit first, then wait with uid+to' specifies the recommended workflow and alternative tool. It also explains backward compatibility behavior with formula_mode, giving clear context for when to use certain parameter combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a blocking/waiting operation ('wait...until success'), it returns specific output ('first page markdown'), and it has caching logic ('reuse an in-process cached uid'). It doesn't mention error handling or rate limits, but covers the core operational flow well.
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?
The description is efficiently structured in two sentences. The first sentence states the core purpose and output. The second sentence provides crucial usage guidance for the two main parameters. Every word earns its place with no redundancy or fluff.
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?
For a tool with 4 parameters, no annotations, and no output schema, the description does well by explaining the waiting behavior, output format, and parameter interplay. It could be more complete by mentioning what happens on failure or the format of the returned markdown, but it covers the essential context given the complexity.
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 50% (uid and image_path have descriptions, poll_interval_ms and max_wait_ms do not). The description adds significant value by explaining the semantic relationship between uid and image_path: uid is preferred to avoid resubmission, while image_path triggers either cache reuse or new submission. This clarifies parameter usage beyond the basic schema descriptions.
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 the specific action ('Wait for an image-layout parse task until success') and the resource involved ('first page markdown'). It distinguishes itself from siblings like doc2x_parse_image_layout_submit (which submits) and doc2x_parse_image_layout_status (which checks status) by emphasizing waiting for completion and returning output.
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?
The description explicitly provides usage guidance: 'Prefer passing uid (no re-submit)' indicates when to use uid over image_path, and it explains the alternative flow when only image_path is provided (reuse cached uid or submit new task). This directly addresses when to use this tool versus its submit sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return structure ({status, progress, detail}), status values (processing/failed/success), progress range (0..100), and when detail is populated (only when status=failed). It also mentions the dependency on doc2x_parse_pdf_submit for obtaining the uid. However, it doesn't cover potential errors, rate limits, or authentication needs.
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?
The description is efficiently structured in two sentences: the first explains the tool's purpose and return values, the second provides critical usage guidance. Every sentence adds essential information without redundancy, making it easy for an agent to parse quickly.
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?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It explains the return structure and tool relationships well. However, it could benefit from mentioning error handling or timeouts, which would make it fully comprehensive for a status-checking operation.
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 schema already documents the uid parameter. The description adds meaningful context by explaining that the uid comes from doc2x_parse_pdf_submit, which helps the agent understand the parameter's origin and relationship to other tools. This goes beyond the schema's technical description.
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 the specific action ('Query parse task status') and resource ('by uid'), distinguishing it from sibling tools like doc2x_parse_pdf_submit (which submits tasks) and doc2x_parse_pdf_wait_text (which waits for completion). It explicitly identifies the tool's role in checking status rather than initiating or retrieving content.
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?
The description provides explicit guidance on when to use this tool: after submitting a parse task via doc2x_parse_pdf_submit (referenced in the parameter description) and before fetching content via doc2x_convert_export_* tools. It clearly differentiates this status-checking tool from content-retrieval alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![doc2x-mcp MCP server](https://glama.ai/mcp/servers/NoEdgeAI/doc2x-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NoEdgeAI/doc2x-mcp)

Score Badge

Copy to your README.md:

[![doc2x-mcp MCP server](https://glama.ai/mcp/servers/NoEdgeAI/doc2x-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NoEdgeAI/doc2x-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NoEdgeAI/doc2x-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server