tldraw-mcp

by dpunj

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. For example, create_shape makes individual shapes, create_frame groups them, create_flowchart auto-arranges nodes, and connect_shapes specifically adds arrows between shapes. The actions (clear, create, delete, get, update, zoom) are well-separated by target objects.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case throughout. Verbs like create, delete, update, get, clear, connect, and zoom are applied predictably to nouns like canvas, shapes, flowchart, frame, snapshot, ensuring readability and predictability across the set.
Tool Count5/5
With 9 tools, this is well-scoped for a diagramming/canvas server. Each tool earns its place by covering distinct operations like creation, modification, deletion, viewing, and canvas management, without being overly sparse or bloated for the domain.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for canvas shapes and diagrams. It includes creation (create_shape, create_frame, create_flowchart), reading (get_snapshot), updating (update_shape, connect_shapes), deletion (delete_shapes, clear_canvas), and utility (zoom_to_fit), with no obvious gaps for the stated purpose.
Average 3.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Connect') but doesn't explain what happens—e.g., whether this creates a permanent link, requires existing shapes, affects other elements, or has side effects like visual updates. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly, and every part of the sentence contributes essential 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 the tool's complexity (a mutation operation connecting shapes), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like effects on the canvas, error conditions, or what the connection entails (e.g., directional arrow, persistence). For a tool with 3 parameters and no structured safety hints, more context is needed.
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%, with clear parameter descriptions in the schema (e.g., 'Source shape ID' for 'from'). The description adds no additional meaning beyond what the schema provides, such as explaining how shapes are identified or what a 'label' represents contextually. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect') and resources ('two shapes with an arrow'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'create_flowchart' or 'update_shape' that might also involve shape relationships, missing explicit differentiation.
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. With siblings like 'create_flowchart' (which might create connections as part of a larger structure) or 'update_shape' (which could modify connections), there's no indication of context, prerequisites, or exclusions for this specific connection operation.
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 full burden. While 'create' implies a write operation, the description doesn't disclose important behavioral traits: whether this creates a new canvas or adds to existing content, what permissions are needed, whether the result is editable, what happens if node IDs conflict, or what the output looks like. The auto-arrangement hint is useful but insufficient 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 extremely concise at just two sentences, front-loading the core purpose. Every word earns its place with no redundancy or unnecessary elaboration. The structure moves from general creation to specific behavioral detail (auto-arrangement).
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?
For a creation tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a diagram ID, image data, or success status), doesn't mention error conditions or constraints, and provides minimal behavioral context despite the tool's complexity.
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 schema already documents all parameters thoroughly. The description mentions 'nodes and connections' which aligns with the schema's nodes and edges parameters, and 'auto-arranged' hints at the direction parameter's purpose. However, it doesn't add significant meaning beyond what the comprehensive schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a flowchart diagram with nodes and connections, specifying that nodes are auto-arranged. It uses specific verbs ('create') and resources ('flowchart diagram'), but doesn't explicitly differentiate from sibling tools like create_shape or create_frame, which appear to be related drawing tools.
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. With multiple sibling tools for creating and manipulating shapes (create_shape, create_frame, connect_shapes, etc.), there's no indication of when this flowchart-specific tool is appropriate versus more general shape tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'create' (implying a write operation) but doesn't cover permissions, whether frames are permanent or editable, what happens to existing shapes, or error conditions. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('create a frame') and purpose ('to group shapes together'), making it easy to parse. Every word earns its place.
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?
For a creation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a frame is in this context, how grouping works, what the output looks like, or error handling. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
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 schema fully documents all 5 parameters (x, y, width, height, name) with descriptions and defaults. The description adds no parameter-specific information beyond implying frames group shapes, which doesn't clarify parameter usage. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'frame', specifying its purpose to 'group shapes together'. It distinguishes from siblings like 'create_shape' or 'create_flowchart' by focusing on frames rather than individual shapes or flowcharts. However, it doesn't explicitly differentiate from all siblings (e.g., 'connect_shapes' also groups 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?
The description provides no guidance on when to use this tool versus alternatives like 'create_shape' or 'connect_shapes'. It doesn't mention prerequisites (e.g., needing shapes to group) or exclusions (e.g., not for grouping text). Without usage context, the agent must infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this requires specific permissions, whether shapes persist, if there are rate limits, what happens on failure, or what the return value might be. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Front-loaded with the core action and resource, followed by helpful examples. Every word earns its place without redundancy or unnecessary elaboration.
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?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, how shapes relate to other tools, error conditions, or system constraints. The agent would need to guess about behavioral aspects despite the comprehensive parameter schema.
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 schema already documents all 9 parameters thoroughly with descriptions, enums, defaults, and required fields. The description adds minimal value by listing examples ('rectangle, ellipse, text, note, etc.') that partially overlap with the 'type' and 'geo' parameter enums, but doesn't provide additional context beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a shape on the canvas') with examples of shape types. It distinguishes from siblings like 'delete_shapes' or 'update_shape' by specifying creation, but doesn't explicitly differentiate from 'create_flowchart' or 'create_frame' which might create different canvas 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create_flowchart' or 'create_frame'. The description implies it's for creating basic shapes, but doesn't specify boundaries or prerequisites. No explicit 'when-not' or alternative tool recommendations 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify if deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting connected shapes). It also omits details on response format or error handling, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly, and every part of the sentence contributes essential 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 the complexity of a destructive operation with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like permanence of deletion, error scenarios (e.g., invalid IDs), or impact on related elements (e.g., connections in sibling tools). For a mutation tool, this leaves too many unknowns for safe and effective use.
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%, with the parameter 'ids' clearly documented as 'Shape IDs to delete'. The description adds no additional meaning beyond this, such as ID format, constraints, or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but there's no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('shapes from the canvas'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'clear_canvas' (which might delete all shapes) or 'update_shape' (which modifies rather than deletes), leaving room for improvement in distinguishing from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like 'clear_canvas' (for bulk deletion) or 'update_shape' (for modifications). It lacks explicit when/when-not instructions or prerequisites, such as whether shapes must exist or be selected first, making usage context unclear.
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 the tool updates properties, implying mutation, but lacks details on permissions, side effects (e.g., if updates affect other shapes), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('update properties') without unnecessary words. It earns its place by succinctly conveying the tool's purpose, making it easy to parse and understand quickly.
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 complexity of an 8-parameter mutation tool with no annotations and no output schema, the description is incomplete. It fails to address behavioral aspects like safety, permissions, or return values, and doesn't leverage sibling context to clarify usage, leaving the agent under-informed for effective tool 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 description mentions 'properties' but doesn't specify which ones, while the input schema has 100% description coverage, detailing all 8 parameters (e.g., 'id', 'x', 'color'). Since the schema does the heavy lifting, the description adds minimal value beyond implying updatable properties, meeting the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('properties of an existing shape'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'create_shape' or 'delete_shapes' beyond the basic action, missing specific distinctions about what properties can be updated versus created.
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. It doesn't mention prerequisites (e.g., shape must exist), exclusions (e.g., cannot update non-existent shapes), or comparisons to siblings like 'create_shape' for new shapes or 'delete_shapes' for removal, leaving the agent without contextual usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get') but doesn't specify if this is a real-time snapshot, cached data, or has any side effects like logging. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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, direct sentence that front-loads the core functionality without any fluff. It uses minimal words to convey the essential action and target, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on output format, error conditions, or performance characteristics. For a read operation in a canvas context, more context on what 'state' includes (e.g., positions, properties) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which is efficient. It earns a 4 because it avoids redundancy while clearly stating the tool's scope ('all shapes on the canvas'), which implicitly defines the output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('current state of all shapes on the canvas'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'zoom_to_fit' (which might also provide canvas state information) or 'create_shape' (which modifies rather than reads), so it falls short of a perfect 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/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. For example, it doesn't clarify if this is for retrieving a full snapshot versus incremental updates, or when to prefer this over other read-like operations that might exist. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Remove all shapes' indicates a destructive mutation, but it does not disclose behavioral traits such as whether this action is reversible, requires specific permissions, or has side effects on other canvas elements. The description is minimal and lacks crucial context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without any wasted words. It is front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
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's destructive nature (implied by 'Remove'), no annotations, and no output schema, the description is incomplete. It does not explain what happens after clearing (e.g., confirmation, error handling, or return values), which is critical for understanding the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics beyond the schema, but this is appropriate given the lack of parameters. A baseline of 4 is applied as it adequately handles the parameter-less case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove all shapes from the canvas' clearly states the tool's purpose with a specific verb ('Remove') and resource ('all shapes from the canvas'). It distinguishes from siblings like 'delete_shapes' (which likely deletes specific shapes) by emphasizing the comprehensive 'all shapes' 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 description implies usage when clearing the entire canvas, but does not explicitly state when to use this tool versus alternatives like 'delete_shapes' or 'create_frame'. It provides some context through the action described, but lacks explicit guidance on 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('zoom') but does not specify whether this is a read-only operation, if it affects the canvas permanently, what happens if no shapes exist, or if there are any rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any redundant or unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate for basic understanding but lacks depth. It does not explain what 'zoom' entails (e.g., view adjustment vs. permanent change) or the return value, which could be important for an agent to use it correctly in a workflow with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter information, as there are none to describe, which aligns with the schema's completeness.
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 ('zoom the canvas') and the goal ('to fit all shapes in view'), using a precise verb+resource combination. It distinguishes this tool from siblings like 'clear_canvas' or 'get_snapshot' by focusing on view adjustment rather than content modification or retrieval.
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 when shapes are not fully visible or need to be centered, but it does not explicitly state when to use this tool versus alternatives like 'get_snapshot' for viewing or manual zoom adjustments. No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred.
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:

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

Score Badge

Copy to your README.md:

[![tldraw-mcp MCP server](https://glama.ai/mcp/servers/dpunj/tldraw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dpunj/tldraw-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/dpunj/tldraw-mcp'

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