EaseWeb

Read any presentation

read_presentation

Read-only

Read any presentation you can see (not private, or shared with you) the way a person sees it: slide by slide, the texts in reading order, pictures' descriptions, code, and where every button or link leads. A card (a shape with a link and the blocks on it that lead to the same place) is one entry of type "card" with the ids of all its blocks. format "markdown" (default) is compact; "json" is structured.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	The presentation's slug (its address: /movie/<slug>/).
`format`	No	Result format: "markdown" (default, compact) or "json" (structured).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`url`	No	The address people open in a browser.
`slug`	No	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`	No
`can_edit`	No	Whether you may change it.
`markdown`	No
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 28, 2026

addedInput schema / properties / format / description

Added value: +"Result format: \"markdown\" (default, compact) or \"json\" (structured)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "With format \"markdown\" (default): {\"markdown\"}; with \"json\": the presentation slide by slide.",
+  "properties": {
+    "access": {
+      "description": "open, public or private.",
+      "type": "string"
+    },
+    "can_edit": {
+      "description": "Whether you may change it.",
+      "type": "boolean"
+    },
+    "description": {
+      "type": "string"
+    },
+    "id": {
+      "type": "integer"
+    },
+    "markdown": {
+      "type": "string"
+    },
+    "owner": {
+      "description": "User name of the author.",
+      "type": "string"
+    },
+    "slides": {
+      "items": {
+        "properties": {
+          "blocks": {
+            "description": "Texts, pictures, code and links in reading order.",
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "has_background_picture": {
+            "type": "boolean"
+          },
+          "id": {
+            "type": "integer"
+          },
+          "name": {
+            "type": "string"
+          },
+          "number": {
+            "type": "integer"
+          },
+          "url": {
+            "description": "The address people open in a browser.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "slug": {
+      "description": "The address of the presentation: /movie/<slug>/.",
+      "type": "string"
+    },
+    "theme": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "description": "The address people open in a browser.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds genuine behavioral context beyond that: the result is structured "the way a person sees it," slide by slide, in reading order, with picture descriptions, link destinations, and card grouping semantics. This is real added value about output shape rather than a restatement of 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?

Purpose is front-loaded, and the dense clauses (reading order, cards, link destinations) each convey distinct output-shape information. The card definition is niche but is the only place that concept is explained, so it earns its space.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile. The description completes the picture with visibility scope and format semantics, leaving only the sibling-differentiation gap unaddressed.

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?

Schema description coverage is 100%, so both slug and format are already documented in the schema, including the enum semantics. The description restates that "markdown" is default/compact and "json" is structured, which is redundant with the schema and adds no new parameter nuance. Baseline 3 is appropriate when the schema carries the burden.

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 states a specific verb+resource ("Read any presentation") and clarifies the visibility scope ("you can see (not private, or shared with you)"), which tells the agent what it may access. However, it never distinguishes itself from siblings like get_presentation or get_slide, so an agent cannot tell from this text alone why it should pick read_presentation over those.

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 via the access constraint (not private, shared with you) and the mention of a presentation-relative slug. But there is no explicit when-to-use versus siblings such as get_presentation, get_slide, or list_presentations, so routing guidance is left to inference.

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?