Skip to main content
Glama

Draw On Board

convyy_draw

Compose board content from primitive elements (shapes, stickies, frames, text, connectors) with explicit layout control to prevent overlaps. Renders the composed board with server-managed styling.

Instructions

Render any board content you compose from native primitives. Provide elements (shape, sticky, frame, text, connector); the server owns ids and styling, but YOU own the layout — give explicit x/y/width/height so nothing overlaps. LAYOUT RULES: (1) Stickies are ALWAYS square; the side equals the width you send (height is ignored), so reserve a square footprint and leave >=40px gaps between boxes. (2) Lay diagrams out on a clean grid (left-to-right or top-to-bottom) and connect adjacent boxes; do NOT place any shape on the straight line between two boxes you connect, or the arrow will cross it. (3) For a branch/decision, offset the branch target to the side or below with clear space so its connector has an empty corridor — the server routes arrows from the nearest edges with elbow bends, which only stays clean when you leave room. Use this for anything that does not fit a named template. THINKING SIGNAL: when you START handling the user's request, call this once with empty elements: [] so the board shows your cursor 'thinking'; then call it again with the real elements once you have composed the answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layoutNoLayout hint: free | flow-lr | grid. Default free.
promptYesShort description of what to draw.
elementsNoElements you generate from the request. Each is one of: { kind:'shape', id, text, shapeType, x?,y?,width?,height?, fill? } — fill is one of: transparent | white | ink | amber | emerald | sky | violet | rose. | { kind:'sticky', id, text, color?, x?,y?,width?,height? } — color is one of: amber | sky | emerald | rose | violet | orange (default amber). Use these tokens, NOT plain color names like yellow/blue/green. | { kind:'frame', id, title, x?,y?,width?,height? } | { kind:'text', id, text, x?,y?,width?,height?, fontSize?, bold? } | { kind:'connector', from, to, label? }. Omit coordinates to let the server lay them out.
Behavior5/5

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

No annotations provided, but the description comprehensively explains server ownership of ids/styling, user ownership of layout, sticky square rule, arrow routing, and thinking signal behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but efficiently structured: purpose first, then rules, then usage note. Every sentence adds necessary value without redundancy.

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?

Covers drawing and layout thoroughly, though lacks explicit return value or error handling. Given no output schema, it's nearly complete for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, but the description adds extensive meaning with element type details, color tokens, layout rules, and usage instructions beyond basic 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 renders board content from primitives and distinguishes it from named templates, specifying it's for anything that doesn't fit a template.

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?

Explicitly states when to use (anything not fitting a named template) and provides a thinking signal for initial empty call, plus detailed layout rules.

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

Install Server

Other Tools

Latest Blog Posts

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/divulture/convyy-mcp'

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