de en es ja ko pt ru zh

MCP-Server de Mapas Mentais

Name: MCP-Server de Mapas Mentais
Author: marioluciofjr

by marioluciofjr

Overview Schema Source Related Servers Discussions Admin

Python

Local

MCP-Server de Mapas Mentais

Made with Python license - MIT site - prazocerto.me linkedin - @marioluciofjr

A dynamic MCP server management service that creates, runs, and manages Model Context Protocol (MCP) servers dynamically. This service itself functions as an MCP server and launches/manages other MCP servers as child processes, enabling a flexible MCP ecosystem.

Índice

Related MCP server: CaptureMind

Introdução

O projeto mapas_mentais é uma aplicação Python que gera mapas mentais automatizados para facilitar o estudo, revisão, comparação e apresentação de temas diversos. Utilizando a ideia de MCP-server, o sistema oferece insights ao interagir diretamente com o Claude Desktop por meio dos modelos Claude. Ideal para estudantes, professores e profissionais que desejam organizar ideias de forma visual e eficiente, o projeto é facilmente extensível e pode ser integrado a outros sistemas de automação ou assistentes virtuais.

Estrutura do projeto

A ideia desse projeto surgiu a partir das explicações do professor Sandeco Macedo, da UFG (Universidade Federal de Goiás), sobre MCPs por meio do livro MCP e A2A para Leigos . É um MCP-Server simples que utiliza somente o pacote FastMCP, seguindo também as orientações do repositório oficial do Model Context Protol, da Anthropic.

Os seis tipos de mapas mentais utilizados neste MCP-Server são:

apresenta - Gera um mapa mental para apresentações sobre um tema;
compara - Gera um mapa mental comparando dois temas;
inicial - Gera um mapa mental de conhecimentos iniciais sobre o tema;
intermediario - Gera um mapa mental de conhecimentos intermediários sobre o tema;
problemas - Gera um mapa mental de análise de problemas relacionados ao tema;
revisa - Gera um mapa mental para revisão de conteúdo sobre um tema.

Tecnologias utilizadas

Requisitos

Python instalado (versão 3.10 ou superior);
Pacote uv instalado;
Claude Desktop instalado.

Como instalar no Claude Desktop

Installing via Smithery

To install Mapas Mentais Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @marioluciofjr/mapas_mentais_mcp --client claude

