Dockito

Change a Word doc

edit_word

Change a Word doc by block ID, at the version you read ("base"). Every op in one call applies in order, all or none: up to 500 ops or 1 MB, so read once and send every change together. Ops: {"replace": {"block"?: "p14", "find": "thirty days", "with": "forty-five days", "all"?: true}} (no "block" and "all": true replaces across the doc with no read; "md" instead of "with" for inline Markdown); {"insert": {"after" | "before": "h3", "md": "## Fees\n\nThe Client pays…"}} ("at": "start" | "end" too); {"set": {"blocks": ["p15"], "style"?: "Heading 2" | "Quote" | "Normal"…, "align"?: "center", "list"?: "bullet" | "numbered" | "none", "level"?: 1}}; {"delete": {"blocks": ["l9"]}}; {"move": {"blocks": ["h5"], "after": "p40"}} (a heading moves with its section); {"table": {"after": "p20", "rows": [["Phase", "Due"], ["Design", "1 Dec"]]}}; {"cells": {"table": "t2", "set": {"r3.c2": "2 Jan"}}}; {"image": {"after": "p8", "media": "", "width": "60%"}}; {"page_break": {"after": "p31"}}; {"page": {"size": "A4", "margins": "2.5cm"}}; {"footer" | "header": {"md": "Cedarline Homes · Page {page} of {pages}"}}; {"accept": ["sg12"]}, {"reject": ["sg13"]} (your own suggestions only). An op that makes blocks can name them, "as": "$fees", and later ops use "$fees" ("after" goes after all it made). Under the doc's "AI changes: Suggest" (the default) your edits land as suggestions people accept or reject; moves, page setup, headers and footers land as edits. The answer has the new version, the new IDs and each changed block's new text: no need to read again.

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>",
      "base": "<base>",
      "ops": "<ops>"
    },
    "name": "edit_word"
  }
}

Input Schema

Name	Required	Description
`doc`	Yes	The doc's link or its code.
`key`	No	A retry key, up to 64 characters. Default: one made from the request.
`ops`	Yes	A list of ops, each {"name": {…}}: replace, insert, set, delete, move, table, cells, image, page_break, page, footer, header, accept, reject.
`base`	Yes	The version you read: v N in get.
`note`	No	Why, in a few words. Shown in changes and History.
`dryRun`	No	Work it out and answer, saving nothing.
`answers`	No	An ask's ID ("a12", from get "asks"): this change answers it and closes it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare this as a non-read-only, non-open-world, non-destructive tool, but the description adds substantial behavior: atomic all-or-none application in order, the 500-op/1 MB limit, the suggestion-vs-direct-edit split for each op class, section-carrying moves, and the response payload (new version, new IDs, changed text). That is genuinely useful context beyond the structured fields, and the suggestion model is consistent 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.

Conciseness4/5

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

It is front-loaded with the core contract (block ID, base version, atomic batch, size limit) before the op catalogue, and virtually every clause carries information. However, packing fourteen op shapes into a single dense paragraph makes it hard to scan; a compact list would convey the same content with less effort.

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?

For a 7-parameter mutation tool with no output schema, the description covers the versioning contract, limits, per-op semantics, alias chaining ("$fees"), the suggestion workflow, and what the response contains. An agent has everything needed to call it correctly without a follow-up read.

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 already 100%, but the description goes far beyond it: it enumerates each op shape with concrete examples, explains "block" optionality on replace, "all": true doc-wide replacement, "md" vs "with", "at": start/end, list/level/align values, cell addressing like "r3.c2", media IDs from upload, and header/footer placeholders. It also adds meaning to "base" and "answers" (which closes an ask that get returns).

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 ("Change a Word doc"), plus the mechanism (by block ID, at the version you read as "base") and scope. That is enough to separate it cleanly from edit_doc, edit_sheet, edit_slides and edit_board without opening any 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?

Gives real usage context: read once, pass the version you read as base, and batch every change into one call ("read once and send every change together"), with a batching limit of 500 ops or 1 MB. It also explains that edits land as suggestions under the default "AI changes: Suggest" setting. It stops short of naming alternatives or stating when not to use it, so a 4 rather than a 5.

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

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