Provides optional AI-generated image descriptions by sending extracted OCR text to OpenAI models (default gpt-4o-mini) to generate brief text summaries.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tool-transcribai-mcp transcribe the text from this image and show the confidence levels"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) para transcribir texto de imágenes con OCR local (tesseract.js, WASM, sin internet y sin gastar tokens) y generar descripciones breves con bajo consumo de tokens.
Compatible con ChatGPT, Claude, opencode, Cursor y cualquier cliente MCP.
Herramienta | Descripción |
| OCR local de una imagen → texto plano + bloques con su confianza |
| Lista las imágenes soportadas de un directorio (ruta y tamaño) |
| OCR + descripción breve opcional → Markdown, texto plano o JSON (puede guardar archivo) |
| Procesa todas las imágenes de una carpeta en lote, un archivo de salida por imagen |
Related MCP server: Mistral OCR MCP Server
OCR 100% local: tesseract.js corre dentro del servidor (WASM). La imagen nunca sale de tu máquina y no se consumen tokens.
Descripción IA opcional: si configuras una API key (OPENAI_API_KEY o TOOL_TRANSCRIBAI_API_KEY), describe envía solo el texto OCR (no la imagen) al modelo con un prompt corto (máx. 3 frases), minimizando tokens.
Seguridad por defecto: toda ruta se resuelve contra allowedRoot (path traversal bloqueado), con límites de tamaño (20 MB) y de lote (100 imágenes).
Configúralo con uvx, npx o la ruta directa al binario. Ejemplo con npx:
{
"mcpServers": {
"transcribai": {
"command": "npx",
"args": ["tool-transcribai-mcp"]
}
}
}O en modo local (tras npm install && npm run build):
{
"mcpServers": {
"transcribai": {
"command": "node",
"args": ["<ruta>/tool-transcribai-mcp/dist/index.js"]
}
}
}TOOL_TRANSCRIBAI_HTTP=1 TOOL_TRANSCRIBAI_HTTP_PORT=3397 npm run startnpm install
npm run dev # servidor stdio con tsx
npm run build # compila a dist/
npm test # tests (Vitest)
npm run typecheckRequisitos: Node.js 18+.
Variable | Defecto | Descripción |
|
| Directorio raíz permitido |
| 20 MB | Tamaño máximo por imagen |
| 100 | Máx. imágenes por carpeta |
| — | Datos de idioma Tesseract locales (offline) |
| — |
|
|
| Puerto del modo HTTP |
| — | API key para la descripción IA |
|
| Modelo de descripción |
eng (defecto), spa, fra, deu, ita, por, nld, cat, eus, glg, ron, ces, pol, rus, ukr, tur, ara, hin, jpn, kor, chi_sim, chi_tra.
MIT. Ver LICENSE.
Transcribe el texto de una imagen, genera una descripción breve (opcional) y devuelve el contenido en Markdown, texto plano o JSON. Puede guardar el resultado como archivo.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | Yes | Ruta local de la imagen a analizar. | |
| idioma | No | Código de idioma del texto (por defecto "eng"). | |
| formato | No | Formato de salida del contenido generado (por defecto "md"). | |
| guardar | No | Escribir el resultado como archivo dentro de "carpetaSalida". | |
| carpetaSalida | No | Directorio donde guardar el archivo si "guardar" es true. | |
| conDescripcion | No | Generar una descripción breve (IA si hay API key, si no, local). | |
| incluirBloques | No | Incluir la transcripción por bloques (por defecto false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the burden falls on the description, and it does surface the main side effect: 'Puede guardar el resultado como archivo.' However, it omits specifics such as file overwrite behavior, the API-key dependency behind the AI description path, and what happens to the output when guardar is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, and the core operation is front-loaded in the first clause. The structure is slightly list-like and the second sentence partly restates what the guardar parameter already implies, but overall it is efficient and scannable.
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 7-parameter tool with no annotations and no output schema, meaningful behaviors are absent: the per-block transcription option (incluirBloques), language handling (idioma), and the AI-vs-local description path are never mentioned. The description also fails to position the tool against the similarly named sibling transcribir_imagen, so an agent cannot fully scope when this tool is appropriate.
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 every parameter is already documented individually. The description loosely mirrors the schema (formato maps to 'Markdown, texto plano o JSON; guardar to 'guardar el resultado') but adds no meaning beyond it, so the 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 the core action clearly: 'Transcribe el texto de una imagen' with an optional brief description and three output formats (Markdown, texto plano o JSON). The action, resource, and deliverable are specific, though it never distinguishes itself from the near-identically scoped sibling 'transcribir_imagen'.
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 tool versus its siblings. The description reads as a feature list and never states selection criteria, prerequisites, or exclusions, leaving an agent to guess whether analizar_imagen or transcribir_imagen is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las imágenes soportadas dentro de un directorio (dentro de la raíz permitida), con su ruta y tamaño.
| Name | Required | Description | Default |
|---|---|---|---|
| carpeta | Yes | Ruta del directorio a inspeccionar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It conveys a read-only listing operation and the allowed-root scope, but it does not mention whether subdirectories are recursed, which image formats are considered supported, or how errors are handled.
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 focused sentence with no filler. It front-loads the action and object, then states the returned information and the access boundary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description adequately names the output fields ('ruta y tamaño') and the access scope. It could state supported formats or recursion behavior, but these are not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter 'carpeta' as 'Ruta del directorio a inspeccionar'. The description adds the 'raíz permitida' constraint but does not clarify path format or relative versus absolute paths, so it adds only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista'), a clear resource ('imágenes soportadas dentro de un directorio'), and states the output ('ruta y tamaño'). It clearly distinguishes listing from the sibling tools that transcribe, analyze, or process 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 implies the tool is for enumerating supported images in a directory and notes the 'raíz permitida' constraint, but it does not explicitly state when to prefer this over procesar_carpeta or mention alternatives. Usage context is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Procesa TODAS las imágenes de un directorio: transcribe cada una con OCR local y genera un archivo de salida por imagen, sin gastar tokens. Ideal para lotes grandes.
| Name | Required | Description | Default |
|---|---|---|---|
| idioma | No | Código de idioma del texto (por defecto "eng"). | |
| carpeta | Yes | Directorio con las imágenes a procesar (dentro de la raíz permitida). | |
| formato | No | Formato de los archivos de salida (por defecto "md"). | |
| carpetaSalida | No | Directorio donde guardar los resultados. Por defecto "carpeta". | |
| conDescripcion | No | Generar descripción breve por imagen (IA si hay API key, si no, local). | |
| incluirBloques | No | Incluir la transcripción por bloques en cada archivo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and performs well: it reveals that OCR is local ('OCR local'), that no tokens are spent ('sin gastar tokens'), and that the tool writes one output file per image ('genera un archivo de salida por imagen'). It does not cover edge behaviors like subdirectory recursion, overwriting existing files, or handling of non-image files, but the core behavioral profile an agent needs is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first front-loads the core behavior (scope, mechanism, output granularity, cost) and the second adds the intended use case. Every phrase 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 6-parameter batch tool with no output schema, the description conveys the essential contract: input is a folder, output is one file per image with transcription. It does not explain output-location defaults (carpetaSalida defaulting to carpeta) or subdirectory behavior, but the core workflow an agent needs to decide and invoke 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 the input schema already documents all six parameters (carpeta, idioma, formato, carpetaSalida, conDescripcion, incluirBloques) with descriptions. The description adds no per-parameter detail beyond the schema, so the 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?
The description states a specific verb and resource: it processes ALL images in a directory ('Procesa TODAS las imágenes de un directorio'), then specifies the action (local OCR transcription, one output file per image). The capitalized 'TODAS' and the 'Ideal para lotes grandes' note sharply differentiate it from the sibling transcribir_imagen, which is the single-image counterpart.
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 clear usage context: use this for large batches ('Ideal para lotes grandes') and when conserving tokens matters ('sin gastar tokens'). It implies the selection criterion versus the siblings (batch vs. single image, local vs. token-consuming) but never explicitly names an alternative or states a when-not-to-use condition, so it stops short of a 5.
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 una imagen usando OCR local (tesseract.js). No sube la imagen a internet y no gasta tokens. Devuelve el texto plano.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | Yes | Ruta local de la imagen a transcribir. | |
| idioma | No | Código de idioma del texto (por defecto "eng"). | |
| bloques | No | Incluir el texto dividido en bloques con su confianza (por defecto true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the safety/behavior burden. It does so by declaring local OCR, no network upload, no token consumption, and plain-text output. It doesn't discuss failure modes or supported image formats, but for a read-only utility these are the most important behavioral facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses: the core action, the privacy/cost behavior, and the return type. Nothing is redundant and the main purpose is front-loaded.
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 a simple schema and three clearly described parameters, the description plus schema is enough for an agent to invoke the tool. The main gaps are the absence of an output schema and a small ambiguity between 'texto plano' and the 'bloques' output (which can include confidence metadata), but these don't block correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already explains 'ruta', 'idioma', and 'bloques'. The description contributes no parameter-specific details beyond the plain-text output, which is more about return shape than input semantics.
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 opens with a specific action ('Extrae el texto de una imagen') and names the mechanism (OCR local con tesseract.js), which clearly differentiates it from a general 'analizar_imagen' sibling. The expected output (plain text) is also stated.
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 privacy/cost characteristics ('No sube la imagen a internet y no gasta tokens') provide clear situational context for choosing this tool, especially against cloud-based analysis. It doesn't explicitly name 'analizar_imagen' as the alternative for non-OCR analysis, so exclusions are only 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analizar_imagenlistar_imagenesprocesar_carpetatranscribir_imagenScored across 4 tools
transcribir_imagen and analizar_imagen both extract text from a single image and heavily overlap in purpose, with the latter only adding optional description/output options. procesar_carpeta also performs transcription, creating further ambiguity between batch and single-image workflows.
All tool names follow a consistent verb_noun pattern in Spanish using snake_case: transcribir_imagen, listar_imagenes, analizar_imagen, procesar_carpeta. Minor pluralization differences do not undermine the clear pattern.
Four tools is a reasonable number for an OCR-focused server. However, the overlap between transcribir_imagen and analizar_imagen makes the set feel slightly less tight than it could be.
The server covers listing supported images, single-image OCR, richer analysis with configurable output, and batch folder processing. There are no major dead ends for the stated OCR purpose, though a tool to configure OCR language or supported extensions would round it out.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
OCR.space MCP — wraps the OCR.space API (ocr.space) for image/PDF → text OCR.
OCR and document understanding: extract text from images, then summarize or translate it.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
