axomind-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are clearly grouped by domain (mindmap, planning, messaging) with distinct purposes. However, there is potential confusion between add_assignment and create_assignment (both create assignments with different parameter styles) and similarly update_assignment vs modify_assignment. The descriptions help differentiate but the overlap reduces clarity.
Naming Consistency4/5
Most tools follow a consistent snake_case verb_noun pattern. However, there are multiple verbs for similar operations (add/create, update/modify) which introduces minor inconsistency. Overall, the naming is predictable and readable.
Tool Count4/5
With 26 tools covering two main domains plus messaging, the count is slightly high but still reasonable. Some redundancy exists (duplicate raw and human-friendly versions), but each tool serves a specific use case. The scope fits the server's purpose.
Completeness5/5
The tool set provides full CRUD coverage for mindmaps, planning assignments, and bot messages. Mindmap tools include bulk import and scanning helpers; planning tools offer both raw and human-friendly operations; messaging covers send, read, update, delete. No obvious gaps in the featured workflows.
Average 4.4/5 across 26 of 26 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It states 'Replaces the group definition and all its slots', indicating a destructive update, and mentions the return format. However, it omits details on permissions, reversibility, error states, or side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with a clear introduction and bulleted args. Some redundancy exists (e.g., repeating 'same format as add_assignment'), and the size could be reduced without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the return value. It includes a prerequisite (get_activity) and references sibling formats. However, it does not address failure modes, rollback, or concurrency issues, leaving the agent with incomplete context for safe invocation.
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 coverage is 0%, so the description must explain each parameter. It lists all four arguments with brief explanations (e.g., 'id_activity: Activity ID', 'planning_list: JSON string — full slot list'). It adds context by referencing identical formats in 'add_assignment'. However, it lacks detailed format specifications or validation rules, which limits its utility.
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 'Update an existing assignment group and its time slots', using a specific verb and resource. It distinguishes from 'add_assignment' by noting the use of existing IDs, but does not fully differentiate from 'modify_assignment' or 'delete_assignment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use get_activity first to find the group ID' and explains that the JSON formats are identical to 'add_assignment'. However, it does not provide explicit when-to-use versus alternatives like 'modify_assignment' or 'delete_assignment', nor does it outline when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains the function (creates a recursive group and planning list), the structure of inputs, and the return type (JSON string with IDs). However, it does not describe side effects (e.g., whether it invalidates caches, requires specific permissions, or has rate limits). The description is adequate but not comprehensive for a mutation tool.
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 longer than necessary, but it is well-structured with a clear purpose statement, labeled parameter details, and a return description. The front-loaded purpose sentence is effective. However, the inclusion of full example JSON structures, while valuable, adds verbosity. It could be slightly more concise without losing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (creating assignments with recurrence), the description is fully complete: it explains the concept of recursive groups and planning lists, details all input parameters with field-level documentation, and describes the return value. The absence of an output schema is mitigated by the description of the return as a JSON string with created IDs. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles with no descriptions (0% schema description coverage). The tool description compensates fully by detailing the structure and required fields of 'planning_list' and 'recursive_group' with example JSON snippets and field-level explanations. For 'id_activity', it simply restates the schema, but overall the description adds essential meaning beyond what the schema offers.
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: 'Assign time slots to an activity by creating a new recursive group.' It uses specific verbs and resources, but it does not differentiate from the sibling tool 'create_assignment' or clarify the distinction between similar assignment-related tools. Hence, while purpose is clear, sibling differentiation is missing.
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 explicit guidance on when to use this tool versus alternatives like 'create_assignment', 'modify_assignment', or 'update_assignment'. It implies usage for creating recurring assignments, but does not state prerequisites, context, or cases where another tool would be more appropriate. This leaves the agent uncertain about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It correctly implies read-only behavior but does not mention permissions, rate limits, or any side effects.
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 concise, well-structured with sections for behavior, parameters, and return value. Every sentence adds value with no redundancy.
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 simple 1-parameter read tool with an output schema, the description covers the return fields and identifies the input. It is complete enough for typical use, though pagination or limits are not mentioned.
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 input schema has 0% description coverage for the parameter, so the description must compensate. It provides a brief but clear definition for id_conversation ('Conversation ID'), adding meaning beyond the schema's type and title.
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?
The description clearly states the action (read) and resource (bot messages in a conversation), and it distinguishes itself from sibling tools like send_message, update_message, delete_message.
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 does not provide guidance on when to use this tool vs alternatives. It only describes what it does, leaving the agent to infer usage context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool builds JSON payloads internally, mirrors Flutter logic, and returns a human-readable JSON summary. However, it does not mention idempotency, conflict handling, or permission requirements, which are relevant for a create operation.
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 well-structured with sections, bullet points for modes, and a clean args list. Every sentence adds value; there is no fluff or redundancy. The length is justified by the tool's complexity (11 parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, two modes, and an output schema, the description covers all necessary aspects: parameter formats, mode logic, return value structure (JSON string with group ID and per-slot details). It is fully complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 thoroughly documents each parameter with formats (YYYY-MM-DD, hour/minute integers), examples, and behavioral context (e.g., weekdays case-insensitive, omit for single-day). This adds immense value beyond the bare schema.
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 it creates a planning assignment with human-friendly parameters and explains two modes (single-day vs recursive). Although sibling 'add_assignment' exists, the description does not explicitly differentiate when to use this versus alternatives, but the purpose is specific and well-articulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditions for using single-day vs recursive modes (based on date equality), but it does not guide when to use this tool over alternatives like 'add_assignment' or 'modify_assignment'. In a context with many sibling tools, this omission reduces guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears transparency burden. It discloses cascading deletion: 'Removes the recursive group and every slot that references it.' This is key behavioral context beyond the basic operation. Could mention irreversibility but sufficient.
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?
Description is brief, front-loaded with purpose, then parameters, then return value. Every sentence adds value with no redundancy. Well-structured for agent parsing.
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 simplicity (2 params, output schema exists), the description covers key aspects: action, effect (cascading deletion), prerequisite, parameters, and return type. Could mention error handling or irreversibility, but overall complete for its scope.
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 has 0% description coverage. Description adds basic meaning: id_activity is 'Activity ID', delete_recursive_group_slot is 'Group ID to delete'. This clarifies purpose but lacks detail on why both are needed or expected value ranges.
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?
The description clearly states it deletes an assignment group and all its time slots. It uses specific verbs and identifies the resource. Among sibling tools, it is distinct from delete_node, delete_message, and other assignment operations.
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?
Provides explicit prerequisite: 'Use get_activity first to find the group ID.' This guides the agent on necessary prior steps. No exclusion or alternative tools mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it deletes and returns confirmation, but does not explicitly mention irreversibility or permission requirements. The restriction to bot messages is a useful behavioral trait, but more detail could be added.
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 concise with three sentences for the main function, plus structured Args and Returns sections. It is front-loaded with the core purpose and efficiently uses space without redundancy.
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?
The tool is simple with one parameter, and the description covers purpose, usage conditions, parameter, and return format. It is mostly complete; mentioning irreversibility would improve it further.
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 adds a brief explanation for 'delete_message_id' ('Message ID to delete'), which clarifies the parameter's purpose but lacks format or constraints beyond the schema.
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?
Clearly states 'Delete a bot message' with specific verb and resource. Differentiates from sibling tools by specifying only bot messages can be deleted, which distinguishes it from other delete or update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (bot messages) and when not to use (user messages), with an alternative ('use the user API for user messages'). This gives clear guidance for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the operation is non-destructive (listing) and describes the return format. However, it omits details like pagination, rate limits, or whether the bot's assignment is fixed, leaving 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 concise with three sentences: purpose, return format, and alternative reference. It is front-loaded and every sentence adds value, making it highly efficient.
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 zero parameters and an output schema describing return fields, the description covers the essential aspects. It references 'get_activity' for completeness, but could mention if metadata includes timestamps or status.
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?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter details. The baseline score of 4 is appropriate as it correctly reflects the lack of parameters.
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?
The description clearly states the tool's purpose: listing activities where the bot is assigned, and specifies it returns metadata only. It distinguishes itself from 'get_activity' which provides full detail, making the purpose precise and actionable.
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?
The description explicitly recommends using 'get_activity' for full details of a single activity, giving clear context for when to use this tool versus an alternative. However, it does not mention when not to use this tool or address other sibling tools like 'list_mindmaps'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses internal behavior: 'marks a tombstone for the old group, removes old slots, and creates new ones.' This gives clear insight into destructive, replacement nature.
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?
Well-structured with explicit purpose, behavioral note, parameter list, and return value. Slightly verbose due to full parameter list, but still efficient and readable.
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?
Covers purpose, behavior, all parameters, and return type. Output schema exists, so return explanation is sufficient. Missing error scenarios or prerequisites (e.g., permissions), but adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description includes an Args block that explains all 12 parameters with clear descriptions, fully compensating for the schema gap.
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?
Clearly states 'Modify an existing assignment group' with a specific verb and resource. Notes similarity to create_assignment, but does not explicitly differentiate from sibling update_assignment, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it replaces the entire group definition and time slots, implying full updates. Mentions parameter format similarity to create_assignment, but lacks explicit when-to-use or when-not-to-use guidance and does not compare to update_assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses key behaviors: directories become category nodes, files become leaf nodes, hidden files and VCS directories are automatically skipped, order_index is implicit, and parent values are pre-computed. It also clarifies the return format. This provides good transparency, though it does not mention error handling or path validation.
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 concise and well-structured, with a clear hierarchy: purpose, integration hints, behavioral details, parameter explanations, and return value. Every sentence adds value, and the information is front-loaded. No redundant or tautological statements.
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 complexity and the existence of an output schema, the description adequately covers scanning behavior, node categorization, hidden file handling, parameters, and integration. It does not detail the exact structure of the output nodes (since output schema exists) and could mention error conditions, but overall it is sufficiently complete.
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 significant meaning beyond the input schema: it explains that root_path is an absolute path and root_title when empty uses the directory name. Since schema coverage is 0%, this compensation is crucial. It clarifies the purpose of each parameter and their effects, though it lacks details on validation or default behavior beyond the empty string case.
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?
The description clearly states the tool's purpose: scanning a directory tree and returning a JSON array of simplified mindmap nodes. It includes specific details about the output being ready for use with sibling tools replace_mindmap and add_nodes, and mentions automatic skipping of hidden files and VCS directories, making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the output is ready for replace_mindmap or add_nodes, but it does not explicitly specify when to use this tool versus the similar sibling inject_directory_to_mindmap or other alternatives. There is no 'when not to use' guidance, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that the tool 'Reads the activity metadata and validates that all assignment groups have consistent time slots,' indicating read-only behavior. Given no annotations, this is transparent about its non-destructive nature.
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 with clear sections (purpose, usage, args, returns) and front-loaded with the main purpose. It is slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one parameter and an output schema, the description covers purpose, parameters, return format, and context for use. It is fully adequate for effective tool selection and invocation.
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 explain parameters. It lists 'id_activity: Activity ID to verify,' adding context beyond the schema's title, but it is minimal and could elaborate on the source of the ID.
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?
The description clearly states 'Verify and inspect all assignments for an activity,' using a specific verb and resource. It differentiates from sibling tools by explicitly recommending use after create_assignment or modify_assignment.
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?
The description explicitly says when to use this tool: 'Use this after create_assignment or modify_assignment to confirm the server accepted and stored the assignment correctly.' It implies when not to use (e.g., for creation or modification), but does not provide explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: appending vs replacing, auto-positioning with free_links, auto-assignment of UID/order_index, and default values. It does not mention rate limits or auth, but for a mutation tool this is sufficient.
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 lengthy but well-structured: purpose sentence, sibling contrast, format, field details, and behavioral notes. It front-loads the key purpose and contrast. Some redundancy exists (e.g., 'append nodes' repeated), but overall it is efficiently organized for a complex tool.
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 has an output schema (not shown), return value explanation is unnecessary. The description covers parameter details, auto-assignment, positioning behavior, and free_link constraints. The id_mindmap parameter could use slightly more context, but the overall completeness for a 2-param tool is good.
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?
Schema coverage is 0%, so the description compensates with extensive detail on the nodes parameter: full field list, defaults, constraints on free_links, and positional behavior. The id_mindmap parameter is minimally described as 'Mindmap ID', but that is acceptable for an integer ID.
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?
The description clearly states 'Append nodes to an existing mindmap (simplified format)' and explicitly contrasts with sync_nodes, which replaces everything. This provides a specific verb+resource and distinguishes it from a sibling tool.
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?
The description contrasts add_nodes with sync_nodes, explaining when to use each. It also provides guidance on free_links usage (only for cycles, not pure trees). While it does not explicitly list when not to use, the contrast and field notes offer adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations, description clearly indicates read operation ('Read'). Specifies return value (JSON string with full metadata). No contradictions. Could mention auth requirements but acceptable for a simple getter.
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?
Four concise sentences, front-loaded with purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple resource retrieval tool, description covers purpose, prerequisite action (list_activities), and output nature. Output schema exists, so return format is fully specified.
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 coverage is 0%, description adds basic meaning ('Activity ID') but no format or constraints beyond schema. Adequate but minimal compensation.
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?
Explicitly states 'Read a specific activity (full metadata)'. Differentiates from sibling 'list_activities' by advising to use it first to find IDs. Clear verb plus resource.
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?
Provides explicit guidance to use list_activities first to find IDs, indicating when to use this tool. However, lacks explicit when-not or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the read-only nature, return format (JSON with specific fields), error case, and a 4 KB cap. This is thorough for a simple read tool.
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?
Four well-structured sentences plus an Args list. Front-loaded with purpose, followed by usage and details. No redundant or missing information. Could be slightly more compact but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, read-only) and the presence of an output schema, the description fully covers purpose, usage, parameters, return format, error handling, and size limit. Nothing essential is missing.
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?
Schema coverage is 0% with no descriptions, but the description compensates by explaining id_mindmap as 'ID of the mindmap' and order_index as '1-based', adding meaning beyond the raw schema types.
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?
The description clearly states the verb 'Read', the resource 'description of a single node', and the method 'by its order_index'. It distinguishes itself from siblings like get_mindmap_summary and get_mindmap by specifying a single node retrieval.
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?
Explicitly advises using this after get_mindmap_summary to avoid loading the entire mindmap, providing clear context. Does not explicitly list when not to use, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes destructive behavior (removes existing nodes), auto-positioning logic, free_links constraints, and default value handling. No annotations provided, so description carries full burden.
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?
Well-structured with a clear example, field list, and behavioral notes. Slightly long but each section adds value; front-loaded with the core action.
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?
Covers all relevant aspects: replacement behavior, node format, field semantics, auto-positioning, and free_links rules. Output schema exists (context signal) but not mentioned; still complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description extensively documents the JSON string format, all fields, defaults, and constraints, fully compensating for the lack of parameter info in the schema.
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?
The description clearly states 'Replace all nodes in a mindmap' and 'Removes existing nodes and replaces them with the new set,' which distinguishes it from sibling tools like add_nodes (additive) and delete_node (single node removal).
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?
Provides explicit constraints (first node must have parent=0, free_links usage rules) and auto-positioning behavior, but does not explicitly compare to alternatives like add_nodes or sync_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses that message is sent on behalf of bot, plaintext with server-side encryption, and special broadcast behavior for id_conversation=0. Returns JSON with message ID.
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?
Description is well-organized with sections (Args, Returns) and no unnecessary information. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, 0% schema coverage, and presence of output schema (mentioned but not shown), the description adequately covers bot behavior, encryption, broadcast, and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds meaningful info: content_message is plaintext encrypted server-side, id_conversation defaults to 0 meaning broadcast to all conversations.
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?
The description clearly states 'Send a message to a conversation as the bot', using a specific verb and resource. It distinguishes from sibling tools like delete_message and update_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (as bot) but does not explicitly state when to use this tool vs alternatives like update_message or delete_message, nor provides exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It discloses that the tool does not read file content, skips hidden files and VCS dirs, and returns a JSON array with specific fields. There is no mention of side effects or destructive actions, which is appropriate for a read-only scan. The output structure is thoroughly explained.
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: a summary sentence, then output format details, usage guidance, and parameter descriptions. It is front-loaded with the main purpose. While somewhat lengthy, each sentence adds value and is clearly organized. Minor redundancy could be trimmed, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description still provides detailed explanation of the return value, including field names, types, and semantics. It covers scanning behavior (skipping hidden files, depth limit) and usage context. No critical information is missing for an agent to select and invoke this tool correctly.
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?
Since schema description coverage is 0%, the description must compensate. It explains root_path as an absolute path, root_title as the title for the root entry (with default behavior: empty uses directory name), and max_depth as maximum nesting depth with default 10. This adds meaning beyond the schema types and defaults.
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?
The description clearly states that the tool scans a directory and returns compact telemetry without reading file content. It distinguishes itself from sibling tools like inject_directory_to_mindmap by specifying its use case as a precursor for node count validation.
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?
The description explicitly recommends using this tool before inject_directory_to_mindmap to obtain a reference count of expected nodes and after injection to validate totals. It also notes that hidden files and VCS directories are skipped. However, it does not provide explicit 'when not to use' guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers core behavior (replaces content, bot-only constraint, returns JSON confirmation). However, it lacks details on error handling, permissions, or idempotency, leaving some 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 succinct with a clear intro, a usage note, parameter list, and return value. No unnecessary words.
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 simple update tool with two parameters and an output schema, the description covers the main purpose, parameters, and return. It lacks information on error conditions or prerequisites, but is largely adequate.
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?
Schema description coverage is 0%, but the description provides brief descriptions for both parameters ('Message ID to update' and 'New content (plaintext)'), adding meaning beyond schema titles and types. It does not specify constraints like length limits.
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?
The description clearly states 'Update a bot message' and 'Replaces the content of an existing bot message.' It distinguishes from user messages by referencing 'user_send_message' tool for user messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only bot-sent messages can be updated and suggests using 'user_send_message' for user messages, providing clear guidance on when to use and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: recursive subtree deletion, cleaning of free_links, and that the root node cannot be deleted. It also references the algorithm steps, offering deep transparency.
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 with a concise first-line summary followed by detailed sections. It is efficient but includes algorithm steps that, while informative, could be slightly trimmed for tighter focus.
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?
The description covers key aspects: what it does, constraints, algorithm details. An output schema exists but is not referenced, and lack of mention about idempotency or node existence handling is a minor gap. Overall, it is sufficiently complete for a deletion tool.
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?
Schema coverage is 0%, so the description compensates by explaining that 'order_index' is 1-based and that 'id_mindmap' is the mindmap ID. While the schema provides types, the description adds semantic meaning beyond the bare property titles.
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?
The description clearly states 'Delete a single node and its entire subtree from a mindmap' with a specific verb, resource, and context. It distinguishes from sibling tools like delete_assignment or delete_message by focusing on mindmap nodes and noting the subtree deletion.
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?
The description labels this as 'the SAFE way to delete a node' and explains the algorithm, providing context for when to use it. However, it does not explicitly mention alternatives or scenarios where other tools might be preferred (e.g., bulk deletions), though few siblings directly compete with this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return type ('JSON string'), the scope ('metadata only'), and lists the fields included. However, it does not mention potential pagination, ordering, or authentication requirements, which is a minor gap.
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: two sentences plus a return type clause. The main purpose is front-loaded, and every sentence adds essential information without redundancy.
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 simplicity (no parameters), the description adequately covers the core behavior. It describes output fields and distinguishes from get_mindmap. However, it lacks details on potential edge cases (e.g., empty result, maximum items) that could be relevant for an agent.
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 tool has zero parameters, and schema coverage is 100% (trivially). The description does not need to elaborate on parameters. The baseline for zero parameters is 4, and the description meets that standard by focusing on the output.
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?
The description clearly states 'List mindmaps where the bot is assigned (metadata only)', providing a specific verb and resource. It distinguishes itself from the sibling tool 'get_mindmap' by explicitly stating that nodes are not included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when not to use this tool ('Does NOT include nodes') and directs to an alternative ('use get_mindmap to read the full node tree'). This provides clear guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It comprehensively describes the return format (JSON with per-activity summary, slots, etc.) and parameter effects. It does not mention side effects, but as a read-only tool this is acceptable. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with the core purpose, then details the return format, and ends with a workflow. Every sentence adds value without redundancy. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but indicated), the description aligns well by explaining the return structure. All necessary information is covered: parameters, return format, and usage workflow. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters in detail: year (example 2026, returns all slots for that year) and id_activity (optional, 0 means all activities). This adds significant meaning beyond the input schema, which only provides types and defaults. Schema coverage is 0%, but the description fully compensates.
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?
The description clearly states the tool's purpose: 'Read all planning slots for a given year via the bot API'. It specifies the resource (planning slots), the verb (read), and the context (year). This distinguishes it from sibling tools which handle assignments, nodes, or mindmaps.
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?
The description includes a 'Workflow' section that advises calling list_activities first and then filtering, providing practical guidance. It explains the optional id_activity parameter and its behavior. However, it does not explicitly state when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: large response size (>2 MB), structure of returned data (metadata + nodes array), and node fields. It warns about performance implications. Lacks explicit read-only hint but 'Read' implies idempotence, which is sufficient.
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 well-structured with a clear opening, a warning block, bulleted use cases, and an Args section. It is concise—every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with one parameter and an output schema (indicated by context), the description covers purpose, usage guidelines, behavioral transparency, parameter meaning, and return format. It is complete enough for an agent to use correctly.
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 only parameter id_mindmap is explained as 'Mindmap ID' in the Args section. While the schema defines it as integer with title, the description adds context that it is the identifier for the mindmap. With 0% schema description coverage, this compensation is effective but minimal.
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?
The description starts with 'Read a mindmap (full metadata + all nodes).' which provides a specific verb and resource. It distinguishes itself from siblings like get_mindmap_summary and inject_directory_to_mindmap by warning against using it for verification, and lists typical use cases that further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when NOT to use it: 'Do NOT use it to verify a previous inject_directory_to_mindmap or replace_mindmap operation — those tools return a summary that is sufficient for validation.' Also provides typical use cases, giving clear guidance on appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It confirms a read-only operation, describes return format, and sets expectations. Lacks mention of auth or rate limits, but for a simple read tool this is sufficient.
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?
Concise and well-structured: first sentence states core purpose, then clarifies scope, then lists args and returns. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: what tool does, what it doesn't, when to use, parameter meaning, and return structure. With a single required parameter and an output schema, description is complete and self-sufficient.
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?
Only one parameter (id_mindmap). Description explains its purpose as 'ID of the mindmap to summarize,' adding meaning beyond the schema's type/title. Schema has 0% description coverage, so description compensates effectively.
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?
Clearly states it reads a compact summary of a mindmap, specifying the exact content (node count, titles, structure, has_description). Distinguishes from tools like get_mindmap by mentioning what it does NOT return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (when you need node count/structure without loading full data) and what to avoid (does NOT return full node data). Provides a clear use case and differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the read-modify-write process, that only provided fields are updated, and the safe behavior. Lacks permissions or rate limits, but overall transparent.
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?
Description is comprehensive but well-structured with a JSON example and headings. Could be slightly more concise, but front-loaded and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and only 2 parameters, the description covers all necessary context: purpose, usage, parameter details, and behavioral nuances. Complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides a detailed JSON example for style_updates with each field's meaning and optionality. This adds immense value beyond the minimal schema.
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?
The description clearly states 'Update style fields on specific nodes without losing existing data' and distinguishes itself from sync_nodes by warning against using it with partial node lists. Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'This is the SAFE way to modify node style — it reads the full mindmap, applies targeted changes, and syncs everything back. Never use sync_nodes with a partial node list (it deletes everything not sent).' Also explains behavior when node_indices is empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully explains behavior: one-shot operation, internal JSON conversion, file handling by extension, size limit (500 KB), and that directory nodes get no descriptions. It is transparent about what happens internally.
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 with sections (intro, workflow, file handling, args, returns). However, it is somewhat lengthy; some detail could be streamlined without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (directory scanning, multiple file types, output summary), the description is comprehensive. It covers file handling, parameter defaults, workflow, return format with example, and error indication. Output schema exists, so return format is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full meaning: root_path (absolute path), root_title (defaults to directory name), id_mindmap (default 0). It clarifies each parameter's role beyond the schema.
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?
The description clearly states the tool scans a directory, reads files, and injects content into a mindmap. It specifies the verb-resource combination and distinguishes from sibling tools like tree_scope and sync_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a recommended workflow (call tree_scope first, then inject, compare results) and explicitly advises against calling get_mindmap for verification. It also details file handling rules for when to create nodes with descriptions vs empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive behavior, the replacement of all nodes, and the Redis-only dirty flag mechanism. It also explains the persistence flow via cron, providing clear behavioral context for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the key warning and behavioral context in the first few lines, followed by a clear argument list. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the presence of an output schema, the description provides comprehensive guidance: the destructive behavior, the need for complete node list, the argument details, and the backend persistence mechanism. This allows the agent to correctly select and invoke the tool.
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 meaning beyond the schema by explaining that 'nodes' is a JSON string representing an array of full node objects, and calling it 'advanced use'. For 'id_mindmap', it provides a brief description. Since schema coverage is 0%, this adds value, though an example of the JSON format could further clarify.
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?
The description clearly states the tool syncs mindmap nodes, specifically 'Redis only + dirty flag', and distinguishes from siblings like add_nodes, delete_node, and update_node by explaining it replaces the entire node list. The verb 'sync' with resource 'mindmap nodes' is specific and differentiated from other node manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the tool is destructive, replacing all nodes, and advises to always send the complete node list. It also mentions the cron flushDirtyMindmaps for persistence, implying when to use this tool (full sync) versus alternatives like add_nodes or update_node for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that it reads the mindmap, applies targeted changes, preserves other nodes, includes cycle detection for re-parenting, markdown-to-Quill conversion, and only updates provided fields.
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 well-structured with a clear summary, bullet-point use cases, and a JSON example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: purpose, usage, parameters, behavior, and contrasts with siblings. Output schema exists but is not required to be explained here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by detailing the node_updates JSON format comprehensively, listing all possible fields with types and descriptions, and explaining order_index is 1-based.
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?
The description clearly states it updates a single node in a mindmap with all fields supported, no data loss, and explicitly distinguishes from sync_nodes which replaces all nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases (renaming, updating description, re-parenting, moving, style changes, free_links) and contrasts with sync_nodes as an alternative for bulk replacement, guiding when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![axomind-mcp MCP server](https://glama.ai/mcp/servers/Sebastien-VZN/axomind-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Sebastien-VZN/axomind-mcp)

Score Badge

Copy to your README.md:

[![axomind-mcp MCP server](https://glama.ai/mcp/servers/Sebastien-VZN/axomind-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Sebastien-VZN/axomind-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Sebastien-VZN/axomind-mcp'

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