Document reader for AI agents: PDF text and tables, Word paragraphs, metadata, and OCR for scanned files and images. Runs in memory and stores nothing. Requires a Bearer token.
Scored across 7 tools
Most tools have clearly distinct purposes, but the PDF-related tools (pdf_texto, pdf_markdown, pdf_tablas) overlap in extracting PDF content, and ocr vs pdf_texto depends on knowing whether the input is scanned. Descriptions clarify the differences, so misselection is limited.
Most tools follow a consistent format_action pattern in snake_case (pdf_texto, pdf_markdown, docx_texto). However, 'estado' and 'ocr' break that pattern, making it mostly consistent with minor deviations.
Seven tools is well-scoped for a document extraction server. Each tool covers a distinct format or output type, with no obvious redundancy.
The surface covers common extraction tasks for .docx, PDFs, and images via OCR, including text, tables, metadata, and markdown. Minor gaps exist, such as no direct .docx-to-markdown conversion or support for other document formats, but agents can work around these.
Extrae párrafos y tablas de un documento Word (.docx).
Args:
fuente: URL pública del .docx o su contenido en base64.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full burden, and it discloses almost no behavior beyond the purpose. It never mentions whether the source URL must be publicly reachable, size limitations, what happens to embedded images or text boxes, or how failures are surfaced.
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 purpose sentence is front-loaded and wastes no words, and the Args block is tight. The pseudo-code Args formatting is slightly unusual for a description but costs nothing.
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 one-parameter, no-output-schema extraction tool the description is roughly adequate: it covers what is extracted and what the parameter accepts. It still leaves error behavior and input constraints unstated, which an agent would need when a URL is unreachable or a file is oversized.
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 coverage is 0% and the single property has no description, so the Args block is the only documentation. It usefully clarifies that fuente accepts either a public .docx URL or base64 content, which the bare 'string' schema does not convey.
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 (extrae) and resource (párrafos y tablas de un documento Word .docx), which is immediately distinct from the pdf_* and ocr siblings by format. It never names an alternative explicitly, so sibling differentiation is only implicit in the resource name.
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 statement of when to use this tool versus ocr or pdf_texto, no prerequisites, and no exclusions. Usage must be inferred entirely from the .docx suffix in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el estado del servicio y si el OCR está disponible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two returned facts (service state, OCR availability), which is the key behavioral signal for a probe, but says nothing about authentication, caching, latency, or the shape/values of the returned status.
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 front-loaded sentence with no filler; the two pieces of information it returns are stated immediately. It is appropriately sized for a no-argument probe, though it is arguably terse enough that one more clause about return format would not have hurt.
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 must convey what comes back, and it does name both returned values (service status, OCR availability). For a zero-parameter read-only probe this is close to sufficient, with only the concrete status values/format unspecified.
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?
The tool takes zero parameters, so per the rubric the baseline is 4. There are no arguments whose semantics could be clarified, and the description does not waste words pretending otherwise.
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?
'Devuelve el estado del servicio y si el OCR está disponible' names a specific verb (devuelve) and resource (estado del servicio) plus the OCR availability flag. It is clearly a health/probe tool, distinct from the document-processing siblings, though it never explicitly contrasts itself with 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?
There is no explicit when-to-use or when-not-to-use guidance, and no mention of the natural precondition use case (verifying OCR availability before calling the 'ocr' sibling). The purpose of a status probe makes usage largely self-evident, so this is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconoce el texto de un PDF escaneado o de una imagen.
Args:
fuente: URL pública del archivo o su contenido en base64.
idioma: Idiomas de tesseract, por ejemplo `spa`, `eng` o `spa+eng`.
paginas: Rango opcional de páginas si es PDF. Sin valor, todas.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes | ||
| idioma | No | spa+eng | |
| paginas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says nothing about cost/latency of OCR, size limits on URL or base64 input, what happens on unsupported languages or malformed page ranges, or what the return value looks like. Only input semantics are covered.
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 front-loaded purpose sentence followed by a tight per-parameter list; no filler. Slightly terse on paginas format, but every sentence earns its place.
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 3-parameter tool with no annotations and no output schema, the parameter documentation is adequate, but the description leaves output shape, error/language-failure behavior, and input size constraints unaddressed. It is the minimum viable description for 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 0%, so the Args block does the work and does it well: fuente is a public URL or base64 content, idioma is a tesseract language code with concrete examples (spa, eng, spa+eng), paginas is an optional PDF page range defaulting to all. The only gap is the exact range syntax (e.g. '1-5').
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 concrete verb and resource: recognize text from a scanned PDF or image. That is specific and unambiguous. It does not differentiate itself from the sibling pdf_texto (digital-PDF extraction) or pdf_markdown, so an agent must infer that OCR is for scans/images rather than born-digital text.
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 the use case by naming 'scanned PDF or image', but never states when to choose this over pdf_texto, pdf_markdown or pdf_tablas, nor any prerequisites (language availability, base64 size limits). No explicit when/when-not guidance for a crowded sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convierte el PDF a Markdown con títulos y listas detectados por forma.
Args:
fuente: URL pública del PDF o su contenido en base64.
paginas: Rango opcional, por ejemplo `1-5,9`. Sin valor, todas.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes | ||
| paginas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state whether scanned/image PDFs are supported, whether large documents are chunked or truncated, whether a URL fetch requires network permissions, or what the returned Markdown looks like. It implies a conversion but discloses no operational traits.
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 purpose is front-loaded in a single sentence, followed by a compact Args block that documents each parameter with no filler. Every line carries 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?
For a two-parameter converter with no output schema and no annotations, the description names the output type (Markdown) but not its return shape, and it omits the key routing context (scanned PDFs → ocr, tables → pdf_tablas) that would make it self-sufficient. Adequate but with clear holes.
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 0%, so the description must compensate, and it does: 'fuente' is explained as either a public URL or base64-encoded content, and 'paginas' is given a concrete format example (`1-5,9`) plus the default behavior ('Sin valor, todas'). Only minor gaps remain (e.g., allowed URL schemes, base64 size limits).
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: 'Convierte el PDF a Markdown'. The added detail 'con títulos y listas detectados por forma' implies a structural conversion that differs from sibling pdf_texto (plain text) and pdf_tablas (tables), though it never names those siblings explicitly.
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?
There is no guidance on when to choose this tool over pdf_texto, pdf_tablas, ocr, or docx_texto. The closest thing to context is the 'por forma' hint, which requires the agent to infer that scanned PDFs belong to ocr and tabular extraction to pdf_tablas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve páginas, cifrado y metadatos del PDF.
Args:
fuente: URL pública del PDF o su contenido en base64.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose the return content (page count, encryption status, metadata). It adds the accepted input forms (public URL or base64), which is genuinely useful, but says nothing about failure behavior for non-public/inaccessible URLs, size limits, or whether encrypted PDFs are readable.
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?
Extremely tight: one sentence of purpose plus a single parameter note, with the operative content front-loaded. The 'Args:' block is slightly redundant scaffolding for a one-parameter tool, but nothing is bloated.
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 single-parameter, read-only extraction tool with no output schema and no annotations, the description tells the agent what it returns and what input forms are accepted, which is close to sufficient. Only the absence of any guidance on sibling selection or input failure modes keeps it from being fully 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 coverage is 0% and the schema only types 'fuente' as a bare string, so the description's clarification that it is a public URL or base64-encoded file content is meaningful added semantics. It stops short of specifying the expected base64 encoding or error handling, but it covers the parameter's core ambiguity.
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 set of outputs — 'páginas, cifrado y metadatos' — for the PDF resource, which is concrete and far better than the bare tool name. It does not, however, explicitly contrast itself with the text-extraction siblings (pdf_texto, pdf_markdown, pdf_tablas), leaving the agent to infer the distinction from the output list alone.
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?
There is no statement of when to prefer this tool over pdf_texto, pdf_markdown, pdf_tablas, or ocr, and no prerequisites are given. The only implicit signal is that it yields metadata rather than content, so the agent must infer the selection rule itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detecta las tablas del PDF y devuelve sus filas.
Args:
fuente: URL pública del PDF o su contenido en base64.
paginas: Rango opcional, por ejemplo `1-5,9`. Sin valor, todas.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes | ||
| paginas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that it returns table rows; it says nothing about authentication needs, page or size limits, whether scanned/OCR-only PDFs are supported, or how the result is structured or paginated.
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 opening sentence is front-loaded and delivers the core behavior immediately, and the Args block is terse with no filler. The Args list restates the schema's parameter names, which is mildly redundant but earns its place given zero schema description coverage.
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 read tool with no output schema and no annotations, the description covers inputs adequately but leaves output shape (row/column representation, multi-table handling) and failure modes unaddressed. It is the minimum viable definition rather than a complete one.
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 0%, so the description must compensate, and it does: "fuente" is documented as either a public URL or base64-encoded content, and "paginas" as an optional range with the example format `1-5,9` and the default of all pages. Both parameters gain meaning beyond the bare schema titles.
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: "Detecta las tablas del PDF y devuelve sus filas", which clearly separates it from pure text-extraction siblings like pdf_texto or pdf_markdown in intent. It does not name any sibling explicitly, so an agent must infer the boundary from the word "tablas".
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as pdf_texto or ocr for scanned documents. The only conditional statement ("Sin valor, todas") concerns a parameter default, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrae el texto de un PDF, página por página.
Args:
fuente: URL pública del PDF o su contenido en base64.
paginas: Rango opcional, por ejemplo `1-5,9`. Sin valor, todas.
| Name | Required | Description | Default |
|---|---|---|---|
| fuente | Yes | ||
| paginas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only partially: it discloses that extraction is page-by-page and that the source may be a URL or base64. It does not say whether it handles scanned/image PDFs (vs ocr), whether there are size or rate limits, or how pages are separated in the output.
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 purpose sentence is front-loaded and the Args block is compact with zero filler. The pseudo-docstring formatting is slightly mechanical but every line carries 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?
For a two-parameter extraction tool with no output schema, the description covers inputs and page semantics adequately but omits the expected return shape (e.g., how text is segmented per page) and whether non-text PDFs are handled. These omissions matter for a retrieval tool an agent must interpret results from.
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 0%, so the description must compensate, and it largely does: 'fuente' is explained as a public URL or base64 content, and 'paginas' is given a concrete range syntax example ('1-5,9') plus its default behavior. Minor gap: no note on out-of-range or malformed page specs.
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 ('Extrae el texto de un PDF, página por página'), which is clear enough to distinguish plain-text extraction from siblings like pdf_markdown and pdf_tablas. However, it never explicitly names or contrasts those alternatives, so differentiation relies on the agent inferring from the sibling list.
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 guidance on when to use this versus ocr (scanned PDFs), pdf_markdown, or pdf_tablas. The only behavioral note is the default 'Sin valor, todas', which describes a parameter default rather than usage context. The agent is left to infer selection entirely.
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.
docx_textoestadoocrpdf_markdownpdf_metadatospdf_tablaspdf_texto
Add one secure layer between your agents and this server.