Model Context Protocol server for Canvelete design platform. Enables AI assistants to create, manipulate, and export designs programmatically with 13 element types including QR codes, barcodes, and access to 200K+ icons and millions of stock images.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The Canvelete MCP server has 24 tools covering design automation, asset management, and templates. While tool names follow verb_noun conventions and schemas are present with typed parameters, there are significant quality gaps. Most tool descriptions are minimal (10-40 chars), lacking context on WHEN to use each tool or WHAT makes it distinct from similar tools. Parameter descriptions exist but are often generic ('Design ID' vs explaining what a design ID is, how to obtain it, or when it's required). Output schemas are not documented in the provided source, only input schemas are visible. Error handling is absent from the visible implementation (no recovery guidance, no validation messaging). The tools lack idempotency hints, destructive operation confirmations, and pagination guidance for list results. API key exposure in parameters (not server-side injection) is a critical security gap. For a design-focused toolkit, the definitions are functional but would not meet code review standards for production LLM agents.
Tools (24)
add_elementwriteauthsource verified57/100
Add an element to the canvas
apply_templatewriteauthsource verified58/100
Apply a template to an existing design
chat_with_civiread onlyauthsource verified55/100
Chat with Civi AI. Note: This requires integration with Civi AI API
API keys exposed as tool parameters instead of server-side secret injection. Tools accept 'apiKey' parameter directly, which will be logged in agent traces and prompt history, risking credential leakage.
Destructive tools (delete_design, delete_element, clear_canvas) lack confirmation/dry-run support and error recovery guidance. No descriptions warn LLMs about irreversibility.
delete_designdelete_elementclear_canvas
Recommendations
CRITICAL: Implement server-side secret injection for API keys. Remove 'apiKey' parameter from all tools. Use environment variables or a vault to inject credentials server-side, never exposing them in tool parameters or agent logs.
CRITICAL: Add confirmation/dry-run support for delete_design, delete_element, and clear_canvas. Implement a confirm=false parameter (default) that returns 'This will permanently delete X items. Call again with confirm=true to proceed.' Pattern: pattern:confirmation-request.
HIGH: Expand tool descriptions to 50-200 characters. Include WHEN to use each tool, what it does, and what makes it different from similar tools. Example: 'delete_design: Permanently delete a design and all its contents. Cannot be undone. Use only when design is no longer needed.'
HIGH: Document output schemas for all 24 tools. Specify what fields are returned, which are IDs usable by downstream tools, and data types. This enables LLM chaining and reduces failed tool calls.
HIGH: Add result caps to list tools. Document that list_designs, list_assets, list_fonts, list_templates will return a maximum of 20-50 items per page. Explain pagination strategy and how to fetch remaining results.
HIGH: Constrain the 'element' parameter in add_element. Define a JSON Schema for valid element types (text, image, shape, qrcode, barcode, etc.), required fields (type, x, y, width, height), and optional fields (fill, stroke, rotation, etc.). Current 'object' type is too loose.
HIGH: Add error recovery guidance. Define what errors each tool can return and what the agent should do: 'design_not_found → try list_designs() to find valid IDs', 'invalid_format → use one of: png, jpg, pdf, svg', etc.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tool descriptions are generic and insufficient. Most are 25-40 characters (below the 50-200 char optimal range). Descriptions do not explain WHEN to use each tool, what makes it distinct, or prerequisites. Example: 'delete_design' = 'Delete a design' (19 chars, no guidance on irreversibility).
Output schemas not documented. Only input schemas are visible in source code. LLMs cannot infer what fields are returned, what IDs they can chain to downstream tools, or what data types to expect.
Missing pagination guidance. List tools (list_designs, list_assets, list_fonts, list_templates) accept page/limit but descriptions do not state result caps or explain pagination behavior. No mention of max result limits to prevent context window exhaustion.
Element parameter in add_element (line 8) uses generic 'object' type with loose description 'Element object with type, x, y, width, height, and other properties'. No schema details, no enum for element types, no field constraints. LLM cannot determine valid element types or required fields.
No error handling guidance visible in tool definitions. No recovery messages, no retry classification, no hints on when to call discovery tools. Errors will not guide LLM remediation.
generate_design and chat_with_civi are not implemented (see ai-tools.ts stub returning 'not yet implemented'). Tools exist in the interface but will always fail. Remove from registry or mark as experimental.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Destructive tools should be marked with destructiveHint=true so agents treat them with extra caution.
Parameter descriptions lack format/constraint details. Width/height numeric parameters do not specify min/max values (e.g., 'width in pixels' vs 'width in pixels (1-10000)'). Quality, page, limit, and per_page parameters lack bounds. LLMs may pass invalid values.
export_design format parameter lacks enum constraint. Description says '(png, jpg, pdf, svg)' in natural language rather than as a JSON Schema enum. LLMs may hallucinate other formats.
No tool chaining support visible. Response schemas not documented, unclear whether get_design returns a designId usable by other tools, or what field names are returned for upstream tools to consume.
search_stock_images source prefix syntax ('icon:home', 'clipart:business') documented in description but not as formal parameter constraints or examples. Unclear if other sources are supported or what happens with invalid prefixes.
search_stock_images
HIGH: Remove or complete generate_design and chat_with_civi. The AI tools stub returns 'not implemented', these will always fail. Either complete the Civi AI API integration or remove these tools from the registry.
MEDIUM: Add tool annotations (readOnlyHint, destructiveHint) to mark delete_design, delete_element, clear_canvas as destructive. This signals to agents to be extra cautious.
MEDIUM: Add numeric constraints to parameters. Width/height: '1-10000 pixels', quality: '0-100', page: 'positive integer', limit/perPage: '1-100 items'. Use parameter descriptions or JSON Schema minimum/maximum properties.
MEDIUM: Convert format parameter in export_design to an enum constraint. Current 'format' has options listed in description, move to JSON Schema enum: ['png', 'jpg', 'pdf', 'svg'].
MEDIUM: Document response chaining. For each tool that creates or retrieves a resource (create_design, get_design, duplicate_design, add_element, create_template), explicitly state what field name holds the ID usable by downstream tools (e.g., 'returns designId for use with update_design, delete_design, add_element').
MEDIUM: Add idempotency guidance. State which tools are safe to retry (read-only tools: list_*, get_*, search_*) vs. which risk side effects on retry (write/destructive: create_*, update_*, delete_*). Consider adding an idempotencyKey parameter to create_* tools.
MEDIUM: Clarify search_stock_images source syntax. Document all supported sources (pixabay, unsplash, iconify, clipart, illustrations) and their query prefixes. Add error handling if user provides invalid source prefix.
LOW: Add batch variants for tools called in loops. For example, offer add_elements (array) alongside add_element (single). Batch operations reduce token waste and latency.
LOW: For file/resource upload (upload_asset), document the full workflow: 'Call upload_asset to get upload instructions, then use the main Canvelete API to perform the actual upload. Return the uploaded asset ID for use with add_element.'
DOCUMENTATION: Add a 'Prerequisites' section to the server README explaining how to obtain and configure API keys, what design/element IDs look like, and common workflows (e.g., 'To add an image: (1) search_stock_images, (2) add_element with the returned image URL').