What can you do with this server?

SheetForge MCP is an Excel MCP server for local-first .xlsx automation, letting AI agents read, inspect, create, format, chart, validate, and safely mutate workbooks over MCP. * Workbook & sheet management: create/delete/rename/copy worksheets, create workbooks, list sheets, set visibility, and read workbook metadata. * Structured reading: quick reads, table reads, dataset descriptions, search, pagination, compact headers/rows or record objects, and schema inference. * Data querying & aggregation: filter/query worksheet or native-table data, compute grouped aggregates, bulk aggregate/filter across workbooks, union tables, and cross-workbook lookups. * Writing & editing data: write raw cell data, append/upsert table rows, update rows by key, with dry-run previews and optimistic-concurrency tokens. * Formatting & layout: format one or many ranges, autofit/set column widths and row heights, freeze panes, autofilters, merges, print areas/titles, and read formatting back. * Formulas & validation: apply/inspect/validate formulas, explain dependency chains, detect circular references, and manage data validation and conditional formatting rules. * Tables, charts & pivots: create native Excel tables, list/create charts from ranges or explicit series, find free canvas placements, and create pivot tables. * Workbook analysis & safety: profile workbooks, describe sheet layouts, audit for issues, plan/apply repairs, diff workbooks, create snapshots, and analyze range impact before mutations. * Named ranges & metadata: create, inspect, list, and delete named ranges, plus workbook-level inventory of sheets, tables, and charts.

How do I use SheetForge MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SheetForge MCP read the sales table from report.xlsx" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SheetForge MCP

by iHeldan

Overview Schema Related Servers Score Discussions

Python

Hybrid

SheetForge MCP

Local-first Excel MCP server for AI agents that need structured reads, workbook introspection, and safer .xlsx mutation.

SheetForge MCP is an Excel MCP server for .xlsx automation over the Model Context Protocol. It is built for AI agents, MCP clients, and automation workflows that need more than raw cell access: compact structured reads, workbook-aware guidance, layout-aware inspection, and safer write paths with Python and openpyxl, without launching Microsoft Excel or LibreOffice.

If you are looking for an Excel MCP server for spreadsheet automation, workbook inspection, Excel report generation, dashboard authoring, or .xlsx editing from AI tools, SheetForge MCP is built for that workflow.

Instead of treating every sheet as a blind cell grid, SheetForge helps agents distinguish native Excel tables, worksheet-shaped datasets, layout-heavy dashboards, and chart sheets, then choose the right read or mutation path for each workbook task.

Package name: sheetforge-mcp CLI command: sheetforge-mcp Published package release: 0.10.0 Repository docs track the current main-branch tool surface, which currently exposes 78 MCP tools.

Why SheetForge

agent-friendly reads via suggest_read_strategy, describe_dataset, query_table, and aggregate_table
verified multi-step edits via apply_workbook_changeset: preview the complete candidate, value/table/layout assertions, structural diff, and sampled cell changes, then commit that exact plan only if the source workbook still matches
safer workbook creation and baselines: create_workbook refuses to overwrite an existing .xlsx, while create_workbook_snapshot creates a verified non-overwriting copy for before/after validation
serialized workbook mutation: same-host writers lock each workbook before loading it, then keep the lock through atomic replace and reopen verification so concurrent agents do not silently overwrite one another
smarter worksheet boundaries with bounded strict, default, and extended read presets plus compact metadata for any trailing blocks that were intentionally left out
workbook and layout awareness via profile_workbook, describe_sheet_layout, list_tables, list_charts, and analyze_range_impact
safer local mutation through dry_run, compact write responses, guarded native-table append/upsert flows, and workbook diff/audit/repair loops
local-first performance and privacy with openpyxl, no desktop Excel dependency, and no cloud-auth requirement

Related MCP server: fcp-sheets

Excel MCP Server Features

workbook creation and metadata
worksheet creation, renaming, copying, deletion, and visibility
structured reads, compact table reads, declarative table queries, grouped aggregates, and cell search
row, column, and range mutations
formulas and validation checks
formatting, freezes, autofilters, merges, and conditional formatting
native Excel tables, charts, and pivot summaries
stdio, streamable-http, and deprecated sse transports

Common Use Cases

AI agents that need safe, structured Excel workbook access through MCP
spreadsheet automation workflows that read and update .xlsx reports
Excel dashboard generation with formatting, tables, charts, freeze panes, and print setup
workbook QA and inspection flows that need metadata, named ranges, tables, charts, and protection state
data extraction from native Excel tables or worksheet-shaped datasets without hand-written openpyxl scripts

Requirements

Python 3.10+
.xlsx workbooks
either uvx or a local package install

Quick Start

Install and run directly from PyPI with uvx, or install the package locally in your Python environment.

Stdio

Use stdio when the MCP client starts the server locally.

uvx sheetforge-mcp stdio

{
  "mcpServers": {
    "excel": {
      "command": "uvx",
      "args": ["sheetforge-mcp", "stdio"]
    }
  }
}

Streamable HTTP

Use streamable-http when you want a long-running local server process.

EXCEL_FILES_PATH=/path/to/excel-files uvx sheetforge-mcp streamable-http

Default endpoint:

http://127.0.0.1:8017/mcp

Example client config:

{
  "mcpServers": {
    "excel": {
      "url": "http://127.0.0.1:8017/mcp"
    }
  }
}

Remote binding is an explicit opt-in because the HTTP transports do not provide built-in authentication:

FASTMCP_HOST=0.0.0.0 \
SHEETFORGE_ALLOW_REMOTE=true \
EXCEL_FILES_PATH=/path/to/excel-files \
uvx sheetforge-mcp streamable-http

Only expose a remote listener behind an authenticated and access-controlled network boundary.

SSE

SSE is kept for compatibility, but new integrations should prefer streamable-http.

EXCEL_FILES_PATH=/path/to/excel-files uvx sheetforge-mcp sse

Default endpoint:

http://127.0.0.1:8017/sse

File Path Rules

In stdio mode, filepath values must be absolute paths.
In streamable-http and sse mode, relative paths are resolved under EXCEL_FILES_PATH.
In streamable-http and sse mode, absolute paths are accepted only when they remain inside EXCEL_FILES_PATH; parent traversal and symlink escapes are rejected.
In streamable-http and sse mode, the server creates EXCEL_FILES_PATH automatically if it does not exist.

Environment Variables

Variable	Default	Used by	Purpose
`FASTMCP_HOST`	`127.0.0.1`	HTTP and SSE	Bind address for the server process
`FASTMCP_PORT`	`8017`	HTTP and SSE	Port for the server process
`EXCEL_FILES_PATH`	`./excel_files`	HTTP and SSE	Base directory for relative workbook paths
`SHEETFORGE_ALLOW_REMOTE`	unset	HTTP and SSE	Required opt-in for any non-loopback bind; does not add authentication

Tooling Overview

The server currently registers 78 MCP tools across these groups:

workbook overview: create_workbook, create_worksheet, create_workbook_snapshot, get_workbook_metadata, profile_workbook, describe_sheet_layout, audit_workbook, plan_workbook_repairs, apply_workbook_repairs, apply_workbook_changeset, diff_workbooks, analyze_range_impact, explain_formula_cell, detect_circular_dependencies, create_named_range, inspect_named_range, list_named_ranges, delete_named_range, list_all_sheets, list_tables
data access: suggest_read_strategy, describe_dataset, query_table, aggregate_table, bulk_aggregate_workbooks, bulk_filter_workbooks, union_tables, cross_workbook_lookup, quick_read, read_excel_table, read_data_from_excel, read_excel_as_table, search_in_sheet, write_data_to_excel, append_table_rows, append_excel_table_rows, upsert_excel_table_rows, update_rows_by_key
worksheet and range changes: copy_worksheet, delete_worksheet, rename_worksheet, set_worksheet_visibility, get_worksheet_protection, set_worksheet_protection, copy_range, delete_range, insert_rows, insert_columns, delete_sheet_rows, delete_sheet_columns
formatting and layout: format_range, format_ranges, read_range_formatting, freeze_panes, set_autofilter, set_print_area, set_print_titles, set_column_widths, autofit_columns, set_row_heights, merge_cells, unmerge_cells, get_merged_cells
formulas and validation: apply_formula, validate_formula_syntax, inspect_formula, validate_excel_range, get_data_validation_info, inspect_data_validation_rules, remove_data_validation_rules, inspect_conditional_format_rules, remove_conditional_format_rules
analysis and structure: create_table, list_charts, find_free_canvas, create_chart, create_chart_from_series, create_pivot_table

For chart authoring, prefer create_chart as the primary entry point:

use data_range for the simple contiguous-data path
use explicit series plus optional categories_range for non-contiguous or hand-authored charts
use top-level width and height to control chart size in centimeters; defaults are 15 x 7.5
use placement when you want SheetForge to position the chart relative to worksheet content, a source range, or a named table instead of guessing target_cell manually
use placement={"relative_to": "free_canvas"} when a busy dashboard needs the first non-overlapping chart slot instead of a simple right/below placement rule
keep create_chart_from_series for backward compatibility or existing prompts that already rely on it

The most agent-friendly read tools are:

suggest_read_strategy: recommends the best next read tool for a workbook target, including whether SheetForge should treat it as a native Excel table, a clean worksheet dataset, a layout-heavy dashboard sheet, or a chart sheet
describe_dataset: samples a worksheet or native Excel table and returns headers, schema hints, key-candidate guesses, structural signals, guarded worksheet-boundary metadata, and a recommended follow-up read path
query_table: filters, projects, sorts, and limits worksheet-shaped data or native Excel tables with a declarative JSON query instead of ad hoc cell loops
aggregate_table: computes grouped metrics such as count, sum, avg, min, and max over worksheet-shaped data or native Excel tables
bulk_aggregate_workbooks: computes the same grouped metrics across many workbook files in one call, with explicit schema handling via strict, intersect, or union
bulk_filter_workbooks: returns matching rows across many workbook files with optional source provenance columns, so recurring cross-file QA and reporting checks no longer need one-tool-call-per-file loops
union_tables: combines comparable worksheet or native-table rows across many workbook files, with optional deduplication keys and explicit schema handling for workbook collections that drift over time
cross_workbook_lookup: enriches one workbook dataset from one or more lookup workbooks with left-join style matching, optional duplicate-match handling, and compact per-row provenance for matched lookup rows
profile_workbook: one-call inventory for sheets, tables, charts, named ranges, and key layout/protection state, including chart occupied_range for grid-anchored worksheet charts
describe_sheet_layout: worksheet-level structural summary for safe dashboard edits, including freeze panes, print settings, merges, chart anchors, table metadata, conditional-format and validation counts, custom row/column sizing, and a small free-canvas preview
audit_workbook: workbook-level audit for high-signal problems such as broken #REF! formulas, error cells, hidden sheets, header-quality issues, layout-heavy sheets, and named ranges that reference missing sheets
plan_workbook_repairs: converts workbook audit findings into prioritized next steps, including suggested SheetForge tool calls for inspection, safe dry runs, and repair workflows
apply_workbook_repairs: dry-runs or applies the safe repair subset from those plans, including broken named ranges, broken validation rules, broken conditional formats, and optional hidden-sheet reveals
apply_workbook_changeset: previews a bounded multi-tool report mutation on an isolated candidate, evaluates explicit postconditions, and commits it with exact-file stale-write protection plus optional verified snapshot and rollback
diff_workbooks: compares two workbook files and reports structural changes plus sampled cell-value diffs, which is useful for before/after verification in agent workflows
create_workbook_snapshot: creates the verified, non-overwriting baseline that makes diff_workbooks usable without an external copy script
analyze_range_impact: preflight blast-radius check for a worksheet range, including overlaps with tables, chart footprints, merged cells, named ranges, data validations, conditional formats, autofilters, print areas, formula cells inside the range, and formulas or rule expressions elsewhere that depend on it directly or transitively, through named ranges, or through structured table references such as Table1[Sales]
explain_formula_cell: resolves a formula cell's direct references, shows upstream formula-chain cells, returns a compact formula_chain summary with depth layers and sampled paths, and reports downstream dependents so agents can debug workbook logic without manual tracing
detect_circular_dependencies: scans workbook formula graphs, including named-range-driven edges, and reports self-references plus multi-cell circular dependency groups before they surprise downstream automation
create_named_range: creates workbook-level or sheet-scoped named ranges with dry_run and replace support, so agents can promote important workbook regions into stable references without dropping to ad hoc Python
inspect_formula: inspects a formula string without workbook context, listing functions, reference token types, volatile functions, and risky functions such as INDIRECT
inspect_named_range: inspects one defined name, including its scope, destinations, and whether it points at missing sheets or broken references
quick_read: single-call compact table read that auto-selects the first sheet when needed, with guarded strict / default / extended boundaries, start_row pagination, and start_col / end_col column windowing for large sheets
read_excel_table: read a native Excel table by table_name without guessing worksheet bounds, now with start_row pagination and optional start_col / end_col table column windowing
list_all_sheets: quick workbook inventory with sheet sizes, emptiness flags, and sheet_type for worksheets versus chart sheets
read_excel_as_table: compact headers + rows output for structured datasets, with guarded boundary presets, compact=True for the smallest payload, start_row for page-like reads, and start_col / end_col for narrower column slices
read_data_from_excel: cell-address-aware range reader that supports max_rows and max_cols windowing for large non-tabular ranges, values_only=True for smaller 2D payloads, and cursor-based continuations for multi-step 2D traversal
read_range_formatting: compact formatting readback for a worksheet range, grouped by distinct style signatures instead of noisy per-cell dumps, with merged-range and conditional-format overlap summaries
search_in_sheet: exact or partial value search across instantiated worksheet cells, so distant style-only cells do not force a scan of the entire rectangular used range

Workbook inventory tools such as list_all_sheets, profile_workbook, and list_charts surface both worksheets and chart sheets. Grid-oriented tools such as quick_read, read_excel_table, create_table, formatting, formulas, and validation require a real worksheet and return a clear chartsheet error if you target the wrong sheet type.

The most agent-friendly write helpers for structured data are:

upsert_excel_table_rows: update matching rows in a native Excel table and append missing keys in one call Note: totals-row tables are update-only for now; append attempts are rejected rather than shifting unrelated rows.
append_excel_table_rows: append rows to a native Excel table when you want the table ref to grow with the new records
append_table_rows: append header-aware rows to worksheet-shaped data when you do not have a native Excel table
update_rows_by_key: update worksheet-shaped data by a named key column without appending missing keys

For the compact table readers (quick_read, read_excel_as_table, read_excel_table):

row_mode="arrays" keeps the smallest headers + rows shape
row_mode="objects" returns records keyed by normalized field names such as first_name
normalized field names are ASCII-safe transliterations, so headers like Näyttökerrat become nayttokerrat
infer_schema=True adds lightweight schema hints inferred from the returned rows
start_col / end_col let you slice wide worksheets or native Excel tables down to just the columns you need before pagination or schema inference
truncated pages now include next_start_row, which you can pass back to the same tool for the next page
non-tabular range reads can also return continuations.down and continuations.right cursor tokens so agents can continue large 2D windows without recomputing coordinates
suggest_read_strategy helps agents choose between table-aware, worksheet-aware, range-aware, and workbook-orientation reads before they spend context on the wrong path
describe_dataset provides a lighter-weight dataset summary than a full read, including sample rows, header quality, key candidates, and recommended next tool
describe_dataset, quick_read, read_excel_as_table, and read_excel_table now also return structure_token, content_token, and snapshot_metadata, so agents can carry read-time identity forward into safer optimistic-concurrency writes
worksheet-shaped compact readers and row-mutation helpers favor the first contiguous data block after the header, so sparse footer notes or distant outlier rows do not silently stretch total_rows, append targets, or key-based update scans
worksheet reads can opt into read_boundary_mode="strict" (0 blank rows), "default" (5), or "extended" (100); the bounded presets deliberately avoid an unlimited raw gap parameter
describe_dataset, quick_read, and read_excel_as_table surface a read_boundary object with the effective tolerance, data end, ignored row count, and compact trailing-block locations
non-default boundary views are read-only diagnostics and return write_precondition_compatible=false; reread with the default mode before carrying a structure token into a write
query_table is the lightest way to pull just the matching rows and columns you need from a worksheet dataset or native Excel table
query_table and bulk_filter_workbooks accept ne as a shorthand for neq, and membership filters can use either values or the shorter value list form
aggregate_table lets agents compute grouped summaries directly in SheetForge instead of over-reading the full dataset into context first
bulk_aggregate_workbooks extends that pattern across many workbook files when a recurring reporting workflow would otherwise need ad hoc Python or repeated per-file tool calls
aggregate metrics accept both the canonical {"op": "sum", "field": "Sales", "as": "total_sales"} shape and the more guessable alias form {"agg": "sum", "column": "Sales", "as": "total_sales"}
bulk_filter_workbooks does the same for row-level inspection, while keeping workbook provenance visible by default
union_tables is the fastest way to normalize many comparable workbook datasets into one combined tabular payload before downstream QA, export, or further aggregation
cross_workbook_lookup is the fastest way to enrich one workbook from another without writing an ad hoc merge script, especially for master-data lookups, status enrichment, and cross-file QA workflows
append_excel_table_rows is the right append path for native Excel tables when you do not need key-based upsert behavior
append_table_rows now refuses to write directly under an adjacent native Excel table and points you at append_excel_table_rows instead of silently leaving the table range stale
token-aware structured writes can pass expected_structure_token to abort on structural drift; append-style writes additionally require allow_structure_change=True, and successful writes report both previous and new structure/content tokens
rename_worksheet now updates formula cells as well as chart references and named ranges, and it also renames the default sibling pivot sheet (Data_pivot -> Revenue_pivot) when that move is conflict-free
copy_worksheet preserves native tables with workbook-unique copied names, data validations, conditional formatting, freeze panes, autofilters, print settings, protection, charts with their exact anchor geometry, and sheet-scoped names; copied self-references and structured table references are rewritten to the new sheet
formatting color inputs accept RRGGBB, #RRGGBB, AARRGGBB, or #AARRGGBB, so prompts do not need to strip CSS-style # prefixes first
audit_workbook is the fastest workbook-wide preflight when you need to know whether a spreadsheet is safe and predictable enough for autonomous editing
audit_workbook now treats dominant native-table sheets more honestly when nearby dashboard/layout artifacts extend the used range, so unrelated merged/chart areas do not create false blank-header risk on an otherwise clean table
plan_workbook_repairs is the fastest way to turn those audit findings into an actual action queue instead of manually deciding the next tool call for every problem
apply_workbook_repairs lets agents preview or apply the safe subset of those repairs without having to orchestrate each broken workbook artifact manually
diff_workbooks is the quickest before/after QA pass when an agent has touched workbook structure and wants proof of what actually changed

