Skip to main content
Glama
Arkanji

iWork Studio MCP Server

by Arkanji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Numbers: set dimensions

numbers_set_dimensions
Destructive

Set column widths and row heights in Apple Numbers spreadsheets by point values, with dry_run preview before applying changes.

Instructions

Set column widths and/or row heights in points, e.g. columns={"A": 160, "C": 90}, rows={"1": 32} (rows are 1-based). Nothing else changes. dry_run=true previews the change on a copy without touching the file. Use for column widths and row heights. To change which rows count as headers use numbers_set_headers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the .numbers file (absolute, or starting with ~).
rowsNoRow heights in points by 1-based row number, e.g. {"1": 32}.
sheetNoSheet name. Omit when the file has one sheet (iwork_read lists sheets and tables).
tableNoTable name on that sheet. Omit when the sheet has one table.
columnsNoColumn widths in points by letter, e.g. {"A": 160, "C": 90}.
dry_runNotrue = make the change on a throwaway copy, run every check, and return what would change; the file itself is not touched. Use it before broad or risky edits and show the user.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.4.1
    • addedInput schema / properties / columns / description
      Added value: +"Column widths in points by letter, e.g. {\"A\": 160, \"C\": 90}."
    • addedInput schema / properties / dry_run / description
      Added value: +"true = make the change on a throwaway copy, run every check, and return what would change; the file itself is not touched. Use it before broad or risky edits and show the user."
    • addedInput schema / properties / path / description
      Added value: +"Path to the .numbers file (absolute, or starting with ~)."
    • addedInput schema / properties / rows / description
      Added value: +"Row heights in points by 1-based row number, e.g. {\"1\": 32}."
    • addedInput schema / properties / sheet / description
      Added value: +"Sheet name. Omit when the file has one sheet (iwork_read lists sheets and tables)."
    • addedInput schema / properties / table / description
      Added value: +"Table name on that sheet. Omit when the sheet has one table."
  2. First observedv2.4.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds real behavioral context beyond that: 'Nothing else changes' bounds the blast radius, and it explains dry_run previews on a copy without touching the file. It omits permission/auth requirements, keeping it short of a 5.

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

Conciseness4/5

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

The description is short and front-loads the core action with examples before the dry_run and sibling routing. The sentence 'Use for column widths and row heights' partially echoes the opening clause, a minor redundancy, but nothing is bloated.

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?

An output schema exists, so return values need not be explained, and the dry_run behavior is described. The safety profile is carried by annotations and the effect scope by 'Nothing else changes.' Nearly complete for a 6-param mutation tool, with only permission context missing.

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 100%, so the schema already documents all six parameters, including 1-based rows and units. The description restates the column/row examples rather than adding syntax or constraints the schema lacks, so the baseline of 3 is appropriate.

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 a specific verb and resource (set column widths and/or row heights), defines the unit (points), and gives concrete examples. It also distinguishes itself from the sibling numbers_set_headers by naming that tool, so an agent can route correctly without opening a schema.

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

Usage Guidelines4/5

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

It explicitly states its purpose ('Use for column widths and row heights') and names the alternative for a nearby task ('To change which rows count as headers use numbers_set_headers'). It gives clear context but no explicit when-not-to-use or dependency conditions beyond that redirect.

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

Deploy Server

Other Tools