NetMap — Network Diagram MCP
Server Quality Checklist
Latest release: v1.2.0
- Disambiguation3/5
While descriptions are detailed, several tools overlap in purpose: map_get_state, map_get_sheet_data, map_export_sheet, and map_export all return map data; map_arrange and map_suggest_layout both auto-layout; map_find_node, map_search, and map_get_nodes_by_type all query nodes. Explicit notes clarify some boundaries, but an agent could easily choose the wrong tool without careful reading.
Naming Consistency4/5All tools share the 'map_' prefix and use snake_case throughout, with most following a verb_noun pattern (map_add_node, map_delete_connection). Minor deviations include bare verbs like map_clear, map_arrange, map_search, and map_export, but these are limited and the overall pattern is predictable.
Tool Count2/5At 44 tools, the server is significantly over the typical range for an MCP server. While the domain is broad, many tools could be consolidated (e.g., map_get_state vs map_get_sheet_data, map_arrange vs map_suggest_layout) to reduce cognitive load. The high count feels heavy even with the expansive feature set.
Completeness5/5The tool surface is remarkably comprehensive, covering full CRUD for nodes, connections, stickies, and sheets, plus view management, settings, search, import (CSV, nmap, JSON), export (JSON/PNG/PDF), layout algorithms, selection, and bulk operations. The domain of network diagram management is well-served with no major dead ends.
Average 3.9/5 across 44 of 44 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
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.jsonto 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?
The description only indicates that a mutation occurs. With no annotations, it does not disclose side effects, error behavior, or that positional changes (x/y) are also possible, leaving the agent unaware of the full impact of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It front-loads the operation and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It fails to mention the full set of updatable fields, including x/y coordinates, and does not differentiate from the sibling map_move_sticky tool, which may also handle position changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is high; the description adds minimal semantic grouping (treating h and w as 'size') but omits x/y and text details. It does not contradict the schema but also adds little beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('update'), target resource ('sticky note'), and lists specific attributes (text, color, size). However, the input schema also allows changing x/y coordinates, which the description omits, creating ambiguity with the sibling tool map_move_sticky.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like map_move_sticky or map_update_node. There is no mention of exclusions or the intended context for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that nodes are arranged but does not disclose side effects such as overwriting manual positions, impact on connections, scope (current sheet vs. all sheets), reversibility, or return value. This is a significant gap 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler. Every word contributes: 'auto-arrange' captures the verb, 'all nodes' defines the scope, and 'grid or circle layout' lists the options. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 no output schema, so the description need not explain return values. However, the lack of behavioral transparency (side effects, scope) and the absence of any context about when to use it relative to siblings leaves gaps. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter (layout) with an enum and description, so schema coverage is 100%. The description simply repeats the enum values ('grid or circle') without adding new meaning, such as default behavior or how the layout is determined. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Auto-arrange all nodes in a grid or circle layout.' It identifies the specific verb ('arrange'), the resource ('all nodes'), and the layout options. However, it does not explicitly distinguish itself from sibling tools like map_suggest_layout, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided beyond the action itself. The description does not specify when to use this tool versus alternatives (e.g., map_suggest_layout), nor does it mention any prerequisites or exclusion cases. The usage is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Rename a sheet' and does not mention side effects, edge cases (e.g., duplicate names), or whether existing references are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. It is appropriately sized for a simple tool and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents both parameters. However, with no annotations or output schema, the description does not convey behavioral details such as error handling or effects on related data, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'name' already described as 'Sheet id' and 'New name (max 50 chars).' The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Rename a sheet.' This clearly identifies the tool's function and distinguishes it from create/delete/list sheet operations by the verb 'rename.' However, it does not explicitly differentiate among sibling tools beyond the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like map_create_sheet or map_delete_sheet. The description simply states the operation without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Return', implying read-only, but does not mention whether missing notes return null/empty, which sheet is referenced, or any edge cases. This leaves ambiguity 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource. It contains no unnecessary words and is highly concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks details about return value behavior (e.g., what happens if no notes exist), which sheet is meant (current active sheet?), and whether there are any side effects. With no output schema, a bit more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, a zero-parameter tool gets a baseline of 4, and there is no parameter information that the description would need to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('sheet-level notes text'), making the tool's purpose specific. It does not explicitly distinguish itself from sibling tools like map_get_sheet_data, but the phrase 'sheet-level notes text' is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. While 'Delete' implies a destructive action, it does not mention whether the operation is irreversible, whether it requires special permissions, what happens if the id does not exist, or any side effects. The description is minimal and does not provide additional context about the operation's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words: 'Delete a connection by id.' It is extremely concise, front-loaded with the verb, and contains no unnecessary words or filler. Every word contributes to the meaning, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequately brief, but it lacks important behavioral context. It does not describe the return value, error conditions, or any side effects. Given that annotations are absent and there is no output schema, the description should provide more detail about the expected behavior of the operation to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'id' with its description 'Connection id'. The tool description's phrase 'by id' simply restates this, adding no new meaning. Since the schema already fully documents the parameter, the description adds no semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'connection', making the tool's action unambiguous. It also specifies the scope 'by id', which identifies how the operation targets a connection. This clearly distinguishes it from siblings like map_delete_node and map_delete_sticky, which operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention any prerequisites, caveats, or mention that it is the appropriate tool for deleting a connection. There is no explicit context about when to prefer this over map_update_connection or map_delete_node, so the agent is left to infer the usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only says 'Update one or more app settings' without mentioning persistence, immediate effect, permissions, or return value. This is insufficient 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded and every word is meaningful, though it is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, the description covers the core operation but lacks any mention of results or side effects. It is sufficient for basic selection but incomplete for understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description of 'changes' and all fields. The description adds the notion of partial update ('one or more') but otherwise relies on the schema, which is adequate. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'app settings', distinguishing it from sibling map_get_settings. The one-liner is unambiguous for an update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as map_get_settings. It does not mention that reading settings should use the sibling get tool, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the return of the new node id, which is helpful, but omits details about defaults (x/y positions), required sheet context, potential errors, or side effects. The tool's behavior beyond the basic add operation is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that convey the essential action and return value without any filler. Every word earns its place, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description covers the core purpose and return value. However, it lacks context about prerequisites (e.g., existing sheet) or behavior when optional parameters are omitted. Still, for a straightforward add operation, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions, so baseline is 3. The description adds no additional meaning to the parameters, such as how x/y interact with map coordinates or how type affects rendering. It relies entirely on the schema, which is acceptable given 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('new node to the map'), clearly distinguishing the action from sibling tools like map_update_node or map_delete_node. It also states the return value ('Returns the new node id'), leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor does it mention any prerequisites or exclusions. While 'Add a new node' implies creation, it fails to differentiate from related operations like map_update_node or map_add_connection, and doesn't state whether a sheet must exist or how to handle duplicate names.
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 provided, the description carries the transparency burden. It states that the tool creates a sticky and returns the new ID, which is useful. However, it does not disclose any prerequisites, error conditions, or behavior when optional coordinates are omitted, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two short sentences. There is no filler; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly includes the return value (new sticky id). However, it lacks information about default placement, interactions with the canvas, or any preconditions. For a simple add tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in the schema. The description adds no parameter-level detail, so it meets the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a sticky note to the map'), distinguishing it from sibling tools like map_add_node. It also mentions the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as map_add_node or map_update_sticky. The description provides no context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the action without indicating permanence, error handling, side effects, or permissions. This is a significant gap for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words or filler. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter delete tool with no output schema, so the description covers the core action. However, it lacks important behavioral context like error behavior or whether the action is permanent, which would be expected given there are no annotations to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'id' is already described as 'Sticky note id'. The description adds 'by id' which restates the schema meaning but does not introduce new information such as format or required format. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') on a specific resource ('a sticky note') using 'id', which distinguishes it from sibling tools like map_delete_node and map_delete_connection. The verb and resource are precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to delete a sticky note, but it does not provide explicit when-to-use guidance or mention alternatives. There is no exclusion or context about prerequisites, making it adequate but not particularly helpful for choosing between this and other tools.
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 burden of behavioral disclosure. It discloses that a new connection is created and that the ID is returned, which is useful. However, it does not mention potential side effects, validation rules, or whether duplicate connections are allowed. This is adequate but minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the core action. It includes the return value in a second short sentence. No wasted words or redundant details, perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward add operation with fully documented parameters and a stated return value, the description is nearly complete. It lacks explicit notes on node existence validation or behavior on duplicate connections, but these are not essential for basic invocation. The lack of an output schema is mitigated by the mention of the returned connection id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described in the input schema. The description adds minimal extra meaning beyond indicating 'between two nodes' and the returned connection id. It does not elaborate on parameter formats or constraints, but the schema already handles this, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('manual connection between two nodes'). It also mentions the return value (new connection id), making the tool's purpose unmistakable. It distinguishes from siblings like map_delete_connection and map_update_connection by focusing on creation, and the word 'manual' hints at a single explicit connection versus bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., nodes must exist), nor does it contrast with map_bulk_add_connections or map_add_node. The description implies usage but offers no explicit context or exclusions.
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 burden of behavioral disclosure. It does reveal one key constraint ('Cannot delete the last remaining sheet'), but it doesn't mention whether deletion is permanent, cascades to associated data, or affects the current view. The confirm parameter in the schema already signals destructiveness, giving partial credit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and adding a key restriction without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the essential purpose and a critical edge case. However, it lacks usage context and does not describe error behaviors when the last sheet is attempted, which is a minor gap but not severe given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'confirm' documented. The description adds no additional parameter semantics, so it relies entirely on the schema without enhancing understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with the resource 'sheet', clearly distinguishing it from sibling tools like map_delete_node or map_delete_sticky. The added constraint 'Cannot delete the last remaining sheet' further clarifies the tool's scope and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like map_clear or map_delete_node. The description only states a limitation but offers no context on prerequisites, typical use cases, or when another tool would be more appropriate.
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?
Since no annotations are provided, the description carries the full burden. It discloses that PNG and PDF return base64-encoded blobs with mimeType, that the client decodes and saves the file, and that the server extends the timeout to 30s for large maps. It could go further by explicitly stating the operation is read-only/non-destructive, but the provided behavioral details are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the core function and formats, the second addresses encoding and timeout behavior. Information is efficiently front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an export tool with no output schema and no annotations, the description covers key operational details: formats, base64 encoding, mimeType, client-side saving, and timeout adjustment. Missing are the exact JSON return format and differentiation from map_export_sheet, but overall it is sufficiently 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have descriptions and format has an enum. The description adds marginal context by explaining that sheet_id can be omitted for the active sheet and that format defaults to 'json'. This aligns with the baseline of 3 for high coverage, with only slight additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource: 'Export current or specified sheet as JSON / PNG / PDF.' It clearly conveys the three supported formats and the sheet scope. No explicit differentiation from sibling tool map_export_sheet, which may have overlapping functionality, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like map_export_sheet. The phrase 'current or specified' implies flexibility but does not explain when to omit vs. provide sheet_id. No exclusion criteria or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. It only states the action without disclosing side effects, reversibility, or view-related consequences. The term 'absolute' adds some context but no deeper behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It conveys the essential action and target resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description covers the core behavior adequately. It lacks notes about view-only effects or prerequisites, but given the tool's simplicity and sibling context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters clearly (horizontal/vertical offset in pixels). The description adds the 'absolute' qualifier, which helps interpret x/y as absolute coordinates, but otherwise relies on the schema's 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('pan') and resource ('canvas'), and clarifies the coordinate system with 'absolute pixel offset'. This clearly distinguishes it from sibling tools like map_set_zoom or map_move_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you need to set the canvas to an absolute pixel position. However, there is no explicit comparison with alternatives or any when-not-to-use guidance, so it's only at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that it returns an array of created IDs, but provides no information about failure semantics, atomicity, partial failures, or side effects. For a bulk mutation tool, this is a significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, front-loaded with the primary action. Every word is informative and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and no output schema, so the description's mention of return value is helpful. However, for a bulk operation, the lack of details on partial failure or behavior on invalid inputs leaves the description incomplete for nuanced use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'connections' parameter. The description adds no extra meaning about parameter structure or formatting. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add multiple connections' with a specific resource (connections) and the batching scope 'in a single call'. This distinguishes it from the sibling tool map_add_connection which implies single-connection operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a single call' clearly implies a batching use case, and the sibling tool naming (map_add_connection) makes the alternative explicit. However, it stops short of explicitly stating 'use this instead of map_add_connection' or defining when not to use it, so it is clear context without exclusion.
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 responsibility. It discloses that it copies properties and returns a new node id, but does not state whether the original is modified, whether connections are also cloned, or any side effects. 'Clone' implies non-destructive, but it is not explicit, and the mention of 'all its properties' could be overbroad.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action ('Clone a node') and includes essential detail about what is copied and the return value. It is concise with no redundant or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and return value, but given the absence of annotations and output schema, it leaves some gaps: it does not clarify whether connections are included in the clone, does not mention that the original remains unchanged, and provides no guidance on when to prefer this over alternatives. These are notable omissions for a tool with no structured behavioral hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all four parameters (id, name, offset_x, offset_y) with clear descriptions. The tool description adds no additional parameter-level detail beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clone') and resource ('a node'), and explicitly lists the cloned properties (ports, services, domains, etc.), making it clear what the tool does. This clearly distinguishes it from sibling tools like map_add_node or map_update_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to duplicate a node with all its properties) but does not explicitly state when not to use it or mention alternatives. There are no references to other map_* tools, so the guidance is only implied.
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 carries the full burden. It discloses the default active sheet behavior and the types of data returned. However, it doesn't describe the return format, potential empty results, or any read-only guarantees, leaving some behavioral aspects unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and resource without any redundant words. It is highly concise and structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description covers what data is returned and the default behavior. However, it omits details about the structure of the returned data and any edge cases, which is notable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'id' with a description that matches the tool description's defaulting behavior. With 100% schema coverage, the description adds no additional parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns nodes, connections, stickies, and notes for a specific sheet, providing a specific verb and resource. It distinguishes itself from sibling getters like map_get_notes and map_get_all_connections by covering multiple entity types, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific sheet (defaults to active sheet)' provides clear context on when to use this tool. It implies use for retrieving sheet content, and the optional id parameter covers the default behavior. However, it doesn't explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 for behavioral disclosure. 'Update label or color' merely restates the tool's function without explaining side effects, partial-update semantics, error handling (e.g., non-existent id), or idempotency. It adds no transparency beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words and clearly conveys the tool's purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters, but the description lacks edge-case details such as whether 'changes' can be empty, what happens if the id is invalid, or what the return value is. Given no output schema, this missing information leaves gaps in the agent's understanding, though it is still adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for top-level parameters, and the description mentions 'label or color' which maps directly to the 'changes' properties. However, it does not add meaning beyond the schema; the schema already documents the fields thoroughly (e.g., color example, 'Fields to update'). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing connection'), with specifics about the fields (label or color). It distinguishes from sibling tools like map_add_connection and map_delete_connection by specifying it updates rather than adds or deletes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing connection' makes it clear this is for modifying an already-created connection, implying it should not be used for adding or deleting. However, it does not explicitly name alternatives or provide when-not-to-use scenarios, 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 carries the burden. It discloses what gets destroyed (nodes, connections, stickies) and the scope. However, it does not mention irreversibility, potential data loss beyond those types, or whether notes are affected, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one well-documented parameter, the description and schema together cover the essentials. It could be improved by stating that the action is irreversible or listing excluded elements (e.g., notes), but it is sufficiently complete for a clear operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the confirm parameter is clearly documented as required for destructive action. The description adds no further parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove all') and clearly identifies the resources (nodes, connections, stickies) and scope ('from the current sheet'). It also distinguishes itself from sibling tools like map_delete_node, which target individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool to clear the entire current sheet's content. However, it does not explicitly mention alternatives (e.g., using individual delete tools) or when not to use it, so guidance is only implicit.
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 carries the burden of behavioral disclosure. It does reveal the important side effect that connections are deleted along with the node, which is valuable. However, it does not mention irreversibility, permissions, or error behavior, leaving potential gaps for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and its consequence. No wasted words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema) and the description covers the primary behavior and a key side effect. It is complete enough for an AI agent to understand the tool's likely effect. Minor details like what happens if the node does not exist are not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'id' with description 'Node id'. The tool description also mentions 'node', reinforcing the context. Since schema coverage is high, the description does not need to add much; it meets the baseline with no additional detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete'), identifies the resource ('a node'), and states the scope ('and all its connections'). This clearly distinguishes it from sibling tools like map_delete_connection and map_delete_sticky.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to remove a node), but it does not explicitly mention alternatives, prerequisites, or exclusions. No guidance is given on when to choose this over map_delete_connection or map_delete_sticky, but the name and description are self-explanatory.
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 carries the full burden. It discloses that the output is JSON, includes auto-connections, and targets the active sheet by default. However, it does not state whether the operation is read-only, what the response structure looks like, or any potential side effects, leaving some transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence. It front-loads the core action and format, then adds the default behavior without any redundancy. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essential context: what is exported, in what format, the inclusion of auto-connections, and the default sheet. It lacks some behavioral details but is sufficiently complete for a simple export operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for the 'id' parameter with the description 'Sheet id (omit for active sheet)'. The tool description essentially restates this by saying 'Defaults to active sheet', adding no new parameter semantics. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'sheet data', and the format 'JSON', along with a distinguishing feature 'including auto-connections'. It also clarifies the default behavior, which helps differentiate it from sibling tools like map_get_sheet_data or map_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint by noting the default to the active sheet, but it does not explicitly state when to use this tool over alternatives like map_export or map_get_sheet_data. The intended usage is implied rather than clearly laid out.
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 carries the burden of explaining behavior. It says 'Return', which implies a read-only operation without side effects, but it does not explicitly state that it makes no changes or describe any relevant context such as prerequisites. The transparent intent is present but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object, with no wasted words. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains what the tool returns (zoom level and pan offset). For a simple getter with no parameters, this is largely sufficient. The only missing piece is a more precise structure of the returned data, but that is not essential for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed since the schema already covers everything (empty object).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return current canvas zoom level and pan offset.' It uses a specific verb and resource, and it distinguishes itself from siblings like map_set_zoom and map_set_canvas_offset, which are setters, while this is a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling map_get_state could potentially overlap, but no differentiation or explicit context is given. The usage is only implied by the name and description, not stated.
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 convey behavioral traits. The verb 'Set' clearly indicates a write operation, and 'sheet-level' scopes it to the current sheet. However, it does not disclose whether it overwrites the entire notes field, requires permissions, or behaves differently on locked sheets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word earns its place, stating the exact action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one fully documented parameter and no output schema. The description is sufficient for its low complexity, clearly indicating the action and scope. It could mention whether the current sheet must be active, but that is implicitly understood from 'sheet-level' and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'notes' parameter is described as 'Notes content', which aligns exactly with the description's 'sheet-level notes text'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and clearly identifies the resource as 'the sheet-level notes text'. This unambiguously distinguishes it from sibling tools like map_get_notes (retrieval) and other update tools by specifying the exact target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this to set sheet-level notes, and implicitly map_get_notes to retrieve them. However, it does not explicitly mention alternatives or exclusions, nor any prerequisites such as requiring an active sheet.
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 provided, the description carries the burden of behavioral disclosure. It adds the valid range (0.1–3.0), which is useful, but does not disclose what happens with out-of-range values, whether the operation is absolute or incremental, or whether it affects the current view only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing exactly the necessary information: the action (set), the target (canvas zoom level), and the valid range (0.1–3.0). There is no unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description plus schema is largely complete. It clearly communicates the action and the constrained range, and no output schema is expected. It could mention clamping or validation behavior, but the core functionality is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'zoom' parameter with an example (1.0 = 100%, 0.5 = 50%), so the description adds minimal semantic value beyond the range. The description's range complements the schema but does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set canvas zoom level' with a specific verb and resource, and it is distinguished from siblings like map_set_canvas_offset and map_zoom_to_fit by explicitly targeting zoom level. The inclusion of the range (0.1–3.0) further specifies the scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for setting the canvas zoom level but does not explicitly state when to use it versus alternatives such as map_zoom_to_fit or map_get_view. It provides no exclusions, prerequisites, or guidance on choosing between related tools.
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 disclosure burden. It discloses the return fields ('id, name, type, ip, x, y for each match') but does not describe behavior when no filters are provided, result limits, or the read-only nature (though implied by 'search'). The schema descriptions provide matching behavior, but the description itself adds limited 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that front-load the purpose, then state the return shape and the usage guidance. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description's mention of return fields is helpful. However, it does not clarify behavior with zero parameters, differentiate from sibling `map_search`, or mention any result limits. These gaps make it adequate but not fully complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter already documented (e.g., exact match for IP, substring case-insensitive for name). The description merely restates the parameter categories without adding new semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search nodes by name, IP, type, or free-text query' with a specific verb and resource. It also specifies the return fields and the intended use case ('locate a node before updating it'), which distinguishes it from update/delete 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use this tool: 'Use this to locate a node before updating it.' It does not explicitly name alternatives or exclusion criteria, but the intended pre-update lookup scenario 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 burden of disclosure. It does add useful behavioral context by specifying the result shape and clarifying that nodeId is a legacy alias for nodeIds[0], including possible null values. However, it does not explicitly state whether this is a read-only operation or mention edge cases like no selection existing beyond the null values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the purpose and then provides the result shape. Every element contributes value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter with no output schema, the description fully compensates by detailing the exact return shape, including types and null possibilities. It covers everything a caller needs to know to use the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain parameter meanings. The baseline for 0 params is 4, and the description appropriately focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns currently selected node/sticky ids and connection id, using a specific verb and resource. It is distinguishable from siblings like map_get_state or map_select because it explicitly mentions the selection retrieval and provides the exact result shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning contexts, exclusions, or alternative tools. For example, it does not clarify whether map_get_state also includes selection info or when one should prefer 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 carries the full burden. It clarifies the return fields and implies read-only behavior through 'List', but it does not explicitly state that the operation is non-mutating or describe pagination/scope limitations beyond 'all sheets'. The field enumeration adds value but lacks explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'List', and contains no redundant or unnecessary information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately specifies the scope ('all sheets') and the exact fields returned. A minor gap is the lack of explicit mention of ordering or whether 'active' is a filter or just a field, but the description is largely complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so schema description coverage is trivially 100%. Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific information because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'sheets' and enumerates the exact fields returned (id, name, createdAt, updatedAt, active status). This clearly distinguishes it from sibling tools that create, switch, rename, or delete sheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it versus alternatives like map_get_sheet_data or map_switch_sheet. Usage context is implied by the return type (an overview of all sheets), but no exclusions or alternative recommendations are given.
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 of behavioral disclosure. It usefully reveals that a locked sheet rejects all MCP mutations and disables manual UI editing, and notes the unlock behavior ('Pass locked: false to unlock'). This goes beyond the basic schema by explaining the operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and each sentence provides essential information without any fluff. It is well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema or annotations, the description covers the key behavioral context: what locking does and how to unlock. It is adequate, though it could theoretically mention persistency or permission requirements, but those are not critical for this tool's basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description of 'locked' ('true = lock (default), false = unlock') essentially repeats the schema. The phrase 'Pass locked: false to unlock' adds marginal clarity, but overall the description does not significantly enrich parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lock or unlock a sheet,' which is a specific verb+resource pair. It clearly distinguishes this tool from siblings by being the only lock/unlock operation, and the purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of locking ('rejects all MCP mutations and disables manual editing') which implies when to use it, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. For a unique tool without alternatives, this is acceptable but not exemplary.
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 must disclose behavior itself. It clearly states the tool only changes coordinates and preserves other fields, which is valuable. It doesn't mention return values, error conditions, or whether the node must exist, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediate and memorable, with no wasted words. Every element contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description covers the essential behavior. It could be enhanced with a note about return values or error handling, but the core use case is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra parameter-level detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Move' with the resource 'node' and clarifies the scope ('to new canvas coordinates without changing any other fields'). This clearly distinguishes it from sibling tools like map_update_node and map_move_sticky.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without changing any other fields' strongly implies this tool is for position-only updates, contrasting with update_node. However, it doesn't explicitly name alternatives or state when not to use it.
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 carries the full burden. It honestly discloses a key behavioral trait: the operation preserves text and color, which is not obvious from the tool name. However, it does not mention error behavior (e.g., invalid id), whether the move is absolute or relative, or any permissions. For a simple move tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and object, includes the essential target (canvas coordinates), and adds a purposeful clarification about text/color preservation. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with full schema parameter coverage and no output schema, the description is complete enough: it states the action, the target resource, and the key invariant (no text/color change). It could mention prerequisites like 'the sticky note must exist', but that is implied by the operation and aligns with sibling conventions. Sibling map_move_node exists but is for a different resource type, so no confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (id, x, y) already has a clear description. The tool description adds no additional semantic details about parameters, merely restating that they are new canvas coordinates. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('sticky note'), clearly stating the operation is to new canvas coordinates. The clause 'without changing its text or color' distinguishes it from sibling tools like map_update_sticky and map_move_node, eliminating ambiguity about what the tool does and does not modify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you want to reposition a sticky note while preserving its text/color. It does not explicitly name alternatives such as map_update_sticky for changing content, but the 'without changing' phrasing provides useful exclusion context. Lacks explicit 'use X instead' guidance, but the implied usage is clear.
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 transparency burden. It discloses an important behavior — that current sheet state is saved before switching — which adds value beyond the basic action. This helps agents understand side effects, though more details (e.g., error handling) could be included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each earning its place. No filler, redundant phrasing, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, fully documented schema, no output schema), the description is sufficiently complete: it states the action, the target (active sheet), and a key behavioral guarantee (saving state). No obvious gaps that would cause misuse for a simple switch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter fully documented as 'Sheet id to switch to'. The description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Switch the active sheet.' This is a specific verb+resource combination that distinguishes it from sibling tools like list, create, rename, or delete sheet operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (switching sheets) but provides no explicit when-to-use guidance, exclusions, or alternatives. The 'saves current sheet state first' is a behavioral note, not usage direction. General context is clear, but no explicit guidance is given.
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?
Without annotations, the description carries the full burden. It discloses that the tool adjusts zoom and pan, but does not mention any side effects, return values, or whether the current view is permanently changed. It is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the purpose and core behavior sufficiently. It lacks explicit usage guidance compared to siblings, but the core function is well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes a description for the padding parameter with default value, and the tool description adds no additional parameter information. Schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Auto-fit' and identifies the resource as 'all nodes' within the 'viewport', clearly distinguishing it from sibling tools like map_set_zoom or map_set_canvas_offset by combining both zoom and pan adjustment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fitting the entire node collection into view, which is a clear use case. However, it does not explicitly compare with map_arrange or map_set_zoom, nor does it state when not to use it, so it lacks explicit alternatives or exclusions.
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 provided, the description must convey safety and behavior on its own. It discloses the return format (array of created ids) and notes that nodes accept fields beyond the schema via the map_add_node reference. However, it fails to address critical bulk-operation behaviors such as atomicity, partial failure handling, or limits on batch size, leaving gaps for an 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loading the core action ('Add multiple nodes in a single call') and immediately specifying input inheritance and output format. Every sentence provides useful information without redundancy or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk creation with a multi-field node object) and lack of output schema or annotations, the description is moderately complete. It covers core purpose, input fields, and return value, but omits important operational details like error handling, maximum batch size, or whether the operation is atomic. These gaps are notable for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's node array has 100% coverage, but the description adds meaningful context by explaining that each node inherits fields from map_add_node and includes type-specific fields, with examples like ports, dockerServices, and domains. This helps an agent understand the structure and applicability of fields beyond a bare schema listing, going beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Add multiple nodes in a single call.' It distinguishes itself from the sibling map_add_node by emphasizing the bulk nature and explicitly mentions the return of an array of created IDs, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a single call' implies use when adding many nodes at once versus calling map_add_node repeatedly. This provides clear context for when the tool is appropriate, though it does not explicitly mention when not to use it or name alternatives. The sibling list reinforces this interpretation.
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 the primary behavior (returning settings) but does not explicitly disclose read-only semantics, absence of side effects, or potential error conditions. However, for a trivial getter, the core behavior is communicated sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that lists all returned settings. It is front-loaded, contains no filler, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description fully captures what is returned by enumerating the exact field names. It is complete for the tool's purpose, and the sibling context (e.g., map_update_settings) makes the read-only nature evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for zero params is 4, and the description does not need to add parameter meaning. It correctly lists the returned fields, which is relevant context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Return' and specifies the exact resource ('current app settings') along with the specific fields returned. It is distinguishable from siblings like map_update_settings, which modifies settings, and map_get_state, which gets overall state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Return current app settings') but provides no explicit guidance on when to use this tool versus alternatives. It does not mention map_update_settings or other related getters, so the context is only implied by the sibling names.
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 of disclosing behavior. It explicitly states that the tool 'Replace[s] active sheet content,' which is a destructive operation, and indicates it uses provided JSON data. This communicates the key behavioral trait of overwriting existing content, though it does not mention other potential side effects like undo history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains no redundant information. Every word adds value, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, clear input schema, and no output schema, the description is sufficiently complete. It explains what the tool does and when to use it, and the schema provides the input format. It could mention error handling or relation to export, but these are not critical for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the 'data' parameter including its nested structure. The description adds minimal extra meaning by calling it 'prepared topology,' but the schema already fully explains the expected format, so the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Replace active sheet content with provided JSON data.' This specifies the verb ('replace'), the resource ('active sheet content'), and the input format ('JSON data'), effectively distinguishing it from sibling import tools like map_import_csv or map_import_nmap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for loading a prepared topology in one call.' This implies when to use the tool (when you have prepared JSON data) without explicitly listing alternative tools or exclusions, but it is sufficient context for selection among siblings.
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 carry the burden. It discloses deselection behavior and connection scope, but doesn't state whether node selection replaces existing selections (though the schema does) or how simultaneous node+connection selection behaves. Some behavioral details remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and efficiently covers all key usage points without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a selection tool with 3 optional parameters and no output schema, the description covers the main use cases well. However, it leaves ambiguity about interactions between node and connection selection (e.g., whether both can be selected simultaneously and how that affects existing selections).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable meaning beyond the schema by explaining that node_ids enables multi-select, node_id is legacy, and empty array/null deselects. This enhances the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: programmatically select nodes/stickies and/or a connection. It distinguishes from siblings like map_get_selection (which reads selection) and map_add_node (which creates nodes), and clarifies legacy vs multi-select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: node_ids for multi-select, node_id as legacy single-select, empty array or null to deselect, and connection selection is single only. It doesn't explicitly name alternative tools, but gives clear context and scope limitations.
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 the key behavioral traits: creating an empty sheet, switching to it, and returning the new sheet id. It doesn't address permissions or error conditions, but for a simple creation tool, this is sufficient and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the primary action, followed by the return value. No filler or redundancy, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter, no output schema, and no annotations. The description covers the action, the switching side effect, and the return value, making it fully sufficient for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'name' has a full description in the schema (100% coverage), so the description doesn't need to add parameter details. Baseline 3 applies; the schema does the heavy lifting, and the description provides no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create), the resource (new empty sheet), and the side effect (switch to it), plus the return value (new sheet id). This distinguishes it from sibling tools like map_switch_sheet and map_rename_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it creates a new sheet and switches to it, implying it should be used when a new sheet is needed and immediate work on it is desired. Though it doesn't explicitly exclude alternatives, the context is clear enough for agent 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context: the tool includes auto-generated connections and marks them with an 'auto:true' flag. However, it does not explicitly state that the operation is read-only, nor does it mention any side effects, performance implications, or permission requirements. The verb 'return' implies read-only, but the description could be more transparent about safety and return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and the key distinction (auto-generated connections). Every sentence adds value: the first defines the action, the second explains the flag, and the third gives usage guidance. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the essential aspects: what it returns, the special auto-generated feature, and how it differs from map_get_state. The main gap is that it does not describe the return structure (e.g., whether it returns an array, or what fields each connection has beyond 'auto'). However, given the tool's simplicity, this is a minor omission and the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing to document. Per the rubric, a baseline of 4 applies. The description does not need to add parameter syntax or semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Return all connections including auto-generated ones.' It also names the specific resource and scope, and distinguishes itself from the sibling tool map_get_state by noting that map_get_state.connections lacks the full topology picture. This is a specific verb+resource+scope that clearly differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: 'Use this instead of map_get_state.connections when you need the full topology picture.' It names the alternative tool and provides a clear condition, satisfying the 'when-to-use vs alternatives' requirement fully.
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 burden of transparency. It discloses the return content (full node data including specific fields) and contrasts with stripped projection. However, it does not clarify scope (e.g., current sheet vs. all sheets) or mention potential performance/payload implications, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states purpose and output, the second gives an explicit alternative. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one well-defined parameter, the description is largely complete: purpose, output detail, and alternative are covered. Missing scope clarification (current sheet vs. all sheets) is a minor omission, but the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'type' parameter, including an enum and a description. The description adds no extra parameter-specific information beyond reinforcing 'given type', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return all nodes of a given type') and specifies the output detail ('FULL field data'), listing examples. It also explicitly differentiates from sibling map_find_node by mentioning stripped projection, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to map_find_node for stripped projection or multi-criteria filtering, making it clear when to use this tool (simple single-type full-data retrieval) versus the alternative. This is a strong when/when-not pattern.
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 important behaviors: auto-detects columns, case-insensitivity, aliases, port parsing format, 6-column grid layout, and return payload {count, ids}. This goes beyond a simple import statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose, and every sentence adds distinct detail without redundancy. Efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values ({count, ids}), node layout, column detection, and port formats. Some edge cases (duplicate handling, errors) are not addressed, but the core usage is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explaining auto-detection from header row, case-insensitivity, aliases, and port field format, which directly informs the 'csv' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Import nodes from CSV') and clearly distinguishes from sibling tools like map_import_nmap and map_import_sheet by specifying the CSV source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (bulk CSV import) but does not explicitly name alternatives or exclusions. The clear purpose makes the appropriate use case evident.
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 full responsibility for behavioral disclosure. It goes beyond basics by stating auto-inference of node type, auto-arrangement in a grid, the priority of `hosts` over `xml`, and the exact return shape `{count, ids}`. It does not mention whether nodes are appended or replace existing map content, but the disclosure is strong overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each adding critical information: the core function, the auto-inference and arrangement behavior, and the input/output contract. No filler or repetition; front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter import tool with no output schema, the description covers input formats, parameter priority, automatic behaviors (type inference, grid layout), and the return value. It omits details like error handling or whether the map is cleared, but the essential information for invoking the tool is present and accurate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters with examples (100% coverage). The description adds valuable semantics beyond the schema: the two parameters are mutually exclusive alternatives, and `hosts` takes priority if both are provided. This clarifies real-world usage that the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses nmap scan output (XML from `nmap -oX`) and creates nodes with open ports, adding that it auto-infers node types. This distinguishes it from sibling tools like `map_import_csv` (CSV import) and `map_add_node` (single node addition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for nmap scan output. It provides specific guidance on input alternatives ('Provide either raw `xml` OR pre-parsed `hosts[]`') and priority (`hosts` takes priority). However, it does not explicitly state when not to use this tool or mention alternative sibling tools.
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 of behavioral disclosure. It discloses the scope of search (name/ip/notes, stickies, labels, ports) and the return shape (categorized hits with total count). While it doesn't state read-only explicitly, the search nature is clear, and it adds useful context beyond the schema. Minor gap: no mention of result limits or error behavior, but acceptable for a read-only search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by output and alternative. Every sentence earns its place, with no fluff or repetition. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set and no output schema, so the description must explain return values. It does say 'Returns categorized hits with a total count,' and the categories are listed. It also gives an alternative. This is sufficient for a search tool, though a bit more detail on the hit structure would make it complete. Overall, quite adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema: it mentions the search categories but does not directly explain the 'types' parameter's behavior beyond what the schema already says. The q parameter is well-described in the schema, so the description's contribution is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs full-text search across nodes, stickies, connection labels, and ports, with specific fields enumerated. It also distinguishes itself from sibling map_find_node, which is for structured node-only filtering, making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use map_find_node for structured node-only filtering, providing a clear alternative and when-not-to-use guidance. It implies this tool is for broader full-text searches, giving practical context for 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 present, the description carries full responsibility for behavioral disclosure. It explicitly discloses that the tool mutates node positions in-place, a key side effect. It also mentions determinism with seed for force-directed layout, adding useful behavioral context. However, it does not specify the scope of mutation (all nodes vs current selection) or any performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and every word carries information. It front-loads the main purpose, lists alternatives concisely, and concludes with the critical side-effect. Zero filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the essential aspects: what it does, algorithm choices, and in-place mutation. It is contextually adequate for a layout tool. The only notable gap is the absence of information about what happens to the existing positions of nodes not affected (e.g., does it run on all nodes or only selected?) and any expected return value, but these are partially implied by the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining what each algorithm does (e.g., 'horizontal lanes per node type' for cluster-by-type, 'BFS components → separate zones' for cluster-by-connection). It also notes that force-directed is 'organic, deterministic with seed', enriching the bare 'force' enum value. This pushes the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs smart auto-layout with three specific algorithms (force-directed, cluster-by-type, cluster-by-connection), each with a brief behavior description. It also distinguishes itself from map_arrange (naive grid/circle), making the unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names map_arrange as an alternative and contrasts this tool as 'smart' vs 'naive', giving clear context on when to choose this over map_arrange. It also describes the three algorithm options with enough detail to guide selection, though it does not provide explicit when-not scenarios or prerequisite conditions beyond that.
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 full responsibility for behavioral disclosure. It explicitly mentions side effects like 'creates auto-connection' for parentServer, domains target, and serviceConns, and enumerates allowed protocol/record enums. It does not detail partial vs. full update semantics or error handling, but the 'changes' object implies partial updates. This is solid disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is well-organized with clear section headers and consistent formatting. Every sentence provides necessary information for the complex schema. It fronts the primary purpose in the first sentence, which aids quick comprehension. It is about as concise as possible given the breadth of node types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and no output schema, the description is impressively thorough—covering node-type-specific fields, enums, and auto-connection side effects. It does not mention the return value or what happens on validation failure, but those are secondary for tool invocation. The main gap is a lack of explicit error/response behavior, which is often critical for update operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes 'changes' as 'Fields to update,' with no structure. The tool description compensates fully by providing a complete field schema per node type, including nested objects, enums, and side-effect annotations. This is essential for the agent to invoke the tool correctly, making the description's parameter guidance highly valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update fields of an existing node by id.' This clearly distinguishes it from siblings like map_add_node, map_delete_node, and map_update_connection. The detailed per-type field schema further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it evident this tool is for modifying node fields, and the extensive field schema implies it is the go-to for updating node properties. However, it does not explicitly mention alternatives or exclusions—e.g., when to use map_update_connection instead for connection updates. Still, the context is clear enough for an agent to infer appropriate use.
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 key behavioral nuance that only manual connections are returned, not auto-generated ones. It also implies a read-only operation via 'Return', but does not mention error conditions or response format. Overall, it adds significant behavioral context beyond a bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and contents, the second provides a critical caveat and alternative. Every word contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, this description is fully complete. It specifies exactly what is returned and explicitly clarifies the scope limitation relative to a sibling tool, which is essential context for an agent choosing this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by definition. The baseline for 0-parameter tools is 4, and the description does not need to explain parameters. It correctly focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the current map state' with a specific verb and resource, then enumerates the included elements (nodes, manual connections, stickies, notes). It also distinguishes the tool from sibling map_get_all_connections by explicitly noting that only manual connections are included, which removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The note explicitly directs users to map_get_all_connections when auto-generated connections are needed, providing a clear when-not-to-use and an alternative. This is exactly the kind of explicit guidance the dimension seeks.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/den-indance/network-diagram-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server