Recommended Agent Workflows

Unfamiliar workbook -> verified multi-step mutation Start with profile_workbook (or list_all_sheets for the lightest inventory), inspect layout-heavy tabs with describe_sheet_layout, and run analyze_range_impact. Put supported report-building edits and explicit postconditions into apply_workbook_changeset(mode="preview"); if ready_to_commit=true, repeat the same plan with mode="commit", expected_workbook_sha256, and changeset_token from the preview.
Workbook repair loop Use audit_workbook to find high-signal issues, plan_workbook_repairs to turn them into an action queue, apply_workbook_repairs(..., dry_run=True) to preview the safe subset, then rerun audit_workbook after applying repairs to confirm the workbook is back to a low-risk state.
Multi-workbook reporting Use bulk_aggregate_workbooks, bulk_filter_workbooks, union_tables, or cross_workbook_lookup to build the reporting dataset first, then write the summarized rows into a fresh workbook tab and finish the presentation layer with format_ranges, find_free_canvas, create_chart, and autofit_columns.

See TOOLS.md for the full reference. Release notes live in CHANGELOG.md.

Response Format

Every tool now returns a JSON envelope with a consistent top-level shape:

{
  "ok": true,
  "operation": "read_excel_as_table",
  "message": "read_excel_as_table completed",
  "data": {}
}

Error responses follow the same contract:

{
  "ok": false,
  "operation": "write_data_to_excel",
  "error": {
    "type": "DataError",
    "message": "No data provided to write"
  }
}

For destructive tools that support preview mode, the envelope may also include dry_run and changes. Committed write operations now default to compact summaries; pass include_changes=True when you want per-cell, per-range, or per-operation detail.

Development

Install dependencies:

uv sync --extra dev

Run tests:

uv run --extra dev pytest -q

Run lint checks:

uv run --extra dev ruff check src tests

Run the package locally:

uv run sheetforge-mcp stdio

Build distributions locally:

uv build

Release Flow

Update pyproject.toml, manifest.json, and the tracked .mcpb bundle together for each release.
Keep the tracked bundle filename in sync with the package version, for example sheetforge-mcp-<version>.mcpb.
Every distribution-building workflow verifies the wheel, source distribution, and tracked MCPB bundle against shared public-artifact allowlists before release or publication.
GitHub releases run a build verification workflow only.
PyPI publishing is a separate manual workflow, so releases do not create a failing deployment before Trusted Publisher is configured for the package.

Repository Layout

src/excel_mcp/server.py: MCP server, transport setup, and tool registration
src/excel_mcp/workbook.py: workbook lifecycle helpers and workbook metadata
src/excel_mcp/changeset.py: verified multi-operation preview/commit transactions and assertions
src/excel_mcp/data.py: read, write, table, and search helpers
src/excel_mcp/sheet.py: worksheet and range mutations
tests/: regression tests covering data, layout, charts, pivots, formatting, tables, and resource safety
scripts/verify_release_artifacts.py: shared wheel/sdist/MCPB content verifier used by CI and release workflows
manifest.json: packaged MCP bundle metadata
docs/index.html: static project landing page

Why SheetForge MCP

Excel-first MCP surface: the toolset is focused on real .xlsx workbook operations, not generic file I/O
agent-friendly responses: consistent JSON envelopes, compact writes, and dry_run previews reduce context waste
workbook introspection: profile_workbook, list_all_sheets, list_tables, and list_charts make unfamiliar spreadsheets easier to navigate
safer edits: analyze_range_impact gives agents a read-only preflight before overwriting, deleting, or restructuring an important range, including downstream formula chains plus validation-rule and conditional-format references elsewhere in the workbook even when formulas point at the range through named ranges or structured table references
verified transactions: apply_workbook_changeset binds a bounded operation/assertion plan to the canonical target path and exact source SHA-256, tests it on an isolated candidate, verifies cells, tables, freeze panes, autofilters, and chart placement, and replaces the source once only after all checks pass
layout planning: find_free_canvas suggests safe empty slots for charts or dashboard blocks before you place them, defaulting to the standard chart footprint when you omit explicit sizing
practical Excel output: formatting, print setup, worksheet protection, table upserts, chart authoring, and autofit helpers cover real reporting workflows
Python ecosystem fit: built on openpyxl, packaged for uvx, and easy to run locally over stdio or through a deliberately gated HTTP deployment

Notes For Integrators

stdio mode is careful not to write non-protocol text to stdout.
All tools return structured JSON envelopes, which makes client-side parsing predictable.
Tool responses now use compact JSON serialization to reduce MCP payload size while keeping the same envelope shape.
read_data_from_excel(..., preview_only=True) limits the response to the first 10 rows in the selected range and marks the payload as truncated when applicable.
read_data_from_excel(..., compact=True) omits default validation stubs for cells that do not have validation rules.
read_data_from_excel(..., values_only=True) returns a plain 2D values array for range reads that do not need per-cell addresses or validation metadata.
read_data_from_excel(..., max_rows=...) paginates tall rectangular ranges and returns next_start_row plus next_start_cell when more rows remain.
read_data_from_excel(..., max_cols=...) paginates wide rectangular ranges and returns next_start_col plus next_column_start_cell when more columns remain.
read_data_from_excel(..., cursor=...) resumes from a continuation token so agents can keep paging without recomputing the next window manually; 2D windows expose directional continuations under continuations.down and continuations.right
read_excel_as_table(..., compact=True) minimizes the tabular payload to headers and rows unless truncation metadata is needed, while still returning dataset identity metadata
compact tabular readers still include structure_token, content_token, and snapshot_metadata, even when the tabular payload itself is minimized
quick_read(..., start_row=...) and read_excel_as_table(..., start_row=...) let agents paginate deep worksheets without first reading from the top.
quick_read(..., start_col=..., end_col=...) and read_excel_as_table(..., start_col=..., end_col=...) let agents request only the relevant columns from wide worksheets instead of pulling every column into context.
read_excel_table(..., start_col=..., end_col=...) now supports the same narrower column slices for native Excel tables, as long as the requested columns fall inside the table range.
quick_read(..., include_headers=False), read_excel_as_table(..., include_headers=False), and read_excel_table(..., include_headers=False) let follow-up pages omit repeated header payload once the first page already established the schema.
read_excel_table(..., start_row=...) now supports deeper pagination into native Excel tables instead of always reading from the top.
Truncated tabular reads now return next_start_row so agents can continue paging without recalculating offsets.
Oversized read responses now fail early with ResponseTooLargeError plus structured hints, so agents can retry with smaller ranges or pagination before the client truncates the payload.
quick_read, read_excel_as_table, and read_excel_table can now return records plus inferred schema hints when you opt into row_mode="objects" and infer_schema=True.
Read tools do not recalculate Excel formulas; formula cells surface as formula text such as =B2*C2, and inferred schema labels formula-backed columns as formula so agents do not mistake them for fresh numeric values.
profile_workbook provides a single-call workbook inventory with sheet-level table, chart, protection, print, and filter metadata for faster agent orientation, and now includes chart occupied_range alongside anchors and dimensions for grid-anchored worksheet charts.
Core mutation tools now default to compact responses on committed writes, including data writes, formatting, worksheet layout helpers, and merge/unmerge helpers. Use include_changes=True for detailed diffs.
Token-aware structured writes now return previous_structure_token, new_structure_token, previous_content_token, new_content_token, and snapshot_metadata, which makes multi-agent or read-then-write flows safer without adding hidden workbook metadata.
dry_run versions of those structured writes now label snapshot metadata as token_basis="dry_run_preview" and keep the on-disk file facts under source_file_*, so preview tokens are no longer mixed with live-file metadata.
Workbook saves that go through safe_workbook(..., save=True) use a timeout-aware same-host workbook lock plus temp-file save, fsync, atomic replace, rollback-on-verification-failure, and reopen verification. Symlink paths update their real target without replacing the symlink itself. If automatic rollback fails, the recovery backup is retained and identified in the error. This protects cooperating SheetForge processes on one machine; it is not a distributed lock for cloud-sync providers.
format_ranges batches multiple formatting operations into one workbook pass and reports per-range errors without discarding successful ranges. A failed range is rolled back to its pre-operation styles, values, comments, hyperlinks, merge state, and conditional-format rules before the batch continues.
validate_formula_syntax performs structural token validation, checks Excel coordinate limits, and rejects risky functions such as INDIRECT, HYPERLINK, WEBSERVICE, DGET, and RTD case-insensitively. It does not calculate formulas or replace Excel's own calculation engine.
write_data_to_excel remains a raw cell-write primitive and can store formula strings directly; use it only with trusted data, or use apply_formula when you want SheetForge's formula safety checks.
Server logs rotate at 5 MiB with two backups instead of growing without a bound.
autofit_columns estimates practical column widths from the current cell contents, with optional column filters and min/max bounds.
list_charts now reports chart width and height in centimeters in addition to anchor, type, and series metadata.
get_worksheet_protection and set_worksheet_protection add a safe worksheet-level wrapper around Excel protection flags.
set_print_area and set_print_titles make report/export setup scriptable without dropping into raw openpyxl workbook internals.
list_tables now returns lightweight schema metadata such as headers, row counts, and stripe settings in addition to table names and ranges.
upsert_excel_table_rows expands native Excel table ranges automatically when it appends missing keys, refuses to grow a table into already occupied cells, and rejects append attempts when the target table has an enabled totals row.
Core mutation tools support dry_run=True so clients can preview changes before saving a workbook.

License

MIT. See LICENSE.

Available Tools

78 tools

aggregate_tableB

Read-only

Compute grouped metrics over worksheet-shaped data or a native Excel table.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`filters`	No
`metrics`	No
`sort_by`	No
`filepath`	Yes
`group_by`	No
`row_mode`	No	arrays
`sort_desc`	No
`header_row`	No
`sheet_name`	No
`table_name`	No
`infer_schema`	No

TDQS

B3/5.0

Behavior3/5

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

The readOnlyHint annotation already signals a read-only operation, and the description aligns with that. However, the description adds little behavioral context beyond the input scope; it does not mention return format, pagination, or side effects, though none are expected for a read-only aggregation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It effectively communicates the core purpose in a compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, no output schema), the one-line description is grossly inadequate. It does not explain how to specify metrics, filters, grouping, or handle worksheet versus table selection, making it impossible for an agent to use correctly without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 12 parameters and 0% schema description coverage, the description must compensate, but it provides no information about metrics, filters, group_by, sort, or row_mode. The mention of 'worksheet-shaped data or native Excel table' hints at sheet_name/table_name, but the untyped metrics and filters objects remain entirely unexplained.

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?

The description uses a specific verb ('Compute') and resource ('worksheet-shaped data or a native Excel table'), clearly indicating the tool performs grouped aggregations. It distinguishes from siblings like query_table and read_excel_as_table by focusing on metric computation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like bulk_aggregate_workbooks or query_table. It does not state exclusions, prerequisites, or scenarios where another tool would be better suited.

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

analyze_range_impactA

Read-only

Inspect workbook structures that overlap a worksheet range before mutation.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`range_ref`	Yes
`sheet_name`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description's 'Inspect' aligns with a read-only operation. The description adds the pre-mutation context but does not elaborate on what 'workbook structures' encompasses or how results are returned, which is a minor gap given the annotation's coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that front-loads the action and purpose. No redundancy or filler, earning its place in the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and minimal annotations beyond read-only, the description is too vague about what structures are inspected and what the return value indicates. This leaves the agent uncertain about the tool's full capabilities, especially given the need to assess range impact before mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description provides no additional parameter information. The parameter names (filepath, sheet_name, range_ref) are somewhat self-explanatory, but the description fails to add any semantics, formats, or relationships beyond the bare schema.

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?

The description uses the specific verb 'Inspect' and clearly identifies the resource as 'workbook structures that overlap a worksheet range', with the added purpose of pre-mutation analysis. This distinguishes it from sibling tools like inspect_named_range or list_tables, which target specific structure types.

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?

The phrase 'before mutation' explicitly signals the intended use case, making it clear when this tool should be invoked. While it doesn't mention alternatives or when not to use it, the context is direct and actionable.

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

append_excel_table_rowsA

Destructive

Append rows to a native Excel table and expand its range safely.

ParametersJSON Schema

Name	Required	Description	Default
`rows`	Yes
`dry_run`	No
`filepath`	Yes
`sheet_name`	No
`table_name`	Yes
`include_changes`	No
`allow_structure_change`	No
`expected_structure_token`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already mark destructiveHint=true; description adds 'expand its range safely' as a behavioral guarantee but does not detail potential structure changes, how safety is ensured (e.g., allow_structure_change), or what conditions might cause failure. No contradiction, but value beyond annotations is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with the core action and a safety qualifier; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no output schema, the description is insufficient: missing alternatives, parameter semantics, and behavioral edge cases. Sibling tools and safety controls are not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must explain parameters; it only hints at 'rows' and 'native Excel table' but leaves sheet_name, dry_run, include_changes, allow_structure_change, and expected_structure_token undefined in meaning.

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?

Description uses specific verb 'Append' and resource 'native Excel table' with 'expand its range safely,' clearly distinguishing it from sibling tools like append_table_rows by emphasizing native tables and safe range expansion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Description implies usage for native Excel tables needing range expansion but does not explicitly state when to use vs alternatives such as append_table_rows or upsert_excel_table_rows. No exclusions or when-not guidance.

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

append_table_rowsB

Destructive

Append dictionary-shaped rows by matching worksheet headers on a worksheet dataset.

ParametersJSON Schema

Name	Required	Description	Default
`rows`	Yes
`dry_run`	No
`filepath`	Yes
`header_row`	No
`sheet_name`	Yes
`include_changes`	No
`allow_structure_change`	No
`expected_structure_token`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations include destructiveHint=true, so the agent already knows the operation is destructive. The description adds a small behavioral detail (rows are matched by headers), but it does not disclose potential side effects such as structure changes or failures when headers don't match. It neither contradicts the annotations nor significantly enriches them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundancy. It efficiently conveys the core action and key constraint. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, destructive annotation, no output schema, and many sibling tools), the description is far too sparse. It doesn't explain the append process, how headers are matched, error conditions, side effects, or when to choose this over similar tools. The lack of parameter descriptions and behavioral context makes it incomplete for an AI agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain the 'rows' parameter by specifying 'dictionary-shaped rows' and 'matching worksheet headers', which clarifies the expected format. However, it provides no meaning for other parameters like dry_run, header_row, include_changes, allow_structure_change, or expected_structure_token, leaving most of the parameter space unexplained.

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 clearly states the action (append), the object (dictionary-shaped rows), and the mechanism (matching worksheet headers). It is specific enough to convey the core function. However, it does not explicitly distinguish itself from the similar sibling tool 'append_excel_table_rows', so it loses a point for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'append_excel_table_rows', 'upsert_excel_table_rows', or 'insert_rows'. The phrase 'by matching worksheet headers' hints at a precondition (rows must be dictionaries with keys matching headers) but does not clarify context or exclusions. This is effectively no guidance.

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

apply_formulaC

Destructive

Apply Excel formula to cell. Excel formula will write to cell with verification.

ParametersJSON Schema

Name	Required	Description	Default
`cell`	Yes
`formula`	Yes
`filepath`	Yes
`sheet_name`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

The annotation destructiveHint: true already flags a mutating operation. The description adds 'with verification,' which hints at a post-write check but gives no detail on what verification involves (e.g., error messages, recalc). With annotations present, the bar is lower, but the added context is minimal.

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?

Two short sentences, front-loaded with the main purpose. The second sentence adds 'with verification' but is otherwise redundant with the first. It is concise, though slightly under-specified rather than overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter descriptions, the description must cover usage, behavior, and return conventions. It does none of that. It omits error handling, effect on existing values, and how verification results are surfaced. For a mutating tool, this is significantly incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no parameter explanations. The four required parameters (cell, formula, filepath, sheet_name) are only named in the schema with no additional meaning. The description entirely fails to compensate for the lack of schema documentation.

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 states a specific action: 'Apply Excel formula to cell.' It clearly identifies the resource (cell) and the operation (applying a formula). It differentiates from siblings like write_data_to_excel (which writes values) and validate_formula_syntax (which validates), though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, preferred contexts, or exclusions. The description simply states the action without any decision-making support.

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