Agora vou detalhar como foi o meu passo a passo no Windows 11, utilizando o terminal (atalho CTRL + SHIFT + ') no VSCode:

Instalei a versão mais atualizada do Python
Já no VSCode, eu utizei o terminal para verificiar a versão do python com o comando
```
python --version
```
Depois eu instalei o uv com o comando
```
pip install uv
```
Para conferir se estava tudo certo, eu utilizei o comando
```
uv
```

Para criar a pasta do projeto, eu utilizei este comando

mkdir “C:\Users\meu_usuario\OneDrive\area_de_trabalho\mapas_mentais”

IMPORTANT

Não necessariamente quer dizer que você utilizará o mesmo caminho, pode ser que você queira utilizar outro caminho, como este abaixo

  mkdir "C:\Users\seu_usuario\mapas_mentais"

Ou você pode simplesmente fazer o download do zip desse projeto para a sua máquina pelo caminho Code > Download ZIP aqui mesmo no GitHub

Chamei a pasta que eu tinha acabado de criar

cd “C:\Users\meu_usuario\OneDrive\area_de_trabalho\mapas_mentais”

Utilizei o comando abaixo para abrir outra janela do VSCode e continuar com os demais comandos direto na pasta
```
code .
```

IMPORTANT

Se não quiser criar a pasta via terminal, você pode criar uma nova pasta na sua área de trabalho ou outro local que se lembre facilmente, a fim de utilizar o atalho no VSCodeCTRL + O Depois é só procurar a pasta que acabou de criar, clicar nela e abrir no VSCode. Ou somente importar a pasta completa desse repositório no seu VSCode.

Voltando ao terminal, utilizei o comando abaixo para inicializar um novo projeto Python, criando arquivos de configuração e dependências automaticamente
```
uv init
```
Utilizei em seguida o comando abaixo para criar um ambiente virtual Python isolado para instalar dependências do projeto
```
uv venv
```
Para ativar o .venv, utilizei o comando abaixo
```
.venv\Scripts\Activate.ps1
```
Adicionei a dependência MCP, necessária para o projeto
```
uv add mcp[cli]
```
Verifiquei se estava tudo ok, com o comando abaixo
```
uv run mcp
```

IMPORTANT

Se aparecer esta informação abaixo no seu terminal é porque está tudo certo

Para criar o arquivo server.py, eu utilizei esse comando
```
uv init --script server.py
```

TIP

Como você pode já ter baixado a pasta desse repositório, então o arquivoserver.pyjá estará lá no seu VSCode nessa altura do campeonato.

Instalei o json abaixo do MCP-Server diretamente no arquivo claude_desktop_config.json

"mapas_mentais": {
  "command": "uv",
  "args": [
    "--directory",
    "C://Users//meu_usuario//OneDrive//area_de_trabalho//mapas_mentais",
    "run",
    "server.py"
  ]
}

IMPORTANT

Se você já instalou o Claude Desktop corretamente, siga o caminho para acessar o arquivoclaude_desktop_config.json no seu computador
14a. Com o Claude Desktop aberto, utilize o atalho CTRL + ,
14b. Clique na aba Desenvolvedor e depois em Editar configuração
14c. Procure o arquivo claude_desktop_config.json e edite no VSCode corretamente
14d. Salve o arquivo com CTRL + S
14e. Feche o Claude Desktop e abra novamente depois de alguns segundos
14f. Confira no ícone de configuração se as ferramentas do MCP "mapas_mentais" estão instaladas corretamente

As ferramentas foram nomeadas como `"apresenta", "compara", "inicial", "intermediario", "problemas" e "revisa".

Links úteis

Documentação oficial do Model Context Protocol - Você saberá todos os detalhes dessa inovação da Anthropic
Site oficial da Anthropic - Para ficar por dentro das novidaddes e estudos dos modelos Claude
Como baixar o Claude Desktop - Link direto para download
Como instalar o VSCode- Link direto para download
Documentação oficial do pacote uv - Você saberá todos os detalhes sobre o uv e como ele é importante no python
venv — Criação de ambientes virtuais - Explicação completa de como funcionam os venvs
Conjunto de ícones de modelos de IA/LLM - site muito bom para conseguir ícones do ecossistema de IA
Devicon - site bem completo também com ícones gerais sobre tecnologia

Contribuições

Contribuições são bem-vindas! Se você tem ideias para melhorar este projeto, sinta-se à vontade para fazer um fork do repositório.

Licença

Este projeto está licenciado sob a licença MIT - veja o arquivo LICENSE para detalhes.

Contato

Mário Lúcio - Prazo Certo®

Available Tools

6 tools

apresentaC

Gera um mapa mental para apresentações sobre um tema.

ParametersJSON Schema

Name	Required	Description	Default
`tema`	Yes

TDQS

C2.8/5.0

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 states the tool generates a mind map but doesn't describe what format the output takes (e.g., text, image, structured data), whether it's a read-only or mutating operation, or any performance characteristics. For a generation tool with zero annotation coverage, this leaves significant behavioral gaps.

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?

The description is extremely concise - a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple tool with one parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It tells what the tool does at a high level but doesn't provide enough information about how to use it effectively, what to expect as output, or how it differs from sibling tools. For a generation tool, more context about output format and behavioral characteristics would be helpful.

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

Parameters2/5

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

The input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention any parameters at all. While the parameter 'tema' (topic) is self-explanatory, the description provides no additional context about what constitutes a valid topic, format expectations, or examples. With low schema coverage, the description fails to compensate.

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: 'Gera um mapa mental para apresentações sobre um tema' (Generates a mind map for presentations on a topic). It specifies the verb ('gera' - generates) and resource ('mapa mental' - mind map) with the context of presentations. However, it doesn't differentiate from sibling tools like 'compara' or 'revisa' which might have related functions.

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. It doesn't mention any prerequisites, exclusions, or suggest when to choose this over sibling tools like 'compara' or 'revisa'. The usage context is implied (for presentations on a topic) but lacks explicit when/when-not instructions.

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

comparaC

Gera um mapa mental comparando dois temas.

ParametersJSON Schema

Name	Required	Description	Default
`tema1`	Yes
`tema2`	Yes

TDQS

C2.9/5.0

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. While 'gera' (generates) implies a creation operation, the description doesn't specify whether this is a read-only or mutating action, what permissions might be required, whether there are rate limits, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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?

The description is a single, efficient sentence: 'Gera um mapa mental comparando dois temas.' It's front-loaded with the core action and includes all essential elements (action, resource, scope) without any wasted words. Every part of the sentence contributes directly to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a mind map generation tool with two parameters), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the mind map output contains, how comparisons are structured, whether there are limitations on theme complexity, or what happens if themes are invalid. For a creative/generation tool, more contextual guidance would be helpful.

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?

The description mentions 'dois temas' (two themes), which aligns with the two parameters (tema1 and tema2) in the schema. However, with 0% schema description coverage, the schema provides no details about these parameters. The description adds basic semantic context (they represent themes to compare) but doesn't elaborate on format, constraints, or examples. This meets the baseline for minimal parameter information.

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: 'Gera um mapa mental comparando dois temas' (Generates a mind map comparing two themes). It specifies the verb ('gera' - generates), resource ('mapa mental' - mind map), and scope ('comparando dois temas' - comparing two themes). However, it doesn't explicitly distinguish this from sibling tools like 'apresenta' or 'revisa', which might also involve presentation or review functions.

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. There are no explicit instructions about when this tool is appropriate, when it should not be used, or what sibling tools might serve as alternatives for related tasks. The agent must infer usage from the purpose alone.

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

inicialC

Gera um mapa mental de conhecimentos iniciais sobre o tema.

ParametersJSON Schema

Name	Required	Description	Default
`tema`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions generation but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what format the mind map output takes. The description is minimal and lacks essential operational context.

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 a single, efficient sentence that directly states the tool's function. It's appropriately sized and front-loaded with the core action, though it could be more structured with additional context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (generating a mind map), lack of annotations, no output schema, and minimal parameter details, the description is incomplete. It doesn't explain what the output looks like, how the mind map is structured, or any limitations, leaving significant gaps for the agent.

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 0%, so the description must compensate. It implies the parameter 'tema' is the topic for the mind map, adding some meaning beyond the bare schema. However, with only one parameter, the baseline is 4, but the description doesn't fully detail the parameter's semantics (e.g., format, scope), so it scores slightly lower.

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

Purpose3/5

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

The description states the tool 'generates an initial knowledge mind map about the topic', which provides a clear verb ('generates') and resource ('mind map'). However, it doesn't specify what distinguishes this from sibling tools like 'apresenta' or 'revisa', leaving the purpose somewhat vague in context.

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. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent with no usage direction beyond the basic purpose.

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

intermediarioC

Gera um mapa mental de conhecimentos intermediários sobre o tema.

ParametersJSON Schema

Name	Required	Description	Default
`tema`	Yes

TDQS

C2.9/5.0

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 states the tool generates a mind map, implying a read-only or creative operation, but doesn't clarify if it requires specific inputs beyond the topic, how the output is structured, whether it's cached or real-time, or any error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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?

The description is a single, clear sentence in Portuguese: 'Gera um mapa mental de conhecimentos intermediários sobre o tema.' It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes to understanding the tool's purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain what 'conhecimentos intermediários' (intermediate knowledge) means, how the mind map is returned (e.g., text, image, structured data), or any limitations. For a tool that likely produces complex output, more context is needed to use it effectively.

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?

The description mentions 'sobre o tema' (on the topic), which aligns with the single parameter 'tema' (topic) in the input schema. However, schema description coverage is 0%, so the schema provides no additional details about the parameter. The description adds minimal semantic context by implying the parameter is a topic string, but doesn't specify format, length, or examples. With one parameter and low coverage, this is adequate but basic.

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: 'Gera um mapa mental de conhecimentos intermediários sobre o tema' (Generates a mind map of intermediate knowledge on the topic). It specifies the action (generate), the resource (mind map), and the scope (intermediate knowledge on a topic). However, it doesn't explicitly distinguish this tool from its siblings like 'inicial' or 'revisa', which might also be related to knowledge mapping or topic exploration.

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. It doesn't mention any prerequisites, context for 'intermediate knowledge', or how it differs from sibling tools such as 'apresenta', 'compara', 'inicial', 'problemas', or 'revisa'. Without this information, an AI agent must guess based on tool names alone.

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

problemasC

Gera um mapa mental de análise de problemas relacionados ao tema.

ParametersJSON Schema

Name	Required	Description	Default
`tema`	Yes

TDQS

C2.4/5.0

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 states the tool generates a mind map but doesn't describe what the output looks like (e.g., format, structure), whether it's a read-only or mutative operation, or any constraints like rate limits or permissions. For a tool with zero annotation coverage, this is a significant gap in behavioral context.

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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with additional context if needed. The structure is clear but minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values (e.g., what the mind map output entails), behavioral traits, or detailed parameter usage. For a tool with no structured data support, the description should provide more comprehensive context to guide the agent effectively.

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

Parameters2/5

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

The input schema has 1 parameter ('tema') with 0% description coverage in the schema itself. The tool description mentions 'related to the theme', which loosely maps to the 'tema' parameter, but doesn't add meaningful semantics such as what constitutes a valid theme, examples, or constraints. With low schema coverage, the description fails to adequately compensate for the lack of parameter documentation.

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

Purpose3/5

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

The description states the tool 'generates a mind map for problem analysis related to the theme', which provides a clear verb ('generates') and resource ('mind map'). However, it doesn't distinguish this from sibling tools like 'apresenta' or 'compara', leaving the specific differentiation unclear. The purpose is understandable but lacks sibling context.

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 like 'apresenta' or 'compara'. It implies usage for problem analysis related to a theme, but doesn't specify prerequisites, exclusions, or comparative contexts with other tools. This leaves the agent with minimal direction for tool selection.

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

revisaC

Gera um mapa mental para revisão de conteúdo sobre um tema.

ParametersJSON Schema

Name	Required	Description	Default
`tema`	Yes

TDQS

C2.9/5.0

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. While 'gera' (generates) implies a creation operation, the description doesn't specify whether this is a read-only or mutative action, what permissions might be required, whether the output is stored or temporary, or any rate limits. It mentions the output type (mind map) but not its format or structure.

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?

The description is a single, efficient sentence in Portuguese that directly states the tool's function. It is appropriately sized and front-loaded with the core action, with no unnecessary words or redundant information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a tool that generates a mind map), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the mind map output looks like, how it's structured, whether it's visual or textual, or any behavioral aspects like error handling. For a generative tool with no structured data, this leaves significant gaps.

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?

The description adds minimal meaning beyond the input schema. It mentions 'tema' (topic) as the subject for the mind map, which aligns with the single parameter 'tema' in the schema. However, with 0% schema description coverage, the parameter is undocumented in the schema, and the description doesn't elaborate on what constitutes a valid 'tema' or provide examples. The baseline is 3 since schema coverage is low but the description partially compensates.

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: 'Gera um mapa mental para revisão de conteúdo sobre um tema' (Generates a mind map for content review on a topic). It specifies the verb ('gera' - generates), resource ('mapa mental' - mind map), and context ('revisão de conteúdo' - content review). However, it doesn't differentiate from sibling tools like 'apresenta' or 'compara', which likely have different functions.

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. It doesn't mention when this tool is appropriate, when to use sibling tools instead, or any prerequisites. The context is implied (content review on a topic) but lacks explicit usage boundaries.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesAug 14, 2025
- First observedapresenta
- First observedcompara
- First observedinicial
- First observedintermediario
- First observedproblemas
- First observedrevisa

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 10:20 across 6 tools

Disambiguation3/5

The tools have overlapping purposes as they all generate mind maps, but their descriptions help differentiate them by specifying distinct contexts like presentations, comparisons, knowledge levels, problem analysis, and review. However, 'inicial' and 'intermediario' could be confused as they both relate to knowledge levels without clear boundaries.

Naming Consistency5/5

All tool names follow a consistent pattern using Portuguese verbs in a simple, uniform style (e.g., 'apresenta', 'compara', 'inicial'). There are no deviations in naming conventions, making them predictable and readable.

Tool Count5/5

With 6 tools, the count is well-scoped for a mind map generation server, covering various use cases like presentations, comparisons, and reviews. Each tool appears to serve a distinct purpose, making the set appropriately sized.

Completeness4/5

The tool surface covers key mind map generation scenarios, including creation for different contexts and review. A minor gap exists in lacking explicit update or delete operations for existing mind maps, but agents can likely work around this by regenerating maps as needed.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MindlifyOAuth
co.mindlify
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Knowledge & Memory Note Taking
1
MindMeisterOAuth
com.mindmeister
Create, edit, and organize MindMeister mind maps from your AI assistant.
Note Taking Project Management Workplace & Productivity
2
MindMap A
com.keenethics-labs
Turn outlines and hierarchical notes into interactive mind maps through a hosted remote MCP server.
Note Taking Data Visualization
12
jeda-ai A
ai.jeda
Visual AI for strategic thinking — SWOT, flowcharts, mindmaps, Gantt diagrams as polished SVG.
Data Visualization Design Tools
52

Related MCP Servers

Markmap MCP Server
Developer Tools Cloud Storage
jiushan-test
A
license
Not graded
quality
D
maintenance
Enables conversion of plain text descriptions and Markdown content into interactive mind maps using AI. Automatically uploads generated mind maps to Aliyun OSS and provides online access links.
Updated a year ago (2025-10-17 09:30 UTC)
22 npm
1
MIT
CaptureMind
Note Taking Knowledge & Memory
acearv09876
A
license
Not graded
quality
D
maintenance
Turn Claude Desktop conversations into visual mind maps via MCP. Highlights blockers to surface where you're stuck.
Updated 5 months ago (2026-05-15 07:42 UTC)
1
MIT
mindkeeper-mcp
Note Taking Knowledge & Memory
icedsg
A
license
A
quality
D
maintenance
Captures ideas from conversations and organizes them into a persistent, hierarchical mindmap. Supports search, deduplication, export, import, and cloud sync.
Updated 5 months ago (2026-05-10 17:34 UTC)
13
17 npm
MIT
visualize-chat-mcp
Data Visualization Knowledge & Memory
Asar007
A
license
B
quality
D
maintenance
MCP server that visualizes Claude conversations as interactive mindmaps, enabling export and optional upload to Navigate Chat.
Updated 7 months ago (2026-02-19 10:20 UTC)
2
12 npm
MIT

MCP-Server de Mapas Mentais

Índice

Introdução

Estrutura do projeto

Tecnologias utilizadas

Requisitos

Como instalar no Claude Desktop

Installing via Smithery

Links úteis

Contribuições

Licença

Contato

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches