Document conversion and OCR for AI agents: PDF, Office docs, images to text.
Scored across 4 tools
Each tool targets a clearly distinct input format and output type: image OCR, spreadsheet parsing, PDF conversion, and URL text extraction. There is no plausible overlap in tool selection for a given input.
Most names follow a predictable action-object pattern (parse_spreadsheet, pdf_to_markdown, url_to_clean_text), though ocr_image starts with an acronym rather than a verb. The deviation is minor and the intent remains obvious.
Four tools is well-scoped for a focused document-conversion server, and each tool covers a distinct, useful input type. No tool appears redundant or unnecessary.
The surface covers common inputs like images, spreadsheets, PDFs, and URLs, but notably lacks DOCX/PPTX/HTML file conversion, which are central to a general document-conversion domain. Agents would hit dead ends for those common document types.
Run OCR on an image (base64-encoded bytes) and return recognized text.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Tesseract language code (default 'eng'). | eng |
| image_base64 | Yes | The image file contents, base64-encoded. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and an output schema exists, so the safety and return profile are fully covered elsewhere. The description adds essentially no behavioral context of its own — nothing about language support, accuracy, size limits, or failure modes.
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?
One sentence, front-loaded with the action and ending with the result. Every clause carries information and nothing is padded.
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 two-parameter, single-purpose tool with full annotations and an output schema, the description covers what an agent needs to call it. Minor gaps remain around accepted image formats and error behavior, but they do not block correct invocation.
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 documented in the schema, and the description merely echoes the base64-encoded input. It adds no meaning beyond the structured field, 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 (Run OCR), the resource (an image), the input encoding (base64-encoded bytes) and the outcome (recognized text). The image-input framing inherently separates it from parse_spreadsheet, pdf_to_markdown and url_to_clean_text, though it never names them.
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?
No when-to-use, when-not-to-use, or alternative routing is given. An agent must infer from the word 'image' that this is the right tool when the source is a picture rather than a PDF, URL, or spreadsheet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a CSV or XLSX file (base64-encoded bytes) into Markdown tables.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Original filename (used to detect .csv vs .xlsx). | |
| file_base64 | Yes | The spreadsheet file contents, base64-encoded. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the base64 encoding requirement, but that is already in the schema, and it says nothing about multi-sheet XLSX handling, size limits, or malformed-file behavior. With annotations carrying the safety burden, a 3 is appropriate.
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?
A single sentence with zero waste; the verb, accepted formats, and output format are all front-loaded. Nothing could be trimmed without losing information.
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?
An output schema exists, so return values need not be explained, and the annotations cover the safety profile. What remains thin is edge-case behavior (multi-sheet workbooks, invalid base64, oversized files), which the description leaves entirely to inference.
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 fully documented in the schema, including filename's role in format detection. The description's '(base64-encoded bytes)' merely restates the schema and adds no syntax or format detail beyond it. Baseline 3 applies when the schema does the heavy lifting.
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 (parse), the input formats (CSV or XLSX), the input encoding (base64 bytes), and the output (Markdown tables). This is clear and goes beyond the title, though it does not explicitly name or contrast with siblings like pdf_to_markdown or ocr_image — the format constraint implies the distinction rather than stating it.
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?
Usage is implied by the accepted formats: an agent can infer this is the tool for spreadsheet inputs rather than PDFs, images, or URLs. However, there is no explicit when-to-use guidance, no statement of prerequisites, and no naming of the sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a PDF (base64-encoded bytes) to Markdown, one section per page.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No | Maximum pages to extract (default 100). | |
| pdf_base64 | Yes | The PDF file contents, base64-encoded. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not carrying that burden. It does add the useful output shape ('one section per page'), but says nothing about failure modes (encrypted, scanned, or malformed PDFs), rate limits, or size constraints beyond the schema default.
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?
A single sentence, front-loaded with the action and resource, with no filler. It earns its place by also conveying the per-page output structure.
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 two-parameter conversion tool with a full output schema and complete safety annotations, the only real gaps are edge-case behavior (scanned PDFs, encryption) and when to prefer a sibling. Everything strictly needed to invoke it correctly is present.
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. The description only restates the base64 input encoding, adding no format, size, or interaction detail beyond what the schema provides — baseline 3 applies.
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 (Convert) and resource (PDF to Markdown) plus the output granularity ('one section per page'). Format specificity implicitly separates it from ocr_image, parse_spreadsheet, and url_to_clean_text, though no sibling is named to make the boundary explicit.
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?
No when-to-use guidance, no alternatives, no exclusions given. The most relevant ambiguity for an agent — whether a scanned/image PDF should go here or to ocr_image — is left unaddressed, so routing must be inferred purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public http(s) URL and return its main text content as plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The http(s) URL to fetch. Private/loopback hosts are rejected. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that only public http(s) URLs are fetched and that content is reduced to main text, but it does not disclose behavior around redirects, JavaScript-rendered pages, timeouts, rate limits, or error cases.
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 a single front-loaded sentence with no wasted wording. It states the operation, the input constraint, and the return format in one pass.
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?
This is a simple one-parameter read-only tool with complete schema coverage, annotations, and an output schema, so the description does not need to explain return values. It is largely complete for correct invocation, though it could say more about non-HTML or JS-heavy pages to set expectations.
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 url parameter is documented as an http(s) URL with private/loopback hosts rejected. The description restates the public-URL requirement but adds no parameter syntax, format, or validation detail beyond what the schema already provides, so the baseline of 3 applies.
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?
The description states a specific verb and resource: fetch a public http(s) URL and return its main text as plain text. It is clear what the tool does, but it does not differentiate itself from sibling parsers such as pdf_to_markdown, parse_spreadsheet, or ocr_image, leaving the agent to infer that this tool is for web page URLs rather than files or images.
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?
The description gives no explicit when-to-use guidance, no when-not-to-use guidance beyond the public-URL constraint, and no alternatives among sibling tools. An agent can infer it is for fetching public URLs, but there is no routing guidance for choosing between this and the file/image parsing siblings.
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.
ocr_imageparse_spreadsheetpdf_to_markdownurl_to_clean_textConvert PDF, Word, Excel and scanned documents to Markdown, tables and RAG chunks. OCR.
Convert, create and edit Word, PowerPoint, Excel and PDF documents from any AI agent.
Hosted document tools for agents: extract, parse, classify, convert, OCR, sign, and redact.
PDF, Word, PowerPoint, Excel, HTML and EPUB to clean Markdown for RAG, with OCR. Pay per document.
Add one secure layer between your agents and this server.