apply_workbook_changesetA

Destructive

Preview or commit an assertion-backed group of workbook mutations as one transaction.

Each operation is {"tool": "name", "args": {...}}. Supported tool names are
create_worksheet, write_data_to_excel, format_range, format_ranges, freeze_panes,
set_autofilter, set_column_widths, set_row_heights, autofit_columns, create_table,
and create_chart. Assertions support sheet_exists, cell_equals, range_equals,
range_values_unchanged, table_exists, freeze_panes_equals, autofilter_equals,
chart_exists, and no_cell_ref_errors.

Call preview first. Commit the identical plan with expected_workbook_sha256 and
changeset_token from that preview. Snapshot creation defaults to enabled.

ParametersJSON Schema

Name	Required	Default
`mode`	No	preview
`filepath`	Yes
`assertions`	No
`operations`	Yes
`sample_limit`	No
`changeset_token`	No
`create_snapshot`	No
`snapshot_filepath`	No
`expected_workbook_sha256`	No

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the destructiveHint=true annotation, the description discloses the safe two-phase protocol (preview before commit), the guardrail role of assertions, and that snapshot creation defaults to enabled — all meaningful safety context. It does not contradict the annotation. It stops short of describing failure semantics, such as what happens when an assertion fails or the expected SHA mismatches.

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?

The description is front-loaded with a crisp purpose sentence, then organized into operation format, assertion list, and workflow steps. The two enumeration lists are long but essential given zero schema coverage. Every sentence earns its place, though the overall density makes it slightly heavy even for a complex tool.

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 destructive, 9-parameter tool with no output schema, the description covers the make-or-break knowledge: the two-phase protocol, what preview returns (token and SHA), and the full operation/assertion vocabularies. Gaps remain around sample_limit, snapshot_filepath, and the precise contents of the preview output beyond the token, so an agent still faces some uncertainty before the first call.

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?

With 0% schema description coverage, the description carries the full burden and largely delivers: it defines the operations payload shape ({"tool": "name", "args": {...}}), enumerates all 11 supported operation tool names, enumerates the 9 assertion types, and explains that changeset_token and expected_workbook_sha256 come from the preview response. It leaves sample_limit and snapshot_filepath unexplained, which prevents a 5.

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?

The first sentence names the specific actions (preview or commit), the resource (a group of workbook mutations), and the distinguishing features (assertion-backed, single transaction). This clearly separates it from single-mutation siblings like write_data_to_excel or format_range, and from apply_workbook_repairs, which addresses a different concept entirely.

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?

The description gives explicit workflow direction: 'Call preview first. Commit the identical plan with expected_workbook_sha256 and changeset_token from that preview.' This is strong when-to-use guidance for the two modes. However, it does not explicitly state when to prefer this batching tool over calling individual mutation tools directly, nor does it name an alternative.

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

apply_workbook_repairsC

Destructive

Apply safe workbook repair actions with dry-run planning and before/after diff output.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`header_row`	No
`sheet_names`	No
`repair_types`	No
`sample_limit`	No

TDQS

C2.8/5.0

Behavior1/5

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

The description says 'safe' workbook repair actions, which contradicts the annotations' destructiveHint=true. The tool may be destructive, yet 'safe' is used without qualification. This is a direct contradiction and gives the agent misleading safety expectations.

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?

The description is a single, front-loaded sentence that conveys the core action and key features. It is concise, though the word 'safe' is misleading and slightly wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has six parameters and no output schema, and the description leaves important context unexplained, such as what repair_types are expected, how sheet_names is used, or what the diff output contains. The mention of dry-run and diff is helpful but insufficient for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the six parameters (filepath, dry_run, header_row, sheet_names, repair_types, sample_limit). Only 'dry-run planning' hint at dry_run, but no semantic detail for the others.

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?

The description uses a specific verb ('apply') and resource ('workbook repair actions'), and clearly distinguishes itself from sibling tools like plan_workbook_repairs by focusing on execution. It also notes dry-run planning and diff output, further defining its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage after planning through 'dry-run planning' but does not explicitly state when to use this tool versus plan_workbook_repairs or diff_workbooks. No alternatives or exclusions are mentioned, so guidance is only implicit.

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

audit_workbookC

Read-only

Audit workbook structure for high-signal issues that affect agent workflows.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`header_row`	No
`sample_limit`	No

TDQS

C2.9/5.0

Behavior3/5

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

The annotation readOnlyHint=true already covers the read-only nature, lowering the bar. The description adds context that the audit focuses on issues affecting agent workflows, but does not disclose output format, potential performance costs, or what constitutes 'high-signal'. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource. Every word earns its place, with no redundant information or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and three parameters, the description is too terse. It does not explain what the audit returns, how sample_limit and header_row affect results, or any behavioral details. The agent lacks sufficient information to invoke the tool correctly with confidence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions none of the three parameters (filepath, header_row, sample_limit), providing no meaning beyond the raw schema field names. This is a significant gap.

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 clearly states the tool audits workbook structure, using a specific verb and resource. It adds scope with 'high-signal issues that affect agent workflows,' which hints at its purpose. However, it doesn't explicitly distinguish from sibling tools like 'profile_workbook' or 'plan_workbook_repairs', so it's clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools such as 'profile_workbook' and 'plan_workbook_repairs', the agent receives no context on selection criteria, exclusions, or alternative workflows.

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

autofit_columnsC

Destructive

Auto-fit worksheet columns based on content width.

ParametersJSON Schema

Name	Required	Description	Default
`columns`	No
`dry_run`	No
`padding`	No
`filepath`	Yes
`max_width`	No
`min_width`	No
`sheet_name`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Annotations include destructiveHint=true, so the agent knows the operation is destructive, but the description adds no extra behavioral context. It does not disclose what exactly gets modified (e.g., whether it overwrites existing column widths, affects only specified columns, or is reversible). Without readOnlyHint or further details, the behavioral profile is incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, direct and free of fluff. It conveys the core purpose without repetition or unnecessary details. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no output schema, and only a destructive hint annotation, a one-sentence description is insufficient. The description does not explain how auto-fit behaves (e.g., whether it applies to all columns or just specified ones, the effect of padding/min/max widths, or the dry_run feature). The agent lacks enough context to confidently invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about any of the 7 parameters. The schema only lists titles and defaults (e.g., columns, dry_run, padding, max_width, min_width), which are ambiguous. The description does not clarify the meaning, usage, or interaction of these parameters, leaving the agent to guess.

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?

The description clearly states a specific action (auto-fit) on a specific resource (worksheet columns) based on content width. This distinguishes it from sibling tools like set_column_widths, which manually sets widths. The verb+object pair is clear and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool vs alternatives such as set_column_widths or format_range. It does not mention when auto-fit is preferred or any exclusions. There is no scenario context or comparison to siblings.

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

bulk_aggregate_workbooksC

Read-only

Aggregate comparable worksheet or table data across multiple workbooks.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`filters`	No
`metrics`	No
`sort_by`	No
`group_by`	No
`row_mode`	No	arrays
`filepaths`	Yes
`sort_desc`	No
`header_row`	No
`sheet_name`	No
`table_name`	No
`schema_mode`	No	strict
`infer_schema`	No
`source_sample_limit`	No

TDQS

C2.9/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, so the safe-read nature is already known. The description adds the 'comparable' constraint, implying data must have compatible schemas, but it does not disclose aggregation behavior, output format, or how missing data is handled. This adds some value but not rich behavioral context.

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?

The description is a single, front-loaded sentence with zero filler. It is efficiently worded, but it is so terse that it omits essential details that could have been included without significant bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 14 parameters, no output schema, and minimal annotations. The description fails to cover critical aspects such as how 'comparable' data is determined, what aggregation metrics are supported, and what the output structure looks like. It is far from complete for this level of complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It mentions none of the 14 parameters (e.g., filepaths, metrics, group_by, schema_mode), leaving all parameter semantics entirely to the raw schema.

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?

The description states the tool aggregates comparable worksheet or table data across multiple workbooks. The verb 'aggregate' and scope 'across multiple workbooks' clearly distinguish it from single-workbook aggregation (aggregate_table) and from join/union tools (union_tables, cross_workbook_lookup).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like union_tables or cross_workbook_lookup. There are no exclusions, prerequisites, or context indicating the best scenarios for this tool.

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

bulk_filter_workbooksA

Read-only

Filter comparable worksheet or table data across multiple workbooks. Uses the same filter operators and aliases as query_table.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`select`	No
`filters`	No
`sort_by`	No
`row_mode`	No	arrays
`filepaths`	Yes
`sort_desc`	No
`header_row`	No
`sheet_name`	No
`table_name`	No
`schema_mode`	No	strict
`infer_schema`	No
`source_sample_limit`	No
`include_source_columns`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the useful behavioral detail that it reuses query_table's filter operators and aliases, but it does not disclose how multi-workbook results are combined, missing-sheet handling, or output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary purpose, and includes only relevant information. No wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 14 parameters and no output schema, the description is far too sparse. It fails to explain how filtering across multiple workbooks works (e.g., combined output, schema compatibility), and it leaves the purpose of many parameters ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate but only references query_table's filter operators. Parameters such as schema_mode, infer_schema, source_sample_limit, and include_source_columns remain completely unexplained, leaving the agent to guess their meaning.

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?

The description clearly states a specific verb ('filter') and resource ('worksheet or table data across multiple workbooks'), distinguishing it from single-workbook tools like query_table. The reference to query_table's operators adds precision about the filtering mechanism.

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?

The description implies the multi-workbook context and the compatibility with query_table's filter syntax, giving enough context for an agent to infer when to use this tool. However, it does not explicitly exclude alternatives or state when not to use it, such as when filtering a single table.

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

copy_rangeC

Destructive

Copy a range of cells to another location.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`source_end`	Yes
`source_start`	Yes
`target_sheet`	No
`target_start`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Although the annotation destructiveHint=true exists, the description does not disclose what destructive behavior occurs (e.g., overwriting target cells). It adds no behavioral context beyond the annotation, leaving key safety implications unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no fluff, but it is under-specified for a tool with 7 parameters. Conciseness is good, but it sacrifices necessary detail, making it minimally adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, destructive annotation, no output schema), the description is incomplete. It does not clarify what happens on execution (e.g., return value or confirmation) or explain dry_run, overwriting behavior, or cross-sheet copying via target_sheet.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it does not explain parameter meanings, formats, or relationships. Names like source_start and target_start are self-explanatory at a high level, but critical details such as cell reference format or the role of target_sheet are omitted.

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?

The description clearly states a specific verb (copy) and resource (range of cells) with a destination (another location). It distinguishes from sibling tools like copy_worksheet by specifying 'range' rather than whole worksheet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, edge cases, or why to choose copy_range over similar tools like copy_worksheet.

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

copy_worksheetB

Destructive

Copy a worksheet with tables, rules, charts, names, and layout settings.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`source_sheet`	Yes
`target_sheet`	Yes

TDQS

B3/5.0

Behavior3/5

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

The destructiveHint annotation already signals mutation, so the description does not need to repeat that. It does add useful behavioral context by listing what gets copied, but it omits important behavioral details such as whether an existing target_sheet is overwritten, whether the operation can be undone, or any side effects on workbook state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler; it states the action, the resource, and the included elements efficiently. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the destructiveHint annotation, no output schema, and sparse parameter descriptions, the tool needs more context to be safely invoked. Critical gaps include what happens if the target worksheet already exists, whether the copied content is linked to the original, and what 'rules' specifically includes. The description is too thin for a destructive worksheet-level operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden of explaining parameters, but it provides none. While the parameter names 'filepath', 'source_sheet', and 'target_sheet' are self-explanatory, there is no clarification of expected formats, overwrite behavior, or relationship between source and target.

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 uses a specific verb ('Copy') and resource ('worksheet'), and enumerates the copied components: 'tables, rules, charts, names, and layout settings.' This makes the tool's scope clear and distinguishes it from range-level operations like copy_range, though it does not explicitly name any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusion criteria. The description only states what the tool does, leaving the agent to infer when it applies.

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

create_chartA

Destructive

Create chart in worksheet from a contiguous range or explicit series.

This is the preferred chart authoring entry point; explicit-series calls are
also still available via create_chart_from_series for backward compatibility.

ParametersJSON Schema

Name	Required	Description	Default
`style`	No
`title`	No
`width`	No
`height`	No
`series`	No
`x_axis`	No
`y_axis`	No
`filepath`	Yes
`placement`	No
`chart_type`	Yes
`data_range`	No
`sheet_name`	Yes
`target_cell`	No
`categories_range`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the safety profile is known. The description adds that the tool works from a contiguous range or explicit series, which is functional context but does not disclose further behavioral nuances like side effects or modifications to the worksheet. It does not contradict annotations, so a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, and includes a useful sibling reference without any extraneous detail. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 14 parameters, no output schema, and many sibling tools. The description covers the basic purpose and entry-point preference but does not explain required vs optional parameters, return behavior, or what happens to existing charts. Given the high complexity, it is notably incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 14 parameters and 0% schema description coverage, the description carries the heavy burden of explaining parameters. It only hints at the data_range vs series distinction via 'contiguous range or explicit series,' but leaves style, title, width, height, placement, target_cell, and other parameters completely unexplained. This is insufficient compensation for the schema 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?

The description clearly states the tool's function: 'Create chart in worksheet from a contiguous range or explicit series.' It uses a specific verb and resource, and distinguishes itself from the sibling tool create_chart_from_series by positioning this as the preferred chart authoring entry point.

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?

It explicitly positions this as the 'preferred chart authoring entry point' and mentions create_chart_from_series as an alternative for explicit-series calls. This provides clear context for when to use this tool, though it lacks explicit 'when not to use' guidance beyond the sibling reference.

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

create_chart_from_seriesB

Destructive

Create a chart from explicit series definitions for non-contiguous ranges.

ParametersJSON Schema

Name	Required	Description	Default
`style`	No
`title`	No
`width`	No
`height`	No
`series`	No
`x_axis`	No
`y_axis`	No
`filepath`	Yes
`placement`	No
`chart_type`	Yes
`sheet_name`	Yes
`target_cell`	No
`categories_range`	No

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, but the description adds no explanation of what destructive action occurs (e.g., overwriting an existing chart or modifying the workbook). It only restates the core function, offering no additional behavioral context beyond the annotation.

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?

The description is a single, front-loaded sentence with no wasted words. It effectively communicates the core purpose, though it's slightly under-specified for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 parameters, no output schema, and zero parameter-level descriptions, this one-sentence description is completely inadequate. It doesn't explain how to define series, what chart types are supported, where charts are placed, or what the return value is. The complexity demands far more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It only refers to 'explicit series definitions' and 'non-contiguous ranges,' hinting at the 'series' and 'categories_range' parameters but leaving the other 11 parameters (e.g., filepath, sheet_name, chart_type, placement) unexplained. This is insufficient for a 13-parameter schema.

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?

The description clearly states the verb ('Create') and resource ('chart from explicit series definitions'), with a specific scope ('non-contiguous ranges') that distinguishes it from the sibling tool 'create_chart'. It immediately conveys what makes this tool unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies the tool is for creating charts with explicit series or non-contiguous ranges, but it doesn't explicitly state when to prefer this over create_chart or other chart tools. It lacks clear alternatives or exclusion criteria.

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

create_named_rangeB

Destructive

Create a workbook-level or sheet-scoped named range.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`hidden`	No
`dry_run`	No
`replace`	No
`filepath`	Yes
`range_ref`	Yes
`sheet_name`	No
`scope_sheet`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the agent knows this is a destructive operation. The description adds the workbook-level vs sheet-scoped distinction, which is useful. However, it doesn't disclose other behavioral traits like whether it overwrites existing ranges, what happens on dry_run, or permission requirements. With annotations covering the safety profile, the description provides only marginal additional context.

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?

The description is a single, concise sentence that avoids redundant phrasing. It front-loads the core purpose. However, it could be slightly more structured to include a couple of key parameters or caveats without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, 0% schema coverage, and no output schema, the description is too thin to provide complete operational context. It doesn't explain the required filepath, range_ref, or name parameters, nor the effect of optional flags like hidden, dry_run, or replace. This is a complex creation tool that needs more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the 8 parameters. It only hints at the 'scope_sheet' parameter via 'sheet-scoped' without explaining any other parameters (e.g., hidden, dry_run, replace, sheet_name). This is insufficient for understanding how to set up the operation.

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?

The description clearly states a specific action ('Create') on a specific resource ('named range') and distinguishes scope options ('workbook-level or sheet-scoped'). This differentiates it clearly from sibling tools like inspect_named_range, list_named_ranges, and delete_named_range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. It doesn't mention when to choose workbook-level vs sheet-scoped, prerequisites (e.g., file must exist), or edge cases (e.g., existing range without 'replace' flag). The only implied usage is creating a named range, which is obvious from the name.

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

create_pivot_tableC

Destructive

Create pivot table in worksheet.

ParametersJSON Schema

Name	Required	Default
`rows`	Yes
`values`	Yes
`columns`	No
`agg_func`	No	sum
`filepath`	Yes
`data_range`	Yes
`sheet_name`	Yes
`replace_existing`	No

TDQS

C2.6/5.0

Behavior2/5

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

The description adds no behavioral context beyond what is already conveyed by the destructiveHint annotation. It does not mention potential side effects (e.g., overwriting existing pivot tables via replace_existing) or any other behavior.

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?

