SheetsFinance

Plan workbook formulas

workbook_plan

Read-onlyIdempotent

Primary tool for Excel and Google Sheets builds. Supply explicit function blocks, semantic requirements, or both. It selects and consolidates public SheetsFinance functions, validates connected-account access, plans spill-safe ranges, and compiles approved native spreadsheet formulas. Follow execution.status exactly: do not edit on unresolved requirements or access choices, and never create scratch/probe formulas. Write its formulas as given; they are how SheetsFinance data reaches the sheet, so never replace them with GOOGLEFINANCE or another provider. When you build the sheet yourself, apply its presentation guide (SheetsFinance's styles, number formats and layout conventions). It does not fetch financial values or modify a workbook.

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": {
      "request": "<request>"
    },
    "name": "workbook_plan"
  }
}

Input Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them ('does not fetch financial values or modify a workbook'). Beyond that it discloses real behavior the annotations cannot: access validation, spill-safe range planning, that execution.status is authoritative and blocks editing, and that returned formulas must be written verbatim and never substituted with GOOGLEFINANCE. It stops short of covering failure modes or what the plan contains beyond the status field, so not a 5.

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?

Purpose and input modes are front-loaded, followed by behavioral rules, and every sentence carries an operative constraint (write formulas as given, no scratch formulas, apply the presentation guide). The middle clauses are dense but not padded. It could be trimmed slightly by merging the two formula-related prohibitions.

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?

For a complex nested-parameter planning tool with an output schema, the description covers the essential contract: what it produces, the execution.status gate, and how downstream writes must treat the output. Output-format details are correctly left to the output schema. Minor gaps remain around the placement parameters (existing_ranges, anchor, row_gap) that affect whether the plan collides with existing content.

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?

Top-level schema coverage is reported as 0% (only the single 'request' wrapper), so the description has to carry weight. It does explain the two input modes (function blocks vs semantic requirements) and the consequence of the access_strategy choice ('returns no writes until the user chooses'). It says nothing about row_gap, start_cell, default_sheet, or existing_ranges, leaving several nested controls to the schema's own property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb chain — 'selects and consolidates public SheetsFinance functions, validates connected-account access, plans spill-safe ranges, and compiles approved native spreadsheet formulas' — so an agent knows this is a planning/compilation tool, not a data fetcher. It also states a negative boundary ('does not fetch financial values or modify a workbook'), which separates it from data tools. It stops short of naming which sibling (e.g. create_workbook) actually performs the build, so sibling differentiation is implied rather than explicit.

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?

'Primary tool for Excel and Google Sheets builds' plus 'Supply explicit function blocks, semantic requirements, or both' tells the agent both the context of use and the two valid input modes. The gating rule 'do not edit on unresolved requirements or access choices' is an explicit when-not condition. However, no sibling tool is named as an alternative, so the agent must infer that create_workbook handles the actual write step.

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

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