This server acts as a translation layer between AI agents and Microsoft Word (.docx) documents, enabling structured, validated edits without the agent ever writing raw XML or file bytes.
Document Management
list_connections: Discover available storage backends (filesystem or SharePoint).
register_document: Register an existing Word document and receive an opaque ID for subsequent operations.
remove_document: Unregister a document (the underlying file is never deleted).
Inspection & Search
inspect_document: Retrieve a structured map of a document including its outline, paragraphs (with stable IDs), styles, content controls, tables, images, document properties, and tracked revisions. Supports pagination and fidelity levels (outline, structure, content).
find_in_document: Search for text using plain text, regex, whole-word, or case-sensitive matching, returning verified anchors usable as edit targets.
Plan-based Editing
preview_plan: Dry-run a DocumentPlan JSON to validate changes and get a before/after report — without writing anything.
apply_plan: Execute a validated DocumentPlan and save via three modes — NewVersion (default), NewDocument, or Replace (with optimistic concurrency).
Supported Edit Operations (within plans)
changeText: Replace text, optionally as a tracked change.
format: Apply formatting (bold, highlight, color, style, borders, image dimensions) to paragraphs, runs, tables, rows, cells, or images.
fill: Fill content controls by tag name.
comment: Add comments to paragraphs.
insert: Insert new paragraphs before/after an anchor.
setProperty: Set document core properties (e.g., title, author).
revision: Accept or reject tracked revisions.
insertTable / removeTable: Insert or remove entire tables.
insertTableRows / removeTableRows: Add or remove rows from a table.
insertImage / removeImage: Insert (from base64 or registered source) or remove images.
OfficeAgent.NET translates an AI agent’s intent into controlled changes to Microsoft Word documents and PowerPoint decks. The agent proposes a typed edit plan; the library validates and applies it while preserving document features such as styles and comments. Word edits can be recorded as tracked changes for human review, while structured document operations can reduce token use compared with processing entire files.
A .docx or .pptx file is a package of related XML parts. A small text change
can affect runs, styles, numbering, comments, content controls, or revision
markup. OfficeAgent.NET handles that document-specific work. The model works
with structured document data and JSON-serialisable operations such as "replace
this clause as a tracked change" or "add a row to this table."
The same engine is available in three forms:
an MCP server for agents that support the Model Context Protocol;
tools for Microsoft Agent Framework and Microsoft.Extensions.AI;
a .NET API for applications that want to control the workflow directly.
It supports Word .docx files and PowerPoint .pptx decks; one client serves
both, routing each document to the module that handles it. Excel is not
implemented. See Scope and limitations before choosing
it for a workflow that depends on Office's layout or calculation engine.
Related MCP server: docx-mcp
I want to... | Start here |
Add Word editing to a local MCP client | |
Connect Codex, Claude Code, Copilot Studio, or Microsoft 365 Copilot | |
Use OfficeAgent from C# | |
Add tools to a Microsoft Agent Framework agent | |
Host the MCP server or use SharePoint | |
Contribute |
Install the server as a .NET tool:
dotnet tool install --global OfficeAgent.McpThe following examples register it with Claude Code and limit its filesystem connection to one directory.
macOS/Linux:
claude mcp add \
--env OfficeAgent__FileSystemConnections__0__ConnectionId=documents \
--env OfficeAgent__FileSystemConnections__0__RootPath=/absolute/path/to/documents \
--env OfficeAgent__AllowCreation=true \
--transport stdio \
officeagent -- officeagent-mcp --stdioPowerShell:
claude mcp add `
--env OfficeAgent__FileSystemConnections__0__ConnectionId=documents `
--env OfficeAgent__FileSystemConnections__0__RootPath=C:\officeagent-documents `
--env OfficeAgent__AllowCreation=true `
--transport stdio `
officeagent -- officeagent-mcp --stdioAllowCreation is off by default and is what adds create_document; drop that
line for an agent that may only edit documents that already exist.
Run claude mcp list to confirm that officeagent is connected. Then ask the
client to edit a file in the configured directory, for example:
Change the payment terms in contract.docx from 30 to 45 days.
The server exposes tools to register, create, inspect, search, preview, and apply
edits. Asking for a document that does not exist yet - "draft a project brief in
brief.docx" - creates it in the configured directory rather than failing.
Text replacements are tracked changes by default. A successful apply writes back
to the document it edited, guarded by an optimistic version check; pass
saveMode: "NewVersion" to keep the source and write a sibling such as
contract.v2.docx instead.
A connection accepts .docx only until you say otherwise. To work on decks, add
three more --env settings to the command above - .pptx in the extension
allow-list, and a Direct default change mode, because a deck has no redline
vocabulary and refuses tracked changes:
OfficeAgent__FileSystemConnections__0__AllowedExtensions__0=.docx
OfficeAgent__FileSystemConnections__0__AllowedExtensions__1=.pptx
OfficeAgent__FileSystemConnections__0__DefaultChangeMode=DirectOfficeAgent does not send the complete .docx package through the model, but
the MCP client and model do receive document text and structure returned by the
inspect and find tools. Only connect document folders and model providers that
are appropriate for the data you are processing.
Configuration for other clients, streamable HTTP hosting, containers, and SharePoint is in Deployment and client setup. The server does not provide an authentication layer for HTTP hosting; put it behind the authentication and network controls appropriate for your environment. Filesystem roots are also trust boundaries: their ACLs must prevent untrusted principals from creating, renaming, or replacing directory entries while the server runs.
Install the core package and Word module:
dotnet add package OfficeAgent.Core
dotnet add package OfficeAgent.WordAfter registering services and a document provider, the edit loop looks like this:
var client = services.GetRequiredService<OfficeAgentClient>();
var doc = await client.RegisterAsync("workspace", "/srv/workspace/contract.docx");
var inspect = await client.InspectAsync("workspace", doc.ItemId);
var hit = (await client.FindAsync(
"workspace", doc.ItemId, new FindQuery("Acme Corp"))).First();
var plan = new DocumentPlan
{
Snapshot = inspect.Snapshot,
Operations = new PlanOperation[]
{
new ChangeTextOp
{
Target = hit.Anchor,
With = "Globex Inc.",
Mode = ChangeMode.Tracked
}
}
};
var preview = await client.PreviewAsync("workspace", doc.ItemId, plan);
if (preview.IsValid)
await client.CommitAsync("workspace", doc.ItemId, plan);The complete example, including service registration and reading the saved
file, is in Getting started.
The minimal sample replaces the first Acme Corp with Globex Inc.. To run it,
copy a Word document containing Acme Corp to contract.docx in the cloned
repository root, then run:
dotnet run --project samples/QuickEdit -- ./contract.docx ./contract-edited.docxThe repository also contains a
direct IChatClient Word-editing sample and an
interactive
Agent Framework sample.
Every edit follows the same four steps:
Inspect returns a structured map of the document: its outline, paragraphs, styles, content controls, tables, images, and revisions.
Find searches text and returns a content-verified anchor for each match.
Preview validates a plan against the current document and reports the proposed changes without writing.
Apply commits the complete plan and saves it through the configured provider.
A plan (DocumentPlan) is a typed, JSON-serialisable list of operations. An
anchor records both a location and the content expected there. If the content
or optional document snapshot has changed, validation fails instead of silently
targeting a different location. Applying a plan is all-or-nothing.
The Word module supports changes to text, paragraphs, tables, images, styles, content controls, comments, document properties, and tracked revisions. The PowerPoint module implements a broad, explicitly documented set of deck operations: text, bullets, run and paragraph formatting, template slots, style copying, tables, images, text boxes, embedded video and audio, speaker notes, resolvable comments, footers and slide numbers, sections, transitions and animations, and the slide lifecycle - adding, removing, reordering and duplicating. Several slide inserts in one plan author a deck end to end, so a single call turns nothing into a finished presentation. Any verb it does not support is named rather than silently skipped. The full operation schema is documented in Document plans, and the deck specifics in PowerPoint support.
Documents are accessed through configured providers. After registration,
editing calls use a (connectionId, documentId) pair instead of a storage path
or credentials. The filesystem provider restricts registrations to its root;
the SharePoint provider uses the permissions of its configured identity.
CreateAsync starts a new document inside a connection: the requested .docx
or .pptx extension selects a registered blank-document factory. The engine
applies an optional initial plan in memory, and then asks
the provider to create and register it without overwriting an existing name.
Guide | Covers |
Learning paths, package map, and the complete documentation set | |
A complete edit from service registration to reading the result | |
Anchors, snapshots, plans, providers, transactions, and capabilities | |
JSON shapes and validation rules for every operation | |
Filesystem, SharePoint, save modes, and custom providers | |
Slide addressing, the verbs the deck module implements, and what it preserves | |
Microsoft Agent Framework and | |
Server configuration, transports, security notes, and tool contracts | |
Codex, Claude Code, Microsoft Copilot clients, containers, and Azure | |
Concurrency, streams, cancellation, telemetry, and production concerns | |
Startup, registration, validation, concurrency, and provider failures | |
Common plan errors and what to do next |
Bug reports, documentation fixes, new document operations, provider integrations, and focused test cases are useful contributions. If you found a problem, open an issue with the document feature involved, the operation you attempted, and the error or unexpected result. Do not attach confidential documents; a small sanitised reproduction is enough.
To work on the code, install the .NET 8 SDK, fork the repository, and run:
dotnet build OfficeAgent.NET.sln
dotnet test OfficeAgent.NET.slnBefore starting a larger change, especially one that changes public types or the JSON wire format, open an issue so the design can be discussed. See CONTRIBUTING.md for code style, tests, and pull-request expectations.
OfficeAgent.NET edits Word .docx files and PowerPoint .pptx decks; it does
not automate the Office desktop applications. An Excel module can be added
through IFormatModule, but it does not ship today.
The deck module refuses the two verbs a presentation has no vocabulary for -
setProperty and revision - per operation, rather than applying part of a
plan. PresentationML has no redline model, so tracked changes are Word-only, and
a slide has no header (that is a notes and handout concept). Animations cover
the effects expressible as a filtered p:animEffect; fly-in, zoom and motion
paths are refused rather than approximated. See
PowerPoint support for what a deck does and does not
accept.
The engine does not render pages or calculate Word fields. Operations that depend on pagination, table-of-contents rendering, field recalculation, or page-fit checks are outside its scope. Preview reports structural changes, not a visual rendering of the final document. Test the workflow on representative documents and keep human review in the loop for consequential edits.
OfficeAgent.NET is MIT-licensed and can be self-hosted. Managed hosting and commercial support are available from dotaction: contact dotaction.
MIT. See LICENSE.
Apply a DocumentPlan JSON to (connectionId, documentId) and save through the provider. Returns {committed, outputConnectionId, outputDocumentId, outputVersion, outputName, outputContentType, changes, errors}. saveMode: 'NewVersion' (default, mints a new id under the same connection), 'NewDocument' (mints a fresh id with an optional newName for display), 'Replace' (overwrites the source after an optimistic version check). On any failure nothing is written.
| Name | Required | Description | Default |
|---|---|---|---|
| newName | Yes | ||
| planJson | Yes | ||
| saveMode | Yes | NewVersion | |
| documentId | Yes | ||
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states 'On any failure nothing is written' and explains save modes, but lacks details on permissions, rate limits, or other side effects beyond the save operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a coherent single paragraph with front-loaded purpose. It covers essential details without unnecessary words, though a bullet structure could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param tool with no output schema or annotations, the description explains return fields, save modes, and failure behavior. Missing deeper context about DocumentPlan format, but acceptable given tool specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains saveMode options and newName context, but does not describe connectionId, documentId, or planJson parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a DocumentPlan JSON to a document and saves through the provider. It lists return fields and differentiates save modes, distinguishing it from siblings like preview_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each saveMode (NewVersion, NewDocument, Replace) with clear behavior. However, it lacks explicit comparison with sibling tools like preview_plan or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find text in a Word document by (connectionId, documentId). Returns content-verified anchors (paragraphId + expected + occurrence) usable as plan targets.
| Name | Required | Description | Default |
|---|---|---|---|
| regex | Yes | ||
| pattern | Yes | ||
| wholeWord | Yes | ||
| documentId | Yes | ||
| connectionId | Yes | ||
| caseSensitive | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions the return format (anchors with paragraphId, expected, occurrence) but omits critical details such as support for regex, case sensitivity, whole-word matching, and whether the operation is read-only. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core purpose and return value format. However, it lacks structure and could benefit from bullet points or separate sentences for parameters and behavior, but remains reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is incomplete. It partially explains the return format but fails to cover all parameters, usage context, and behavioral traits (e.g., regex support). For a 6-parameter required tool, this is insufficient for an agent to reliably select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It only mentions connectionId and documentId, ignoring the 4 other required parameters (pattern, regex, wholeWord, caseSensitive). Without any description of pattern or search options, the agent cannot understand how to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find text in a Word document', specifying the action, resource, and key identifiers (connectionId, documentId). It is distinct from sibling tools like inspect_document or list_connections, as none other specialize in text search within a document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context like 'Use this to find text patterns; for structural overview use inspect_document.' The agent is left without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a Word document by (connectionId, documentId). Returns outline, paragraphs (with their in table containment), content controls, nodes (tables/images/docProperties/revisions - paths for table-row and image operations come from here), styles, and a snapshot etag for drift detection. Use paragraphOffset/paragraphLimit to page; fidelity='outline'|'structure'|'content' to control payload size.
| Name | Required | Description | Default |
|---|---|---|---|
| fidelity | Yes | content | |
| documentId | Yes | ||
| connectionId | Yes | ||
| paragraphLimit | Yes | ||
| paragraphOffset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It discloses paging mechanism (paragraphOffset/paragraphLimit), fidelity levels, and returned components including a drift-detection etag. Does not mention authorization or destructive behavior, which is acceptable for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the core purpose. While dense, it conveys all essential information without fluff. Could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains return components and key usage options. However, it lacks details on error handling, etag usage for drift detection, and potential performance implications of different fidelity levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description explains fidelity (outline/structure/content) and paging parameters (paragraphOffset/paragraphLimit) but does not explain connectionId or documentId beyond being required. Adds value for 3 of 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a Word document and lists the returned components. It distinguishes from siblings like find_in_document (search) and apply_plan (modification) through the verb 'inspect' and specific resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (inspect document) and includes guidance on paging and fidelity control. Does not explicitly exclude use cases or mention alternative tools, but the context is sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the connections you can address documents under. Returns [{connectionId, provider}] where provider is "filesystem" or "sharepoint". Use a connectionId as the connectionId for register_document and the document tools; never ask the user for it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a list of connections with specific fields, implying a read-only operation. However, it does not mention any potential side effects or edge cases like empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states purpose and return format; the second gives actionable usage advice. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description is complete: it explains what is returned and how to use it. It does not cover error scenarios, but given the simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema coverage 100%), so baseline is 4. The description does not need to add parameter info but effectively describes the return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connections and provides the return format with explicit examples of providers ('filesystem' or 'sharepoint'). It ties to sibling tools like register_document, differentiating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the returned connectionId for register_document and document tools, and says never ask the user for it. This provides clear guidance on when to use the output and avoids unnecessary user interaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a DocumentPlan JSON against (connectionId, documentId). Returns {isValid, changes, errors} without writing. Plan shape: { "operations": [ ... ] }. Do NOT set contractVersion or snapshot. Each operation is one object. Concrete examples:
// Replace text: { "op": "changeText", "target": { "paraId": "w14:...", "expect": "Acme Corp", "occurrence": 0 }, "with": "Globex Inc.", "mode": "Tracked" }
// Unified formatting (paragraph/run/table/row/cell/image): { "op": "format", "target": { "paraId": "w14:...", "expect": "important", "occurrence": 0 }, "highlight": "yellow", "bold": true, "color": "FF0000" } { "op": "format", "target": { "kind": "table", "path": "table#0" }, "styleId": "TableGrid", "borderStyle": "single" } { "op": "format", "target": { "kind": "image", "path": "image#0" }, "widthPx": 320, "heightPx": 200 }
// Fill / comment / insert paragraph / setProperty / revision: { "op": "fill", "target": { "tag": "ClientName" }, "value": "Globex" } { "op": "comment", "target": { "paraId": "w14:...", "expect": "..." }, "text": "Confirm this." } { "op": "insert", "target": { "paraId": "w14:...", "expect": "..." }, "position": "After", "text": "New paragraph." } { "op": "setProperty", "target": { "kind": "docProperty", "path": "core/title" }, "value": "My Title" } { "op": "revision", "target": { "kind": "revision", "path": "all" }, "action": "Accept" }
// Insert a whole new table after a paragraph, or remove an entire table (table path from inspect_document.nodes): { "op": "insertTable", "target": { "paraId": "w14:...", "expect": "..." }, "position": "After", "table": { "headers": ["Region", "Q1"], "rows": [["NL", "41850"]] } } { "op": "removeTable", "target": { "kind": "table", "path": "table#0" } }
// Add or remove table rows / columns; insert or remove image; copy or clear styles. Paths come from inspect_document.nodes: { "op": "insertTableRows", "target": { "kind": "table", "path": "table#0" }, "rows": [["NL","17","41850"]], "position": "End" } { "op": "removeTableRows", "target": { "kind": "table", "path": "table#0" }, "onlyIfEmpty": true } { "op": "insertImage", "target": { "paraId": "w14:...", "expect": "..." }, "base64Bytes": "iVBORw0KGgo...", "imageType": "png", "widthPx": 200, "heightPx": 80 } { "op": "insertImage", "target": { "paraId": "w14:...", "expect": "..." }, "imageConnectionId": "images", "imageDocumentId": "", "imageType": "png", "widthPx": 200, "heightPx": 80 } { "op": "removeImage", "target": { "kind": "image", "path": "image#0" } }
| Name | Required | Description | Default |
|---|---|---|---|
| planJson | Yes | ||
| documentId | Yes | ||
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the operation is a dry-run (no writing), returns specific fields, and warns not to set contractVersion/snapshot. It does not disclose auth or rate limits but covers behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, but contains many examples making it lengthy. While examples are helpful, the description could be more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return shape and plan structure, covering main usage. Lacks details on error formats or edge cases, but sufficient for a dry-run tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description explains planJson format extensively but does not describe connectionId or documentId beyond their names. Thus it adds partial value for one parameter but not all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a 'Dry-run' of a DocumentPlan JSON, returning validation results without writing. It distinguishes from sibling tool 'apply_plan' by explicitly noting 'without writing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before applying changes (dry-run vs apply_plan), but lacks explicit when-not-to-use or alternative guidance. The context of sibling tools provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register an existing document with a host-configured provider connection and return its opaque documentId. source is connection-specific: for a filesystem connection, a path under its root; for a SharePoint connection, the document's SharePoint/OneDrive URL (e.g. 'https://contoso.sharepoint.com/:w:/s/…') or a 'driveId/itemId' pair (e.g. 'b!9a3f…/01ABCDEF'). Never pass credentials. Returns {connectionId, documentId, name, contentType, version}.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format, warns not to pass credentials, and explains source format specifics. With no annotations, it provides good behavioral context, though could mention error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Appropriately sized with front-loaded action and return info. Includes examples and warning, no unnecessary fluff, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter semantics for source, output format, and a safety note. Missing error behavior and connectionId details, but sufficient for a simple registration tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains 'source' parameter in detail with examples. 'connectionId' is not described beyond being a connection identifier, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it registers a document and returns a documentId. Explains source formats for different connections, distinguishing it from sibling tools like find_in_document or list_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (registering a document) but no explicit when-to-use vs alternatives or prerequisites. Sibling tools are different enough that context is clear, but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a document registration from a provider connection by (connectionId, documentId). Only the registration is removed - the underlying file is never deleted. Returns {removed, connectionId, documentId}.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | ||
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds key behavioral detail: 'the underlying file is never deleted' and specifies the return format. It does not cover idempotency or error states, but the most critical trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with the action and key constraint. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% param coverage, the description covers the essential purpose, key behavior, and return structure. It lacks error handling or prerequisites, but for a simple removal tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It names the required parameters (connectionId, documentId) and indicates their role via 'by (connectionId, documentId)', but adds no additional detail about format or constraints, which is minimal for the context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'document registration', specifying it only removes the registration without deleting the file. It distinguishes from siblings like register_document by its inverse action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to remove a registration) but lacks explicit guidance on when not to use it or alternatives. No mention of prerequisites or context compared to siblings like list_connections or inspect_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
apply_planfind_in_documentinspect_documentlist_connectionspreview_planregister_documentremove_documentEach tool serves a distinct purpose: connection management, document registration/removal, inspection, text search, plan preview, and plan application. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_connections, inspect_document, apply_plan), making the surface predictable and easy to navigate.
With 7 tools, the server is well-scoped for its purpose of document editing via plans. Each tool is necessary and no tool feels redundant or missing.
The tool set covers the core workflow: connection listing, document registration, inspection, text search, preview, and apply. A minor gap is the lack of a tool to list documents under a connection, but the workflow remains functional without it.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI document editing for agents: draft, edit, export .docx/PDF. 37 MCP tools; agent self-signup.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
MCP server for managing FormDesigner forms, fields, logic rules, themes, and entries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ilia-sokolov/OfficeAgent.NET'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