The description is a single, concise sentence with no filler words. It is efficient, though arguably too minimal for a tool of this complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters and a destructive hint, a one-sentence description is insufficient. It fails to mention required inputs, output, or usage scenarios, making it incomplete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description gives no insight into the meaning or format of any of the 8 parameters (e.g., data_range, rows, values). The schema titles provide some hints, but the description does not add value.

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 clearly states the action ('Create') and the resource ('pivot table') with a location ('in worksheet'). It is specific enough to distinguish from sibling tools like create_table, though it doesn't explicitly call out alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool, what prerequisites are needed (e.g., data range, sheet), or which alternative tools might be more appropriate. It is a bare statement with no usage context.

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

create_tableB

Destructive

Creates a native Excel table from a specified range of data.

ParametersJSON Schema

Name	Required	Default
`filepath`	Yes
`data_range`	Yes
`sheet_name`	Yes
`table_name`	No
`table_style`	No	TableStyleMedium9

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already provide destructiveHint: true, but the description adds no additional behavioral context, such as side effects on existing data/formatting, table name uniqueness, or potential errors. For a mutation tool, more disclosure is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no extraneous wording. It is front-loaded with the core action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no output schema, and only a destructive hint annotation, the description is insufficient. It omits details about optional parameters, valid range requirements, and behavior when the range already contains a table or formatting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only mentions 'specified range of data' (data_range). It does not explain filepath, sheet_name, table_name, or table_style, providing negligible value beyond the schema's parameter names.

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?

The description clearly states the tool creates a native Excel table from a specified range. It uses a specific verb ('creates') and resource ('native Excel table'), which distinguishes it from sibling tools like create_workbook and create_worksheet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied: the tool is for turning a data range into an Excel table. However, it does not explicitly mention when to use it over alternatives like format_range or list_tables, nor does it provide exclusions or prerequisites.

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

create_workbookA

Destructive

Create a new Excel workbook with an optional initial worksheet name.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	No		Sheet1

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already signal destructiveHint=true, so the agent knows this is a destructive operation. The description adds no behavioral details beyond the optional worksheet name, such as what happens if the target filepath already exists (overwrite vs. error). It does not contradict annotations, but also provides no additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and includes only relevant detail. No filler words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive create operation, the description omits critical context about file existence behavior: whether the tool overwrites an existing file or fails. It also does not mention return values, but given no output schema and a straightforward action, the main gap is the destructive condition. This is moderately complete but not fully safe for an agent to invoke blindly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for the schema's lack of documentation. It explicitly describes sheet_name as the optional initial worksheet name, adding meaning, but filepath is left undocumented, relying entirely on the parameter name. This is partial compensation.

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?

The description uses a specific verb ('Create') and resource ('Excel workbook'), and distinguishes from sibling tools like create_worksheet by targeting the file itself rather than a sheet inside an existing file. It also adds the key optional parameter detail (initial worksheet name), making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description clearly implies the tool's use case: creating a new workbook file. However, it does not explicitly state when to use this tool versus alternatives such as create_worksheet, nor does it mention preconditions or exclusions. This makes the usage guidance implied rather than explicit.

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

create_workbook_snapshotB

Destructive

Create a verified workbook snapshot without overwriting an existing file.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`snapshot_filepath`	Yes

TDQS

B3.1/5.0

Behavior1/5

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

The description says the tool creates a snapshot 'without overwriting an existing file,' yet the annotations mark it with destructiveHint=true. This is a direct contradiction: the description disclaims the destructive behavior the annotation warns about, and neither explains the 'verified' aspect further.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It delivers the action, the output type, and the key safety constraint in minimal space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 0% schema coverage, no output schema, and a contradictory destructiveHint, the definition is incomplete for safe invocation. The simple two-parameter shape makes the basics inferable, but an agent cannot learn what 'verified' means, what happens if the snapshot path exists, or what a successful call returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not define filepath or snapshot_filepath or their relationship. The only parameter-related clue is the 'without overwriting' constraint, which gives one behavioral detail about snapshot_filepath but leaves formats, source/destination roles, and failure behavior undocumented.

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?

The description begins with a specific verb and object: 'Create a verified workbook snapshot.' The added constraint 'without overwriting an existing file' clarifies the operation's scope and distinguishes it from plain workbook creation or copying tools among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies a backup/verification use case for a workbook, but it never states when to use this tool versus alternatives or what conditions make it the right choice. No sibling tool performs snapshots, so the intent is inferable, but the guidance is only implicit.

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

create_worksheetB

Destructive

Create new worksheet in workbook.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The description adds no behavioral context beyond the action itself. The annotation destructiveHint=true signals potential destructive impact, but the description does not explain what could be destroyed, whether existing sheets are overwritten, or if the operation is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

At six words, the description is extremely concise and front-loaded. Every word contributes functional meaning, with no filler, repetition, or irrelevant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a simple two-parameter create operation, the description covers the core purpose and is minimally viable. However, it leaves gaps: no return value is described, no duplicate/error behavior is mentioned, and parameter details are absent. The annotation and schema provide some context but do not fully compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for parameters, and the description does not define filepath or sheet_name. The parameter names are self-explanatory to some degree, but the description does not compensate for the missing schema details by clarifying how filepath identifies the workbook or how sheet_name is used.

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 'Create new worksheet in workbook' states a specific action and resource, clearly distinguishing it from sibling tools like create_workbook, copy_worksheet, or delete_worksheet. However, it does not explicitly contrast it with alternatives or add any scope constraints, so it falls slightly short of a top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

No explicit when-to-use or alternative guidance is provided. The intended use is implied by the verb 'Create' and the resource 'worksheet', but the description does not mention prerequisites, duplicate-handling scenarios, or when to prefer a different sibling tool.

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

cross_workbook_lookupC

Read-only

Enrich one workbook dataset from matching rows in one or more lookup workbooks.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`select`	No
`row_mode`	No	arrays
`join_type`	No	left
`lookup_key`	No
`match_mode`	No	first
`source_key`	Yes
`schema_mode`	No	strict
`infer_schema`	No
`lookup_select`	No
`case_sensitive`	No
`lookup_sort_by`	No
`source_filepath`	Yes
`lookup_filepaths`	Yes
`lookup_sort_desc`	No
`lookup_header_row`	No
`lookup_sheet_name`	No
`lookup_table_name`	No
`source_header_row`	No
`source_sheet_name`	No
`source_table_name`	No
`lookup_sample_limit`	No
`include_lookup_match_count`	No
`include_lookup_source_columns`	No

TDQS

C2.7/5.0

Behavior2/5

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

The readOnlyHint annotation covers the non-destructive nature, and the description does not contradict it. However, the description adds no extra behavioral context beyond the core concept—no mention of how matches are handled, return format, or impact of parameters like join_type or match_mode. Minimal value beyond annotations.

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?

The description is a single sentence with no redundant wording—highly concise and front-loaded. However, for a tool with 24 parameters, this brevity borders on under-specification, though it still earns a 4 for efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 24 parameters, no output schema, and only a terse one-line description, the tool definition lacks any explanation of expected outputs, parameter interactions, or practical usage context. The description is far from complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage across 24 parameters, and the tool description does not compensate. It only references 'source' and 'lookup' generically, failing to explain critical parameters such as join_type, match_mode, schema_mode, or lookup_select. The agent is left without sufficient meaning to set parameters correctly.

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 clearly states the tool's action ('Enrich one workbook dataset from matching rows') and specifies the resource involved ('one or more lookup workbooks'). This distinguishes it from simple read tools, though it does not explicitly name alternative tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The phrase 'Enrich one workbook dataset from matching rows' implies the use case for cross-workbook lookups, but there is no explicit when-to-use guidance or mention of alternatives like query_table or union_tables. Usage context is only inferred, not stated.

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

delete_named_rangeB

Destructive

Delete a workbook-level or sheet-scoped named range.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`dry_run`	No
`filepath`	Yes
`scope_sheet`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations provide destructiveHint=true, and the description does not contradict this. It adds the context of scope types (workbook-level vs sheet-scoped) which is useful behavioral nuance. However, it does not disclose effects on dependents, the dry_run safety option, or reversibility, so the value added beyond annotations is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no filler. It is front-loaded with the action verb and contains only the essential distinction about scope. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 4 unspecified parameters and no output schema, the one-sentence description is too thin. It omits important operational context such as the use of dry_run, behavior when the named range doesn't exist, or how it differs from generic range deletion. The input schema offers no descriptions, so the overall tool context is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It partially explains scope_sheet via 'workbook-level or sheet-scoped', but does not clarify dry_run, name, or filepath. Given 4 parameters, this is insufficient compensation for the schema 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?

The description clearly states the verb 'Delete' and the resource 'named range', with a specific distinction between workbook-level and sheet-scoped. This differentiates it from sibling tools like delete_range (cell ranges) and aligns with related named range tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contrast with delete_range for cell ranges. Usage is only implied by the name and description.

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

delete_rangeB

Destructive

Delete a range of cells and shift remaining cells.

ParametersJSON Schema

Name	Required	Default
`dry_run`	No
`end_cell`	Yes
`filepath`	Yes
`sheet_name`	Yes
`start_cell`	Yes
`shift_direction`	No	up

TDQS

B3.3/5.0

Behavior3/5

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

The destructiveHint annotation already signals the destructive nature, and the description adds the useful detail that remaining cells are shifted after deletion. However, it does not disclose the impact on formulas, formatting, merged cells, or default shift direction. Given the annotation covers the core destructive trait, the added value is moderate but not extensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that efficiently conveys the core operation. No fluff or redundancy; it is front-loaded with the verb and object.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with six parameters, no output schema, and meaningful optional parameters (dry_run, shift_direction), the description is too sparse. It omits return behavior, error conditions, and the existence of dry_run for safe previewing, leaving significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description is the sole source of parameter meaning. It only loosely implies start_cell/end_cell with 'range' and shift_direction with 'shift', but does not explain any parameter names, value formats (e.g., 'A1:B2'), defaults, or the dry_run safety flag. This is insufficient for an agent to correctly populate all six parameters.

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?

The description clearly states the action (Delete), the target (a range of cells), and the subsequent behavior (shift remaining cells). This distinguishes it from sibling tools like delete_sheet_rows/delete_sheet_columns, which target entire rows/columns, and delete_worksheet, which removes a whole sheet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where range deletion is preferred over deleting entire rows/columns, nor any prerequisites or conditions that would make this tool the right choice.

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

delete_sheet_columnsA

Destructive

Delete one or more columns starting at the specified column.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`dry_run`	No
`filepath`	Yes
`start_col`	Yes
`sheet_name`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the description does not need to restate destructiveness. It adds context about 'starting at the specified column,' but does not mention effects like column shifting or the availability of dry_run. This is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that packs the essential action and scope. Every word earns its place, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the destructive nature and multiple parameters, the description is very sparse. It does not explain the dry_run preview capability, what happens to adjacent columns, or the return value. The tool would benefit from more behavioral detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the burden of explaining parameters. It clarifies start_col and implies count via 'one or more columns,' but fails to mention dry_run, filepath, or sheet_name. The dry_run param is particularly important for a destructive tool.

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?

The description clearly states the action ('Delete') and the resource ('one or more columns') with a specific starting point. It is concise and distinguishes itself from sibling tools like delete_sheet_rows by explicitly targeting columns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies its usage (deleting columns) but does not explicitly contrast with alternatives such as delete_range or delete_worksheet. There is no when-not-to-use guidance, but the tool name and description make the primary use case clear.

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

delete_sheet_rowsC

Destructive

Delete one or more rows starting at the specified row.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`dry_run`	No
`filepath`	Yes
`start_row`	Yes
`sheet_name`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The annotation only provides destructiveHint, but the description does not disclose the dry_run behavior, the irreversibility beyond the hint, or the effect on the remaining rows. It adds little beyond what the parameter names already imply.

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?

The description is a single clear sentence with no wasted words, which is efficient. However, it omits important information that would be necessary for correct use, though that is more a completeness issue than a conciseness one.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters, destructive behavior, and a safety flag. The description is too brief to guide an agent on proper usage, expectations, or the dry_run safety mechanism. No return value is documented, and the dry_run parameter is a critical omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 0% of parameters, so the description must compensate. It vaguely addresses 'start_row' and 'count' but leaves filepath, sheet_name, and especially the critical dry_run parameter unexplained.

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?

The description uses the specific verb 'Delete' with the resource 'rows' and specifies the starting row, effectively distinguishing it from sibling tools like delete_sheet_columns and delete_range. It clearly communicates the core action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of the dry_run option for safe preview. It is purely a statement of action without usage context.

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

delete_worksheetC

Destructive

Delete worksheet from workbook.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

The annotation already discloses destructiveHint: true, and the description adds no extra behavioral context such as whether deletion is permanent, what happens to references, or error conditions. It merely restates the action, providing no value beyond the annotation.

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?

The description is a single concise sentence with no unnecessary words. It is efficiently structured for a simple tool, though it omits potentially useful details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool, the description is too sparse. It lacks information about return values, error handling, prerequisites, and what happens to the worksheet's contents. The annotations cover the destructive aspect, but the overall context is incomplete for an agent to understand the full impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fails to explain 'filepath' and 'sheet_name'. While the names are somewhat self-explanatory, the description does not clarify how these parameters are used (e.g., file path format, workbook structure). The description thus does not compensate for the lack of parameter documentation.

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 uses a specific verb and resource: 'Delete worksheet from workbook.' This clearly states the tool's function and distinguishes it from sibling tools like create_worksheet or rename_worksheet. However, it could be more precise by specifying permanence or scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool vs. alternatives such as hiding a worksheet, clearing contents, or deleting rows. The description simply states the action without providing context on appropriate scenarios or prerequisites.

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

describe_datasetC

Read-only

Summarize a worksheet or native Excel table for agent-friendly orientation.

ParametersJSON Schema

Name	Required	Default
`filepath`	Yes
`header_row`	No
`sheet_name`	No
`table_name`	No
`sample_rows`	No
`read_boundary_mode`	No	default

TDQS

C2.4/5.0

Behavior2/5

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

Annotations declare readOnlyHint=true, which the description does not contradict. However, the description adds almost no behavioral context beyond a vague phrase ('agent-friendly orientation') and does not disclose what the summary contains, how it is returned, or any limitations. With the readOnlyHint covering safety, the bar is lower, but the description still fails to add meaningful behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no wasted words, but it is under-specified. Conciseness without substance is not valuable here; it is too terse to be helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six parameters, no output schema, and only readOnlyHint as an annotation, the description is grossly incomplete. It does not explain what the summary includes, how to choose between sheet/table, or what the output will look like, making it inadequate for reliable agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden of explaining the six parameters. It does not mention any parameter (filepath, header_row, sheet_name, table_name, sample_rows, read_boundary_mode) or clarify their roles, leaving the agent without guidance on how to set them.

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 states a specific verb ('Summarize') and resource ('worksheet or native Excel table') with a clear intended use ('for agent-friendly orientation'). It is not a tautology, but it does not explicitly differentiate from similar siblings like describe_sheet_layout or profile_workbook, which also summarize structures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No information about when to use this tool versus alternatives. It does not mention conditions, exclusions, or how it differs from the many other read/orientation tools, leaving the agent to guess based on the name alone.

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

describe_sheet_layoutB

Read-only

Return a structural worksheet layout summary for safe dashboard-style edits.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes
`sample_limit`	No
`free_canvas_cols`	No
`free_canvas_rows`	No
`free_canvas_limit`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description aligns with that ('Return... summary'). The word 'safe' reinforces non-destructive behavior, but the description doesn't disclose specifics like how layout is computed, what data is read, or whether it samples actual cell contents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently conveys the basic action and purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters and no output schema, the description is too thin. It doesn't describe the return structure, the role of sample_limit, or the meaning of free_canvas metrics, making it hard to know what results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description doesn't explain any of the 6 parameters, especially the free_canvas_* and sample_limit, leaving their semantics unclear. Parameter names in the schema are the only hints.

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 uses a specific verb 'return' and identifies the resource as a 'structural worksheet layout summary' with a purpose clause ('for safe dashboard-style edits'). However, what constitutes the summary is vague and not differentiated from sibling tools like audit_workbook or find_free_canvas.

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?

The phrase 'for safe dashboard-style edits' implies when to use it (before editing), providing clear context. Yet it doesn't mention exclusions or alternatives, stopping short of explicit guidance.

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

detect_circular_dependenciesC

Read-only

