Permite que un agente pregunte qué hay dentro de un archivo PDF, Office o iWork — sin abrirlo.
Instalación · Herramientas · Configuración · Seguridad · Cómo funciona · DeckProbe
Un servidor MCP que expone DeckProbe — ffprobe para documentos — como cuatro herramientas tipadas. Pide recuentos de páginas, recuentos de diapositivas, metadatos, señales de cifrado y macros, estructura o integridad, y recibe JSON acotado y determinista con confianza, evidencia y coste de E/S medido.
No se renderiza nada, no se ejecuta ninguna macro, no se sigue ninguna referencia externa y no se abre ninguna conexión de red. Es seguro apuntarlo a archivos no fiables.
// probe { "path": "deck.pptx", "targets": ["slide_count"], "view": "values" }
{
"schema_version": 2,
"status": "ok",
"driver": { "id": "powerpoint", "profile": "pptx" },
"values": { "powerpoint.slide_count": 31 },
"view": "values"
}No hay nada que instalar de antemano — npx obtiene el servidor y el motor juntos.
Claude Code
claude mcp add deckprobe -- npx -y @deckflow/deckprobe-mcpClaude Desktop, Cursor, VS Code, Zed y cualquier otra cosa que lea mcpServers
{
"mcpServers": {
"deckprobe": {
"command": "npx",
"args": ["-y", "@deckflow/deckprobe-mcp"]
}
}
}Para una instalación con una versión fija, ejecuta npm install -g @deckflow/deckprobe-mcp y usa deckprobe-mcp como comando.
Requiere Node.js 20 o superior. El binario del motor se distribuye como dependencia opcional por plataforma para macOS, Linux (glibc y musl) y Windows en x86-64 y ARM64; en cualquier otro lugar el servidor recurre al mismo motor compilado a WebAssembly, por lo que npx funciona dondequiera que funcione Node.
Related MCP server: flexorch-mcp
Herramienta | Para qué sirve |
| Todo sobre un documento |
| Inventariar o clasificar muchos documentos en una sola llamada |
| Qué formatos se admiten y hasta dónde llega el soporte |
| Los nombres exactos de objetivos que ofrece un formato |
También hay un recurso, deckprobe://schema, con el JSON Schema del informe que trae el motor en ejecución.
probe{
"path": "reports/q3.pptx",
"targets": ["@summary", "@security"], // presets, short names, or canonical names
"level": "metadata", // header | metadata | deep
"min_confidence": "high", // low | medium | high | exact
"target_confidence": { "slide_count": "exact" },
"view": "report", // report | values
"budget": { "max_physical_bytes": 8388608, "timeout_ms": 1000 }
}targets acepta nombres cortos (slide_count), nombres canónicos (powerpoint.slide_count) y preajustes:
Preajuste | Se expande a |
| Solo la identidad del contenedor: formato, tamaño, coincidencia de extensión, indicador de cifrado |
| Identidad, metadatos comunes y estructura primaria |
| Cifrado, macros, firmas, referencias externas, contenido activo |
| Recuentos, nombres y dimensiones propios del formato |
| Imágenes, medios, vistas previas, fuentes, objetos incrustados |
| Integridad, reparación, coincidencia de extensión, conformidad |
| Todos los objetivos específicos del formato en el nivel activo |
| Todo lo disponible en el nivel activo |
@summary omite deliberadamente las estadísticas que requieren una lectura completa del archivo. El page_count de un PDF es el caso notable — pídelo explícitamente.
probe_batch{ "paths": ["a.pdf", "b.pptx", "c.xlsx"], "targets": ["@security"] }Un solo proceso del motor gestiona todo el lote. Los resultados vuelven en el orden de entrada, cada uno con su propio informe o su propio error, de modo que un archivo malo nunca estropea la ejecución. Por defecto se usa la vista compacta values. Solo rutas literales — expande los globs tú mismo.
list_formats y list_targetslist_targets toma un format (pdf, docx, xlsx, pptx, doc, xls, ppt, key, numbers, pages) y devuelve los alias de cada objetivo, su descripción, tipo de valor, nivel mínimo, clase de coste y pertenencia a selectores. Pasa detail: "full" para obtener el informe completo del motor, incluidos los fragmentos JSON Schema por objetivo y las listas de selectores expandidas.
Ambos se almacenan en caché durante la vida del proceso del servidor.
El resultado de la herramienta es el sobre schema-v2 propio del motor, sin modificar. Hay dos cosas que conviene saber antes de consumirlo:
status: "partial" no es un fallo. Significa que al menos un objetivo solicitado no pudo resolverse con el nivel de confianza solicitado. Se indica en execution.unresolved_targets, y todos los demás resultados siguen siendo válidos.
confidence_score es una constante fija por etiqueta (0.4, 0.7, 0.95, 1.0), no una probabilidad calibrada. 0.95 no significa que el valor sea correcto el 95 % de las veces.
Solo los resultados con estado resolved o estimated llevan un value. unknown es común y normalmente significa que el documento simplemente no registra ese dato.
Una llamada fallida devuelve isError con el sobre de error del motor más una línea que indica qué hacer al respecto. Los fallos que el propio servidor genera antes de que el motor se ejecute — una ruta inexistente, un directorio, una ruta fuera de la lista de permitidos, un plazo superado — usan la misma forma de sobre con un código prefijado con MCP_ y origin: "mcp-server".
Todos los ajustes son variables de entorno que se definen en la configuración MCP de tu cliente. Todos son opcionales.
Variable | Por defecto | Significado |
| – | Binario del motor que se usará en lugar del incluido |
| sin restricciones | Directorios permitidos, separados como |
|
| Plazo máximo por llamada en un proceso del motor |
|
| Procesos simultáneos del motor |
|
| Rutas aceptadas por una llamada |
{
"deckprobe": {
"command": "npx",
"args": ["-y", "@deckflow/deckprobe-mcp"],
"env": { "DECKPROBE_MCP_ROOTS": "/Users/me/Documents:/Users/me/Downloads" }
}
}DeckProbe está diseñado para entradas no fiables: análisis acotado, sin renderizador, sin intérprete de macros, sin resolución de referencias externas y sin acceso a la red. Este servidor añade dos cosas más.
Aislamiento de procesos y un plazo máximo. Cada análisis se ejecuta en su propio proceso de vida corta, que se termina si supera DECKPROBE_MCP_TIMEOUT_MS.
Una lista de permitidos de lectura opcional. DECKPROBE_MCP_ROOTS fija el árbol accesible; las rutas se resuelven a través de enlaces simbólicos antes de la comprobación, de modo que un enlace no pueda saltársela. El valor predeterminado es sin restricciones, igual que la CLI que el usuario podría ejecutar por sí mismo — configúrala para despliegues compartidos o automatizados.
Los informes describen un documento (metadatos, recuentos, señales) en lugar de reproducir su contenido. Ten en cuenta que los valores del informe, como el título de un documento, siguen siendo cadenas controladas por el atacante: el servidor las pasa como datos JSON y nunca las interpola en instrucciones, y un consumidor debe tratarlas de la misma manera.
Notifica una vulnerabilidad de forma privada como se describe en SECURITY.md.
MCP client
│ JSON-RPC over stdio
▼
deckprobe-mcp ── validates arguments, resolves the path, maps the result
│ argv + stdout (one process per probe, or one --jsonl process per batch)
▼
DeckProbe engine ── plans the cheapest paths that answer the requestEl servidor lanza la CLI nativa de DeckProbe en lugar de usar la compilación WebAssembly. La CLI solo lee los rangos de bytes que necesita un plan de análisis, mientras que la vía WebAssembly mantiene el archivo completo en memoria; además, un proceso separado del sistema operativo aísla el análisis de datos no fiables y puede terminarse por completo. El motor se elige en este orden:
DECKPROBE_MCP_BIN
el binario que se incluye con la dependencia @deckflow/deckprobe de este paquete
deckprobe en PATH
el motor WebAssembly incluido
El motor resuelto se registra en stderr al arrancar. stdout pertenece al transporte MCP y no lleva nada más.
DeckProbe también incluye una Agent Skill que enseña a un agente capaz de usar un shell a utilizar la CLI directamente. Ambos enseñan el mismo vocabulario. Usa la habilidad cuando el agente tenga un shell y quieras la superficie completa de la CLI; usa este servidor cuando no lo tenga, o cuando quieras que los argumentos tipados se validen antes de que el motor llegue a ejecutarse.
npm install
npm test # typecheck, lint, build, and the full suite
npm run test:watchLas contribuciones son bienvenidas — consulta CONTRIBUTING.md. La justificación del diseño, incluidas las alternativas que se rechazaron, se encuentra en docs/rfc.md.
MIT. Consulta LICENSE.
List the document formats DeckProbe can inspect: drivers, the extensions each one handles, and where support stops. Call this when you are unsure whether a file type is supported at all.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the exact output content (drivers, extensions, support limitations), which goes beyond the annotations. No contradictions with annotations.
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 two sentences, with the primary purpose and scope front-loaded. It avoids redundancy and every sentence earns its place—the first states what it lists, the second when to call it. No unnecessary detail.
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, parameterless list tool with no output schema, the description fully explains what the tool returns (drivers, extensions, and support limits). There is nothing missing for an agent to correctly invoke it and interpret the result. Complexity is low, so this is 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?
The tool has zero parameters, so the schema is fully covered (100% by default). There is nothing to add about parameters; the description doesn't need to explain any. The baseline for zero parameters is 4, and no additional info is required.
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 ('List'), a clear resource ('document formats DeckProbe can inspect'), and specifies the content (drivers, extensions, and where support stops). It effectively distinguishes itself from sibling tools like probe and list_targets by focusing on format capabilities rather than probing or target listing.
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 explicit when-to-use guidance: 'Call this when you are unsure whether a file type is supported at all.' It doesn't mention alternatives, but the trigger condition is clear and implies that if you have a specific file, you would use probe instead. It could be improved by naming the sibling tools explicitly, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every target a format supports, with its aliases, value type, minimum probe level, cost class, and which @selectors include it. Call this before naming a target you have not already seen — probe rejects an unknown one rather than guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | compact (default): target names, aliases, descriptions, levels, and selector membership. full: the complete report, including each target's JSON Schema fragment and every selector's expanded member list. | |
| format | Yes | A format profile from list_formats, such as "pdf", "docx", "xlsx", "pptx", "doc", "xls", "ppt", "key", "numbers", or "pages". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, covering safety. The description adds behavioral context by spelling out returned fields and the probe rejection behavior, which matters for planning calls. No contradictions.
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 front-load the core purpose and output contents, then give one practical usage rule. No filler or repetition of schema details.
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 rich annotation set, fully documented parameters, and a description that names the output fields and the prerequisite call, an agent has enough to invoke the tool correctly even with no output schema.
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 100%, so the schema already explains format and detail fully, including enumerations and examples. The description adds no new parameter-level semantics beyond naming the report contents, so baseline 3 is 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?
The description states a specific verb (list) and resource (targets for a given format), enumerates exactly what is included (aliases, value type, minimum probe level, cost class, selector membership), and contrasts with probe by stating probe rejects unknown targets. This distinguishes it from sibling tools list_formats and probe.
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?
It explicitly instructs when to call: before naming a target not already seen, because probe rejects unknowns rather than guessing. It also ties the format parameter to list_formats, implying the prerequisite and differentiating from list_formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read facts about one local PDF, Microsoft Office, or Apple iWork document without opening or rendering it: page, slide, and sheet counts; title, author, and dates; encryption, macro, signature, and active-content signals; structure; embedded assets; and integrity. Handles .pdf, .docx/.xlsx/.pptx, legacy .doc/.xls/.ppt, and modern .key/.numbers/.pages.
Start with targets ["@summary"], or ["@security"] to triage an untrusted file. Prefer this over unzipping the document or parsing its bytes by hand.
Reports facts ABOUT the document, never its text: it does not extract, render, run macros, follow external references, or open a network connection.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the document. The filename extension selects the format driver, and the container is then verified against it. | |
| view | No | report: full evidence — value, confidence, path, and cost per target. values: a compact target-to-value map. | |
| level | No | Probe budget and eligible paths. header: identity only. metadata (default). deep: higher-cost paths, needed only when a target's min_level says so. | |
| budget | No | Override the level's resource limits. Raise after a BUDGET_EXCEEDED error. | |
| targets | No | Short names (slide_count), canonical names (powerpoint.slide_count), or presets: @header, @summary, @security, @structure, @assets, @quality, @format, @all. Defaults to the driver's own set. Call list_targets rather than guessing a name. @summary omits statistics needing a full-file read, so ask for a PDF's page_count explicitly. | |
| min_confidence | No | Weakest evidence a path may offer. Default high; lower it to accept an approximation. | |
| target_confidence | No | Per-target override, e.g. {"slide_count": "exact"} to force the authoritative path. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds critical behavioral context beyond those hints: it does not extract, render, run macros, follow external references, or open a network connection; it handles legacy formats; it can hit resource limits (referenced by 'Raise after a BUDGET_EXCEEDED error'). This is exactly the kind of non-obvious behavior an agent needs to trust the tool with untrusted files.
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 well-structured: opening scope sentence, format list, usage hint, and a final 'does not' sentence. It is front-loaded with the core purpose and scoping. It earns its sentences; only a minor redundancy exists (the 'Prefer this over...' sentence partially repeats the 'does not' list). Not a 5, but far above the typical terse definition.
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 tool with 7 parameters, nested budget object, output schema present, and complex behavior (format drivers, confidence levels, presets, resource limits), the description provides substantial orientation: preset suggestions, the @summary caveat, the budget-error hint, and a clear non-extraction guarantee. The description does not explain what each target means, but it correctly defers to list_targets. So it's complete enough without being exhaustive.
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 schema already documents all 7 parameters well. The description adds important cross-references that the schema alone does not capture: the distinction between @summary and full-read statistics, the warning that @summary omits page_count so ask explicitly, and that list_targets should be used rather than guessing names. This goes beyond a baseline 3 by explaining how the parameters interact with presets and the driver's default set.
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 verb ('Read facts about one local PDF, Microsoft Office, or Apple iWork document') plus a precise resource list (page/slide/sheet counts, title/author/dates, encryption, macros, structure, assets, integrity). The scope is explicit: it reports facts ABOUT the document, never extracts text, renders, runs macros, or opens connections. It also names sibling tools (list_targets, probe_batch) and distinguishes from unzipping/byte-parsing by hand. This is clear and differentiated.
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 explicitly advises 'Start with targets ["@summary"], or ["@security"] to triage an untrusted file.' and 'Prefer this over unzipping the document or parsing its bytes by hand.' It also warns about @summary omitting statistics and instructs to 'Call list_targets rather than guessing a name.' This provides direct when-to-use and when-not-to-use guidance, plus pointers to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe many local documents in one call — inventory a folder, triage a batch of uploads, or compare a set of files. One engine process handles the whole batch, so this is much cheaper than calling probe once per file.
Takes literal paths; expand any glob yourself first. Returns one entry per path, in the order given, each carrying that file's report or its own error envelope. A file that fails does not affect the others.
Defaults to the compact "values" view because inventory rarely needs per-target evidence; pass view: "report" when it does.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | report: full evidence — value, confidence, path, and cost per target. values: a compact target-to-value map. | |
| level | No | Probe budget and eligible paths. header: identity only. metadata (default). deep: higher-cost paths, needed only when a target's min_level says so. | |
| paths | Yes | Document paths, at most 64 per call. Literal paths only. | |
| budget | No | Override the level's resource limits. Raise after a BUDGET_EXCEEDED error. | |
| targets | No | Short names (slide_count), canonical names (powerpoint.slide_count), or presets: @header, @summary, @security, @structure, @assets, @quality, @format, @all. Defaults to the driver's own set. Call list_targets rather than guessing a name. @summary omits statistics needing a full-file read, so ask for a PDF's page_count explicitly. | |
| min_confidence | No | Weakest evidence a path may offer. Default high; lower it to accept an approximation. |
| Name | Required | Description |
|---|---|---|
| reports | Yes | One entry per requested path, in order. A per-file failure is confined to it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: one engine process for the batch, per-path results in order, error envelopes per file, failure isolation, default view and when to switch. Annotations already cover read-only/idempotent/destructive, and the description does not contradict them.
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 sentences, zero fluff. The first sentence front-loads purpose and use cases; the second covers path handling and return behavior; the third gives view guidance. 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 tool with 6 parameters, nested objects, and a full output schema, the description covers the essential usage context: batch behavior, order of results, error isolation, and view default. It does not mention budget override or target selection, but those are adequately documented in the schema. The description is sufficient 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 coverage is 100%, so the baseline is 3. The description adds valuable semantic guidance: 'Takes literal paths; expand any glob yourself first' clarifies the paths parameter, and the view default rationale ('inventory rarely needs per-target evidence') adds context beyond the schema. It does not elaborate on every parameter, but the key ones receive useful extra meaning.
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 clearly states the tool probes many local documents in one call, listing concrete use cases (inventory a folder, triage a batch, compare files). It distinguishes itself from the sibling 'probe' by explicitly being the batch 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 explicitly explains when to use this tool ('Probe many local documents in one call'), gives practical scenarios, and contrasts cost efficiency ('much cheaper than calling probe once per file'). It also gives guidance on view selection ('pass view: report when it does').
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. Dates show when Glama detected each change.
v0.1.1list_formatslist_targetsprobeprobe_batchEach tool has a wholly distinct purpose: probe handles a single file, probe_batch handles multiples, list_formats enumerates supported file types, and list_targets enumerates probe targets. There is no overlap or ambiguity between them.
All tools follow a consistent lowercase_snake_case convention with clear verb prefixes: probe, probe_batch, list_formats, list_targets. The naming style is uniform and predictable, making the tool set easy to reason about.
With exactly 4 tools, the server is tightly scoped for its purpose of document inspection. Each tool fills a necessary role (single file, batch, format discovery, target discovery) without redundancy or bloat, fitting well within the ideal 3–15 range.
The surface covers all core workflows: probing an individual file, probing many files efficiently, discovering supported formats, and enumerating probe targets for a given format. There are no obvious dead ends or missing operations for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native document parsing: PDF, scans and FR/EU invoices to structured JSON or Markdown.
Check a document for hidden text before your agent reads it. PDF, Office, RTF, HTML.
Verified OCR with per-value coordinates, plus a workspace agents can file documents into and query.
Agent microtools: secret scanning, preflight, receipts, JSON checks and Zero Point analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deckflow/deckprobe-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
