Mural MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Widget-specific create/update tools are clearly separated by widget type, and the three arrow tools are differentiated by connection mode.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_, get_, create_, update_, delete_, connect_). The two batch variants are clearly named, and no style mixing occurs.
Tool Count4/5
20 tools is on the heavier side but justified for covering workspaces, rooms, murals, and a variety of widget types. The count is slightly over the ideal range but not excessive.
Completeness4/5
Core workflows are covered: listing and creating murals, reading and creating widgets, updating sticky notes/text/shapes/areas, and deleting any widget. Minor gaps exist (no update_image, no delete_mural or update_mural), but these are not blocking for typical use.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the mutation without explaining whether it partially updates fields, requires specific permissions, or affects existing properties. It provides no context about reversibility or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence that is under-specified rather than concisely informative. While it is short, it lacks the structure to front-load any useful details, failing to earn its place beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema or annotations, the description is severely incomplete. It does not explain what an area widget is, how it differs from other widgets, or how the update behaves, leaving a large knowledge gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, and the description does not compensate by explaining any parameters. It mentions no parameter names or semantics, leaving the agent to infer meaning from property names like 'x', 'y', and 'width' without any additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an area on a mural' barely goes beyond the tool name itself, essentially restating the resource and operation without specifying what 'area' means or which properties can be updated. It lacks the specificity seen in sibling tools like update_sticky_note or update_shape, making it nearly tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_shape or update_sticky_note. The description gives no context about widget types or differentiating use cases, so an agent gets no help selecting the correct tool.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Update a text box' with no information about whether it performs a partial or full replacement, whether it requires specific permissions, what happens if the widget does not exist, or any side effects. This is highly opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded but under-specifies the tool. It conveys only the general purpose and omits crucial details, making it more under-specification than concise in a useful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, low schema coverage, no annotations, and no output schema, this one-line description is grossly inadequate. It provides no information about required parameters, parameter semantics, behavior, or expected outcomes, making it nearly impossible for an agent to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only muralId and widgetId have descriptions). The description adds no parameter information at all, failing to compensate for the low coverage. Undocumented parameters like x, y, text, width, and height gain no meaning beyond their names, which are insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update') and resource ('a text box'), with the scope 'on a mural'. It distinguishes itself from sibling tools like create_text_boxes (create vs update) and update_sticky_note/update_shape (different widget types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need to modify an existing text box widget. However, it does not explicitly state when to use this vs alternatives like create_text_boxes for new text boxes, or how it differs from updating other widget types. No clear exclusions or alternatives 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. It discloses only that the operation updates a shape, implying mutation, but omits side effects (e.g., overwriting vs. merging), required permissions, or effects on existing properties. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential verb and object. It is appropriately concise, containing no unnecessary words or redundancies, and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is severely under-specified. It lacks information about return values, parameter behavior, prerequisites, and side effects, making it inadequate for guiding an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a low description coverage (38%), with only muralId, widgetId, and backgroundColor described. The description itself adds no parameter meaning, leaving five parameters (x, y, text, width, height) without any explanation of their semantics, units, or behavior. The description fails to compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a shape on a mural' clearly states the action (update) and the resource (shape on a mural), matching the tool name with a slight clarification. However, it does not explicitly differentiate from sibling tools like update_sticky_note or create_shapes, though the resource type is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. There is no mention of 'use this when updating shapes' or references to sibling tools, leaving the agent to infer usage solely from 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 only says 'Draw a connected arrow' without explaining whether this is a create operation, what side effects it has, how coordinates are interpreted, or what happens if the widgets don't exist. Terse to the point of lacking transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the purpose and core inputs. However, for a tool with 11 parameters and complex geometry, it is notably under-specified. It is concise but not appropriately sized given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description should provide information about return values, error behavior, and how the arrow geometry is computed. It provides none of this, making it incomplete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27%, and the description adds minimal value. 'Provide source/target IDs and positions' hints at some parameters but leaves sourceWidth/sourceHeight and X/Y coordinate semantics unexplained. It also omits any mention of the style or arrowType options, which are available in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: drawing a connected arrow between two widgets. This specific verb+resource distinguishes it from sibling tools like connect_widgets_batch, which handles batch connections, and create_arrow, which likely creates a generic arrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus connect_widgets_batch or create_arrow, nor does it specify any prerequisites or context for choosing this tool over alternatives.
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 must disclose behavioral traits itself. It only states the action and type of object; it doesn't mention return values, permissions, side effects, or how areas relate to other widgets. The term 'grouping section' provides a small hint but not enough for a creation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it concise and front-loaded. It effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema or annotations, the description is far too sparse. It doesn't explain the area's behavior, relationship to widgets, or what the response will contain, making it incomplete for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 86% parameter coverage, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, so it neither elevates nor degrades the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an area, defines it as a grouping section, and specifies the location is on a mural. This distinguishes it from sibling creation tools like create_shapes or create_sticky_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like update_area or create_shapes. The only implied usage is that areas are grouping sections, suggesting use when wanting to organize widgets, but this is left to inference.
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?
The description discloses batch behavior and the return of IDs, which adds value beyond the schema. However, with no annotations, it does not cover important mutation aspects like error handling, partial failures, or permissions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, delivering the core purpose, batch capability, and return type in a single sentence. Every word adds functional value with no unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key operational details like batch size and return IDs, and the schema provides coordinate and style context. However, for a mutation tool without annotations, it lacks guidance on failure modes and operational prerequisites, leaving the agent under-informed for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on any parameters. With schema description coverage at only 50%, the missing parameter explanations for 'stickies' are not compensated, leaving the agent to rely solely on the schema for the array structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create sticky notes') on a specific resource ('a mural') with batch support and a limit of 1000. This distinguishes it from sibling tools like create_text_boxes and create_shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives. Sibling tools such as create_text_boxes and create_shapes imply different use cases, but the description does not mention them or provide contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update' and lists fields, but does not state whether the update is partial or full, coordinate semantics, permission requirements, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loads the action and resource, and contains no redundant or filler information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is too sparse. It lacks critical context such as partial update behavior, coordinate system details, required identifier semantics, and return value information, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 38%, so the description must compensate. The parenthetical groups x/y as 'position', width/height as 'size', and names 'text' and 'color', giving meaningful semantics to otherwise undocumented parameters. However, it omits coordinate units and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Update' and names the resource 'sticky note' with a parenthetical list of updatable aspects (text, position, color, size). This clearly distinguishes it from sibling tools like create_sticky_notes and update_text_box.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that create_sticky_notes is for new notes, nor any 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, the description carries the full burden of behavioral disclosure. It discloses that only key metadata fields are returned, but does not specify which fields, error behavior, permissions, or confirm read-only semantics beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence: it opens with the action and resource, then adds a useful qualifier. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple one-parameter getter with a strong parameter schema, but no annotations and no output schema. The phrase 'stripped to key fields' hints at the return shape, but the description does not enumerate the key fields or describe behavior for invalid IDs, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description already explains the mural ID format and that full URLs are accepted. The description adds no additional semantic value beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get metadata for a specific mural', using a specific verb and resource. The phrase 'stripped to key fields' adds a scoping detail that helps distinguish it from list_murals and other workspace-level tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need metadata for one mural rather than a list of murals. However, there is no explicit when-not-to-use guidance or mention of alternative tools like list_murals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does and that it returns all arrow IDs, but it fails to disclose important behavioral traits such as atomicity (all-or-nothing behavior), error handling for partial failures, permissions, or rate limits. For a mutation tool, this lack of safety context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two short sentences—and front-loads the primary action. It contains no filler and every word adds value. The mention of returning arrow IDs is essential and efficiently integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex batch operation with nested object parameters, no output schema, and no annotations. The description does not explain coordinate systems, arrow types, failure modes, or how to structure the connections array beyond what the schema implies. It is too sparse for the complexity involved, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes muralId and style with clear descriptions, covering 67% of top-level parameters. The connections array fields are self-explanatory by name but lack descriptions. The tool description itself adds no parameter meaning, but the schema provides adequate baseline, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Connect multiple widget pairs with arrows in one call', which distinguishes it from single-pair tools like connect_widgets and create_arrow. It uses a specific verb and resource, and explicitly mentions the batch capability, so there is no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for connecting multiple widget pairs in one call, which implies a batch scenario. However, it does not explicitly mention when not to use it or alternatives (e.g., use connect_widgets for single connections), so it lacks explicit exclusions. Still, the batch context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the return value (mural ID + title), but does not disclose side effects (e.g., creating an empty mural), permission requirements, or behavior on invalid roomId. For a mutating creation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that covers the essential action and return value. There is no wasted text, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents all six parameters and the description states the return value, the tool is adequately complete. No output schema exists, so mentioning the return is valuable. A slight gap is that it does not describe the state of the created mural (e.g., empty canvas), but this is largely implied by 'create'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning: 'in a room' maps to roomId, but otherwise it only restates what the schema already conveys. The return value note does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' with the resource 'mural' and the location 'in a room', clearly distinguishing it from all sibling tools that create widgets within a mural. It also states the return value (mural ID + title), which further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context: you need a roomId to create a mural. However, it does not explicitly state when to prefer this over alternatives, such as 'use this before creating widgets' or mention any prerequisites beyond the required roomId. There are no exclusions or alternative tool references.
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?
The description adds useful behavioral context by stating 'Returns IDs' and the batch size limit of 1000, which goes beyond the basic create intent. However, with no annotations provided, it does not disclose potential failure modes, permission requirements, or the effect of partial batch failures. It gives only minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the key information: what, where, batch size, and return value. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a relatively simple parameter structure (two top-level params, one array of objects), and the schema provides detailed descriptions for the core properties. The description mentions return IDs and batch limit, but does not explain behavior on errors, partial success, or output format. Given no output schema and no annotations, this is adequate but leaves gaps for an agent to fully understand invocation consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description should compensate for undocumented parameters (e.g., style, width, height). The description merely says 'text boxes' without elaborating on their structure or required fields. It adds no semantic value beyond what the schema already provides for x, y, and text, and fails to clarify the nested properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create text boxes on a mural (batch, up to 1000)'. It specifies the resource (text boxes on a mural), the action (create), and distinguishes from sibling tools like create_sticky_notes or create_shapes by naming the specific object type. The batch limit adds scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The batch limit 'up to 1000' implies use for bulk creation, but there is no explicit guidance on when to prefer this tool over alternatives like create_sticky_notes or update_text_box. No exclusions or when-not-to-use scenarios are provided, so the usage context is only 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?
With no annotations, the description carries the full burden of disclosing behavioral traits. While 'delete' inherently implies destruction, the description does not mention irreversibility, whether connected elements are affected, or any permission requirements. This lack of context could lead an agent to underestimate the action's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing exactly the necessary information: the action, the target, and the input method. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the schema's thorough parameter documentation, the description is mostly complete. However, it omits any mention of outcome (e.g., success/failure behavior) or post-conditions, which would be helpful for a destructive operation, though not strictly required for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters with 100% coverage. The description adds no additional parameter-level meaning beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with a clear resource ('any widget from a mural') and specifies the input mechanism ('by ID'). It distinguishes from sibling tools, which are all create/update/get operations, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is the only delete tool among widgets, so the context is clear. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or prerequisites, such as permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that returned data is 'stripped to key fields,' a useful non-obvious trait, but it does not discuss error handling, permissions, or invalid ID behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the core action front-loaded and no redundant wording. It earns its place with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get with no output schema, the description gives a partial return-shape hint but does not enumerate which key fields are included or what happens on failure. It also omits mention of the dual-ID requirement, making it minimally complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both required parameters with descriptions, giving 100% schema coverage, so the baseline is 3. The description itself does not mention parameters or clarify how muralId and widgetId relate, but the schema already handles that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'single widget by ID,' clearly distinguishing it from the plural sibling get_widgets and the mutation delete_widget. The parenthetical '(stripped to key fields)' adds precise scoping of the response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single widget by ID' implies the tool is for retrieving one specific widget, but it does not explicitly state when to prefer this over get_widgets or mention any exclusions. No alternatives are named, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds value by mentioning the 1000-item batch limit (though also in schema) and that the full list of shapes is validated server-side, which warns the agent about potential invalid values. However, it does not disclose return values, error behavior, partial failure semantics, or authentication requirements, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core action and batch limit front-loaded in the first sentence. It uses a second sentence to list common shapes and note server-side validation, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool, the description and schema together cover the essential input details well. The description adds useful context about shape options and validation. The main missing piece is the return value or response format, especially since there is no output schema, but this is not critical for the create action itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must compensate. It provides concrete examples for the 'shape' parameter (rectangle, circle, etc.) and clarifies that other values are server-validated, which is not evident from the schema alone. However, it does not elaborate on other parameters (x, y, width, height, style, text), which are left to the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates shapes on a mural, specifically mentioning batch creation and a limit of 1000. This distinguishes it from sibling tools like create_sticky_notes, create_text_boxes, and create_area, which target different widget types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating geometric shapes on a mural, and the batch size suggests it's suitable for bulk operations. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., 'for sticky notes, use create_sticky_notes'), so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It clearly indicates this is a read-only listing operation ('List widgets'), discloses that the response is reduced ('stripped to key fields'), and explains pagination behavior. This is meaningful behavioral context beyond what the schema offers, though it does not cover output format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences. The first tells the core purpose, the second packs pagination details. Every chunk of information is useful and front-loaded. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 1 required) and no output schema, the description covers the key operational aspects: listing action, reduced payload, and pagination. It does not mention the optional type filter, but the schema documents it clearly. For an AI agent selecting the tool, this is sufficient context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all four parameters with 100% coverage, so the baseline is 3. The description merely restates the default limit and the pagination cursor, adding no new semantic meaning beyond what the schema already provides. Thus, it does not elevate beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource construction: 'List widgets on a mural'. It also notes 'stripped to key fields', distinguishing it from get_widget (which likely returns full details). This makes the tool's purpose unmistakable even among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear pagination context (default limit 50, use 'next' cursor), but does not explicitly name alternatives for when to use get_widget instead. The phrase 'stripped to key fields' implicitly suggests that get_widget is for full details, but the guidance is not explicit, so it falls into 'implied usage' rather than a clear when/when-not formulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a significant behavioral trait: returned rooms are 'stripped to id+name+type'. It also mentions the default limit, though that is already in the schema. However, it does not disclose other potential behaviors such as ordering, pagination or error conditions, which would typically be needed for a list operation. This is adequate but not rich, so a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action, resource, scope, and key output characteristic. It contains zero superfluous information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and no output schema, the description effectively conveys the purpose and the stripped output fields. It does not explicitly describe the response envelope (e.g., array or paginated object), but given the low complexity and available schema, it is sufficiently complete. The lack of an explicit mention of pagination behavior beyond the limit is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of both parameters with descriptions (workspaceId and limit). The description adds no extra parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'rooms' with a scope 'in a workspace'. It is distinct from sibling tools like list_workspaces and list_murals, which target different resources. The addition of 'stripped to id+name+type' further clarifies the scope of returned data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool for listing rooms within a specific workspace, providing context for when it should be used. However, it does not explicitly name alternative tools or state exclusions, so it falls short of a 5. The context is clear enough to guide selection, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by revealing that the output is limited to 'id+name', which is a behavioral trait. However, it does not explicitly state whether the operation is read-only, mention permissions, or describe any side effects, though 'List' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information in just a few words. Every component earns its place: the verb, the resource, and the output shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, this description provides sufficient context: what is listed and the exact fields returned. It is not overly complex, and the description covers the key aspects needed for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so per the rubric the baseline is 4. The description does not need to explain parameters; it adds output-related context ('stripped to id+name') beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb 'List' and resource 'Mural workspaces', and further specifies the output shape 'stripped to id+name'. This distinguishes it from sibling tools like list_rooms and list_murals by naming the exact entity being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving workspaces but provides no explicit guidance on when to use it versus alternatives like list_rooms or list_murals. The context is clear (need workspace listing), but there are no exclusions or alternative references.
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 and discloses key behavior: returned fields are stripped and default limit is 50. It does not cover edge cases like behavior when neither roomId nor workspaceId is provided, but the disclosed behaviors are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two short sentences that front-load the core action and include the stripped-fields note and default limit. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description indicates return fields but leaves ambiguity about behavior with no filters, sorting, or error conditions. It covers the essentials but lacks completeness for a tool with optional parameters and no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented there. The description adds minimal extra meaning beyond 'room or workspace' mapping to roomId/workspaceId, matching the baseline 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists murals in a room or workspace, specifying the resource and scope. It differentiates from siblings like get_mural (individual) and list_workspaces/list_rooms by mentioning stripped fields, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for lightweight listing with 'stripped to id+title+roomId' and mentions the default limit. However, it does not explicitly contrast with get_mural for full details or state when not to use it, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention the key trait of being 'not snapped to widgets', which is useful, but it omits other behavioral details like whether it creates a new widget, permissions required, or response behavior. The description is not misleading, but leaves room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that clearly state the tool's purpose and the alternative. Every word adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and nested objects, but the schema is rich (86% coverage), the description sufficiently clarifies the tool's role and differentiates it from connected arrows. It could hint at arrowhead placement or coordinate details, but the schema covers those. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, so the schema already documents most parameters. The description adds no parameter-specific semantics beyond what the schema provides, maintaining a baseline of 3 as per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool draws a freeform arrow, using a specific verb ('Draw') and resource ('freeform arrow'). It also explicitly differentiates from connected arrows by noting 'not snapped to widgets' and referencing connect_widgets as the sibling for connected arrows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for freeform arrows that are not snapped to widgets. It also names the alternative for connected arrows ('use connect_widgets'), making the usage context clear and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses useful behavioral traits beyond the schema: auto-detection of dimensions and a 10MB size limit. It does not detail failure modes or return values, but the core behavior is transparent for a simple create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every phrase adds information: action, target, source condition, automatic behavior, and size limit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple tool with 6 parameters and no output schema, the description covers the essential context: what it does, where the image comes from, and key constraints. It doesn't explain returned data, but the absence of an output schema lowers that expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 6 parameters with descriptions, so additional explanation is limited. The description adds the 10MB size constraint and implies width/height defaults, but mostly paraphrases the schema's 'default: original' for dimensions. It provides marginal semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Add an image to a mural') and clearly states the source ('public URL'). It distinguishes create_image from sibling tools like create_sticky_notes or create_shapes by indicating it handles image placement specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this when adding an image from a public URL, with explicit constraints (must be public, max 10MB). It does not name alternatives or state when not to use it, but the sibling tools are clearly different in purpose.
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:

[![mural-mcp MCP server](https://glama.ai/mcp/servers/janschmiedgen/mural-mcp/badges/card.svg)](https://glama.ai/mcp/servers/janschmiedgen/mural-mcp)

Score Badge

Copy to your README.md:

[![mural-mcp MCP server](https://glama.ai/mcp/servers/janschmiedgen/mural-mcp/badges/score.svg)](https://glama.ai/mcp/servers/janschmiedgen/mural-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/janschmiedgen/mural-mcp'

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