The Modellix Agent Canvas server provides a comprehensive set of tools for managing a local, AI-powered infinite canvas with image generation, editing, project management, and asset handling. You can:
Canvas & Project Management: Open the canvas (embedded or via URL), check workspace binding and API status, read and save full projects with content-addressed assets, get canvas context (active page, selection), and create, rename, or delete pages.
Asset Management: Save images (PNG, JPEG, WebP, GIF) or SVGs as content-addressed assets for use in the canvas or image tasks.
Image Generation & Editing: Prepare tasks via a free pre-flight that shows model selection, estimated cost, and effective parameters; submit after explicit user confirmation (supports text-to-image or editing with multiple outputs, masks, transparency, and fidelity controls); monitor task status; and finalize successful tasks by downloading results into the canvas.
API Key & Setup: Initiate a secure, short-lived setup flow to store the Modellix API key without exposing it in arguments or project files.
History & Cleanup: List redacted operation summaries for recovery and clean up temporary uploads after terminal tasks.
Integrates an Excalidraw infinite canvas, supporting text, shapes, lines, arrows, freehand drawing, frames, images, grouping, locking, layers, alignment, a project-persisted personal library, and undo/redo.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Modellix Agent Canvas create a presentation about the new product launch"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English · 简体中文
Modellix Agent Canvas is a local, workspace-bound stdio MCP plugin for visual AI work. It brings an Excalidraw infinite canvas, Modellix image generation and editing, paid-operation confirmation, durable task recovery, HTML drafts, presentations, and project-local persistence into one workspace.
It supports Codex, Cursor, Claude Code, OpenCode, and other applications that implement local stdio MCP. Hosts with MCP Apps can embed the complete canvas; other compatible hosts use the same MCP server through a short-lived loopback page. Canvas runs locally and does not require a deployed Canvas service.
These screenshots come from one real local Canvas session. The reproducible walkthrough uses the original local artwork in docs/images/demo/creative-studio.webp, so you can explore image editing, HTML capture, and presentations without first creating a paid image task.
The single Lumen Creative Direction story below verifies seven connected capabilities instead of showing unrelated examples:
Import a real local image as an ordinary canvas asset.
Turn the selection into the primary reference for a controlled image edit.
Inspect the routed model, effective specification, quantity, and price disclosure before any paid submission.
Edit HTML beside a CSP-restricted live preview and capture the rendered result back to Canvas.
Reuse the same visual direction in a five-slide presentation.
Play the deck in a clean full-screen sequence.
Export the page as PNG/SVG, export the deck as a PNG sequence, or back up and restore the project.
Drop an image onto the canvas or select a completed generation, then describe only the change you want. The selected image becomes the primary reference; output size, count, background, quality, and additional ordered references remain editable before preparation.
prepare_modellix_image_task is free. It shows the actual model, routing reason, requested and effective specifications, quantity, and the available price disclosure before a separate confirmation. This documentation run returned an unavailable quote, so no paid submission was made; do not confirm an unquoted task when you have a fixed budget.
Edit HTML source beside an isolated live preview, capture it back to the canvas, or export the source as a ZIP archive.
Create editable slide decks from several layouts, drop visual assets into ordinary slide elements, manage the sequence visually, present it, or export a PNG sequence.
The same image-led slide plays in the built-in presenter with previous/next controls and a visible slide count.
Export the current page at 1×, 2×, or 4× PNG, save SVG, download a presentation PNG sequence, or create and restore a project backup.
Install the plugin through one host path below, then open it in a real project workspace.
Call get_modellix_canvas_status and open_modellix_canvas with the same absolute workspace path.
Drop creative-studio.webp onto the canvas, select it, and enter an edit instruction.
Choose 16:9 · Landscape, click Prepare edit, and inspect the returned model, route, effective specification, quantity, and price disclosure. Preparation is free.
Confirm only when the disclosed total fits your budget. Otherwise choose Back to edit; the walkthrough does not require a paid submission.
Open HTML, save the isolated draft, and choose Create screenshot to insert the rendered result back into Canvas.
Open Presentation, create a starter deck, and drop the visual into a slide. Use Play or PNG sequence to finish.
Related MCP server: imagegen
Infinite canvas: text, shapes, lines, arrows, freehand drawing, frames, images, grouping, locking, layers, alignment, a project-persisted personal library, and action-level undo and redo.
Multi-page projects: create, rename, duplicate, reorder, and delete pages while preserving an independent viewport and history for every page.
Image placeholders: reserve a target area before generation; the selected result replaces the placeholder and remains undoable, while extra results are placed predictably beside it.
Image generation and editing: text-to-image, single-image editing, ordered 2–10 image references, an explicit primary reference, annotation-based editing, transparent backgrounds, fidelity controls, and 1–4 outputs.
Model-aware routing: the user states the creative requirement; prepare returns the selected model, routing reason, effective specification, limitations, and estimated total cost.
Paid-operation safety: prepare is free, submit requires an explicit one-time confirmation, duplicate work is locally deduplicated, and an unknown submission is never retried automatically.
Durable tasks: task IDs, state transitions, and local results are persisted in an append-only ledger, so work can continue after the host or browser closes.
HTML drafts: source editing, CSP-restricted sandbox preview, refresh, canvas capture, and source ZIP export.
Presentations: 16:9, 4:3, and custom ratios; title, content, image, comparison, and blank layouts; thumbnails, reordering, duplication, presentation mode, and PNG-sequence export.
Import and export: selected area or full-page PNG/SVG at 1×, 2×, or 4×, presentation PNG ZIP, and confirmed project JSON backup restore.
English, Chinese, and Japanese UI: English is the default. The language switch in the upper-right updates the Canvas, Excalidraw controls, and secure API Key form, and the choice is saved with the project.
Local security: credentials use the modellix-cli system credential store and are never written to chat, MCP arguments, URLs, project files, or task ledgers.
Node.js ^20.19.0 || >=22.12.0
Access to the production API at https://api.modellix.ai
A valid API Key from the Modellix console
Choose one installation path only. Codex, Cursor, and Claude users install once from the host's Git or Marketplace entry; the plugin loads its manifest and Skills and automatically resolves the pinned npm runtime in the background. OpenCode and generic MCP users add the npm-backed MCP once. Users never run a second npm or CLI installation command. The package includes the tested modellix-cli 0.0.8 runtime as an offline fallback. On the first CLI use of each MCP process, Canvas checks the public npm latest tag, atomically caches that exact CLI version in the user-local Modellix cache, and pins it for the rest of the process. A registry or compatibility failure falls back to the bundled version, so a CLI release cannot make the installed Canvas disappear. Set MODELLIX_CLI_AUTO_UPDATE=0 only when a deployment must remain on the bundled fallback. Existing valid CLI credentials are reused; otherwise the first-use prompt only asks for a Modellix API Key.
Optionally run npm exec --yes --package=@modellix/agent-canvas@0.1.17 -- modellix-agent-canvas --doctor from outside the source checkout to verify the published package's Node.js requirement, production dependencies, bundled Widget, and active version. This is a diagnostic, not a second installation path.
Install from the host's plugin interface whenever possible.
Install this repository or its npm package through any compatible Agent Plugins client. The portable core is the root plugin.json, mcp.json, and skills/ directory. The manifest and MCP configuration target the official 1.0.0 schemas; fixed-location discovery loads the three Agent Skills and the generic stdio server without relying on a host-specific manifest.
codex plugin marketplace add Modellix/modellix-agent-canvas
codex plugin add modellix-agent-canvas@modellixThe Git marketplace installs the plugin files from this repository. Its Codex adapter starts a single Node bootstrap process, installs the pinned npm runtime into a user-local cache on first use, and then imports the MCP server into that same process. Warm starts reuse the validated cache without retaining an npx wrapper process or requiring a global CLI installation.
Run the following command in Cursor:
/add-plugin modellix-agent-canvasFor a GitHub or local-checkout install, open Customize → Plugins → + Add and select the repository root. Cursor reads .cursor-plugin/marketplace.json, then offers Modellix Agent Canvas from the modellix personal marketplace. This is separate from the Open Plugins metadata submitted to Cursor Directory.
claude plugin marketplace add Modellix/modellix-agent-canvas
claude plugin install modellix-agent-canvas@modellixAfter enabling or upgrading the plugin, run /reload-plugins, then use /mcp to verify the connection.
Use the public npm package @modellix/agent-canvas. Ready-to-merge host configurations are included in this repository. See the complete installation guide for setup, verification, upgrades, uninstallation, and source development.
After installation, call:
get_modellix_canvas_status { "refresh": true, "workspacePath": "<absolute project path>" }
open_modellix_canvas { "workspacePath": "<the same absolute project path>" }If status is missing or invalid, Canvas displays a password input directly in its credential card. The field follows the language selected in the upper-right and is an isolated, one-time loopback form that expires after five minutes; submitting it validates the key through the bundled CLI, stores it in the system credential store, and automatically refreshes Canvas status. The Key never enters Canvas state or MCP tool arguments. start_modellix_api_key_setup remains available to integrations that need to obtain the same short-lived local form explicitly.
Host | Local MCP | Canvas surface | Configuration |
Agent Plugins 1.0.0 clients |
| Portable local-page fallback; MCP Apps metadata remains discoverable |
|
Codex |
| MCP Apps widget, with local fallback |
|
Cursor 2.6+ |
| MCP Apps |
|
Claude Code |
| Short-lived local page |
|
OpenCode | Local MCP command | Short-lived local page |
|
OpenCode V2 beta | Local MCP command | Short-lived local page |
|
Use the adapter intended for the target host. Root plugin.json and mcp.json form the portable Agent Plugins 1.0.0 core. .plugin/plugin.json and .mcp.json remain the legacy Open Plugins entry for Cursor Directory and the Cursor-specific MCP Apps adapter. The Codex manifest embeds its own server configuration and .mcp.codex.json mirrors it for direct development. See host compatibility for protocol mappings, host-specific UI behavior, and validation status.
The Cursor-specific .mcp.json runs:
npx -y --package @modellix/agent-canvas@0.1.17 modellix-agent-canvas --host cursor --supports-mcp-apps trueThe template does not contain an API Key. Cursor supplies the active workspace through MCP Roots; the template intentionally avoids unportable ${workspaceFolder} interpolation.
claude mcp add --transport stdio modellix-agent-canvas -- node /absolute/path/modellix-agent-canvas/scripts/start-mcp.mjs --host claude-code --supports-mcp-apps false --project-dir /absolute/path/to/projectFor the stable OpenCode release, merge mcp.modellix-agent-canvas from adapters/opencode/opencode.json into the project configuration. OpenCode V2 beta users should instead merge mcp.servers.modellix-agent-canvas from adapters/opencode/opencode-v2.json. Both adapters start @modellix/agent-canvas@0.1.17 from the active workspace and use the local page fallback.
Credential resolution is deliberately simple:
Check the credentials already persisted by modellix-cli.
Reuse a valid credential when available.
Otherwise, enter a key in the isolated setup field embedded in the Canvas credential card.
Do not place a key in chat, tool arguments, command-line arguments, repository files, screenshots, project backups, or task reports. Canvas does not store keys in localStorage, sessionStorage, or IndexedDB.
Prompts and input images are sent to Modellix only after the user confirms the paid task. Prepare reads model capability and pricing data but does not upload references or create a paid task. Completed outputs are downloaded immediately into project assets, avoiding dependence on expiring remote result URLs.
Requirement | Default capability route |
Standard opaque text-to-image | GPT Image 2 |
Transparent text-to-image | GPT Image 1.5 |
Standard single-image editing | GPT Image 2 Edit |
Transparent, strict-fidelity, or standard multi-image editing | GPT Image 1.5 Edit |
Multi-reference editing with special ratios or 2K/4K output | Nano Banana Pro Edit |
The production API supplies the current model catalog, capabilities, and price. Canvas selects only from approved candidates. If no model satisfies every hard requirement, it returns CAPABILITY_CONFLICT or MODEL_UNAVAILABLE instead of silently degrading or creating a paid task.
The paid workflow is:
prepare_modellix_image_task resolves ordered references, selects a model, and returns a short-lived confirmation fingerprint.
The UI or agent displays the actual model, routing reason, effective specification, quantity, warnings, and estimated total cost.
After explicit user approval, submit_modellix_image_task submits the unchanged intent with the same fingerprint.
get_modellix_image_task polls only registered tasks. SUBMISSION_UNKNOWN is query-only and must never trigger an automatic resubmission.
finalize_modellix_image_task validates downloads, writes content-addressed assets, and places results at the placeholder or beside the source.
The agent-facing workflow uses:
get_modellix_canvas_status
start_modellix_api_key_setup
open_modellix_canvas
get_canvas_context
create_canvas_page, rename_canvas_page, and delete_canvas_page
prepare_modellix_image_task
submit_modellix_image_task
get_modellix_image_task
list_modellix_canvas_tasks
finalize_modellix_image_task
cleanup_modellix_canvas_uploads, which requires confirmCleanup: true and affects only terminal temporary uploads recorded in the ledger
get_canvas_project, save_canvas_project, and save_canvas_asset are app-only MCP Apps data channels. They keep large scene JSON and base64 assets out of model context. Every tool returns stable error codes, retryability, and recovery guidance.
Each bound workspace stores data under:
.modellix/canvas/
├── project.json
├── pages/<page-id>.json
├── assets/
│ ├── images/
│ ├── html/
│ └── exports/
├── tasks/
│ ├── snapshot.json
│ ├── events.jsonl
│ └── staging/
├── recovery/
└── locks/Images are SHA-256 content-addressed and deduplicated; page JSON stores relative asset IDs.
Project and page writes use temporary files, flush, atomic replacement, and revision conflict checks.
Recovery snapshots are created before writes; an older build never overwrites an unknown schema version in place.
Real-path, symbolic-link, junction, and workspace-boundary checks protect every file operation.
Task ledgers exclude API Keys, full prompt text, input images, remote temporary URLs, and absolute local paths.
The fallback page listens only on 127.0.0.1 with an ephemeral system-assigned port and enforces:
A one-time high-entropy open token and short-lived HttpOnly; SameSite=Strict session
Host, Origin, HTTP method, Content-Type, and request-size validation
Strict CSP, no-store, no-referrer, and nosniff
No remote scripts, fonts, analytics, or general-purpose file proxy
HTML drafts run in a separate sandboxed iframe with its own CSP. External networking, top-level navigation, pop-ups, downloads, device permissions, and host APIs are disabled by default.
npm ci
npm run sync:skills
npm run check
npm run check:licenses
npm run check:plugin
npm test
npm run build
npm run build:widget
npm run probe:mcp
npm audit --audit-level=moderatenpm run quality runs the complete local gate except npm audit and the real packed-install smoke test. npm run smoke:package installs the publishable package with lifecycle scripts disabled and probes the complete MCP.
Before release, use npm pack --dry-run to confirm that the package contains no QA origin, internal acceptance material, absolute path, test credential, or obsolete resource.
WORKSPACE_UNBOUND: provide the active project's absolute workspacePath, or restart MCP from the actual user project with --project-dir.
WORKSPACE_BOUNDARY_VIOLATION: a path or linked target resolved outside the bound workspace.
AUTH_REQUIRED / AUTH_INVALID: use or regenerate the secure input inside the credential card; do not send the key through chat.
ROUTE_CHANGED_RECONFIRM_REQUIRED: an input, reference order, specification, price, or expiry changed; prepare and confirm again.
SUBMISSION_UNKNOWN: do not resubmit; continue polling the existing operation from the task center.
FINALIZE_CONFLICT: inspect whether the intended target moved or was deleted, then choose a recovery location.
REVISION_CONFLICT: another session updated the project; reload before reapplying the current change.
No marketplace manifest found: when using Customize → Plugins → + Add, select the repository root containing .cursor-plugin/marketplace.json; loading a standalone plugin for development uses ~/.cursor/plugins/local/modellix-agent-canvas instead.
Host-specific commands are documented in Upgrade and uninstall. Upgrading does not delete .modellix/canvas/. Uninstalling also preserves workspace data and system credentials, preventing accidental deletion of keys shared by other Modellix tools. To remove a credential, run modellix-cli auth logout for the corresponding profile.
Project-owned code is available under the MIT License. The canvas engine uses @excalidraw/excalidraw 0.18.1 under MIT; the bundled modellix-cli 0.0.8 fallback and an automatically cached newer CLI retain their own package license and metadata. See THIRD_PARTY_NOTICES.md and THIRD_PARTY_LICENSES.
Retry deletion of temporary File API inputs retained after terminal image tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes | ||
| confirmCleanup | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| operationId | No | |
| deletedCount | No | |
| remainingCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive (destructiveHint=true) and idempotent (idempotentHint=true) behavior. The description adds contextual detail about 'temporary' inputs and 'retry' semantics, which complements the annotations. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no redundant words. It conveys purpose and context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose and an output schema, but the description omits parameter explanations and explicit confirmation/safety details. While annotations and schema cover some aspects, the 0% parameter coverage leaves gaps in understanding what operationId refers to and why confirmCleanup is required. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention operationId or confirmCleanup at all. The schema only provides structural constraints (length, const) without semantic meaning. The description fails to compensate for the low coverage, leaving parameter semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retry deletion') and the target resource ('temporary File API inputs retained after terminal image tasks'). It is specific and distinguishes this tool from sibling tools like get_canvas_project or delete_canvas_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when temporary File API inputs are retained after terminal image tasks and need retry deletion. It provides clear context but does not explicitly state alternatives or exclusions, though the context is sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and activate a new workspace-local Canvas page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| name | No | |
| error | No | |
| order | No | |
| pageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Create and activate a new' which contradicts the annotation idempotentHint=true, as creating a new page each time would not be idempotent. This is a direct conflict, so the description fails to align with the annotation and receives the minimum score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and object. No unnecessary words or repetition, making it appropriately sized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits critical details: the meaning of 'activate' and whether 'name' is required. The idempotentHint annotation suggests important behavior not reflected in the description. It does not fully inform the agent on how to invoke the tool correctly, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'name' with no description coverage, and the tool description does not mention the parameter or its optionality. Since schema coverage is 0%, the description should compensate, but it provides no additional meaning about the parameter's purpose or behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Create and activate' and clearly identifies the resource as a 'new workspace-local Canvas page.' This distinguishes it from sibling tools like rename_canvas_page or delete_canvas_page, which imply different actions on existing pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new page, and 'workspace-local' provides some context. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, such as not using it for existing pages or when certain conditions apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Canvas page while preserving the rule that every project has at least one page.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| pageId | No | |
| activePageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral constraint beyond the annotations: it guarantees the 'at least one page' rule is preserved. This is meaningful context not captured by the idempotentHint or destructiveHint annotations. It does not mention what happens when violation is attempted, but the rule itself is transparent enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Delete a Canvas page') and adds the key constraint. No filler or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with annotations and an output schema, the description is largely complete. It explains the core purpose and the important invariant. It could detail edge-case behavior (e.g., what happens if you try to delete the last page), but given the simple interface and available annotations, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate for parameter meaning. It does not mention pageId at all, leaving the agent to infer from the parameter name and tool name. While pageId is fairly self-explanatory, the description adds no explicit semantics or guidance on how to obtain or format it, which is a notable gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'Canvas page', and adds a critical scoping rule ('preserving the rule that every project has at least one page') that distinguishes it from sibling tools like create_canvas_page and rename_canvas_page. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool can be used: deleting a page while respecting the 'at least one page' invariant. This implicitly tells the agent that deletion is not allowed if it would leave zero pages. It doesn't explicitly mention alternatives, but the rule itself is a strong usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a successful task into controlled staging, insert or replace Canvas objects, persist project assets, and clean temporary uploads.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| confirmTargetOverride | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| bounds | No | |
| taskId | No | |
| objectIds | No | |
| elementIds | No | |
| localAssets | No | |
| alreadyFinalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable specifics: 'controlled staging', 'insert or replace', 'persist project assets', and 'clean temporary uploads', giving the agent a clear mental model of what side effects occur. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, dense sentence with a clear sequence of actions. Every phrase carries meaning, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description sufficiently outlines the tool's multi-phase behavior. It does not elaborate on failure cases or the 'confirmTargetOverride' parameter, but the main purpose is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level details. While 'taskId' is self-explanatory, 'confirmTargetOverride' is completely unexplained, forcing the agent to guess its meaning. The description focuses on overall actions rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly enumerates concrete actions (download, insert/replace, persist, clean) and resources (successful task, Canvas objects, project assets, temporary uploads), making it distinct from sibling tools like submit or get. The verb 'finalize' is not used, but the multi-step language unambiguously establishes this as the completion step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Download a successful task' sets an explicit precondition, implying this tool is for post-success finalization. It does not name alternatives or say when not to use it, but the context is clear enough for an agent to select it as the finalization step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the active page and selected Canvas business objects without returning image bytes or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| detailLevel | No | selection |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| pages | No | |
| projectId | No | |
| selection | No | |
| projectName | No | |
| activePageId | No | |
| elementCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a meaningful output constraint: it will not return image bytes or secrets. This is beyond what annotations provide and helps the agent avoid unexpectedly large or sensitive payloads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 14 words, front-loaded with the verb 'Return'. Every phrase adds value: the resource, the scope, and the exclusion. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with output schema and full annotations, the description covers core functionality and includes an important exclusion. However, it lacks explicit usage guidance and does not explain the detailLevel parameter, leaving the agent without enough information to choose an effective level. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter detailLevel is not mentioned in the description. The schema has an enum but does not explain what each level means, and with 0% schema coverage, the description does not compensate. The agent cannot reason about the difference between summary, selection, and page levels, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: it states the tool returns active page and selected Canvas business objects, using a concrete verb and resource. It distinguishes from sibling tools like get_canvas_project and page manipulation tools by focusing on context retrieval. The negative clause about image bytes and secrets reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when the agent needs the current canvas context without heavy or sensitive data. It clearly excludes image bytes and secrets, suggesting it is a lightweight alternative, but it does not explicitly name alternatives or state when not to use it. This is clear context without direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the workspace-local Canvas project, pages, Excalidraw elements, business metadata, and optionally hydrated image data.
| Name | Required | Description | Default |
|---|---|---|---|
| hydrateFiles | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| name | No | |
| error | No | |
| pages | No | |
| projectId | No | |
| activePageId | No | |
| schemaVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description is consistent with these. It adds useful context by clarifying the workspace-local scope and the optional hydration of image data. It does not describe auth or rate limits, but the safety profile is well covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the object. It contains no filler or redundant information, earning its place with every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter, an output schema present, and strong safety annotations, the description covers the core read behavior adequately. It identifies the main returned content categories and the optional image data. It could be slightly more complete by addressing alternative sibling tools, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, hydrateFiles, has no description in the schema (0% coverage). The description's phrase 'optionally hydrated image data' hints at the parameter's role but does not explicitly state how hydrateFiles affects the response or what true/false values do. It provides some meaning but leaves room for inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Read' and identifies the exact resource: the 'workspace-local Canvas project.' It enumerates the contents (pages, Excalidraw elements, business metadata, optionally hydrated image data), making the tool's purpose very clear. It also distinguishes this tool from siblings like get_canvas_context by specifying it reads the whole project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for reading project data, but it does not explicitly state when to choose this tool over alternatives such as get_canvas_context or get_modellix_canvas_status. There are no exclusions or when-not-to-use scenarios, leaving usage guidance solely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check workspace binding, CLI dependency compatibility, persistent API-key status, approved models, and Canvas mode without exposing secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| workspacePath | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| host | No | |
| error | No | |
| profile | No | |
| canvasMode | No | |
| cliVersion | No | |
| workspaceId | No | |
| baseUrlOrigin | No | |
| cliCompatible | No | |
| routerVersion | No | |
| approvedModels | No | |
| workspaceBound | No | |
| credentialState | No | |
| recoveryActions | No | |
| supportsMcpApps | No | |
| credentialSource | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations by explicitly stating that it checks 'persistent API-key status' and does so 'without exposing secrets' — a key safety guarantee for an agent handling credentials. This goes beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly structured sentence that front-loads the action and lists all checked items without unnecessary words. It is appropriately sized and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main aspects of the tool's behavior (what it checks and the secrecy guarantee), and the presence of an output schema removes the need to describe return values. However, it omits parameter semantics and usage context, leaving minor gaps for a moderately complex status-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. However, it makes no mention of 'refresh' or 'workspacePath' or their semantics. The parameter names are somewhat self-explanatory, but 'refresh' is ambiguous (e.g., whether it forces a re-check) and no additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check') and enumerates the exact set of statuses it retrieves (workspace binding, CLI dependency compatibility, persistent API-key status, approved models, Canvas mode). This differentiates it from sibling tools like get_canvas_project or get_canvas_context, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or context for invoking it. The description simply states what it checks, leaving the agent to infer appropriate 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.
Query one task recorded in this workspace and return normalized status without exposing temporary result URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| status | No | |
| taskId | No | |
| resourceCount | No | |
| resultExpiresAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it normalizes the status and hides temporary result URLs, which goes beyond the basic safety profile. It does not detail error handling, but that is not required given the strong annotations and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and key behavioral trait. Every word adds value, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description needn't explain return values. It covers the core functionality and adds the important privacy behavior. However, it does not place the tool within the broader Modellix workflow (e.g., how it relates to prepare/submit/finalize steps), though this is a minor gap for a simple read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden for parameter meaning. It implies that taskId identifies a task recorded in the workspace, but adds minimal detail about the parameter's format or source. Since there is only one parameter and the schema includes a pattern, this is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query', the resource 'one task recorded in this workspace', and the specific behavior 'return normalized status without exposing temporary result URLs'. This distinguishes it from sibling tools like list_modellix_canvas_tasks and get_modellix_canvas_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for querying a single task's normalized status, and the phrase 'without exposing temporary result URLs' implies a use case where URL privacy matters. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List redacted workspace-local operation summaries for recovery. Prompts, secrets, absolute paths, and temporary URLs are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| total | No | |
| cursor | No | |
| nextCursor | No | |
| operations | No | |
| schemaVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds meaningful context about redaction (omitting prompts, secrets, absolute paths, temporary URLs) and the workspace-local scope, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('List redacted workspace-local operation summaries for recovery') and then adds necessary detail about omissions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema, the description is minimally adequate. However, it lacks parameter semantics and usage guidance, and does not explain how limit/cursor/status affect the listing. The presence of an output schema helps but does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the parameters (limit, cursor, status). The description does not compensate for the complete lack of parameter information in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'redacted workspace-local operation summaries for recovery,' which is a specific verb and resource. It does not explicitly distinguish from sibling tools, but the 'redacted' and 'workspace-local' qualifiers give it a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of 'for recovery' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives like get_canvas_context or get_modellix_canvas_status. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the workspace-bound Canvas. MCP Apps hosts receive the embedded app; other compatible MCP hosts receive a short-lived loopback URL.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | No | ||
| workspacePath | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| mode | No | |
| error | No | |
| pageId | No | |
| widget | No | |
| localUrl | No | |
| workspaceId | No | |
| preferredDisplayMode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety expectations. The description adds valuable behavioral context about host-specific outputs (embedded app vs. loopback URL) and the workspace-bound scope, which goes beyond the annotations. It does not detail potential side effects, but none are expected for a read-only, idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the primary action and then clarify host-specific behavior. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations plus an output schema, the description provides adequate high-level context (host-specific output behavior). However, it omits parameter semantics and does not clarify how 'open' translates to a user action in each host context, leaving some gaps for an agent to fully invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two parameters (pageId, workspacePath) or how they affect behavior. The phrase 'workspace-bound' hints at workspacePath, but this is insufficient. With two parameters and no schema descriptions, the description fails to compensate, leaving parameter semantics largely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open the workspace-bound Canvas.' It uses a specific verb ('open') and resource ('Canvas'), and distinguishes itself from siblings like get_canvas_project or save_canvas_page by focusing on launching/displaying the canvas rather than managing its contents or metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Open the workspace-bound Canvas') but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. However, the host-specific behavior hints at when it applies, giving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve ordered project assets, select an approved model, disclose effective output and estimated cost, and return a short-lived confirmation fingerprint. Does not upload or submit.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| size | No | 1024x1024 | |
| count | No | ||
| pageId | No | ||
| prompt | Yes | ||
| quality | No | medium | |
| fitPolicy | No | contain | |
| background | No | auto | |
| placementX | No | ||
| placementY | No | ||
| maskAssetId | No | ||
| inputFidelity | No | standard | |
| sourceAssetIds | No | ||
| targetObjectId | No | ||
| sourceObjectIds | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| pricing | No | |
| expiresAt | No | |
| modelSlug | No | |
| taskCount | No | |
| inputDigest | No | |
| routerVersion | No | |
| modelAvailable | No | |
| referenceCount | No | |
| effectiveOutput | No | |
| requestedOutput | No | |
| routeReasonCode | No | |
| modelDisplayName | No | |
| routeFingerprint | No | |
| routerFingerprint | No | |
| capabilityWarnings | No | |
| effectiveModelParams | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: it resolves assets, selects an approved model, discloses cost, and returns a short-lived fingerprint. It also explicitly states it does not upload or submit, which clarifies the side-effect profile. No contradictions; the extra disclosure enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and includes a crucial negative constraint ('Does not upload or submit'). Every sentence adds value with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the tool is highly complex with 15 parameters and 5 enums. The description only covers high-level purpose and does not explain prerequisites, how to set parameters, or how this step chains with sibling tools (beyond not submitting). An agent would struggle to invoke this correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description carries full responsibility for parameter guidance, but it only gives vague hints like 'ordered project assets' and 'approved model' without mapping to specific parameters. It does not explain required fields (prompt, mode) or optional ones (size, count, fitPolicy, etc.), leaving agents without enough detail to correctly populate the 15-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it resolves assets, selects an approved model, discloses output/cost, and returns a short-lived fingerprint. The explicit 'Does not upload or submit' distinguishes it from sibling submission tools, making its role as a preparation step unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a pre-submission step by stating it does not upload or submit, which signals that a separate submission tool is needed. However, it does not explicitly name alternatives like 'submit_modellix_image_task', relying on sibling names for context. Clear when-to-use context is present, but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing Canvas page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| pageId | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| name | No | |
| error | No | |
| pageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds only that it operates on an existing page, offering minimal extra behavioral context but not contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for a simple tool and does not repeat schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with annotations and an output schema, the description is minimally adequate. It states the core purpose but lacks usage guidance and context about side effects or naming rules, making it complete only at a basic level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention 'pageId' or 'name' at all. Property names and constraints imply the semantics, but the description adds no explicit meaning or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('rename') and resource ('existing Canvas page'), distinguishing it from sibling tools like create_canvas_page and delete_canvas_page. It is a direct, non-tautological statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no exclusions. The word 'existing' implies a precondition but does not explicitly say when to choose this over create or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a bounded bitmap or sanitized SVG as a content-addressed project asset for later Canvas or image-task use.
| Name | Required | Description | Default |
|---|---|---|---|
| fileName | No | ||
| mimeType | Yes | ||
| dataBase64 | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| size | No | |
| error | No | |
| width | No | |
| height | No | |
| assetId | No | |
| mimeType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include idempotentHint=true and readOnlyHint=false. The description adds behavioral context by noting the content-addressed nature (implied idempotency) and the input constraints ('bounded bitmap or sanitized SVG'), which enhances understanding beyond the structured data. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loaded with the action, and contains no filler. Every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations present, the description doesn't need to explain return values. However, the 0% schema coverage and lack of parameter details leave gaps about the exact encoding requirements and optionality, while the phrase 'sanitized SVG' is ambiguous as to whether sanitization is performed or assumed. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only loosely hints at input types via 'bounded bitmap or sanitized SVG' and does not explain fileName's role or how dataBase64 should be encoded. The schema carries the burden, but the description adds minimal parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and identifies the exact resource ('bounded bitmap or sanitized SVG' as a 'content-addressed project asset'), clearly distinguishing it from sibling tools like save_canvas_project by focusing on asset-level storage rather than project-level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this tool is for storing assets intended for later Canvas or image-task use, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, such as 'for whole projects, use save_canvas_project'. Thus it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atomically save a validated Canvas project inside the bound workspace. Image data is externalized into content-addressed local assets.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| revision | No | |
| pageCount | No | |
| projectId | No | |
| updatedAt | No | |
| activePageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond the annotations: atomicity (all-or-nothing save), validation of the project, and externalization of image data to content-addressed assets. These are not covered by the annotations and do not contradict them, enhancing the agent's understanding of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action ('Atomically save a validated Canvas project'). Every sentence adds meaningful information without unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested project parameter and zero schema coverage, the description lacks structural detail and validation specifics. However, the existence of an output schema and annotations partially compensates, making the description moderately complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'project' parameter, and the description only refers to a 'validated Canvas project' without specifying its structure, required fields, or validation criteria. This is insufficient guidance for an agent to construct a valid parameter object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool atomically saves a validated Canvas project within the bound workspace, using a specific verb ('save') and resource ('Canvas project'). It effectively distinguishes itself from sibling tools like save_canvas_asset, which saves individual assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for saving a whole project, but it does not explicitly state when to use it versus alternatives or provide exclusions. The mention of 'validated' suggests a precondition, but no alternative tools are named or contrasted, leaving usage guidelines implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a short-lived loopback form that validates and stores a Modellix API key through the installed CLI dependency. Create a production key at https://www.modellix.ai/console/api-key. The key is never a tool argument.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| setupUrl | No | |
| expiresAt | No | |
| apiKeyPageUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no hints), so the description carries the burden. It discloses that the tool creates a 'short-lived loopback form,' validates and stores the key, and emphasizes 'The key is never a tool argument.' This goes beyond the empty annotations and gives important safety-relevant behavior. It does not mention all potential side effects (e.g., file system changes), but it provides meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, yet it packs the core action, a prerequisite URL, and a critical safety constraint. It is front-loaded with the primary action and contains no filler. Every sentence earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description defines the tool's mechanics, it lacks explicit context about when to invoke it relative to other Modellix tools (e.g., 'run before any canvas task') and what the agent should do after the loopback form is created (e.g., interactive steps). An output schema exists, so return values are covered, but the overall workflow context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'language' with an enum, but no description. The tool description does not mention this parameter at all, and schema description coverage is 0%. Thus, the agent receives no guidance on what values mean or how to choose them. Since the parameter is optional and simple, this is a moderate gap but still a failure to clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 a short-lived loopback form that validates and stores a Modellix API key through the installed CLI dependency.' This uses a specific verb and resource, and the added note 'The key is never a tool argument' further clarifies its unique behavior. It is easily distinguished from sibling tools, which all focus on canvas operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Create a production key at https://www.modellix.ai/console/api-key.' It also implicitly indicates when to use this tool (for API key setup) by its name and content, and explicitly warns against passing the key as an argument. However, it does not explicitly contrast with alternatives or state when not to use it, though the sibling set makes the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After explicit confirmation, revalidate the route, upload ordered inputs, and create one paid Modellix task per requested output.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| size | No | 1024x1024 | |
| count | No | ||
| pageId | No | ||
| prompt | Yes | ||
| quality | No | medium | |
| fitPolicy | No | contain | |
| background | No | auto | |
| placementX | No | ||
| placementY | No | ||
| maskAssetId | No | ||
| operationId | No | aba3a81b-b7c7-499b-9ba9-e1248e83eb87 | |
| inputFidelity | No | standard | |
| sourceAssetIds | No | ||
| targetObjectId | No | ||
| sourceObjectIds | No | ||
| routeFingerprint | Yes | ||
| confirmedPaidSubmission | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| tasks | No | |
| modelSlug | No | |
| operationId | No | |
| routeReasonCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false, openWorld=true, idempotent=false, destructive=true. The description adds valuable context by mentioning the task is 'paid' (financial side effect), requiring 'explicit confirmation' (safety guard), and 'revalidate the route' (prerequisite check), which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the condition 'After explicit confirmation,' and every phrase contributes to the meaning. It is somewhat dense with three sequential actions but contains no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 parameters, 4 required, 0% schema documentation), this description is inadequate. It does not explain the workflow relationship to prepare/finalize tools, what 'revalidate the route' entails, how confirmation is expressed, or the cost implications of a 'paid' task. The output schema exists but does not cover prerequisites or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. It only vaguely references 'route' (likely routeFingerprint), 'inputs' (possibly sourceAssetIds), and 'requested output' (maybe count), but does not explain the 18 parameters, including required ones like prompt, mode, or confirmedPaidSubmission. This leaves substantial ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: after confirmation, it revalidates the route, uploads inputs, and creates one paid Modellix task per requested output. This distinguishes it from sibling tools like prepare_modellix_image_task and finalize_modellix_image_task by implying submission as the final step, though the phrasing is somewhat convoluted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies it should be used 'after explicit confirmation' and includes actions like revalidating the route and uploading ordered inputs, implying it is the submission step in a workflow. However, it does not explicitly name alternatives or exclusion criteria, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.16cleanup_modellix_canvas_uploadscreate_canvas_pagedelete_canvas_pagefinalize_modellix_image_taskget_canvas_contextget_canvas_projectget_modellix_canvas_statusget_modellix_image_tasklist_modellix_canvas_tasksopen_modellix_canvasprepare_modellix_image_taskrename_canvas_pagesave_canvas_assetsave_canvas_projectstart_modellix_api_key_setupsubmit_modellix_image_taskMost tools have clearly distinct purposes: project read/save, page CRUD, asset saving, status/API setup, and image task lifecycle. The only potential confusion is between get_canvas_project and get_canvas_context, which both retrieve canvas data but differ in scope (full project vs. active page/selection).
All tool names follow a consistent verb_noun pattern in snake_case (get, save, create, rename, delete, start, open, prepare, submit, finalize, cleanup, list). The inclusion of 'modellix' and 'canvas' modifiers is logical and consistent throughout.
With 16 tools, the count is slightly above the typical 3-15 range, but each tool serves a distinct and necessary function in the canvas management and image task workflow. No tool feels redundant, so the count is well-justified.
The tool surface covers the full lifecycle: project read/write, page CRUD, asset management, status/API setup, and image task preparation, submission, status query, finalization, and cleanup. The only missing operation is project deletion, but that may be intentionally out of scope for a workspace-bound canvas.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
The back-office workspace for your team's AIs: tasks, knowledge and context shared over MCP.
Creative workspace. Public MCP: outline previews for Codex and Claude Code; media in the web app.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Modellix/modellix-agent-canvas'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
