excalidraw-mcp-obsidian
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Several tools have overlapping purposes: get_element, get_element_context, and query_elements all retrieve element data; export_to_excalidraw_url, export_to_obsidian, and export_scene all export the scene. Descriptions clarify distinctions (by ID vs detailed context vs filtered query; URL vs file vs JSON), but agents may still conflate them. get_resource is vague and doesn't clearly fit the element/scene model.
Naming Consistency4/5Most tools follow a consistent verb_noun pattern (create_element, delete_element, group_elements). Minor deviations exist: export_to_excalidraw_url vs export_scene, snapshot_scene vs restore_snapshot, and the use of 'resource' in get_resource instead of 'element' or 'scene'. Overall readable and predictable.
Tool Count2/5With 31 tools, the server exceeds the 25+ threshold for 'too many'. While the domain is complex, the toolset could be consolidated (e.g., merging get_element/get_element_context, or unifying export/import variants). The high count adds cognitive load and selection risk.
Completeness5/5The toolset provides full CRUD for elements, batch operations, layout controls (group, align, distribute), locking, multiple export/import formats, snapshots, style presets, and design guidance. No obvious dead ends; agents can accomplish a complete diagram lifecycle.
Average 3.3/5 across 31 of 31 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavior. It only says 'Get' with no mention of read-only semantics, side effects, return format, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a single sentence, but this brevity reflects under-specification rather than conciseness. It contains zero useful information beyond what the tool name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is critically incomplete. It omits resource types, return values, example usage, and any distinguishing context, leaving the agent to guess the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'resource' parameter. While the schema provides an enum, the description adds no meaning about what each resource type represents or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an Excalidraw resource' essentially restates the tool name without adding specificity. It does not enumerate the supported resource types (scene, library, theme, elements) nor differentiate from similarly named siblings like get_element or get_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Sibling tools like get_element, get_selection, and export_scene clearly overlap, yet the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 fails to state whether this tool modifies element positions, requires a selection, or affects layout. No side effects, limitations, or operational details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than impactful. It front-loads the core action, but fails to provide context that would be expected for a tool with two parameters and a direction enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and appears to be a layout operation, the description is severely incomplete. There is no output schema, no annotations, and the description does not clarify what 'evenly' means spatially or how direction affects the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter ('elementIds' or 'direction'). It adds no meaning beyond what the schema already shows, leaving the agent to infer the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Distribute elements evenly' names a specific verb ('distribute') and resource ('elements'), but it is vague about what 'evenly' means (e.g., spacing, position, alignment). It does not distinguish from siblings like align_elements or group_elements, which could also involve arranging elements.
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. No mention of prerequisites, selection requirements, or which distribution scenarios it handles. Sibling tools like align_elements suggest related functionality, but the description does not clarify boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only states the action without disclosing behavioral consequences such as whether a group object is created, whether elements are repositioned, or whether the operation is reversible. The description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no extraneous words. It is efficient, though it sacrifices substance for brevity.
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?
With no annotations, no output schema, and a single undocumented parameter, the description is insufficiently complete. It does not explain the effect on the canvas, expected return value, or any constraints, which is particularly problematic for a mutation-like tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention elementIds or explain what the array should contain, any constraints, or the relationship of these IDs. The description provides zero added meaning beyond the parameter name.
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 uses a specific verb ('Group') and resource ('elements'), clearly distinguishing it from siblings like ungroup_elements. It is minimal but not a bare tautology.
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 ungroup_elements, align_elements, or distribute_elements. There are no prerequisites or exclusions mentioned.
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?
Since there are no annotations, the description carries the full burden of disclosing behavioral traits. It only states that it updates an existing element, but does not mention side effects (e.g., overwriting vs. merging), error behavior if the id does not exist, or any permissions required. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no fluff or redundant wording. It is front-loaded and easily parsed. However, its extreme brevity sacrifices essential explanatory content, which slightly detracts from its structural effectiveness.
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 tool with 15 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to convey what properties are updatable, whether the operation is a partial or full replacement, and what the expected return value or side effects are. The tool's complexity is not matched by the descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and a 15-parameter schema, the description is required to compensate, but it does not explain the meaning or use of any parameter beyond the implicit understanding that 'id' identifies the element. There is no mention of how x, y, text, or other properties are applied, making the parameter semantics entirely ambiguous.
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 ('Update') and the resource ('an existing Excalidraw element'), which distinguishes it from sibling tools like create_element and delete_element. However, it does not elaborate on what aspects of the element can be updated, so it lacks some specificity.
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 like create_element or lock_elements, nor does it mention any prerequisites or contexts. There is no explicit exclusions or favored scenarios, leaving the agent to infer usage solely from the tool name.
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 is the only source of behavioral transparency. It fails to disclose whether alignment is relative to other elements or an absolute canvas position, what values like 'center' vs 'middle' mean, or any side effects. This ambiguity leaves the agent guessing about the tool's actual behavior.
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 a single, efficient sentence with no redundancy or fluff. It is front-loaded with the action and resource. However, it errs on the side of underspecification, which slightly detracts from its effectiveness, though it remains concise.
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 tool with no annotations, no output schema, and two parameters, the description is not complete enough. It lacks information on return values, alignment semantics, and how it interacts with the canvas or selection. The sibling tools like distribute_elements and group_elements suggest a broader context that this description fails to address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the meaning of the 'alignment' enum values (e.g., 'left', 'center', 'right', 'top', 'middle', 'bottom') or clarify what 'elementIds' refers to. The parameter names are self-evident but their precise semantics remain under-specified.
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 a specific action (Align) and target (elements) with an outcome ('to a specific position'). It distinguishes itself from generic tools but does not explicitly differentiate from closely related siblings like distribute_elements, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. There is no mention of prerequisites, scenarios, or exclusions. The description is purely a bare definition without contextual usage advice.
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 must disclose behavioral traits but does not. It implies a read operation via 'Get', but does not explain the return format, the meaning of 'context', the effect of the optional radius parameter, or any side effects or permissions.
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 a single, concise sentence with no redundant wording. However, it is under-specified, so while it is efficient, it sacrifices useful detail.
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?
Given no annotations, no output schema, and an undocumented optional parameter, the description is incomplete. It leaves the meaning of 'radius', the shape of the returned context, and the exact use case undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'id' param implicitly, but completely omits the 'radius' parameter. No additional meaning is added beyond what the bare schema already shows.
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 action ('Get detailed context') on a specific resource ('a specific element by ID'). It is clear enough, though 'detailed context' is somewhat vague and does not explicitly differentiate from sibling tools like get_element or query_elements.
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 such as get_element or query_elements. It only states what the tool does, with no mention of prerequisites, exclusions, or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Query' and 'optional filters', but does not disclose return format, whether the query is read-only, or any side effects. This is inadequate for a tool with no structured annotations.
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 a single concise sentence that states the core purpose without redundancy. It is front-loaded and efficient, though it could be slightly better structured with additional context.
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?
Given three parameters (one nested object, one enum) and no output schema, the description is far too sparse. It fails to explain what the tool returns, how filters behave, or any other contextual details needed by an agent. The tool is more complex than the description acknowledges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (bbox has a description, type and filter do not). The description adds no additional parameter detail, and the 'filter' parameter remains completely unexplained beyond being an arbitrary object. The description does not compensate for the low schema coverage.
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 queries Excalidraw elements with optional filters, using a specific verb and resource. It is distinct from sibling tools like get_element (which implies retrieving a single element) or get_selection, though it does not explicitly name them.
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 get_element or get_selection. The description only states what the tool does, leaving the agent to infer intended usage based on the name.
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 does not mention whether deletion is permanent, whether it cascades to dependent elements, any authorization requirements, or potential side effects. The terse statement leaves critical behavioral aspects undisclosed.
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 one short sentence with no wasted words, making it highly concise and front-loaded. However, it is minimal to the point of missing valuable contextual information, so it earns a 4 rather than a 5.
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?
Given the lack of annotations and output schema, the description is the only source of completeness. It fails to explain return values, behavior on non-existent elements, or any other operational details. For a deletion tool, this is a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'id' parameter's format, meaning, or how to obtain it. The description adds no value beyond the raw schema field definition, leaving the agent without context for correctly populating the required 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 'Delete an Excalidraw element' uses a specific verb (delete) and resource (Excalidraw element), clearly distinguishing it from sibling tools like create_element, update_element, and query_elements. It is unambiguous and action-oriented.
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 any exclusions or prerequisites. It simply states the action without contextual cues, leaving the agent to infer usage purely from the tool name.
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 disclosing side effects and behavior. It does not state whether the operation creates new elements, leaves originals intact, or affects any related data. It also does not explain the return behavior or potential side effects on selections or groupings.
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 a single, front-loaded sentence with no redundant words. It communicates the core action and a key qualifier efficiently. It is appropriately concise, though a bit more detail could be added without becoming verbose.
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?
Given the tool's moderate complexity, no output schema, and no annotations, the description is insufficient. It fails to explain what the operation returns, whether it is destructive, or how the offset parameters behave. Key contextual details that an agent would need for correct use are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers a minimal hint that offsets are configurable, but it does not explain the parameters at all. With 0% schema description coverage, this is insufficient. The meaning of 'elementIds' is left to inference from its name, and the description adds little beyond the schema's bare property names.
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 purpose: duplicating elements, with the added detail of a configurable offset. The verb 'duplicate' is specific and distinguishes it from sibling tools like create_element or update_element. The 'configurable offset' further specifies the operation's scope.
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 does not mention any prerequisites, exclusions, or preferred contexts. It simply states the action without any comparative or situational advice.
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 states the export action but does not mention whether it overwrites existing files, requires special permissions, or how file saving behaves. Minimal detail beyond the obvious.
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-loading the action and format with no wasted words. It is appropriately sized for the tool's simplicity.
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?
Given the simple one-parameter tool, the description is too sparse. It omits parameter semantics, usage context, and potential side effects, leaving the agent without enough information to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, filePath, has no schema description, and the description does not reference it at all. With 0% schema coverage, the agent receives no guidance on path format, required extension, or parameter meaning. The description fails to compensate.
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 (export), scope (current canvas), and output format (.excalidraw JSON). This distinguishes it from sibling tools like export_to_excalidraw_url and export_to_obsidian, which target different output channels.
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 export_to_excalidraw_url or export_to_obsidian. The description lacks any context about intended use cases, 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?
No annotations are present, so the description carries full responsibility for disclosing behavior. It states only the basic action, not the semantics of the 'mode' parameter (replace vs. merge), side effects on existing canvas content, or error handling. This is a significant transparency gap.
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 a single concise sentence that is front-loaded and free of fluff. However, it omits necessary details about modes and behavior, so it is more under-specified than optimally concise.
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?
With no annotations and a minimal schema, the description leaves crucial aspects unclear, such as the meaning of 'mode', how the import interacts with existing canvas elements, and potential failure modes. It is inadequate for a tool with this complexity and no structured guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'filePath' or 'mode'. While the schema's enum values hint at replace/merge, the description adds no context about how these modes affect the import process. The description fails to compensate for the lack of parameter meaning.
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 specifies the verb 'import', the resource ('diagram from an Obsidian .excalidraw.md file'), and the destination ('onto the canvas'), making the tool's function unambiguous. It clearly distinguishes from siblings like export_to_obsidian (reverse direction) and import_scene (presumably a different format or source).
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 offers no guidance on when to use this tool versus alternatives. It does not mention preconditions, differences from import_scene, or contexts where replace vs. merge mode is appropriate. No exclusions or alternative tool references are provided.
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. 'Restore' implies overwriting the current canvas, but the description does not explicitly state that current content will be replaced, whether the operation is reversible, or what happens if the named snapshot does not exist. This is a significant gap for a potentially destructive mutation.
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 main action ('Restore the canvas') and includes the key qualifier ('from a previously saved named snapshot'). There is zero redundant information, making it concise and efficiently scannable.
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 tool with one parameter, no output schema, and no annotations, the description is incomplete. It omits critical side effects (e.g., overwriting current canvas state, potential data loss) and does not mention error conditions (e.g., if the snapshot doesn't exist). A simple but complete description should at least note that the current canvas will be replaced.
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 only defines a required string parameter 'name' with 0% schema description coverage. The description's phrase 'previously saved named snapshot' adds the meaning that the 'name' parameter identifies the snapshot to restore, providing some context beyond the bare schema. However, it does not clarify format, constraints, or behavior when the name is invalid, leaving room for improvement.
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 a specific verb ('Restore') and resource ('the canvas') from a 'previously saved named snapshot', which distinguishes it from siblings like snapshot_scene (which saves) and clear_canvas (which clears). However, it does not explicitly name an alternative tool or contrast with other restoration/import tools, so it falls short of a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'previously saved named snapshot' but does not reference the snapshots created by snapshot_scene or explain when restore_snapshot is preferable to import_scene. There are no exclusions or context cues.
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 side effects. It only states the export action, but does not mention whether the file is overwritten, what 'current canvas' entails, or any permission requirements. The write nature is implied but not elaborated.
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, front-loaded sentence efficiently communicates the core purpose with no filler. Every word contributes value, aligning with ideal conciseness.
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 simple export tool with no output schema and no annotations, the description lacks important context: tag semantics, file behavior (overwrite/create), and relationship to sibling exports. The basic purpose is clear, but an agent would need to infer too much about how to use parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It fails to explain the purpose of 'filePath' or 'tags' beyond their names. Tags are entirely ignored, and no syntax or expected value format is given.
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 a specific verb ('Export'), the resource ('current canvas'), and the target format ('Obsidian-compatible .excalidraw.md file'). This distinguishes it from siblings like export_to_excalidraw_url (URL) and import_from_obsidian (import).
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 for exporting a canvas to an Obsidian-compatible file, but provides no explicit guidance on when to use this tool versus alternatives like export_to_excalidraw_url or export_scene. No when-not or alternative mentions are present.
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 full burden. It fails to disclose that the 'mode' parameter can replace or merge elements, potentially overwriting the current scene. No side effects, permissions, or error behavior are mentioned.
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 wasted words. It efficiently conveys the core function.
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?
Given the tool's complexity with a required enum and potential destructive behavior, the description is too terse. It doesn't explain the replace/merge modes, output, or impact on existing elements, making it insufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description must compensate. It hints that filePath or data are alternative sources, but it doesn't explain the meaning of the 'mode' parameter or formats expected for data/filePath.
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 imports elements from a .excalidraw JSON file or raw JSON data, using a specific verb and resource. This distinguishes it from sibling tools like import_from_obsidian and other element 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 such as import_from_obsidian or create_element. It lacks context on recommended scenarios, 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 does not mention side effects, whether the operation is reversible, any permissions required, or what happens to the elements after ungrouping. It is a minimal statement of intent without behavioral depth.
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 that immediately communicates the core action. It is concise, fully front-loaded, and contains no unnecessary words or repetition.
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 does not explain the required parameter, potential errors, or behavioral outcomes, leaving the agent with only a high-level understanding. More context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, and the description does not explain the 'groupId' parameter at all. While the parameter name is somewhat self-explanatory, the description adds no meaning beyond what the schema provides, failing to compensate for the lack of schema documentation.
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 ('Ungroup') and the target ('a group of elements'), making it immediately distinguishable from sibling tools like group_elements. The verb+resource structure is specific 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 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, prerequisites (e.g., elements must already be grouped), or context for typical use cases. The description simply states the operation without any additional context.
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 full burden for behavioral disclosure. It only states the basic action and purpose, but does not mention side effects, whether the operation is reversible, idempotency, or any required permissions. 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 sentence, front-loaded with the action and purpose, with no wasted words. Every part contributes to meaning.
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?
The tool is simple (one parameter, no output schema), but given the absence of annotations, the description is too minimal. It does not clarify return behavior, effects on element state, or how it relates to lock_elements, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the elementIds parameter at all. It neither explains the format, accepts one or multiple IDs, nor the type of elements. The description fails to compensate for the lack of schema documentation.
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 with a specific verb ('Unlock') and resource ('elements'), and the phrase 'to allow modification' clarifies the purpose. It distinguishes itself from the sibling tool lock_elements by describing the inverse 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 phrase 'to allow modification' implies the tool is used before modifying elements, giving some context. However, it lacks explicit guidance on when to use it versus alternatives like lock_elements or update_element, and no exclusions are mentioned.
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 does not disclose whether the operation is read-only, what the output format is (plain text vs JSON), or whether it describes the entire canvas or only visible/selected content. The phrase 'AI-readable' hints at a natural language output but is ambiguous.
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 with no unnecessary words. It is well-structured and immediately clear about the tool's 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?
For a zero-param tool with no output schema, the description is minimal but adequate. It lacks details about output format or scope (whether it covers the whole canvas or only a selection), which could cause ambiguity given similar sibling tools. Still, it is not completely inadequate.
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 the description's mention of 'current canvas' sufficiently scopes the operation. The baseline for zero params is 4, and the description adds no unnecessary param details.
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 returns an AI-readable description of the current canvas. It is distinct enough from siblings like export_scene or get_selection, though it does not explicitly differentiate them.
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 sibling tools like get_selection or export_scene. Without any context about alternatives, the agent must infer usage.
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 mentions the batch nature and prerequisite, but does not disclose potential side effects, validation behavior, failure handling, or response format. For a batch mutation tool, this is a significant transparency 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 two sentences, front-loaded with the action, and includes a concise warning. Every sentence provides value with no filler or redundancy.
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?
The tool has a complex schema (17 properties per element object) and no output schema or annotations, yet the description is minimal. It provides a design-rule prerequisite but does not explain return values, error semantics, or how the schema fields interconnect, leaving significant context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no semantic information about the 'elements' parameter or its nested properties. It only restates the concept of creating elements without explaining field meanings, defaults, or required behaviors.
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 ('Create') and resource ('multiple Excalidraw elements at once'), distinguishing it from the sibling tool 'create_element' (singular). The scope is explicit 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'BEFORE using this tool, call read_diagram_guide(template="...")' to obtain design rules. This offers a procedural guideline, but it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls short of a 5.
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 exist, so the description carries the full burden. It states the intended effect (prevent modification) but does not disclose side effects, reversibility, permissions, or persistence. This is significantly under-specified for a mutating 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 sentence, direct, and front-loaded. Every word earns its place with no waste or redundancy.
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 tool that modifies state, the description lacks context on prerequisites, reversibility, and effects. Sibling tools like unlock_elements exist, but the description doesn't reference them, leaving the agent uncertain about the tool's broader usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, elementIds, with 0% description coverage. The description says 'elements' but does not explain that the parameter is an array of element IDs or how to obtain them. The parameter name is self-explanatory, providing minimal additional 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 'Lock elements to prevent modification' with a specific verb (lock), resource (elements), and purpose (prevent modification). This distinguishes it from siblings like unlock_elements and other element 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 when modification should be prevented, but provides no explicit when-to-use or alternatives (e.g., no mention of unlock_elements for reversal). It is clear enough for basic use but lacks decision guidance.
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 states 'clear all elements' but does not disclose whether the action is irreversible, whether it clears undo history or presentational attributes, or if any confirmation is required. The destructive nature is implied but not explicit, which 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, concise sentence with no filler words. It communicates the action and target resource efficiently, earning a perfect score for conciseness.
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 tool with zero parameters and no annotations, the description is minimal. While it adequately conveys the basic function, it omits crucial context such as irreversibility, potential impact on undo history or associated resources, and return value. Given the destructive nature, this is a noteworthy gap that a more complete description should address.
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 the schema provides full coverage by definition. The description adds no parameter-specific detail, but none is needed. According to the rubric, 0 parameters warrant a baseline of 4, and the description does not detract from this.
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 'Clear all elements from the canvas' uses a specific verb ('clear') and resource ('canvas'), explicitly stating the scope ('all elements'). This distinguishes it clearly from sibling tools like 'delete_element' which removes a single element, and 'query_elements' which reads data.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that this is a bulk/clear-all operation and should be preferred over 'delete_element' or 'batch_create_elements' when the entire canvas needs resetting, nor does it list any exclusions or 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 to fall back on, the description should disclose behavioral traits. It does not mention overwrite behavior, error conditions, return values, or any side effects beyond saving. It adds the scope 'current canvas state' but leaves key behaviors unclear.
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 with no redundant words. It is front-loaded with the primary verb and resource, making it easy to parse.
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 low-complexity tool with one parameter and no output schema, the description is adequate for basic invocation but lacks details on overwrite behavior, return values, or storage semantics. It is complete enough to understand the core action but leaves gaps that could affect agent decision-making.
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 has 0% description coverage for the 'name' parameter, but the tool description says 'named snapshot', which clarifies that the name parameter is the identifier for the snapshot. This adds meaningful semantics beyond the schema, though it does not specify any constraints or uniqueness rules.
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 'save' and the resource 'a named snapshot of the current canvas state', distinguishing it from siblings like restore_snapshot, export_scene, and import_scene. It is specific about the action and scope.
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 only states what the tool does and does not provide guidance on when to use it compared to alternatives. There is no mention of exclusions, prerequisites, or when to prefer another tool such as export_scene.
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 adds meaningful behavioral detail by noting that arrows auto-route to element edges when bound via startElementId/endElementId. However, it does not describe side effects, return values, or error scenarios, and the prerequisite to read the guide is more of a usage guideline than a behavioral trait.
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 compact: two sentences. The first is a direct statement of purpose. The second integrates an important warning and a targeted tip about arrow binding without unnecessary fluff. Every sentence 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 19 parameters, no output schema, and no annotations, so the description needs to carry substantial explanatory weight. It covers the arrow-binding case and the design-guide prerequisite, but leaves many parameters unexplained, does not state what the return value is, and offers no guidance on common usage patterns. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (37%), with many parameters like x, y, width, and height lacking descriptions. The description adds some meaning by emphasizing startElementId and endElementId for arrows, but it does not explain the majority of parameters. Given the low schema coverage, the description should compensate more than it does.
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 core action and resource: 'Create a new Excalidraw element.' This specific verb+resource phrasing separates it from sibling tools like update_element, delete_element, and batch_create_elements. It also adds relevant arrow-binding details that further clarify 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: call read_diagram_guide(template="...") before using the tool to get design rules. It also gives guidance for arrows, telling the agent to use startElementId/endElementId to bind to shapes. While it doesn't explicitly contrast with batch_create_elements, the sibling names make the single-element scope clear, so usage context is well implied.
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 the burden. 'Get' implies a read-only operation, but no behavior is disclosed for not-found cases, error handling, permissions, or return format. Minimal transparency beyond the verb itself.
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 six-word sentence, front-loaded with the action verb. No filler or redundant material; 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?
For a simple one-parameter getter, the core purpose is adequately conveyed, but the total absence of annotations and lack of return/error-behavior details leave gaps. It is minimally viable but not fully complete for an agent unfamiliar with MCP conventions.
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?
With 0% schema description coverage, the description compensates by explaining that 'id' identifies the Excalidraw element to retrieve. This adds meaningful semantic context beyond the bare string type, though examples or format expectations are absent.
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?
Crisp verb 'Get' plus specific resource 'single Excalidraw element by ID' clearly states function. The qualifiers 'single' and 'by ID' distinguish it from siblings like query_elements and get_resource.
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 phrase 'by ID' implies this tool is for fetching one known element, providing some implied usage context. However, there is no explicit when-to-use, when-not-to-use, or reference to alternatives such as query_elements for multiple/filtered lookups.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states the action but does not reveal side effects (e.g., whether a public link is created, if the canvas is modified, or if external service calls are made). The absence of any mention of persistence or access permissions is a notable 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 a single, well-constructed sentence that front-loads the action and destination. Every word contributes meaning, with no redundancy 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 zero-parameter tool with no output schema and no annotations, the description is adequate: it names the action, subject, and output format. However, it leaves out details about the nature of the URL (e.g., whether it's temporary or requires authentication), which would enhance completeness. Still, the simplicity of the tool makes this a minor gap.
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 has zero parameters, and the description correctly references an implicit context ('current canvas'). With no parameters to document, the description fully satisfies this dimension, and the baseline of 4 for zero-param tools is exceeded by the clear contextual mention.
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 ('Export') and clearly identifies both the resource ('current canvas') and the destination ('shareable excalidraw.com URL'). It distinguishes itself from sibling tools like export_to_obsidian and export_scene, which target different outputs.
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 a clear use case (when you want to share the canvas via a link) but does not explicitly differentiate from alternatives such as export_scene or export_to_obsidian. No exclusions or conditions are mentioned, leaving the agent to infer when this tool is preferred.
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 clearly implies a read operation ('List') and describes the conceptual content of presets, but it does not mention return format, ordering, pagination, or whether it returns full preset objects or just names. For a zero-parameter list tool, this is adequate but not detailed.
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, no filler. The first states the action, the second provides defining context. 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 list tool with no output schema and no annotations, the description is mostly complete: it defines what is listed and what a style preset is. It could mention the shape of the returned data (e.g., names vs. full objects), but the description is sufficient for an AI agent to invoke it 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?
The tool has zero parameters, so the schema is empty. The description adds value by explaining what style presets are (color palettes, shape defaults, layout rules), which helps the agent infer the kind of data returned. Since there are no parameters to document, a baseline of 4 applies and the description meets it.
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+resource: 'List all available style presets.' This clearly distinguishes the tool from siblings like apply_style_preset and lookup_style_tokens. The second sentence adds useful context about what style presets are, reinforcing purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('when you need to see all presets') but does not explicitly state when to choose this over alternatives. Sibling tools like apply_style_preset and lookup_style_tokens exist, but the description gives no guidance on when to use this tool instead. This is clear context but no exclusions or explicit 'when to 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?
Despite lacking annotations, the description discloses a key behavioral trait: it uses actual rendered dimensions, which is why shapes must be created first. It also notes that arrow endpoints are computed from these dimensions. While it doesn't cover all side effects (e.g., idempotency, error handling), it adds significant non-obvious behavioral context 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?
The description is three sentences with no fluff. It front-loads the purpose, then gives the critical usage order, and ends with a requirement. Every sentence contributes to understanding 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?
For a tool with a complex nested parameter and no output schema, the description provides essential context (create shapes first, reference existing IDs). It does not explain behaviors like parallel arrow gaps, but those are covered in the schema's item descriptions. Overall, it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the top-level 'arrows' parameter, so the description must compensate. It only mentions that each arrow needs startElementId/endElementId, without explaining the array structure or the richer properties like gap, snap, or labelOffset. The nested property descriptions in the schema are helpful, but the description itself adds minimal parameter-level meaning.
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 'Bind arrows to shapes using actual rendered dimensions for precise edge-to-edge connections,' which specifies the exact action and resource. It also differentiates from sibling tools like create_element by emphasizing the use of actual rendered dimensions and the reliance on pre-existing shapes.
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 explicitly instructs to call this tool AFTER batch_create_elements (shapes only), providing clear timing and prerequisite context. It does not explicitly mention when not to use it or name alternatives, but the order dependency is a strong usage guideline.
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 clearly discloses the main behavior: sets defaults for future creation and optionally updates existing elements. It also specifies the conditional nature ('Optionally') of the updating, which is important. It does not mention potential side effects like overwriting current styles or error behavior, but for a style preset tool, the key behavior is transparent.
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 sentences, each providing essential information. The first sentence states the primary action and the second explains the optional behavior. No redundancy or filler, making it highly effective.
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 no output schema and only two parameters, all fully documented. The description covers the core functionality and the optional mode. It lacks details on what happens if the preset name is invalid or how to discover available presets, but these are covered by sibling tools and the schema. Overall, it is complete for a tool of this simplicity.
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 already documents both parameters with clear descriptions, so the baseline is 3. The description adds value by explaining what 'defaults' means (font, colors, roundness) and by clarifying that applying the preset affects future creations unless applyToExisting is true. This enriches the user's understanding of the parameters beyond the schema alone.
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 identifies the action ('Apply a style preset to the canvas') and its effect ('Sets defaults... for future element creation'). It also distinguishes itself from related sibling tools like list_style_presets and lookup_style_tokens by stating it actively applies the preset, not just lists or looks up.
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 context: when you want to set default styles or update existing elements. However, it provides no explicit guidance on when to use this tool instead of alternatives (e.g., set_canvas_font for just font, or list_style_presets to see available presets). There are no exclusions or alternatives mentioned, so it relies on the user to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's core behavior: it reads a specific file, returns a summary, and optionally includes the full JSON payload. Since no annotations are provided, the description carries the burden of explaining the operation. It doesn't cover error scenarios, but for a simple read-only tool this is adequate.
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, with the first sentence front-loading the core purpose and the second explaining parameter usage. There is no redundancy 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?
The description covers the tool's purpose, return value, and parameter behavior. It lacks explicit error handling or file path details, but given the tool's simplicity and the presence of no output schema, it is sufficiently complete for an agent to invoke it 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?
The input schema already describes fullJson as a boolean, but the description adds that passing fullJson=true returns the raw payload, clarifying the exact effect and intended use. This adds value beyond the schema's minimal definition.
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 identifies the tool as reading the Obsidian selection bridge file and returning a summary of selected elements (ids, type, text, bounds) plus optional instruction. This distinguishes it from sibling tools like get_element or query_elements, which operate directly on the canvas.
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 provides clear context for when to use this tool: after the 'AI Edit Selected' EA script writes the .ai-selection.json file. However, it does not explicitly mention alternatives or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses two accepted input syntaxes (JSON paths and template shorthand) and the default preset behavior, which are beyond what the schema alone would tell the agent. It does not describe the return format or behavior on invalid roles, but for a read-only lookup this is reasonably transparent.
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 long, front-loaded with the primary purpose, and each clause adds distinct value (syntax variants, default behavior). There is no wasted text or repetition of schema 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?
Given the simple 2-parameter schema and absence of annotations, the description covers purpose, input syntax, and defaulting comprehensively. It does not explicitly state the return structure, but for a lookup tool whose purpose is to resolve roles to hex colors, the missing detail is minor and unlikely to mislead.
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%, providing a baseline of 3. The description adds meaningful detail by explaining the two syntax formats for the roles parameter and the default chain for the preset parameter, both of which are only tersely represented in the schema.
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: 'Resolve style preset token roles to hex colors for batch_create_elements,' clearly indicating the tool's function and target usage. This distinguishes it from sibling tools like apply_style_preset or list_style_presets, which are related but serve different purposes.
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 states the intended context ('for batch_create_elements') and explains the default preset resolution chain (activePreset from apply_style_preset, falling back to clean-tech). It does not explicitly list when not to use the tool or name alternatives, but the context is clear enough for an agent to select it appropriately.
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 disclosing behavioral traits. It explicitly says the font updates every existing element immediately and persists as the default for new elements. It also provides semantic meaning for font choices (hand-drawn, clean standard, classic sketch). While it doesn't discuss undo or reversibility, the core side effects are well covered.
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 long, front-loads the main action, and every sentence earns its place. The first sentence states the action and its immediate effect, the second clarifies persistence and provides helpful font semantics. 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 single-parameter tool with no output schema, the description is fully complete. It covers the tool's purpose, scope, immediate effect, persistence, and offers user-friendly font hints. There is no ambiguity about what happens when this tool is invoked.
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 provides 100% coverage with descriptions for each numeric font value, but the description adds qualitative meaning (e.g., Excalifont = hand-drawn, Helvetica = clean standard, Virgil = classic sketch) that helps the agent understand which font to choose. This goes beyond the schema's literal mapping.
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 'Set' with a clear resource 'global font' and scope 'ALL elements on the canvas'. It immediately distinguishes this from per-element editing tools like update_element, making the tool's 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the global scope and that it updates all elements, which implies when to use it—when you want a canvas-wide font change. However, it does not explicitly mention alternatives or when not to use it, only that the effect is global and persistent.
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 burden of conveying safety and behavior. It uses 'Returns' to indicate a non-mutating read operation and lists the template options, which adds context about what to expect. However, it does not explicitly state that the tool has no side effects or mention error handling, leaving a small 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 two sentences long, front-loading the main purpose in the first sentence and listing templates, then adding a critical usage note in the second. Every sentence and detail serves a purpose with no 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 simple read-only tool with one parameter and no output schema, the description covers purpose, template options, and invocation order. Minor omissions like the default template or output format are not critical but would make it fully complete.
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 schema only defines 'template' as a string with no description or enums. The description compensates fully by listing all available template values (base, flowchart, architecture-diagram, etc.), providing the exact semantic meaning expected for the 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 clearly states the tool returns a comprehensive design guide for Excalidraw diagrams, with a specific verb 'Returns' and resource 'design guide'. It lists the available templates, distinguishing it from sibling tools that create or modify elements.
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 instructs to call this tool BEFORE any create_element or batch_create_elements call, making the usage context and ordering unambiguous. It also implicitly excludes other operations, providing clear when-to-use guidance.
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/zzmkxd/excalidraw-mcp-obsidian'
If you have feedback or need assistance with the MCP directory API, please join our Discord server