A
licenseNot graded
qualityD
maintenanceEnables 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.
22 npm
1
MIT
MCP-Server de Mapas Mentais
MCP-마인드맵 서버
동적으로 MCP(Model Context Protocol) 서버를 생성, 실행 및 관리하는 동적 MCP 서버 관리 서비스입니다. 이 서비스는 MCP 서버 역할을 하며 다른 MCP 서버를 자식 프로세스로 실행/관리하여 유연한 MCP 생태계를 구축합니다.
색인
Related MCP server: CaptureMind
소개
mapas_mentais 프로젝트는 다양한 주제에 대한 공부, 검토, 비교, 프레젠테이션을 용이하게 하기 위해 자동화된 마인드 맵을 생성하는 Python 애플리케이션입니다. MCP 서버라는 아이디어를 활용하여 시스템은 Claude 모델을 통해 Claude Desktop과 직접 상호 작용하여 통찰력을 제공합니다. 아이디어를 시각적이고 효율적으로 정리하고 싶어하는 학생, 교사, 전문가에게 이상적인 이 프로젝트는 쉽게 확장 가능하며 다른 자동화 시스템이나 가상 비서와 통합할 수 있습니다.
프로젝트 구조
이 프로젝트에 대한 아이디어는 UFG(고이아스 연방 대학)의 Sandeco Macedo 교수가 MCP와 A2A for Dummies라는 책을 통해 MCP에 대해 설명한 것에서 나왔습니다. Anthropic의 공식 Model Context Protocol 저장소의 가이드라인을 따르고 FastMCP 패키지만 사용하는 간단한 MCP 서버입니다.
이 MCP-Server에서 사용되는 6가지 유형의 마인드 맵은 다음과 같습니다.
presents - 주제에 대한 프레젠테이션을 위한 마인드 맵을 생성합니다.
비교 - 두 주제를 비교하는 마인드 맵을 생성합니다.
초기 - 주제에 대한 초기 지식의 정신적 지도를 생성합니다.
중급 - 해당 주제에 대한 중급 지식의 마인드 맵을 생성합니다.
문제 - 주제와 관련된 문제에 대한 분석의 정신적 지도를 생성합니다.
리뷰 - 주제에 대한 콘텐츠를 리뷰하기 위한 마인드맵을 생성합니다.
사용된 기술
요구 사항
Python 설치(버전 3.10 이상)
uv패키지가 설치됨Claude Desktop이 설치되었습니다.
Claude Desktop에 설치하는 방법
이제 VSCode의 터미널(단축키 CTRL + SHIFT + ' )을 사용하여 Windows 11에서 단계별로 어떻게 진행했는지 자세히 설명하겠습니다.
최신 버전의 Python을 설치했습니다.
VSCode에서는 터미널을 이용하여 다음 명령어로 파이썬 버전을 확인했습니다.
지엑스피1
그래서 리모컨으로
uv설치했어요pip install uv모든 것이 괜찮은지 확인하기 위해 다음 명령을 사용했습니다.
uv프로젝트 폴더를 생성하기 위해 이 명령을 사용했습니다.
mkdir “C:\Users\meu_usuario\OneDrive\area_de_trabalho\mapas_mentais”
[!중요] 반드시 동일한 경로를 사용해야 한다는 의미는 아닙니다. 아래와 같이 다른 경로를 사용할 수도 있습니다.
mkdir "C:\Users\seu_usuario\mapas_mentais"또는 GitHub에서
Code>Download ZIP통해 이 프로젝트의 zip 파일을 컴퓨터에 간단히 다운로드할 수 있습니다.
방금 만든 폴더의 이름을 지정했습니다.
cd “C:\Users\meu_usuario\OneDrive\area_de_trabalho\mapas_mentais”아래 명령을 사용하여 다른 VSCode 창을 열고 폴더에서 직접 다른 명령을 계속 실행했습니다.
code .
[!중요] 터미널을 통해 폴더를 만들고 싶지 않다면 바탕 화면이나 기억하기 쉬운 다른 위치에 새 폴더를 만들어 VSCode에서
CTRL+O단축키를 사용할 수 있습니다. 그런 다음 방금 만든 폴더를 찾아 클릭한 다음 VSCode에서 열면 됩니다. 또는 이 저장소의 전체 폴더를 VSCode로 가져오면 됩니다.
터미널로 돌아와서 아래 명령을 사용하여 새 Python 프로젝트를 초기화하고 구성 파일과 종속성을 자동으로 생성했습니다.
uv init그런 다음 아래 명령을 사용하여 프로젝트 종속성을 설치하기 위한 격리된 Python 가상 환경을 만들었습니다.
uv venv.venv를 활성화하기 위해 아래 명령을 사용했습니다.
.venv\Scripts\Activate.ps1프로젝트에 필요한 MCP 종속성을 추가했습니다.
uv add mcp[cli]아래 명령어로 모든 것이 괜찮은지 확인했습니다.
uv run mcp[!중요] 아래 정보가 터미널에 나타나면 모든 것이 정상입니다.
server.py파일을 생성하기 위해 다음 명령을 사용했습니다.
uv init --script server.py[!TIP] 이 저장소의 폴더를 이미 다운로드했을 수 있으므로
server.py파일은 이 시점에 VSCode에 이미 있을 것입니다.
MCP-Server에서 아래 json을
claude_desktop_config.json파일에 직접 설치했습니다.
"mapas_mentais": {
"command": "uv",
"args": [
"--directory",
"C://Users//meu_usuario//OneDrive//area_de_trabalho//mapas_mentais",
"run",
"server.py"
]
}[!중요] Claude Desktop을 이미 올바르게 설치한 경우 컴퓨터의
claude_desktop_config.json파일에 액세스하기 위한 경로를 따르세요.
14일 Claude Desktop을 열고 단축키CTRL+,
14b.Desenvolvedor탭을 클릭한 다음Editar configuração클릭합니다.
14세기claude_desktop_config.json파일을 찾아 VSCode에서 올바르게 편집하세요.
14일CTRL+S로 파일을 저장합니다.
14e. Claude Desktop을 닫고 몇 초 후에 다시 엽니다.
14층 MCP "mental_maps" 도구가 올바르게 설치되었는지 확인하려면 구성 아이콘을 확인하세요.
도구의 이름은 '현재', '비교', '초기', '중간', '문제', '검토'였습니다.
유용한 링크
모델 컨텍스트 프로토콜의 공식 문서 - Anthropic의 이 혁신에 대한 모든 세부 정보를 알 수 있습니다.
Anthropic 공식 웹사이트 - Claude 모델에 대한 최신 뉴스와 연구 결과를 받아보세요.
Claude Desktop 다운로드 방법 - 직접 다운로드 링크
VSCode 설치 방법 - 직접 다운로드 링크
공식 uv 패키지 문서 -
uv에 대한 모든 세부 사항과 파이썬에서 uv가 왜 중요한지 알 수 있습니다.venv — 가상 환경 만들기 - venv 작동 방식에 대한 전체 설명
AI/LMM 모델 아이콘 세트 - AI 생태계 아이콘을 얻을 수 있는 아주 좋은 사이트
Devicon - 기술에 대한 일반 아이콘도 포함된 매우 완벽한 사이트
기여
기여를 환영합니다! 이 프로젝트를 개선할 아이디어가 있으면 저장소를 포크해 주시기 바랍니다.
특허
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
연락하다
마리오 루시오 - 데드라인®
Available Tools
6 toolsapresentaC
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 updates
- First observed
apresenta - First observed
compara - First observed
inicial - First observed
intermediario - First observed
problemas - First observed
revisa
TDQS
B3.1/5.0
Scored 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
Related MCP Connectors
- MindlifyOAuthco.mindlify
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Create, edit, and organize MindMeister mind maps from your AI assistant.
Turn outlines and hierarchical notes into interactive mind maps through a hosted remote MCP server.
Visual AI for strategic thinking — SWOT, flowcharts, mindmaps, Gantt diagrams as polished SVG.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceTurn Claude Desktop conversations into visual mind maps via MCP. Highlights blockers to surface where you're stuck.1MIT
- AlicenseAqualityDmaintenanceCaptures ideas from conversations and organizes them into a persistent, hierarchical mindmap. Supports search, deduplication, export, import, and cloud sync.1317 npmMIT
- AlicenseBqualityDmaintenanceMCP server that visualizes Claude conversations as interactive mindmaps, enabling export and optional upload to Navigate Chat.212 npmMIT