Simpler.Asia

edit_project_update

Save changes to an existing canvas project by id — the autosave door: send only the fields that changed (name, canvas_json, width, height, thumbnail_data_url), everything else on the row is left alone. A canvas_json you send goes through the same image-externalization and hygiene refusal as edit_project_create (embedded images become R2 keys; SVG, unrecognized types, oversized images, or a still-too-large canvas refuse the whole save). version is bumped by the door itself on every save and thumbnail_key is server-minted from thumbnail_data_url — both refuse if you pass them directly. NEXT: edit_project_read to confirm the saved version.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "edit_project_update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The edit_project id (edit_project_list shows them).
`name`	No
`width`	No
`height`	No
`version`	No
`canvas_json`	No
`thumbnail_key`	No
`thumbnail_data_url`	No	Optional thumbnail as a data: URL (PNG/JPEG/WebP/GIF, max 2MB) — externalized into thumbnail_key the same way embedded canvas images are. Omit to skip thumbnail externalization (create: no thumbnail_key is set; update: the existing thumbnail_key is left unchanged).
`expected_updated_at`	No	Optional compare-and-set guard: the updated_at you last read. Mismatch returns CONFLICT with the current value.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: version is bumped server-side on every save, thumbnail_key is server-minted from thumbnail_data_url, and both refuse if passed directly. It also discloses that image externalization and hygiene checks can reject the entire save (atomic failure mode) — exactly the kind of consequence an agent needs before invoking a mutation. Consistent with destructiveHint=false and idempotentHint=false (each save bumps version).

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?

Front-loads the core action and the partial-update contract in the first clause, then layers refusal rules, then the next step. Dense with em-dashes but every sentence carries information; slightly packed for a single paragraph, though nothing is redundant.

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 mutation tool with no output schema, this covers the important unknowns: partial-update semantics, atomic rejection modes, server-managed fields, and how to verify the result (read back for version). It stops short of describing what the save returns, but the pointer to edit_project_read covers the verification need.

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

Parameters4/5

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

Schema coverage is only 33%, and the description compensates by naming the mutable fields, explaining that unlisted fields are left untouched, clarifying the canvas_json externalization path, and flagging the two parameters that will be refused if supplied. It leaves expected_updated_at (the compare-and-set guard) undocumented in prose, so coverage of the 9 params is good but not complete.

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?

States a specific verb and resource ('Save changes to an existing canvas project by id') and immediately frames the tool's role as 'the autosave door', which distinguishes it from edit_project_create (new rows), edit_project_read (inspection) and edit_project_list (discovery). An agent can route correctly without opening the schema.

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?

Explicitly instructs to 'send only the fields that changed' and names edit_project_create as the reference point for canvas_json hygiene and edit_project_read as the follow-up step. It doesn't spell out the inverse case ('use create for new projects' or 'use delete to remove'), so routing is strongly implied rather than fully enumerated.

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

All Simpler.Asia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?