Skip to main content
Glama
Sign In

Dockito

by ai.dockito
OverviewDiscussionsAdmin

Change Slides

edit_slides

Changes Slides read at "base". All ops apply, or none. Boxes are s3.b2 (or s3.). Ops: set, text (html, find/with, insert, delete, format, append), insert, delete, move, z, group, ungroup, slide.insert, slide.delete, slide.move, slide.set, slide.html, media, theme, density. A person's edit since base is refused, naming them; text find/with still lands. "intent" lights up boxes before you change them; "answers" closes an ask. Replies with each change and what to fix (overflow, overlap, contrast). Render after changing how slides look.

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": {
      "doc": "<doc>"
    },
    "name": "edit_slides"
  }
}

Input Schema

NameRequiredDescriptionDefault
docYesThe doc's link or its code.
keyNoA retry key, up to 64 characters. Default: one made from the request.
opsNoAt most 200, applied in order. Boxes "s3.b2" or "s3.<name>"; slides "s3" or a name. {"op":"text","id":"s3.b2","find":"$48k","with":"$52k"} · {"op":"text","id":B,"html":"Revenue <b>grew</b>"} · "insert":{"at":N,"html":H} · "delete":{"from":N,"to":M,"expect":"$48k"} · "format":{"from":N,"to":M,"marks":{"b":true}} · "append":H · "field":"cell.r2.c3" or "notes" {"op":"set","id":B,"props":{"class":"card accent","style":{"color":"accent"},"alt":"…","build":1}} (null removes; build: the click it comes in on when presenting, the same number together) · {"op":"move","id":B,"x":96,"y":240,"w":800,"h":400} · {"op":"z","id":B,"to":"front"} {"op":"insert","slide":"s3","box":{"kind":"text","at":[96,240,800,200],"class":"body","text":"…"},"after":B} · {"op":"delete","ids":[B]} · {"op":"group","ids":[B,B]} · {"op":"ungroup","id":B} {"op":"slide.html","id":"s3","html":"<section>…</section>"} (rewrite a slide from get's HTML; keep data-box on boxes you keep) · {"op":"slide.insert","after":"s3","html":"<section>…</section>"} · {"op":"slide.delete","ids":["s6"]} · {"op":"slide.move","ids":["s6"],"after":"s2"} · {"op":"slide.set","id":"s3","props":{"class":"bg-soft","notes":"…","transition":"fade"}} (transition as it arrives when presenting: none, fade, push, zoom, morph; morph glides boxes with the same name on both slides) {"op":"media","id":B,"file":"<library name>"} (or "stock": an ID, "url": https) · {"op":"theme","theme":"Paper"} (Harbor, Harbor Dark, Paper, Slate) · {"op":"density","density":"compact"} · {"op":"table","id":B,"insert":"row","after":"r2"} ("delete":["r5"])
baseNoThe version you read: v N in get.
noteNoWhy, in a few words. Shown in changes and History.
undoNoUndo your own change that made this version. Goes alone.
dryRunNoWork it out and answer, saving nothing.
expectNoFields that must still hold these values, or nothing applies: {"s2.b1": "92%"}.
intentNoLight up boxes before a change, for people watching: {"boxes": ["s4.b2"], "say": "Updating the revenue chart"}. Alone (no ops) it lights them before a long think.
answersNoThe ask this change answers ("a12"). With intent and no ops, it takes the ask; with ops, it closes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive mutation, and the description adds genuinely useful traits: atomicity ('All ops apply, or none'), concurrent-edit refusal that names the person while letting text find/with still land, and a response that reports each change plus fixes (overflow, overlap, contrast). However, much of the remaining text recycles what the annotations and schema already convey, and it does not reconcile destructive delete ops with destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the atomicity rule are front-loaded, but the middle of the description is a comma-separated inventory of op names (set, text, insert, delete, move, z, group, ungroup, slide.*, media, theme, density) that the ops schema already enumerates in far greater detail — redundant bulk. The compressed, jargon-heavy register ('z', 'intent lights up boxes') makes several sentences harder to parse than they need to be.

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 10-parameter mutation tool with nested objects and no output schema, the description covers the high-risk gaps: atomicity, concurrent-edit conflicts, retry key existence, dryRun (in schema), intent/answers, and the return shape ('Replies with each change and what to fix'), plus the render follow-up. It is close to complete, missing only a plain statement of prerequisites/permissions and any note on limits (schema caps ops at 200).

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% and every parameter (doc, key, ops, base, note, undo, dryRun, expect, intent, answers) is already documented with examples in the schema. The description adds little beyond implying base-version and intent/answers semantics that the schema states more precisely, so the baseline 3 applies.

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 opening verb+resource ('Changes Slides read at "base"') makes the operation identifiable and the 'Slides' resource separates it from siblings like edit_doc and edit_sheet. The phrasing is telegraphic ('read at "base"') and less polished than a clean statement, but an agent can tell what it does 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?

It explicitly routes the agent to another tool at the right moment — 'Render after changing how slides look' — and clarifies that 'intent' alone is for pre-announcing boxes before a long think, while 'answers' with ops closes an ask. There is no explicit statement of when not to use it (e.g., reading vs. writing, or vs. apply/restore), so it stops short of full when/when-not guidance.

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

All Dockito toolsInspect
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