Read and write Microsoft Excel workbooks stored in OneDrive for Business or SharePoint, via the Microsoft Graph workbook API.
Microsoft Excel ships in the w6w first-party pack. It declares 16 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.excelExcel puts a shared workbook into a workflow’s reach — pulling data out of it or writing results back — using the Microsoft Graph workbook API, the same surface OneDrive for Business and SharePoint serve to Excel Online itself.
A workbook is located by item id or file path, and then its worksheets, ranges, tables and charts become directly readable and writable: pull or overwrite a range, add or remove a worksheet, create a table and append rows to it in a single batch, or render a chart to an image for a report. A session keeps a multi-step run fast and lets a workflow discard scratch changes rather than always saving to the live file.
It fits reporting and data-entry workflows that already live in a shared workbook — updating a tracker, appending rows from another system, or pulling a used range into the rest of an automation — for a work or school Microsoft account (personal OneDrive is not supported by this API).
Three routes to the same 16 actions. The Workflow tab is generated from Microsoft Excel's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
add-table-rows Append one or more rows to an Excel table. Batch them into a single call — Microsoft's own guidance.
close-session Close a workbook session. Releases the server-side workbook copy immediately instead of waiting out the inactivity timeout.
create-session Open a workbook session and return its id for the `workbook-session-id` header. Persistent sessions save changes; non-persistent ones discard them on expiry.
get-chart-image Render a worksheet chart to a base64-encoded PNG — for embedding in a report, an email or a Slack message.
get-range Read a range of cells — values, display text, formulas, number formats and value types.
get-used-range Read the smallest range covering the worksheet's actual data — the practical 'read the whole sheet'.
list-tables List the tables in a workbook, or just those on one worksheet, with their ids and names.
list-workbooks Find Excel workbooks in the signed-in user's drive and return their driveItem ids, so the other actions have something to address.
list-worksheets List the worksheets in a workbook, with their ids, positions and visibility.
update-range Write values, formulas and/or number formats into a range of cells. `null` inside a grid skips that cell; `""` clears it.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Microsoft Excel's real ids.
{
"manifestVersion": "2",
"name": "excel-example",
"steps": [
{
"id": "add-table",
"uses": {
"app": "io.w6w.excel",
"action": "add-table",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"address": "<address>"
}
}
]
}add-table add-table-rows add-worksheet clear-range create-session +11 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Microsoft Excel, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Microsoft Excel. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "update-range",
payload: {
// itemId: "<value>",
// itemPath: "<value>",
worksheet: "<value>",
address: "<value>",
// values: "<value>",
// formulas: "<value>",
// numberFormat: "<value>",
// sessionId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action update-range --payload '{"worksheet":"<value>","address":"<value>"}' Give an AI agent Microsoft Excel — without giving it Microsoft Excel's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.excel#add-table",
"input": {
"address": "<address>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Microsoft Excel connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Microsoft Excel's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Microsoft Excel itself is MIT, and the runtime that executes it is source-available (FSL).
Microsoft Excel declares its own checks, so its health is a property of the app rather than something the host guesses at.
Resource units remaining in the current SharePoint Online one-minute window, read off the IETF `RateLimit-*` headers. Those headers appear only once the app passes 80% of that limit, so their absence is itself the healthy answer.