EaseWeb

Get some slides for editing

get_slides

Read-onlyIdempotent

Some slides of a presentation you can see, with their blocks (ids and complete props) -- a part of a big presentation: "from_number" / "to_number" (1-based, inclusive) and/or "slide_ids"; "texts_only": true gives only the words of the blocks (html, tr, code), no geometry. Every slide has a "version": pass it as "base_version" when you change the slide. The answer also has the presentation's "version" and "slides_total".

Input Schema

Name	Required	Description
`slug`	Yes	The presentation's slug (its address: /movie/<slug>/).
`slide_ids`	No	Only these slides (ids).
`to_number`	No	Only the slides up to this number (inclusive).
`texts_only`	No	Only the texts of the blocks (for reading, checking or translating), not their props.
`from_number`	No	Only the slides from this number on (1-based).

Output Schema

Name	Required	Description
`id`	Yes
`url`	No	The address people open in a browser.
`lang`	No	The language its texts are written in; "tr" holds the others.
`slug`	Yes	The address of the presentation: /movie/<slug>/.
`owner`	No	User name of the author.
`theme`	No
`title`	No
`access`	No	open, public or private.
`slides`	Yes
`project`	No	The project it belongs to, or null.
`version`	No	Stamp of the content as it is now: give it back as "base_version" to change it only if nobody else did meanwhile.
`can_edit`	No	Whether you may change it.
`database`	No	Setup scripts of the databases of runnable code blocks (shown to the author only).
`title_tr`	No	The same text in the other languages of the site: {"en": "..."}.
`languages`	No	The languages of the site.
`cover_slide`	No	Id of the slide shown as its cover in the lists (null: an uploaded picture, or no slides).
`description`	No
`slides_total`	No
`database_chars`	No	A part or the words only were read: how long each database script is (the whole presentation without "texts_only" gives 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."
```
Changed3 schema fields changedOct 23, 2026
- 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"
+}
```

Changed2 schema fields changedOct 19, 2026

addedOutput schema / properties / database_chars

Added value: +{
+  "description": "A part or the words only were read: how long each database script is (the whole presentation without \"texts_only\" gives them).",
+  "type": "object"
+}

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 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/no-destruction, so the description correctly spends its words on beyond-annotation behavior: the per-slide version must be echoed as base_version on edits, and the response carries the presentation version and slides_total. It does not discuss size limits or how large ranges are handled.

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?

Core purpose is front-loaded in the first clause and every remaining clause carries information (selection axes, texts_only, version contract). The paragraph is dense and slightly run-on, but there is no filler.

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

Completeness5/5

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

With an output schema present, the description needn't explain return shapes, yet it still names the key returned fields (version, slides_total) and the edit-time version contract. For a 5-parameter read tool, an agent has enough to select slides and feed a subsequent edit correctly.

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 100%, so the baseline is 3; the description earns above that by clarifying the range semantics (1-based, inclusive) and, importantly, what texts_only actually returns (words from html/tr/code blocks, no geometry). It leaves the interaction between slide_ids and the numeric range unstated.

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 specific verb and resource (get some slides of a presentation) plus exactly what comes back: blocks with ids and complete props. It is clearly narrower than read_presentation/get_slide by describing partial selection via from_number/to_number/slide_ids, though it never names those siblings explicitly.

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 title and text frame it as the editing-oriented fetch, and it explains two concrete usage modes: texts_only=true for reading/checking/translating, and passing a slide's version as base_version when you change the slide. It stops short of explicit exclusions (e.g., when to prefer get_slide or read_presentation instead).

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?