EaseWeb

Change blocks on several slides

edit_slides

Change blocks on many slides in one step (and one version in the history). "edits" is a list of {"slide_id", "add", "update", "delete", "at_bottom", "base_version"}; on its slide each item adds new blocks ("add": [{"type", "props"}], on top or with "at_bottom": true under the others), changes the given props of blocks ("update": [{"id" | "ids": [...] | "inside": , "props"}]) and deletes blocks ("delete": [ids]). Nothing is changed when one item is wrong (or its slide changed meanwhile). Returns the changed slides.

Input Schema

Name	Required	Description
`slug`	Yes	The presentation's slug (its address: /movie/<slug>/).
`edits`	Yes	Up to 100 items: [{"slide_id", "add"?, "update"?, "delete"?, "at_bottom"?, "base_version"?}].
`response`	No	"brief" (default): only the ids, numbers and types of the slides and blocks; "full": every prop of every block too.

Output Schema

Name	Required	Description
`slides`	Yes	The changed slides.
`layout_warnings`	No	How the changed slides will probably look: texts too long for their blocks, blocks outside the slide, texts over each other (estimated -- look at them).
`missing_translations`	No	What is not translated yet into the other languages of the site (add it): the first ones; "missing_translations_count" says how many there are.
`missing_translations_count`	No	How many texts are not translated yet.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026
- changedOutput schema / properties / slides / items / properties / objects / items / properties / type / description
```
Previous value: -"text, shape, button, line, image or code."New value: +"text, shape, button, line, image, code or table."
```

Changed4 schema fields changedOct 23, 2026

addedOutput schema / properties / layout_warnings / items / properties / lang

Added value: +{
+  "description": "Only the text in this language has the problem.",
+  "type": "string"
+}

addedOutput schema / properties / missing_translations / items / properties / outdated

Added value: +{
+  "description": "There is a translation, written for an earlier text.",
+  "type": "boolean"
+}

addedOutput schema / properties / slides / items / properties / layout_warnings / items / properties / lang

Added value: +{
+  "description": "Only the text in this language has the problem.",
+  "type": "string"
+}

addedOutput schema / properties / slides / items / properties / missing_translations / items / properties / outdated

Added value: +{
+  "description": "There is a translation, written for an earlier text.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 19, 2026

addedOutput schema / properties / slides / items / properties / notes

Added value: +{
+  "description": "The speaker notes (for those who may edit; only when there are some).",
+  "type": "string"
+}

AddedOct 17, 2026

TDQS

A4/5.0

Behavior4/5

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

The description goes meaningfully beyond the annotations: it discloses all-or-nothing atomicity ('Nothing is changed when one item is wrong'), optimistic concurrency via 'base_version' and the 'slide changed meanwhile' check, that exactly one history version is produced, and that changed slides are returned. Annotations only declare the generic non-readOnly/non-destructive/non-idempotent profile, so this added context is real value.

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-loaded with the batch+versioning purpose, then the payload contract, then the failure semantics and return value — a good information order. It is dense and slightly run-on with nested parentheticals, and the opening sentence trails into a fragment before the spec begins.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the risky behaviors an agent must know before calling a mutation tool: atomic failure, stale-write protection, history side effect, and return shape. With an output schema present it does not need to enumerate return values, and the 'response' enum is documented in the schema, so the remaining gap is only the missing sibling comparison.

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

Parameters5/5

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

Schema coverage is 100%, but the 'edits' items are declared only as untyped objects, so the description carries the entire payload contract: the add/update/delete/at_bottom/base_version keys, the 'add' block shape {type, props}, top-vs-bottom placement, and the three update targeting forms ('id', 'ids', 'inside' with a card block id). That is substantive meaning the schema does not provide.

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?

States a concrete verb and resource ('change blocks on many slides') and adds the batch/versioning framing, which distinguishes it from single-block editing. It never names its closest siblings (edit_blocks, update_slide), so the differentiation is implicit rather than explicit.

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?

Usage is implied through the batching semantics and the atomicity guarantee, which tells an agent this is the right tool when multiple slides must change together or not at all. However, there is no explicit 'use this instead of edit_blocks/update_slide when...' routing, which is exactly what an agent needs among 50 siblings.

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

All EaseWeb 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?