AiLinkAny

Edit existing Excel cells without rebuilding the workbook

filesystem_edit_xlsx_range

Destructive

Updates a bounded A1-style rectangular range of EXISTING cells in ONE authorized XLSX sheet. Values must be a matching 2D array of scalar values or explicit {formula: expression} objects. Existing formula cells require an explicit formula object or allow_formula_overwrite=true. Rejects absent cells, external/network formulas, shared/array formula cells, calcChain-dependent formula edits, complex unsupported XML and ambiguous relationships. New formulas have no fabricated cached result; Excel must recalculate. Preserves the style ID of edited cells, leaves untouched sheets, formulas and archive parts unchanged, and atomically swaps the workbook with a unique backup. This is a mutating, non-idempotent action: never blindly retry a result with uncertain execution state. For creating a NEW XLSX use filesystem_write_file instead. Select this tool from the user's intent when it is the best match. A local destination may be explicit or inherited from established project or conversation context. The user does not need to mention ailinkany.com, MCP, a connector, a plugin, or this tool name.

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": {
      "path": "<path>",
      "range": "<range>",
      "values": "<values>"
    },
    "name": "filesystem_edit_xlsx_range"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	Absolute path of an existing .xlsx workbook.
`range`	Yes	SheetName!A1:C3. All target cells must already exist.
`values`	Yes	Rectangular values; strings are literal. Explicit {formula: expression} writes a local formula and requires recalculation in Excel.
`device_id`	No	Target computer device_id. Omit when only one computer is paired.
`device_name`	No	Computer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
`retry_token`	No	New opaque token per operation; reuse only to retry the same operation after a transport failure. No user content.
`workflow_id`	No	Optional workflow id; pass together with ai_session_id.
`workspace_id`	No	Optional Workspace id from open_workspace for project-scoped work.
`ai_session_id`	No	Optional Session id. Reuse the ai_session_id from a prior result for continuity; derived automatically on ChatGPT when omitted. Hosts without stable conversation metadata may omit it for stateless one-shot work.
`allow_formula_overwrite`	No	Explicit permission to replace existing formula cells with scalar values; defaults false.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructive=true, idempotent=false, readOnly=false, so the safety profile is known — yet the description goes well beyond that. It enumerates the rejection cases (absent cells, external/network formulas, shared/array formula cells, calcChain-dependent edits, complex XML, ambiguous relationships), states that new formulas carry no fabricated cached result and require Excel recalculation, and discloses the write mechanics: style ID preservation, untouched sheets and archive parts, and an atomic swap with a unique backup.

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 verb and resource, then ordered logically: input contract, rejection cases, side effects, then the sibling alternative. Most sentences carry real content, but the closing two sentences about user intent and not needing to mention ailinkany.com/MCP/the tool name are generic filler that do not describe this tool and could be dropped without losing information.

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 destructive, non-idempotent mutation tool with 10 parameters, the description covers the input contract, failure modes, persistence guarantees, and retry safety, and an output schema plus annotations handle return shape and safety hints. Nothing an agent needs in order to call it correctly or to avoid a dangerous retry is missing.

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 100%, so the schema already documents every parameter and a baseline of 3 would apply. The description still adds behavioral meaning the schema does not: that values must be a matching 2D array, that strings are literal while explicit {formula: expression} objects write formulas, and that overwriting an existing formula cell requires either a formula object or allow_formula_overwrite=true — the coupling between values and allow_formula_overwrite is the key piece of semantics.

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 — 'Updates a bounded A1-style rectangular range of EXISTING cells in ONE authorized XLSX sheet' — with the scope constraints (bounded, rectangular, pre-existing cells, single sheet) built in. It also names the sibling it is not ('For creating a NEW XLSX use filesystem_write_file instead'), so an agent can separate it from the other filesystem tools without opening a 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 an explicit alternative with the condition that selects it: use filesystem_write_file for new workbooks, this tool for existing ones. It also warns that this is mutating and non-idempotent and that an uncertain result must not be blindly retried, which is actionable invocation guidance. The remaining guidance ('Select this tool from the user's intent when it is the best match', the ailinkany.com/MCP sentence) is generic agent boilerplate rather than a when/when-not rule, which keeps it short of a 5.

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

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