Skip to main content
Glama
qingchejun

mindlm-mcp

by qingchejun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

PDF to mind map

pdf_to_mindmap
Read-only

Convert a local PDF into a mind-map outline, using bookmarks as the skeleton when available. Limit pages for long documents; image-only scanned PDFs are rejected.

Instructions

Read a local PDF and turn it into a mind-map outline, using its bookmarks as the skeleton when it has them. Scanned PDFs with no text layer are rejected — there is no OCR. Use pages to limit long documents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoauto (default): use a configured API key if there is one, otherwise "client". client: get a draft plus the source text back and write the outline yourself. llm: the server calls the model configured by ANTHROPIC_API_KEY / OPENAI_API_KEY. heuristic: rule-based only, no model.
pathYesPath to a local PDF file. "~" is expanded.
pagesNoPage selection, 1-based, e.g. "1-20", "3" or "1-5,9". All pages by default.
titleNoRoot node title. Derived from the source if omitted.
exportNoAlso render the outline to a standalone HTML file and return its path.
languageNoLanguage for the node labels, e.g. "English" or "中文". Defaults to the source language.
maxDepthNoLevels including the root (default 4).
outputPathNoWhere to write the HTML when export is true. A directory gets a generated file name. Defaults to $MINDMAP_OUTPUT_DIR or ./mindmaps/.
maxChildrenNoChildren kept per node before the rest collapse into "…(+N)" (default 8).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real behavioral context beyond the readOnlyHint/openWorldHint annotations: the no-OCR limitation and the bookmark-skeleton heuristic are things an agent cannot infer from the schema. It stays quiet on cost/latency of the LLM modes and on failure modes for malformed PDFs, so not quite a 5.

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?

Three tight sentences, zero filler, with the core transform stated first and constraints (bookmarks, no OCR, pages) following. Nothing to cut.

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 9-parameter read tool with no output schema, the description covers purpose, source limitations, and scoping. It never hints at the shape of the produced outline (especially the draft-plus-source-text behavior in client mode), but that gap is largely filled by the mode parameter's own schema text.

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 explains mode, pages, export, title and the rest. The description only echoes the 'pages' parameter with the long-document hint, adding little beyond the schema. Baseline 3 applies.

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?

Specific verb ('Read a local PDF and turn it into a mind-map outline') plus the exact resource and behavior. It is instantly distinguishable from the siblings url_to_mindmap and text_to_mindmap, which take a different input source.

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?

Gives concrete conditions: bookmarks are used as the skeleton when present, scanned PDFs without a text layer are rejected, and 'pages' should be used for long documents. It lacks an explicit 'use this instead of url_to_mindmap when...' routing sentence, 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.

Deploy Server

Other Tools