Modellix Agent Canvas

Official

by Modellix

Overview Schema Related Servers Score Discussions

Local

Server Quality Checklist

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

Latest release: v0.1.16
Disambiguation4/5
Most 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).
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.8/5 across 16 of 16 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![modellix-agent-canvas MCP server](https://glama.ai/mcp/servers/Modellix/modellix-agent-canvas/badges/card.svg)](https://glama.ai/mcp/servers/Modellix/modellix-agent-canvas)

Score Badge

Copy to your README.md:

[![modellix-agent-canvas MCP server](https://glama.ai/mcp/servers/Modellix/modellix-agent-canvas/badges/score.svg)](https://glama.ai/mcp/servers/Modellix/modellix-agent-canvas)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Modellix/modellix-agent-canvas'

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