Detect circular workbook formula dependencies, including self-references.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sample_limit`	No

TDQS

C2.9/5.0

Behavior3/5

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

The annotation readOnlyHint=true already indicates a safe read operation. The description adds the detail about self-references, but it does not disclose behavior such as how sample_limit affects results, whether it scans the whole workbook, or what output format to expect. The description adds minimal value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that directly states the tool's function without wasted words. It earns its place with the important 'including self-references' nuance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal and lacks information about return values, the effect of sample_limit, or any caveats. Given no output schema and no parameter documentation, the description leaves substantial gaps for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not mention any parameters. filepath and sample_limit are completely unexplained, and the description does not compensate for the schema's lack of documentation. This is a significant gap for a two-parameter tool.

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 clearly states the tool detects circular workbook formula dependencies, including self-references. The verb 'detect' and resource are specific, but it does not differentiate from sibling tools like audit_workbook or analyze_range_impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description implies use for circular dependency detection but offers no guidance on when to prefer this over alternatives, no prerequisites, and no exclusions. It does not state any context beyond the basic purpose.

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

diff_workbooksA

Read-only

Diff two workbook files and report structural changes plus sampled cell-value changes.

ParametersJSON Schema

Name	Required	Description	Default
`sample_limit`	No
`after_filepath`	Yes
`before_filepath`	Yes
`include_cell_changes`	No

TDQS

A3.7/5.0

Behavior3/5

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

The readOnlyHint annotation already indicates a safe read operation, so the description adds value by mentioning 'structural changes' and 'sampled cell-value changes', indicating the tool does not exhaustively report all changes. However, it does not disclose the return format or any additional behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no filler. Every word contributes to understanding the tool's purpose and scope. It is front-loaded and easily parsed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description must explain what the tool returns, but it only states high-level categories ('structural changes plus sampled cell-value changes'). It does not clarify the sample limit's effect, whether structural changes are exhaustive, or the response structure. More detail is needed for an agent to confidently invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, leaving the description to compensate. It mentions 'two workbook files', which maps to the required filepath parameters, and 'sampled' hints at sample_limit. However, it does not explain the meaning of sample_limit or include_cell_changes, leaving significant ambiguity.

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?

The description clearly states the tool's function: 'Diff two workbook files and report structural changes plus sampled cell-value changes.' The verb 'diff' is specific, the resource is 'two workbook files', and the output is described. It distinguishes itself from siblings as the only diff tool.

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?

The description clearly implies the intended use: comparing two versions of a workbook to identify changes. No exclusions or alternatives are mentioned, but the context is clear enough that an agent would know when to use this tool over other read/inspect tools.

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

explain_formula_cellA

Read-only

Explain a formula cell's direct references, upstream formula chain, and downstream dependents.

ParametersJSON Schema

Name	Required	Description	Default
`cell`	Yes
`filepath`	Yes
`max_depth`	No
`sheet_name`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With readOnlyHint=true in annotations, the description adds value by specifying the exact scope of analysis (direct references, upstream chain, downstream dependents). This goes beyond the annotation and gives the agent a clearer picture of the tool's behavior, though it does not mention all edge cases or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that is front-loaded with the action ('Explain') and resource ('formula cell'). Every word contributes to meaning, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex, and no output schema is provided. The description gives a high-level summary but does not explain return values, how the chain is reported, or how max_depth impacts results. It is adequate but leaves room for ambiguity in interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter semantics. It does not explain any of the four parameters (filepath, sheet_name, cell, max_depth) beyond their names. The mention of 'upstream formula chain' hints at max_depth but does not clarify how depth is applied.

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?

The description clearly states the tool's function: explaining a formula cell's direct references, upstream formula chain, and downstream dependents. This specific verb+resource combination distinguishes it from sibling tools like inspect_formula or analyze_range_impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage when one needs to understand formula dependencies, but it does not explicitly mention when to use this over alternatives or provide exclusions. Sibling tools like inspect_formula exist, yet no differentiation is mentioned, leaving usage context implicit.

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

find_free_canvasC

Read-only

Suggest free worksheet slots for charts or dashboard blocks.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`width`	No
`height`	No
`filepath`	Yes
`min_cols`	No
`min_rows`	No
`sheet_name`	Yes
`origin_cell`	No	A1
`search_rows`	No
`padding_rows`	No
`search_columns`	No
`padding_columns`	No

TDQS

C2.4/5.0

Behavior2/5

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

The readOnlyHint annotation already signals a safe read operation, but the description adds no extra behavioral context—such as what constitutes a 'free' slot, how existing content is considered, or whether the search is bounded by sheet dimensions. It does not contradict the annotation, but it fails to disclose meaningful operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise and front-loaded, but it is also under-specifying. While brevity is positive, the structure omits essential information that should accompany a tool with complex parameters, making it more of a vague headline than an effective description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool has 12 parameters, no output schema, and no parameter documentation. The description provides only a high-level summary, leaving the agent without enough context to correctly invoke the tool or interpret results. It is far from complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 12 parameters with 0% coverage by the description. The description mentions none of them, leaving the agent to guess the meaning of origin_cell, search_rows, padding_columns, etc. Given the high parameter count and lack of schema descriptions, this is a critical gap.

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 states a clear verb ('Suggest') and resource ('free worksheet slots for charts or dashboard blocks'), giving a specific purpose. It doesn't explicitly distinguish from sibling tools, but the function is unique enough that the core intent is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like describe_sheet_layout or suggest_read_strategy. There is no mention of typical scenarios, prerequisites, or situations where another tool would be more appropriate.

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

format_rangeC

Destructive

Apply formatting to a range of cells. Colors accept RRGGBB, #RRGGBB, AARRGGBB, or #AARRGGBB.

ParametersJSON Schema

Name	Required	Description	Default
`bold`	No
`italic`	No
`dry_run`	No
`bg_color`	No
`end_cell`	No
`filepath`	Yes
`alignment`	No
`font_size`	No
`underline`	No
`wrap_text`	No
`font_color`	No
`protection`	No
`sheet_name`	Yes
`start_cell`	Yes
`merge_cells`	No
`border_color`	No
`border_style`	No
`number_format`	No
`include_changes`	No
`conditional_format`	No

TDQS

C2.7/5.0

Behavior2/5

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

Annotations indicate `destructiveHint: true`, so the agent knows the operation is potentially destructive, but the description adds little beyond that. It does not mention whether existing formatting is overwritten, whether the file is modified in place, or how `dry_run` or `include_changes` affect behavior. This is a significant transparency gap for a mutation tool.

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?

The description is concise with two sentences, front-loaded with the main action. No redundant words. However, the second sentence, while useful, is narrowly focused on color formats and could be expanded to cover other key parameters without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 20 parameters and no output schema, yet the description provides only a high-level purpose and color format syntax. It lacks critical context such as how to specify the range, what `dry_run` does, what `protection` accepts, and what the result of the operation is. The tool is considerably under-described for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only explains the accepted color formats (RRGGBB, #RRGGBB, etc.) for color-related parameters. The other 17 parameters (e.g., `dry_run`, `protection`, `conditional_format`, `border_style`) are left entirely unexplained, so the description adds minimal value for most parameters.

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 clearly states the tool applies formatting to a range of cells, which is a specific verb+resource. However, it does not distinguish this tool from the sibling `format_ranges` (plural), so the purpose is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as `format_ranges`, `read_range_formatting`, or `copy_range`. There is no mention of exclusions, prerequisites, or ideal use cases, leaving the agent without contextual selection criteria.

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

format_rangesC

Destructive

Apply formatting to multiple ranges in a single workbook pass. Colors accept RRGGBB, #RRGGBB, AARRGGBB, or #AARRGGBB.

ParametersJSON Schema

Name	Required	Description	Default
`ranges`	Yes
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`include_changes`	No

TDQS

C2.9/5.0

Behavior2/5

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

With destructiveHint=true, the description should clarify that existing formatting gets overwritten, but it only states 'Apply formatting' and adds color format variants. It does not disclose side effects like loss of prior formatting or whether the operation is reversible.

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?

Two short sentences, the first states the core purpose and the second gives color format details. No redundant content, but it is under-specified for a 5-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and sparse descriptions, the tool lacks essential context: the shape of range objects, behavior of optional flags, and expected return value. The one useful hint (color formats) is insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description only mentions color format syntax, leaving the structure of the 'ranges' objects and the purpose of dry_run/include_changes entirely unexplained. This does not compensate for the bare schema.

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 uses a specific verb ('Apply') and resource ('formatting to multiple ranges') and notes a single workbook pass, which distinguishes it from the singular format_range sibling. However, it doesn't explicitly name alternatives or detail what formatting entails beyond colors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The phrase 'in a single workbook pass' implies use for batched range formatting, but there is no explicit when-to-use or comparison to format_range or other formatting/reading tools. No exclusions or prerequisites are mentioned.

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

freeze_panesC

Destructive

Set or clear worksheet freeze panes.

ParametersJSON Schema

Name	Required	Description	Default
`cell`	No
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`include_changes`	No

TDQS

C2.8/5.0

Behavior2/5

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

The annotation destructiveHint=true already signals mutating behavior, and the description's 'Set or clear' is consistent. However, the description adds no additional behavioral context, such as overwriting existing freeze settings, reversibility, or side effects. With the annotation present, the bar is lower, but the description still adds no value beyond the structured annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no redundant words. It is front-loaded and easily parseable, which meets the conciseness requirement despite being under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, no output schema, destructive annotation, many siblings), the description is severely incomplete. It does not explain how freeze panes work, which parameter to use for setting vs clearing, or any behavioral implications. It fails to equip an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description mentions no parameters. The tool has 5 parameters (filepath, sheet_name, cell, dry_run, include_changes) that are completely unexplained in both schema and description, leaving the agent with no understanding of how to set or clear freeze panes or what each parameter does.

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?

The description uses a specific verb phrase 'Set or clear' with a clear resource 'worksheet freeze panes'. It unambiguously identifies the operation and distinguishes it from sibling tools like set_autofilter or merge_cells. The double action (set/clear) is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor any context about typical scenarios (e.g., keeping header rows visible). The description only states what it does, not when it should be chosen.

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

get_data_validation_infoB

Read-only

Get all data validation rules in a worksheet.

This tool helps identify which cell ranges have validation rules
and what types of validation are applied.

Args:
    filepath: Path to Excel file
    sheet_name: Name of worksheet
    
Returns:
    JSON string containing all validation rules in the worksheet

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description adds the return format (JSON string) and the scope of retrieval (all rules in the worksheet), which is useful context. However, the read-only behavior is already covered by the readOnlyHint annotation, and the description does not disclose edge cases, performance considerations, or any other behavioral traits beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear opening sentence, an Args section, and a Returns section. Every sentence contributes value, and there is no redundant or filler content. It is appropriately sized for the tool's simplicity.

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 simple read-only tool with two parameters, the description provides adequate context: purpose, parameter roles, and return format. Since there is no output schema, the explicit statement that the return is a JSON string is helpful. It does not explain behavior when no validation rules exist, but that is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The Args section only restates the parameter names with obvious definitions ('filepath: Path to Excel file', 'sheet_name: Name of worksheet'), which adds little meaning beyond the schema itself. This is insufficient for a tool with no schema-level 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 clearly states the tool's function: 'Get all data validation rules in a worksheet.' It uses a specific verb and resource, making the purpose apparent. However, it does not distinguish itself from the sibling tool 'inspect_data_validation_rules', which likely serves a similar function, so it misses the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 lacks any mention of exclusions, prerequisites, or specific scenarios that would help an agent decide between this tool and similar ones like 'inspect_data_validation_rules' or 'read_data_from_excel'.

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

get_merged_cellsB

Read-only

Get merged cells in a worksheet.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent, but it adds no behavioral details beyond the annotation. It does not disclose return format, coordinate system, or whether merged cell ranges are returned as addresses, which leaves transparency minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with no unnecessary words. It is front-loaded with the verb and object, making it very scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain what the return value represents (e.g., range addresses, list of merged regions). It does not, leaving the agent uncertain about how to use the result. The description is sufficient for tool selection but not for complete invocation and downstream use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no parameter-level meaning. It only mentions 'worksheet', loosely mapping to sheet_name, but does not clarify filepath or sheet_name formats. The description completely fails to compensate for the lack of schema descriptions.

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?

The description uses a specific verb 'Get' with a clear resource 'merged cells' scoped to 'in a worksheet', distinguishing it from sibling tools like merge_cells and unmerge_cells. It directly states what the tool retrieves.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage: use this when you want merged cells in a worksheet. However, it provides no explicit guidance on when to use it versus alternatives like inspect_named_range or read_excel_as_table, and no exclusion criteria.

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

get_workbook_metadataB

Read-only

Get metadata about workbook including sheets, ranges, etc.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`include_ranges`	No

TDQS

B3/5.0

Behavior3/5

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

The readOnlyHint annotation already declares the tool as read-only, so the safety profile is covered. The description adds minimal behavioral context ('including sheets, ranges') but doesn't disclose whether include_ranges affects output or other behavioral traits. It is consistent with the annotation, so no contradiction.

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?

The description is a single concise sentence with no fluff. It front-loads the main purpose. The use of 'etc.' is imprecise, but overall it is appropriately sized and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should clarify what metadata is returned. It lists 'sheets, ranges, etc.' but the 'etc.' is vague and doesn't mention other possible metadata like tables, named ranges, or workbook properties. For a simple read-only tool, this is adequate but has clear gaps in return-value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it doesn't explain the parameters. The mention of 'ranges' hints at include_ranges, but filepath and include_ranges are not explicitly described. Parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema.

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 uses a specific verb ('Get') and resource ('metadata about workbook'), with examples ('sheets, ranges'). It clearly indicates a read-only overview task. However, it doesn't explicitly distinguish itself from sibling tools like list_all_sheets or list_named_ranges, and the trailing 'etc.' adds ambiguity about the exact scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. There is no mention of sibling tools, prerequisites, or scenarios where another tool would be more appropriate. The description only states what it does, not when to choose it.

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

get_worksheet_protectionB

Read-only

Get worksheet protection status and option flags.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The annotation readOnlyHint=true already communicates the safe, read-only nature. The description adds no further behavioral context, such as return format, error behavior, or scope constraints. It simply restates the purpose without elaborating on what 'status and option flags' means for the caller.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no filler or redundant content. It is front-loaded with the primary action and target. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description should explain what 'status and option flags' includes or how the return value is structured. Because it does not, the agent lacks critical information about the tool's output. The tool is simple, but the description is still incomplete for making an informed invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, with two parameters (filepath, sheet_name) that have no descriptions. The description does not explain or specify these parameters; it only implies that sheet_name refers to the worksheet and filepath to the file. This is minimal compensation and leaves the agent to guess parameter formats or constraints.

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?

The description clearly states the tool's function: 'Get worksheet protection status and option flags.' It uses a specific verb ('get') and resource ('worksheet protection'), and the purpose distinguishes it from the sibling tool 'set_worksheet_protection', which would be the write counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or any relationship to sibling tools such as set_worksheet_protection. The agent is left to infer usage from the tool's name.

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

insert_columnsB

Destructive

Insert one or more columns starting at the specified column.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`dry_run`	No
`filepath`	Yes
`start_col`	Yes
`sheet_name`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already indicate destructiveHint=true, but the description adds no context about what gets shifted, whether changes are reversible, or the existence of dry_run to avoid mutation. The description provides minimal behavioral insight beyond what annotations and schema already convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the verb and object. It contains no unnecessary words and is appropriately sized for a simple insertion operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no output schema, and 0% schema description coverage, the description is too sparse. It omits the meaning of dry_run, how count behaves, and the effect on existing columns, making it incomplete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain filepath, sheet_name, count, or dry_run. It only implies start_col and count via 'starting at the specified column' and 'one or more', which is insufficient for a 5-parameter tool with no other documentation.

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?

The description clearly states the action ('Insert'), the object ('one or more columns'), and the location ('starting at the specified column'). It differentiates from siblings like insert_rows and delete_sheet_columns by specifying columns and insertion behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 dry_run for previewing or the impact on existing data, and no sibling tools are referenced for comparison.

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

insert_rowsB

Destructive

Insert one or more rows starting at the specified row.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`dry_run`	No
`filepath`	Yes
`start_row`	Yes
`sheet_name`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The description only states the basic insertion action. It does not disclose side effects like shifting existing rows, reversibility, or the purpose of dry_run. The destructiveHint annotation flags mutation, but the description adds no additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no filler or redundancy. It is appropriately concise for the simple action it describes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, a dry_run flag, and no output schema, this one-sentence description is incomplete. It fails to explain dry_run, the impact on existing rows, or any return value, making it inadequate for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that count refers to the number of rows and start_row is the starting position, but it does not explain dry_run, filepath, or sheet_name, leaving a significant 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?

The description clearly states the action (insert), the resource (rows), and the specific location (starting at the specified row). This distinguishes it from sibling tools like insert_columns or append_table_rows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The phrase 'starting at the specified row' implies positional insertion rather than appending, but no alternatives or exclusions are mentioned.

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

inspect_conditional_format_rulesA

Read-only

Inspect worksheet conditional formatting rules with stable rule indexes.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes
`broken_only`	No

TDQS

A3.5/5.0

Behavior4/5

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

The readOnlyHint annotation already declares the read-only nature, and the description is consistent with that. The description adds a behavioral guarantee about 'stable rule indexes', which is not conveyed by annotations. This is useful context for downstream operations that rely on rule identity. However, it doesn't disclose other behavioral details like return format or how broken rules are represented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It states the action and key qualifier efficiently, achieving maximum clarity with minimal length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has three parameters and no output schema, so the description carries the burden of explaining both parameter behavior and return expectations. It fails to explain the 'broken_only' parameter or what details are returned for each rule beyond the promise of stable indexes. Without this context, an agent cannot reliably predict the tool's full behavior or use it correctly in all scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero descriptions (0% coverage), and the description does not mention any parameters. The names 'filepath' and 'sheet_name' are somewhat self-explanatory, but 'broken_only' is not described at all. The description fails to add meaning beyond the bare schema, forcing the agent to guess at parameter 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?

The description clearly states the verb 'inspect' and the resource 'worksheet conditional formatting rules', making the purpose immediately evident. The additional qualifier 'with stable rule indexes' distinguishes this tool from sibling inspection tools like inspect_data_validation_rules, which inspect different rule types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies the tool is for reading conditional formatting rules without modifying them, and the readOnlyHint annotation reinforces this. However, there is no explicit guidance on when to choose this tool over alternatives, such as inspect_data_validation_rules or remove_conditional_format_rules. No when-not-to-use or alternative references are provided.

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

inspect_data_validation_rulesC

Read-only

Inspect worksheet data validation rules with stable rule indexes.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	Yes
`broken_only`	No

TDQS

C2.9/5.0

Behavior3/5

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

The readOnlyHint annotation already establishes the safe, read-only nature of this tool. The description adds minimal behavioral context with the phrase 'stable rule indexes,' implying a guarantee about index stability, but it does not disclose return format, handling of broken rules, or ordering. This aligns with a baseline where annotations carry the safety burden and the description contributes limited extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that uses no filler words. It efficiently states the action and the key qualifier without any redundancy, making it maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the readOnlyHint annotation, the description omits critical context: what the broken_only parameter does, what the return value looks like, and what 'stable rule indexes' means in practice. With no output schema and minimal description, the tool is not adequately contextualized for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no explanations for the parameters. The meanings of filepath, sheet_name, and especially broken_only are left entirely to the agent's inference. The description does nothing to compensate for the missing schema descriptions, making parameter semantics essentially absent.

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?

Description uses the specific verb 'inspect' and identifies the resource as 'worksheet data validation rules.' It adds a distinguishing qualifier 'stable rule indexes' that hints at a unique behavior. However, it does not explicitly contrast with sibling tools like get_data_validation_info, so it stops short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives such as get_data_validation_info or remove_data_validation_rules. The description only states the action without any context, exclusions, or recommendations, leaving the agent without usage direction.

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

inspect_formulaA

Read-only

Inspect a formula string for functions, references, and risky signals.

ParametersJSON Schema

Name	Required	Description	Default
`formula`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

The description adds some context beyond the readOnlyHint annotation by specifying what is inspected, but it does not disclose what the output looks like, what counts as a 'risky signal', or how errors are handled. The annotation already covers safety, and the description adds a modest layer of behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action and object, and contains no redundant words. It is appropriately short and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter, read-only tool, the description gives a basic understanding of the tool's function. However, the lack of an output schema and the vague term 'risky signals' leave gaps about the return format and the precise nature of the analysis, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no description for the 'formula' parameter (0% coverage), so the description must compensate. However, it only states 'formula string', which essentially repeats the parameter name and type without adding format examples or acceptable values. This adds minimal semantic value.

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?

The description clearly states the specific verb 'Inspect' and the resource 'a formula string', and enumerates what is examined: 'functions, references, and risky signals'. This distinguishes it from siblings like validate_formula_syntax and apply_formula, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies when to use the tool—when you need to analyze a formula for functions, references, and risky signals—but it does not provide explicit context about when not to use it or mention alternative tools. The use case is inferable but not explicitly delineated.

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

inspect_named_rangeA

Read-only

Inspect a named range, including scope, destinations, and broken-reference signals.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`filepath`	Yes
`scope_sheet`	No

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, so the description's additional details about scope, destinations, and broken-reference signals provide useful behavioral context beyond the structured data. No contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently communicates the tool's action and key outputs. Every word adds value, with no redundancy.

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?

Given the absence of an output schema and sparse parameter descriptions, the description covers the essential behavioral aspects (scope, destinations, broken-reference signals). It could be more explicit about the return format or parameter usage, but it is adequate for a simple inspection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. While filepath and name are self-explanatory, the scope_sheet parameter is not described, and the description does not explain how parameters relate to the output. The tool adds minimal semantic value over the parameter names.

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?

The description 'Inspect a named range' uses a specific verb and resource, and it clearly distinguishes this tool from siblings like list_named_ranges or delete_named_range. It also adds unique output details (scope, destinations, broken-reference signals) that further clarify its purpose.

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?

The description clearly implies when to use this tool: when you need details about a specific named range. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to select it over listing or modifying tools.

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

list_all_sheetsA

Read-only

List all sheets in a workbook with row/column counts. Quick overview before reading data.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safe read behavior is covered. The description adds value by specifying that the tool returns row/column counts, which is not in the annotations. It also conveys a lightweight intent with 'Quick overview'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the primary action and adding a secondary benefit. Every word earns its place; no fluff, no redundancy.

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 simple read-only list operation with a single obvious parameter and no output schema, the description is complete. It states what it does, what extra information is provided (row/column counts), and when to use it (before reading data). There are no significant gaps for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (filepath) with no description, and the tool description does not elaborate on it. Since schema coverage is 0%, the description carries the burden of explaining the parameter, but it only says 'workbook' without any details about file path format, required extensions, or how to reference the file.

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?

The description clearly states the action (List all sheets), the resource (in a workbook), and the specific detail (with row/column counts). This distinguishes it from sibling tools like list_tables or list_named_ranges, which target different resource types.

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?

The phrase 'Quick overview before reading data' provides clear contextual guidance on when to use this tool. However, it does not explicitly mention alternatives or exclusions, so it stops one step short of full guidance.

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

list_chartsA

Read-only

List embedded charts in a workbook or worksheet.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	No

TDQS

A3.5/5.0

Behavior3/5

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

The readOnlyHint annotation already establishes this as a read-only operation. The description adds the workbook/worksheet scope but offers no detail on return format, behavior for missing sheets, or whether charts are returned with metadata. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly worded sentence of eight words. Every word contributes to purpose and scope; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with two params and no output schema, the description is minimally viable but leaves gaps: no return value description, no guidance on optional sheet_name, and no differentiation from sibling tools. It does what is needed for basic selection but not more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It hints at the two-level scope via 'workbook or worksheet,' which partially maps to filepath and sheet_name, but it doesn't explicitly explain that sheet_name is optional or how null behaves. Some added meaning, but not robust.

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?

The description uses a specific verb ('List'), names the resource ('embedded charts'), and specifies scope ('in a workbook or worksheet'), clearly distinguishing it from siblings like list_tables or list_named_ranges. It precisely states what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. There is no mention of when to prefer list_charts over list_tables or other listing tools, and no exclusions or prerequisites are stated.

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

list_named_rangesA

Read-only

List workbook defined names and their destinations.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds 'and their destinations,' clarifying the scope of the returned information. It does not mention edge cases like missing files or potential errors, but for a read-only enumeration this is acceptable. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is perfectly front-loaded, stating the verb and resource immediately.

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?

The tool is simple: one parameter, read-only, no output schema. The description and annotation together cover the essential behavior—listing named ranges and their destinations. Minor gaps like error behavior or prerequisites are not critical for this type of tool, and the description is complete enough for the agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the single 'filepath' parameter is self-explanatory from its name. The description's mention of 'workbook' implies filepath points to the workbook, adding some meaning beyond the raw schema. However, no explicit format, path constraints, or examples are provided.

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?

The description clearly identifies the action ('List') and the resource ('workbook defined names') while also specifying what is returned ('their destinations'). It distinguishes this from sibling tools like inspect_named_range (which targets a specific named range) and create_named_range/delete_named_range (which modify).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies the tool is used when you need to enumerate defined names in a workbook, but it does not explicitly contrast with inspect_named_range or list_tables, nor does it state when not to use it. For a straightforward listing tool, the context is decent but not explicit.

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

list_tablesA

Read-only

List native Excel tables for one worksheet or the whole workbook.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`sheet_name`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds that only 'native Excel tables' (not ranges or sheet data) are listed and that scope can be per-sheet or whole workbook. However, it does not disclose behavior for invalid sheet names or return format, which annotations do not need to cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action and resource, with no filler. Every word adds meaning.

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 simple read-only listing tool, the description plus annotations cover the core purpose, scope, and safety. The schema is minimal, and no output schema exists. It lacks explicit usage guidance and parameter details, but is largely sufficient for this low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explicitly explain filepath or sheet_name. 'one worksheet or the whole workbook' implies the optionality of sheet_name, but filepath remains undefined. The description adds minimal value beyond the schema's parameter names.

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?

Description clearly states a specific verb ('List') targeting a specific resource ('native Excel tables') with scope options ('one worksheet or the whole workbook'). This distinguishes it from sibling tools like list_named_ranges or read_excel_table.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives, nor when to pass a sheet_name versus omitting it. The scope mention is the only contextual cue, but it does not cover selection criteria or exclusions.

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

merge_cellsC

Destructive

Merge a range of cells.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`end_cell`	Yes
`filepath`	Yes
`sheet_name`	Yes
`start_cell`	Yes
`include_changes`	No

TDQS

C2/5.0

Behavior2/5

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

With destructiveHint=true in annotations, the agent knows this is a destructive operation, but the description adds no additional behavioral context such as what content is overwritten, whether the merge is irreversible, or how the dry_run/include_changes parameters affect execution. The description is silent on all behavioral traits beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise in length, but it is under-specified. It provides almost no substantive information, making it more of a placeholder than a concise, high-value description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, a destructive operation, and no output schema), the description is drastically incomplete. It fails to explain the merge behavior, the range semantics, or the purpose of optional parameters, making it impossible for an agent to invoke the tool correctly without external information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the six parameters, especially required ones like start_cell and end_cell. It does not mention any parameter semantics; for instance, it does not clarify whether start_cell and end_cell define the top-left and bottom-right corners of the merge range, or what dry_run true does. This is a significant gap.

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

Purpose3/5

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

The description states the action (merge) and the object (a range of cells), but it is nearly a restatement of the tool name. It provides no details that differentiate it from sibling tools such as unmerge_cells or get_merged_cells, and the specifics of how merging behaves (e.g., alignment, value handling) are absent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the range being within the same sheet, or when dry_run might be appropriate. No exclusions or alternatives are noted.

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

plan_workbook_repairsB

Read-only

Turn workbook audit findings into prioritized next steps for SheetForge workflows.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`header_row`	No
`sample_limit`	No

TDQS

B3.1/5.0

Behavior3/5

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

The readOnlyHint annotation already communicates the tool's non-mutating nature, lowering the burden on the description. The description adds minimal behavioral context ('prioritized next steps') but does not disclose output format, side effects, or how the tool operates beyond the purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no filler. It front-loads the core purpose and avoids unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description omits critical information such as what the 'prioritized next steps' look like, how parameters like sample_limit affect the output, and how the tool fits into the broader audit-repair workflow. Since there is no output schema, the description should provide more context but does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the tool description mentions none of the three parameters (filepath, header_row, sample_limit). The description does not compensate for the lack of parameter documentation, leaving their roles entirely unexplained.

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 'Turn workbook audit findings into prioritized next steps' clearly states the tool's purpose as a planning/analysis operation. It distinguishes itself from sibling tools like apply_workbook_repairs (which actually applies fixes) and audit_workbook (which produces the findings), though it doesn't explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The phrase 'workbook audit findings' implies usage after an audit and before repairs, but the description provides no explicit guidance on when to use this tool versus alternatives. It relies on the reader to infer the workflow context.

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

profile_workbookB

Read-only

Return a compact workbook inventory with sheets, tables, charts, and layout state.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds the inventory content but does not disclose other behaviors like result format, performance impact, or error conditions. This adds some value but not substantial context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no redundancy or extraneous detail. It is front-loaded with the main action and resource, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description outlines the inventory content but leaves out details on the structure or format of the returned data, and does not clarify terms like 'layout state.' With no output schema and a single obvious parameter, the description is minimally adequate but not fully complete for an agent to predict the tool's exact output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no description for the 'filepath' parameter (0% coverage). The tool description does not explain the expected path format, file types, or any constraints. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema-level documentation.

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?

The description clearly states the tool's action ('Return') and resource ('a compact workbook inventory'), specifying the contents as sheets, tables, charts, and layout state. This distinguishes it from sibling tools like list_all_sheets or list_charts, which focus on individual aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as needing a quick overview or avoiding multiple list calls, leaving the agent without cues for tool selection.

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

query_tableB

Read-only

Filter, project, sort, and limit worksheet or table data. Filters support eq/neq/ne, comparisons, string matching, blank checks, and in/not_in with value or values.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`select`	No
`filters`	No
`sort_by`	No
`filepath`	Yes
`row_mode`	No	arrays
`sort_desc`	No
`header_row`	No
`sheet_name`	No
`table_name`	No
`infer_schema`	No

TDQS

B3/5.0

Behavior3/5

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

Annotations declare readOnlyHint: true, and the description adds value by enumerating supported filter operators (eq/neq, comparisons, string matching, blank checks, in/not_in). It does not disclose return format or edge-case behavior, but annotation coverage lowers the bar; some behavioral context is added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary operations. No filler; every word adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters and no output schema, the description covers only the core query operations. It omits parameter semantics for row_mode, header_row, sheet/table selection, infer_schema, and any return-value description, making it incomplete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies the 'filters' parameter by listing allowed operators and implies select/sort_by/limit via 'filter, project, sort, limit'. However, row_mode, header_row, sheet_name, table_name, infer_schema, and sort_desc remain undocumented, leaving significant gaps.

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?

Description clearly identifies the tool's function (filter, project, sort, limit) on worksheet/table data, with specific filter operator detail. However, it doesn't explicitly differentiate from sibling read tools like read_excel_as_table or quick_read, so it's clear but not fully distinguishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description implies a query use case but never states exclusions or recommends simpler tools for basic reads. Siblings like quick_read and read_excel_as_table would benefit from a comparison.

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

quick_readA

Read-only

Read a compact table from an explicit sheet or the first workbook sheet.

Can return either array rows or object-shaped records, plus optional schema hints inferred from the returned rows.

ParametersJSON Schema

Name	Required	Default
`end_col`	No
`filepath`	Yes
`max_rows`	No
`row_mode`	No	arrays
`start_col`	No	A
`start_row`	No
`header_row`	No
`sheet_name`	No
`infer_schema`	No
`include_headers`	No
`read_boundary_mode`	No	default

TDQS

A3.6/5.0

Behavior4/5

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

With readOnlyHint=true in the annotations, the safety profile is already known. The description adds useful behavioral context: output can be array rows or object records, schema hints may be inferred, and the sheet can be explicit or defaulted to the first workbook sheet.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The primary purpose is front-loaded, and the flexible output behavior is stated in a compact second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool has 11 parameters and no output schema, yet the description does not explain key behavioral terms like read_boundary_mode or what 'compact table' means, nor does it document defaults for boundary handling. For correct invocation, the agent is left to infer too much from parameter names and sibling context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description carries the burden. It clarifies row_mode, infer_schema, sheet_name, and filepath behavior indirectly, but many parameters (read_boundary_mode, include_headers, start_col, end_col, max_rows, etc.) remain unexplained beyond their names.

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 identifies a specific verb ('Read') and resource ('compact table'), and specifies the source as an explicit sheet or the first workbook sheet. It stops short of differentiating itself from the many sibling read tools by name or explicit conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The word 'compact' and the tool name 'quick_read' imply a lightweight read for simple table extraction, and the statement about array/object records hints at flexible output. However, there is no explicit when-to-use guidance, exclusions, or comparison with sibling tools such as read_data_from_excel or query_table.

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

read_data_from_excelA

Read-only

Read data from Excel worksheet with cell metadata including validation rules.

Args:
    filepath: Path to Excel file
    sheet_name: Name of worksheet
    start_cell: Starting cell (default A1)
    end_cell: Ending cell (optional, auto-expands if not provided)
    max_rows: Optional maximum number of rows to return from the starting row
    max_cols: Optional maximum number of columns to return from the starting column
    cursor: Optional continuation token returned by an earlier range read
    preview_only: Whether to return preview only
    compact: Whether to omit default validation metadata for smaller responses
    values_only: Whether to return a 2D value grid without per-cell metadata

Returns:  
JSON string containing either structured cell data with validation metadata
or a plain 2D value grid when values_only=True.

ParametersJSON Schema

Name	Required	Default
`cursor`	No
`compact`	No
`end_cell`	No
`filepath`	Yes
`max_cols`	No
`max_rows`	No
`sheet_name`	Yes
`start_cell`	No	A1
`values_only`	No
`preview_only`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: it mentions cursor continuation tokens for range reads, auto-expansion of end_cell, and the compact and values_only modes that alter the response structure. This is useful, non-contradictory information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief one-sentence purpose, a bulleted Args list, and a Returns section. It covers all parameters without redundancy or fluff, making it both comprehensive and scannable.

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 tool with 10 parameters and no output schema, the description adequately covers all parameters and the return type, including the values_only mode. It could be more explicit about cursor pagination usage (e.g., whether to resend all parameters), but it provides sufficient context for understanding the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage (0%), so the description fully compensates by explaining all 10 parameters with concise, meaningful one-liners covering defaults, optionality, and behavior. This is essential for correctly invoking the tool with such a large parameter set.

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 clearly states the tool reads data from an Excel worksheet with cell metadata including validation rules, which is a specific verb+resource+scope. However, it does not explicitly differentiate from sibling tools like read_excel_as_table or quick_read, relying on the metadata mention as an implicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives. The description lists parameters but does not state use cases, prerequisites, or alternative tool recommendations, leaving the agent to infer usage context from the tool's name and parameter details.

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

read_excel_as_tableA

Read-only

Read Excel data as a compact table with headers and rows or record objects.
Much more context-efficient than read_data_from_excel for structured data,
with optional inferred schema hints for downstream steps.

ParametersJSON Schema

Name	Required	Default
`compact`	No
`end_col`	No
`filepath`	Yes
`max_rows`	No
`row_mode`	No	arrays
`start_col`	No	A
`start_row`	No
`header_row`	No
`sheet_name`	Yes
`infer_schema`	No
`include_headers`	No
`read_boundary_mode`	No	default

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds that the output is a compact table (context-efficient) and mentions schema inference, which are useful behavioral traits. But it doesn't disclose output structure details (e.g., how rows are represented, row limits, or error behavior), leaving some behavioral transparency gaps beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences long. The first sentence states the core function and output format; the second adds a key differentiator (context efficiency) and a feature (schema hints). It is front-loaded and contains no filler or redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, 0% schema coverage, no output schema), the description is inadequate. It does not explain how to specify source ranges, row/column options, or the meaning of compact and row_mode. An agent cannot correctly configure calls without consulting external documentation or guessing. The description covers only the primary intent and a single advantage, leaving most operational details unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the 12 parameters. It only vaguely references 'optional inferred schema hints,' which corresponds to infer_schema, but does not name or explain any other parameter (filepath, sheet_name, start_row, row_mode, etc.). This is a major gap for such a parameter-rich tool; the description fails to compensate for the absent schema documentation.

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?

The description clearly states the tool's purpose: 'Read Excel data as a compact table with headers and rows or record objects.' It identifies the specific resource (Excel data) and output format, and explicitly contrasts with sibling read_data_from_excel ('Much more context-efficient than read_data_from_excel for structured data'), making it distinguishable from that common alternative.

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?

The description provides a clear usage hint: use this tool over read_data_from_excel for structured data when context efficiency matters. It also implies suitability for downstream steps via 'optional inferred schema hints.' However, it does not mention other closely related siblings (e.g., read_excel_table, quick_read) or state when not to use it, so guidance is partial.

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

read_excel_tableA

Read-only

Read a native Excel table by its table name.

Supports compact table payloads, object-shaped record output, and optional inferred schema hints.

ParametersJSON Schema

Name	Required	Default
`compact`	No
`end_col`	No
`filepath`	Yes
`max_rows`	No
`row_mode`	No	arrays
`start_col`	No
`start_row`	No
`sheet_name`	No
`table_name`	Yes
`infer_schema`	No
`include_headers`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description adds behavioral context about supporting 'compact table payloads,' 'object-shaped record output,' and 'inferred schema hints.' While useful, these terms are vague and not fully explained, leaving some behavioral transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with the primary purpose front-loaded. The second sentence adds key capabilities without redundancy or excessive detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and minimal annotations, the description is insufficient for confident invocation. It omits return format, parameter behaviors, and differentiation from the many sibling read tools, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate by explaining parameter meanings. It mentions 'compact' and 'inferred schema,' but does not map these to schema properties, leaving most of the 11 parameters undefined.

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?

The description clearly states 'Read a native Excel table by its table name,' specifying a distinct verb, resource, and scope. This differentiates it from sibling tools like read_data_from_excel and read_excel_as_table, which likely handle ranges or non-native tables.

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?

The description implies usage for reading native Excel tables via their table name, providing clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it stops short of full usage guidance.

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

read_range_formattingC

Read-only

Read a compact formatting summary for a worksheet range.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`range_ref`	Yes
`sheet_name`	Yes
`sample_limit`	No

TDQS

C2.9/5.0

Behavior3/5

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

The description is consistent with the readOnlyHint annotation, confirming a read operation. It adds the term 'compact' but does not elaborate on what the summary includes, how sample_limit affects results, or error behavior. With annotations already covering safety, this is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no redundancy. It communicates the core purpose efficiently, though it sacrifices detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The absence of an output schema and minimal description leaves the return format, sample_limit semantics, and formatting details unspecified. For a 4-parameter tool with no schema descriptions, the description is too sparse to be fully contextual.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain filepath, sheet_name, range_ref, or sample_limit. It only hints at 'worksheet range', leaving all parameter semantics to their field names.

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?

Clearly states the tool reads a compact formatting summary for a worksheet range, with a specific verb ('read') and resource ('formatting summary'). It inherently distinguishes from data-reading or formatting-modification siblings, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 instead of sibling tools like read_data_from_excel, inspect_formula, or format_range. The description lacks context, prerequisites, or exclusions.

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

remove_conditional_format_rulesA

Destructive

Remove worksheet conditional formatting rules by index or remove all broken ones.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`broken_only`	No
`rule_indexes`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the description does not need to restate that. However, it does not mention the dry_run parameter's preview behavior or clarify what constitutes a 'broken' rule, both of which are behavioral traits beyond the annotation. The two removal modes add some context, but the description remains thin on side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It conveys the core action and two modes efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, a destructive annotation, and no output schema, the description is slightly underspecified. It lacks mention of the dry_run preview flag, the return value, and the recommended workflow of inspecting rules first (sibling inspect_conditional_format_rules exists). However, the core operation is clear enough for basic usage, so it is minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially explains the rule_indexes and broken_only parameters via the phrase 'by index or remove all broken ones', but does not describe dry_run, filepath, or sheet_name semantics. Param names are self-evident for the latter two, but dry_run remains unexplained. The description adds some value but does not fully cover the schema's parameters.

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?

The description clearly specifies the verb 'Remove' and the resource 'worksheet conditional formatting rules', with explicit scoping via 'by index or remove all broken ones'. This distinguishes it from sibling tools like inspect_conditional_format_rules (read operation) and remove_data_validation_rules (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description gives some context about the two operating modes (by index or broken-only), but it does not explicitly mention when to prefer this over inspecting rules first, nor does it name alternatives or exclusions. Usage guidance is implied rather than explicit.

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

remove_data_validation_rulesA

Destructive

Remove worksheet data validation rules by index or remove all broken ones.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`broken_only`	No
`rule_indexes`	No

TDQS

A3.5/5.0

Behavior3/5

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

The description adds context by mentioning the 'broken only' mode, but beyond that and the destructiveHint annotation, it does not disclose irreversibility, impact on dependent cells, or what constitutes 'broken'. The meaning of 'broken' is left ambiguous, which is a transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no redundant words. The phrase 'Remove worksheet data validation rules' is specific, and every word contributes to the purpose without wasted filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive tool with 5 parameters and no output schema, yet the description omits dry_run semantics, the definition of 'broken', and any reference to listing rules first (e.g., via inspect_data_validation_rules). The overall context is thin for a mutation tool, leaving the agent to guess critical operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for parameter semantics. It maps 'by index' to rule_indexes and 'broken ones' to broken_only, but it does not explain filepath, sheet_name, or the critical dry_run parameter. The dry_run omission is especially problematic for a destructive tool.

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?

The description uses a specific verb ('Remove') with a clear resource ('worksheet data validation rules') and specifies two modes (by index, broken only), distinguishing it from sibling tools like remove_conditional_format_rules. The purpose is immediately understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied from the verb and the mention of 'by index or remove all broken ones', but there is no explicit guidance on when to use this tool versus alternatives like inspect_data_validation_rules. No prerequisites, exclusions, or workflow context are provided.

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

rename_worksheetC

Destructive

Rename worksheet in workbook.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes
`new_name`	Yes
`old_name`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

The destructiveHint: true annotation already indicates mutating behavior, but the description adds no extra context beyond the annotation. It does not disclose potential side effects like broken references or formula updates, and does not contradict the annotation.

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?

The description is a single, front-loaded sentence that efficiently states the core action. It is appropriately concise for a simple operation, though it sacrifices important context that would make it more informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, sparse annotations, and 0% parameter coverage, this description is severely under-specified. It fails to explain return values, error conditions, or the impact on workbook data, making it inadequate for an agent to use the tool safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description offers no parameter-level details. While the parameter names (filepath, old_name, new_name) are self-explanatory, the description does not compensate for the missing schema descriptions, such as constraints or expected formats.

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 clearly states the action ('Rename') and the resource ('worksheet in workbook'), making the tool's purpose obvious. However, it does not differentiate from sibling tools like copy_worksheet or delete_worksheet beyond the inherent semantic distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool vs. alternatives. It omits prerequisites such as the worksheet existing or the new name being unique, and does not mention any exclusions or preferred contexts.

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

search_in_sheetD

Read-only

Search for cells matching a value in a worksheet.

ParametersJSON Schema

Name	Required	Description	Default
`exact`	No
`query`	Yes
`filepath`	Yes
`sheet_name`	Yes
`max_results`	No

TDQS

D1.8/5.0

Behavior2/5

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

The description only states that it searches for matching cells, providing no details on exact vs. partial matching, case sensitivity, return format, or limits. The readOnlyHint=true annotation is present but the description adds no behavioral context beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, but it is under-specified rather than appropriately concise. It repeats information already present in the tool name and provides no additional useful content, so it does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters and no output schema, yet the description gives no information about search behavior, return format, matching rules, or limitations. It is completely inadequate for a tool with this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions no parameters and does not explain the meaning or behavior of query, exact, max_results, filepath, or sheet_name. It completely fails to compensate for the schema's lack of descriptions.

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

Purpose2/5

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

The description 'Search for cells matching a value in a worksheet' essentially restates the tool name 'search_in_sheet' and the annotation title 'Search Cells'. It uses the same verb and resource without adding scope, matching semantics, or differentiation from sibling tools like query_table or read_data_from_excel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is given about when to prefer this tool over alternatives. The sibling list includes many reading/searching tools (e.g., read_data_from_excel, query_table), but the description does not mention any differentiators or exclusions.

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

set_autofilterB

Destructive

Set worksheet autofilter for an explicit or inferred range.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`range_ref`	No
`sheet_name`	Yes
`include_changes`	No

TDQS

B3.3/5.0

Behavior3/5

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

The annotations already declare destructiveHint=true, which is consistent with the set operation. The description adds value by explaining the range inference behavior, but does not disclose what happens to an existing autofilter or any other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single, well-structured sentence that is front-loaded with the primary action and resource. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no output schema, and a destructive hint, the description is too sparse. It lacks explanation of the inference mechanism, the effect on existing filters, and the roles of dry_run and include_changes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only hints at range_ref via 'explicit or inferred range', leaving filepath, sheet_name, dry_run, and include_changes to schema defaults without added meaning.

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?

The description clearly states the action ('Set'), the resource ('worksheet autofilter'), and the scope ('for an explicit or inferred range'). It distinguishes from all sibling tools, none of which mention autofilter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what it does without context for the decision.

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

set_column_widthsC

Destructive

Set explicit widths for one or more worksheet columns.

ParametersJSON Schema

Name	Required	Description	Default
`widths`	Yes
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`include_changes`	No

TDQS

C2.9/5.0

Behavior2/5

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

The only behavioral signal is the annotation destructiveHint=true; the description adds no extra context about overwriting existing widths, return values, or effects of dry_run. It does not contradict annotations but fails to enrich them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single 9-word sentence that is front-loaded and free of filler. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with a nested object and no output schema, the description is too sparse. It lacks details on the key-value mapping for widths, the effect of dry_run, and how changes are reported, making it inadequate for reliable invocation in a complex spreadsheet toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate. It does not explain the structure of the 'widths' object, the meaning of dry_run, or the include_changes parameter, leaving all parameter semantics to the bare property names.

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?

Description clearly states the verb 'set' and resource 'column widths', with 'explicit' distinguishing it from autofit_columns and other width-related tools. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like autofit_columns or set_row_heights. The description only states what it does, leaving usage context entirely to inference.

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

set_print_areaB

Destructive

Set or clear worksheet print area.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`range_ref`	No
`sheet_name`	Yes
`include_changes`	No

TDQS

B3/5.0

Behavior3/5

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

Annotations already disclose destructiveHint=true, and the description adds the 'or clear' behavior, which clarifies the tool can both set and remove the print area. However, it does not detail other behavioral aspects like whether existing settings are overwritten or what happens when `range_ref` is null. This exceeds the baseline for annotation-only transparency but remains limited.

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?

The description is a single short sentence, highly efficient and easy to parse. It front-loads the core action with no filler, though its brevity sacrifices explanatory depth.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no output schema, and only a destructive annotation, the description is far from complete. It omits when to use the tool, parameter semantics, side effects, and expected outcomes, leaving significant gaps for an agent attempting to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero descriptions, and the description's 'Set or clear' does not explain any parameter meanings. Parameters like `range_ref`, `include_changes`, and `dry_run` are left entirely undefined, and the description fails to compensate for the 0% schema coverage.

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?

The description uses the clear verb 'Set or clear' paired with the specific resource 'worksheet print area,' which immediately distinguishes it from sibling tools like `set_print_titles` and `freeze_panes`. It unambiguously communicates the tool's primary function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as `set_print_titles` or `format_range`. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without direction on choosing this tool.

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

set_print_titlesA

Destructive

Set, preserve, or clear repeating print title rows and columns.

ParametersJSON Schema

Name	Required	Description	Default
`rows`	No
`columns`	No
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`include_changes`	No

TDQS

A3.5/5.0

Behavior3/5

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

The description adds behavioral context beyond the destructiveHint annotation by stating that the tool can preserve or clear existing settings, not just set them. However, it does not disclose side effects, what 'preserve' means in terms of null values, or how dry_run and include_changes affect behavior. The annotation provides the destructive warning, but the description remains thin on operational detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and target. Every word earns its place, and there is no filler, repetition, or unnecessary detail. It is an appropriately sized and well-structured summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite moderate complexity (6 parameters, no output schema, destructive annotation), the description does not explain how to use the parameters or what the tool returns. It omits critical details such as row/column syntax, the effect of dry_run, and the meaning of include_changes. The tool is not fully described for an agent to invoke it correctly without additional inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it only mentions rows and columns in generic terms. It does not explain the accepted format (e.g., '1:3' or 'A:C') or the purpose of dry_run and include_changes. The two required parameters filepath and sheet_name are factually obvious, but the core parameters rows and columns are left under-specified.

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?

The description uses a specific verb set with a clear resource: 'repeating print title rows and columns.' It distinguishes itself from sibling tools like set_print_area by focusing on print titles rather than the print area. The three actions (set, preserve, clear) fully convey the tool's scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The phrase 'repeating print title rows and columns' implies when to use the tool, but there is no explicit guidance about when not to use it or mention of alternatives. Sibling tools such as set_print_area or freeze_panes exist, but the description does not differentiate them or state exclusions. Usage context is implied but not explicit.

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

set_row_heightsB

Destructive

Set explicit heights for one or more worksheet rows.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`heights`	Yes
`filepath`	Yes
`sheet_name`	Yes
`include_changes`	No

TDQS

B3.3/5.0

Behavior2/5

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

Annotations only provide destructiveHint (a mutation operation). The description adds no behavioral context beyond the intended effect, such as whether existing heights are overwritten, the unit of measure, or the meaning of dry_run/include_changes. It fails to disclose any non-obvious side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence of 10 words, front-loaded with the primary action. Every word contributes meaning; there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 5-parameter tool with a nested heights object and no output schema, the description is far too sparse. It omits critical details such as how rows are identified (e.g., row numbers), the expected format of heights, the purpose of dry_run/include_changes, and safety implications beyond the destructiveHint annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any parameters. The 'heights' object's structure (row identifier → number) is not clarified, nor are dry_run and include_changes. The description offers minimal semantic value for the five parameters.

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?

The description uses a specific verb ('Set') and resource ('explicit heights for one or more worksheet rows'), which clearly defines the tool's function and distinguishes it from sibling tools like set_column_widths or autofit_columns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage (when you need to fix row heights manually) but provides no explicit when-to-use/when-not-to-use guidance or references to alternatives such as autofit_columns. This is a minimal, implied-level of guidance.

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

set_worksheet_protectionB

Destructive

Enable or disable worksheet protection with optional capability flags.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`enabled`	No
`options`	No
`filepath`	Yes
`password`	No
`sheet_name`	Yes
`include_changes`	No

TDQS

B3.1/5.0

Behavior3/5

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

The annotation destructiveHint: true already flags this as a mutating operation. The description adds minimal context beyond this, only mentioning 'optional capability flags.' It does not disclose the effects of password protection, how options alter behavior, or any side effects. While the annotation lowers the bar, the description still provides little additional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that conveys the core purpose without unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, 2 required, no output schema), the description is far too sparse. It doesn't mention the return value, potential errors, password semantics, or the effect of dry_run/include_changes. The agent is left without sufficient context to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description does not compensate by explaining any parameters. It only mentions 'optional capability flags' which vaguely alludes to the 'options' parameter, but leaves filepath, sheet_name, enabled, password, dry_run, and include_changes completely unexplained.

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?

The description clearly states the tool's purpose: enabling or disabling worksheet protection, with optional capability flags. The verb 'enable or disable' is specific and the resource 'worksheet protection' is clear. It also distinguishes from the sibling tool get_worksheet_protection by indicating a mutating action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like get_worksheet_protection. There are no prerequisites, exclusions, or contextual hints about when enabling/disabling protection might be appropriate.

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

set_worksheet_visibilityA

Destructive

Set worksheet visibility to visible, hidden, or veryHidden.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`visibility`	Yes
`include_changes`	No

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, and the description does not contradict this. The description adds the allowed visibility values, which is helpful but not deep behavioral context (e.g., reversibility, side effects). With annotations present, the baseline is lower and the description provides minimal extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core action and allowed values with no filler. It is appropriately front-loaded and every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters including dry_run and include_changes, but the description does not explain their behavior or return values. There is no output schema, so the agent lacks critical context about the tool's side effects and output. The description is incomplete for a tool with this many parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does clarify that 'visibility' accepts 'visible', 'hidden', or 'veryHidden', which adds meaning beyond the schema. However, it provides no information about filepath, sheet_name, dry_run, or include_changes, leaving the agent to infer their purpose from names alone.

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?

The description uses a specific verb 'set' with a clear resource 'worksheet visibility' and enumerates the exact allowed values (visible, hidden, veryHidden). This fully distinguishes the tool from sibling tools like delete_worksheet or rename_worksheet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage: if you need to change worksheet visibility, use this tool. However, it provides no explicit guidance on when not to use it or alternatives, so it relies on implication rather than explicit direction.

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

suggest_read_strategyA

Read-only

Recommend the best SheetForge read tool for the requested workbook target.

ParametersJSON Schema

Name	Required	Description	Default
`goal`	No
`filepath`	Yes
`header_row`	No
`sheet_name`	No
`table_name`	No
`sample_rows`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description adds that the tool recommends a tool rather than performing the read itself—a useful behavioral disclosure. It doesn't explain how 'best' is determined or what the recommendation contains, but the safety profile is already covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, action-first, and free of redundancy. Every word is purposeful, clearly stating the tool's function without wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no output schema, and a non-trivial meta-tool role, the description is incomplete. It does not describe what the recommendation looks like (e.g., tool name, arguments, confidence), how 'best' is decided, or how the target parameters map to candidate read tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only references a generic 'workbook target' and does not explain any of the six parameters (filepath, sheet_name, sample_rows, etc.). The schema titles are self-explanatory, yet the description contributes almost no additional meaning.

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?

The description uses the specific verb 'Recommend' with a clear resource ('the best SheetForge read tool') and target ('workbook target'), making the tool's role obvious. It distinguishes itself from sibling read tools, which actually perform reads, by framing this as a recommendation/meta-tool.

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?

The phrase 'for the requested workbook target' establishes clear context: use this tool when you need to determine the best read tool for a workbook. It does not explicitly state exclusions or alternatives, but the recommender role is clear enough to guide when to invoke it.

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

union_tablesC

Read-only

Union comparable worksheet or table data across multiple workbook files.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`select`	No
`sort_by`	No
`row_mode`	No	arrays
`dedupe_on`	No
`filepaths`	Yes
`sort_desc`	No
`header_row`	No
`sheet_name`	No
`table_name`	No
`schema_mode`	No	strict
`infer_schema`	No
`source_sample_limit`	No
`include_source_columns`	No

TDQS

C2.8/5.0

Behavior2/5

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

The annotation readOnlyHint=true already signals safety. The description adds little behavioral context beyond the term 'union' itself; it does not explain how schema mismatches are handled, whether deduplication applies by default, or what the output structure looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the action and object with no wasted words. It is highly concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (14 parameters, no output schema, no parameter descriptions), this one-sentence description is severely under-specified. It provides no information about input requirements, edge cases, or what a successful union produces.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about the 14 parameters (e.g., filepaths, select, limit, row_mode). It mentions 'multiple workbook files' only at a high level, failing to compensate for the complete lack of parameter documentation.

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 uses a specific verb ('union') and names the resource ('worksheet or table data across multiple workbook files'). It clearly conveys the core operation, but it does not explicitly distinguish itself from sibling tools like cross_workbook_lookup or bulk_filter_workbooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The qualifier 'comparable' implies that the tool should be used when data across files shares a compatible schema, but it gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives.

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

unmerge_cellsC

Destructive

Unmerge a range of cells.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`end_cell`	Yes
`filepath`	Yes
`sheet_name`	Yes
`start_cell`	Yes
`include_changes`	No

TDQS

C2.5/5.0

Behavior2/5

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

While annotations include destructiveHint: true, the description adds no behavioral context beyond that. It does not disclose what happens to cell values after unmerging, whether the entire range must be merged, or how dry_run affects the operation, providing minimal value beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short, but it is under-specified rather than concisely complete. For a tool with 6 parameters and a destructive side effect, one short sentence is insufficient, making this a case of under-specification rather than effective conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a mutation with no output schema, destructiveHint, and a 0% parameter description coverage. The description provides none of the necessary context about return values, effects, or prerequisites, making it wholly inadequate for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for parameter meanings, but it only mentions 'a range of cells', which vaguely maps to start_cell and end_cell. It does not explain filepath, sheet_name, dry_run, or include_changes, leaving most parameters underspecified.

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?

The description uses the specific verb 'unmerge' with the resource 'a range of cells', clearly identifying the operation. It distinguishes itself from sibling tools like merge_cells and get_merged_cells by stating an opposite action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. It does not mention merge_cells as the inverse operation, nor does it suggest using get_merged_cells to identify merged ranges first, leaving the agent without context for appropriate invocation.

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

update_rows_by_keyC

Destructive

Update existing table rows using a named key column.

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`updates`	Yes
`filepath`	Yes
`header_row`	No
`key_column`	Yes
`sheet_name`	Yes
`include_changes`	No
`expected_structure_token`	No

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, but the description adds no additional behavioral context. It does not disclose how key matching works, what happens to non-matching rows, whether updates overwrite entire rows or merge fields, or the purpose of dry_run and include_changes parameters. The description is essentially a restatement of the action rather than an explanation of its side effects.

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?

The description is a single, front-loaded sentence that communicates the core purpose without any filler. It is concise and easy to parse, though it sacrifices necessary detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate-high complexity (8 parameters, no output schema, destructive annotation), the description is too sparse. It does not explain return values, error behavior, or the effects of parameters like dry_run and include_changes. A tool performing updates by key should clarify the update semantics and safety mechanisms.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description only hints at key_column by mentioning 'named key column.' It does not explain the structure of 'updates', the role of 'expected_structure_token', the meaning of 'dry_run', or the format of 'header_row'. With eight parameters and no parameter descriptions, this is insufficient compensation.

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?

The description clearly states a specific action ('Update existing table rows') and a distinguishing method ('using a named key column'). This differentiates it from sibling tools like append_table_rows (insert) and upsert_excel_table_rows (insert-or-update) by explicitly limiting to existing rows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 exclusions, prerequisites, or when a different tool might be preferred. For example, nothing contrasts it with upsert_excel_table_rows or append_excel_table_rows, leaving the agent to infer the appropriate choice.

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

upsert_excel_table_rowsB

Destructive

Update matching rows in a native Excel table and append missing keys.

ParametersJSON Schema

Name	Required	Description	Default
`rows`	Yes
`dry_run`	No
`filepath`	Yes
`key_column`	Yes
`sheet_name`	No
`table_name`	Yes
`include_changes`	No
`allow_structure_change`	No
`expected_structure_token`	No

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the agent knows this is destructive. The description adds the behavioral semantics of matching rows and appending missing keys, but it does not disclose other important behaviors such as potential structure changes or the effect of dry_run.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that conveys the core action without redundancy or filler. Every word serves a purpose, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 9 parameters, a destructive annotation, and no output schema. The one-sentence description is far too sparse to provide adequate context for an agent to invoke it correctly, omitting details about table selection, dry run, structure preservation, and expected return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for the 9 parameters. It only vaguely references 'matching rows' and 'missing keys' without explaining key_column, dry_run, allow_structure_change, expected_structure_token, or any other parameter. This is a critical gap for correct invocation.

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?

The description clearly states the tool's action with specific verbs 'Update' and 'append', targeting 'matching rows' in a 'native Excel table'. This distinguishes it from sibling tools like append_excel_table_rows (append-only) and update_rows_by_key (update-only), making the upsert behavior unambiguous.

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?

The description implies the intended use case—when you need to update existing rows and add new ones based on a key. However, it does not explicitly mention when not to use it or name alternatives, so it lacks explicit exclusions.

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

validate_excel_rangeC

Read-only

Validate if a range exists and is properly formatted.

ParametersJSON Schema

Name	Required	Description	Default
`end_cell`	No
`filepath`	Yes
`sheet_name`	Yes
`start_cell`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

The readOnlyHint annotation already signals a safe read operation, which the description supports. However, the description adds minimal detail beyond that: it does not disclose what happens when the range does not exist, whether it returns a boolean or throws an error, or what constitutes 'properly formatted'. With annotations present, the bar is lower but the description still lacks useful behavioral context.

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?

The description is a single concise sentence with no filler, earning a high score for conciseness. It is front-loaded with the verb 'Validate' and the object. However, it is so brief that it borders on under-specification, preventing a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what the tool returns or its behavior on success/failure, but it does not. The tool has four parameters and a validation purpose, yet the description omits details about error handling, return values, or additional context needed for correct invocation. The description does not fully cover the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about the parameters. It does not explain the expected format of start_cell/end_cell, how they define the range, or the meaning of filepath and sheet_name. This is a critical gap since the description must compensate for missing parameter documentation, but it fails to do so.

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 clearly states the tool validates whether a range exists and is properly formatted, using the specific verb 'validate' and resource 'excel range'. It is somewhat vague about what 'properly formatted' means, but it distinguishes from sibling tools like inspect_named_range or validate_formula_syntax by focusing on range existence/format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description does not mention prerequisites, use cases, or exclusions. It relies solely on the tool name and short description, leaving the agent to infer when validation is needed.

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

validate_formula_syntaxA

Read-only

Validate Excel formula syntax without applying it.

ParametersJSON Schema

Name	Required	Description	Default
`cell`	Yes
`formula`	Yes
`filepath`	Yes
`sheet_name`	Yes

TDQS

A4/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description clarifies that only syntax is validated and the formula is not applied, which adds meaningful behavioral context. It does not mention return values or error behavior, but with annotations already covering safety, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It directly states the action and a crucial qualifier, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool's purpose is clear and the readOnlyHint annotation provides safety context, but the lack of parameter descriptions and any output behavior information leaves gaps. Given the simplicity of the tool, the description is minimally adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not describe any of the four required parameters (filepath, sheet_name, cell, formula). With 0% schema description coverage, the agent must rely solely on parameter names, which is insufficient for correct invocation.

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?

The description uses a specific verb 'validate' with the resource 'Excel formula syntax' and adds a key qualifier 'without applying it', clearly distinguishing it from sibling tools like apply_formula. The purpose is unambiguous and precise.

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?

The phrase 'without applying it' provides clear context for when to use this tool (to check syntax without side effects). However, it does not explicitly name alternative tools or state when not to use it, falling short of the full explicit guidance standard.

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

write_data_to_excelC

Destructive

Write data to Excel worksheet.
Excel formula will write to cell without any verification.

PARAMETERS:  
filepath: Path to Excel file
sheet_name: Name of worksheet to write to
data: List of lists containing data to write to the worksheet, sublists are assumed to be rows
start_cell: Cell to start writing to, default is "A1"

ParametersJSON Schema

Name	Required	Default
`data`	Yes
`dry_run`	No
`filepath`	Yes
`sheet_name`	Yes
`start_cell`	No	A1
`include_changes`	No

TDQS

C2.9/5.0

Behavior3/5

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

The destructiveHint annotation covers the overall destructive nature. The description adds the note about writing 'without any verification', but this is vague and ambiguous. It doesn't clarify what is not verified (e.g., formula validity, overwrites, data types). This adds some context but not enough to be fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and front-loaded, and the parameter list is clear. However, the second sentence ('Excel formula will write to cell without any verification') is cryptic, redundant, and confusing. It detracts from the overall conciseness and clarity, making the description less structured than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description is incomplete. It fails to mention return values, behavior when writing to an existing file, or the purpose of dry_run and include_changes. The ambiguous behavioral note doesn't compensate. Given the tool's complexity and the rich sibling context, more guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains filepath, sheet_name, data (list of lists with sublists as rows), and start_cell default. However, dry_run and include_changes are completely omitted, and the schema provides no descriptions. This partial coverage adds value but leaves two parameters undocumented, limiting the agent's ability to use the tool fully.

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 first sentence clearly states the action ('Write data to Excel worksheet') with a specific verb and resource. It distinguishes from read tools, though not from other write tools like apply_formula. The second sentence about 'Excel formula will write to cell without any verification' is confusing and obscures the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or suitable scenarios. Sibling tools like apply_formula or append_table_rows are not referenced, so the agent receives no help in selecting among write operations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev0.10.0Sep 5, 2026
- Addedapply_workbook_changeset
5 tool updatesv0.9.0Sep 1, 2026
- Changedcreate_workbook1 field changed
  - addedInput schema / properties / sheet_name
```
Added value: +{
+  "default": "Sheet1",
+  "title": "Sheet Name",
+  "type": "string"
+}
```
- Addedcreate_workbook_snapshot
- Changeddescribe_dataset1 field changed
  - addedInput schema / properties / read_boundary_mode
```
Added value: +{
+  "default": "default",
+  "title": "Read Boundary Mode",
+  "type": "string"
+}
```
- Changedquick_read1 field changed
  - addedInput schema / properties / read_boundary_mode
```
Added value: +{
+  "default": "default",
+  "title": "Read Boundary Mode",
+  "type": "string"
+}
```
- Changedread_excel_as_table1 field changed
  - addedInput schema / properties / read_boundary_mode
```
Added value: +{
+  "default": "default",
+  "title": "Read Boundary Mode",
+  "type": "string"
+}
```
76 tool updatesv0.8.0Aug 7, 2026
- First observedaggregate_table
- First observedanalyze_range_impact
- First observedappend_excel_table_rows
- First observedappend_table_rows
- First observedapply_formula
- First observedapply_workbook_repairs
- First observedaudit_workbook
- First observedautofit_columns
- First observedbulk_aggregate_workbooks
- First observedbulk_filter_workbooks
- First observedcopy_range
- First observedcopy_worksheet
- First observedcreate_chart
- First observedcreate_chart_from_series
- First observedcreate_named_range
- First observedcreate_pivot_table
- First observedcreate_table
- First observedcreate_workbook
- First observedcreate_worksheet
- First observedcross_workbook_lookup
- First observeddelete_named_range
- First observeddelete_range
- First observeddelete_sheet_columns
- First observeddelete_sheet_rows
- First observeddelete_worksheet
- First observeddescribe_dataset
- First observeddescribe_sheet_layout
- First observeddetect_circular_dependencies
- First observeddiff_workbooks
- First observedexplain_formula_cell
- First observedfind_free_canvas
- First observedformat_range
- First observedformat_ranges
- First observedfreeze_panes
- First observedget_data_validation_info
- First observedget_merged_cells
- First observedget_workbook_metadata
- First observedget_worksheet_protection
- First observedinsert_columns
- First observedinsert_rows
- First observedinspect_conditional_format_rules
- First observedinspect_data_validation_rules
- First observedinspect_formula
- First observedinspect_named_range
- First observedlist_all_sheets
- First observedlist_charts
- First observedlist_named_ranges
- First observedlist_tables
- First observedmerge_cells
- First observedplan_workbook_repairs
- First observedprofile_workbook
- First observedquery_table
- First observedquick_read
- First observedread_data_from_excel
- First observedread_excel_as_table
- First observedread_excel_table
- First observedread_range_formatting
- First observedremove_conditional_format_rules
- First observedremove_data_validation_rules
- First observedrename_worksheet
- First observedsearch_in_sheet
- First observedset_autofilter
- First observedset_column_widths
- First observedset_print_area
- First observedset_print_titles
- First observedset_row_heights
- First observedset_worksheet_protection
- First observedset_worksheet_visibility
- First observedsuggest_read_strategy
- First observedunion_tables
- First observedunmerge_cells
- First observedupdate_rows_by_key
- First observedupsert_excel_table_rows
- First observedvalidate_excel_range
- First observedvalidate_formula_syntax
- First observedwrite_data_to_excel

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.7/5.0

Disambiguation2/5

Many tools have overlapping purposes, such as the multiple read tools (read_data_from_excel, read_excel_as_table, quick_read, read_excel_table) and validation/formatting inspection tools. Agents will have difficulty distinguishing between subtle variations like format_range vs format_ranges or get_data_validation_info vs inspect_data_validation_rules.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (e.g., list_named_ranges, create_worksheet, set_autofilter). However, there are minor deviations like quick_read, and the read tool family is inconsistently named (read_data_from_excel vs read_excel_as_table vs read_excel_table).

Tool Count1/5

With 76 tools, this server vastly exceeds a reasonable count for even a broad Excel automation domain. The overwhelming number creates cognitive load and is well beyond the scope of a coherent tool set, with many tools likely redundant or too narrowly scoped.

Completeness4/5

The surface is impressively comprehensive, covering reading, writing, formatting, formulas, charts, pivot tables, data validation, conditional formatting, worksheet management, and workbook audits/repairs. Minor gaps exist, such as no explicit delete chart or delete pivot table tools, but core workflows are well covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agentdocsOAuth
io.github.dancourse
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Workplace & Productivity Documentation Access
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

Excel MCP Server
File Systems App Automation Data Platforms
Aifornorms
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI agents to create, read, and modify Excel workbooks without requiring Microsoft Excel installation.
Updated a year ago (2025-05-24 11:46 UTC)
MIT
fcp-sheets
Workplace & Productivity Data Visualization
os-tack
A
license
B
quality
C
maintenance
MCP server for semantic spreadsheet operations that lets LLMs create and edit Excel workbooks by describing spreadsheet intent.
Updated 2 months ago (2026-07-06 17:13 UTC)
4
2
MIT
formulon-mcp
Workplace & Productivity File Systems
libraz
A
license
Not graded
quality
A
maintenance
MCP server for Excel-compatible formula evaluation and workbook operations, enabling agents to open, inspect, mutate, recalculate, and save .xlsx files in-memory over stdio.
Updated 15 days ago (2026-08-22 15:49 UTC)
83
Apache 2.0
excel-mcp-server
Workplace & Productivity File Systems Data Visualization
ZhouYFei7788
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that lets you manipulate Excel files without needing Microsoft Excel installed. Create, read, and modify Excel workbooks with your AI agent.
Updated 6 months ago (2026-02-23 09:58 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iHeldan/sheetforge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server