Skip to main content
Glama
YuChenSSR

Mindmap MCP Server

convert_markdown_to_mindmap

Transform Markdown content into interactive mindmaps to visualize hierarchical information through HTML output or saved files.

Instructions

Convert Markdown content to a mindmap mind map.

Args:
    markdown_content: The Markdown content to convert

Returns:
    Either the HTML content or the file path to the generated HTML, 
    depending on the --return-type server argument

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
markdown_contentYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the 'convert_markdown_to_mindmap' tool, decorated with @mcp.tool() for registration. Converts Markdown to mindmap HTML using temporary files and markmap-cli subprocess. Includes inline schema via type hints and docstring.
    @mcp.tool()
    async def convert_markdown_to_mindmap(
        markdown_content: str,  # The Markdown content to convert
    ) -> str:
        """Convert Markdown content to a mindmap mind map.
        
        Args:
            markdown_content: The Markdown content to convert
        
        Returns:
            Either the HTML content or the file path to the generated HTML, 
            depending on the --return-type server argument
        """
        try:
            # Create a temporary markdown file
            input_file = await create_temp_file(markdown_content, '.md')
            
            # Run mindmap on it
            output_file = await run_mindmap(input_file)
            
            # Check if the output file exists
            if not os.path.exists(output_file):
                raise RuntimeError(f"Output file was not created: {output_file}")
            
            # Return either the HTML content or the file path based on command line arg
            if RETURN_TYPE == 'html':
                html_content = await get_html_content(output_file)
                return html_content
            else:
                return output_file
        except Exception as e:
            raise RuntimeError(f"Error converting Markdown to mindmap: {str(e)}")
  • Helper function to execute markmap-cli via asyncio subprocess on the input Markdown file and generate the HTML mindmap output file.
    async def run_mindmap(input_file: str, output_file: str = None) -> str:
        """Run markmap-cli on the input file and return the path to the output file."""
        args = ['npx', '-y', 'markmap-cli', input_file, '--no-open']
        
        if output_file:
            args.extend(['-o', output_file])
        else:
            output_file = os.path.splitext(input_file)[0] + '.html'
        
        try:
            process = await asyncio.create_subprocess_exec(
                *args,
                stdout=asyncio.subprocess.PIPE,
                stderr=asyncio.subprocess.PIPE
            )
            
            stdout, stderr = await process.communicate()
            
            if process.returncode != 0:
                error_msg = stderr.decode() if stderr else "Unknown error"
                raise RuntimeError(f"markmap-cli exited with code {process.returncode}: {error_msg}")
            
            return output_file
        except Exception as e:
            raise RuntimeError(f"Failed to run markmap-cli: {str(e)}")
  • Helper to create a temporary Markdown file from the input content for processing.
    async def create_temp_file(content: str, extension: str) -> str:
        """Create a temporary file with the given content and extension."""
        temp_dir = tempfile.mkdtemp(prefix='mindmap-')
        file_path = os.path.join(temp_dir, f"input{extension}")
        
        with open(file_path, mode='w') as f:
            f.write(content)
        
        return file_path
  • Helper to read the generated HTML mindmap file content.
    async def get_html_content(file_path: str) -> str:
        """Read the HTML content from the given file."""
        with open(file_path, 'r', encoding='utf-8') as f:
            return f.read()
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return behavior (HTML content or file path based on server argument), which adds some context, but lacks details on error handling, performance, or side effects. For a tool with no annotations, this is insufficient to fully inform the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, with a clear purpose statement followed by brief sections for arguments and returns. Each sentence serves a functional role without unnecessary elaboration, though minor redundancy ('mindmap mind map') slightly detracts from perfection.

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?

Given the tool's moderate complexity (one parameter, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, parameter meaning, and return behavior, and the presence of an output schema reduces the need to detail return values. However, it could benefit from more behavioral context to achieve full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaningful semantics beyond the input schema, which has 0% coverage. It explains that 'markdown_content' is 'The Markdown content to convert', clarifying the parameter's purpose. Since there is only one parameter and the schema provides no description, this compensation is effective, though not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: converting Markdown content to a mindmap. It specifies the verb 'convert' and the resource 'Markdown content', making the function unambiguous. However, since there are no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It only states what the tool does without context for its application, leaving the agent to infer usage scenarios independently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YuChenSSR/mindmap-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server