Skip to main content
Glama

web_draw

Author a pure SVG asset file that rejects scripts, foreignObject, and event attributes; external references require --allow-external. Reference it with web_insert_section or web_set_attr.

Instructions

Author a pure SVG asset file. Rejects scripts, foreignObject and event attributes. External references are refused unless started with --allow-external. Reference it afterwards with web_insert_section or web_set_attr.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
svgYesComplete pure SVG source.
pathYesSafe relative .svg asset path.
expected_revYesRevision returned by your most recent read. Stale revisions refuse; read again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it discloses meaningful behavior: scripts, foreignObject and event attributes are rejected, and external references are refused unless the '--allow-external' flag is used. This is real constraint disclosure an agent cannot infer, though it omits overwrite/create semantics for an existing path.

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?

Three short sentences, front-loaded with the primary action, then constraints, then follow-up routing. No filler and each sentence carries distinct 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?

No output schema and no annotations, so the description must stand alone; it covers the content safety rules and the follow-up tools. What it lacks is any statement of success/return behavior or whether authoring an existing path overwrites it, which matters for a 3-required-param mutation tool.

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 three parameters (svg, path, expected_rev) are already documented in the schema, including the stale-revision retry behavior. The description adds nothing parameter-specific, so the baseline of 3 applies.

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?

States a specific verb+resource: 'Author a pure SVG asset file.' The content restrictions (scripts, foreignObject, event attributes) sharpen what kind of file this produces, distinguishing it from generic write tools like web_set_text or web_css. It does not explicitly contrast with any sibling by name, keeping it at 4.

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 tells you what to do after authoring ('Reference it afterwards with web_insert_section or web_set_attr'), which gives useful sequencing context. It does not state when this tool should be chosen over sibling write tools (web_set_attr, web_css_set) or what conditions make it the wrong choice beyond the SVG-specific rejections.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.