Skip to main content
Glama
Sign In
officeagent-net

officeagent-net

by ilia-sokolov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Edit a document

edit_document
Destructive

Edit a Word document in a single call: register the source, resolve text or paragraph targets, and apply validated operations. Nothing saves unless every operation validates.

Instructions

Edit a document the user named by source, in one call: registers it, resolves targets, and applies the operations - use this instead of register_document + find_in_document + apply_plan. planJson is an operations array [ … ] or { "operations": [ … ] }, the same operations preview_plan documents. Targets may name text directly instead of a paragraph id, so no lookup call is needed first: { "op": "changeText", "target": { "find": "Acme Corp" }, "with": "Globex Inc." } If that text matches more than once the call fails with 'ambiguous-anchor' and lists each candidate with its context; re-issue with { "find": "Acme Corp", "match": 2 } (zero-based) or use more surrounding text. Text that matches nothing fails with 'anchor-not-found'. Anchors resolved from inspect_document/find_in_document ({ "paraId": …, "expect": … }) work here too, and can be mixed in the same plan. saveMode and newName behave as in apply_plan. Nothing is written unless every operation validates. Returns the apply_plan shape plus sourceDocumentId - the id of the document that was opened, usable for follow-up calls even when the edit failed.

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": {
      "connectionId": "<connectionId>",
      "source": "<source>",
      "planJson": "<planJson>",
      "saveMode": "<saveMode>",
      "newName": "<newName>"
    },
    "name": "edit_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYes
newNameYes
planJsonYes
saveModeYesReplace
connectionIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, but the description adds non-obvious traits: the call is transactional ('Nothing is written unless every operation validates'), it names specific error codes and their recovery, and it discloses the extra return field sourceDocumentId that is usable even on failure.

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 core claim and the sibling replacement, then detail. It is long and dense, but with five required undocumented parameters the error-recovery and planJson-shape sentences are load-bearing rather than padding.

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?

There is no output schema, and the description compensates by describing the return shape (apply_plan shape plus sourceDocumentId). It covers atomicity, failure modes and plan format for a destructive 5-param tool; only the connectionId/source semantics are unaddressed.

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 0%, so the description must carry the load: it explains planJson's two accepted shapes, gives a concrete operations example, defines the zero-based 'match' disambiguator, and points saveMode/newName at apply_plan's semantics. It does not explain connectionId at all and only obliquely covers 'source', leaving a small gap.

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?

Names a specific verb and resource and immediately scopes it: 'Edit a document the user named by source, in one call: registers it, resolves targets, and applies the operations.' It explicitly differentiates from sibling tools by declaring it replaces the register_document + find_in_document + apply_plan sequence, so an agent can select it 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States when to use it ('use this instead of register_document + find_in_document + apply_plan') and covers the failure branches of the alternative anchor strategy: ambiguous-anchor with an explicit re-issue syntax ({ find, match }) and anchor-not-found. It also says paraId/expect anchors from inspect_document/find_in_document work and can be mixed.

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

Deploy Server

Other Tools