Skip to main content
Glama
Arkanji

iWork Studio MCP Server

by Arkanji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Numbers: sort

numbers_sort
Destructive

Sort an Apple Numbers table's body rows by a chosen column while keeping header rows on top. If formulas reference other rows, use to_new_table=true to produce a sorted values copy.

Instructions

Sort a table's body rows by a column letter (header rows stay on top). Verified as a pure reorder. A table whose formulas read other rows (e.g. =B2*0.1 below a base-figure row) is refused, because Numbers' sort would break them; for it, to_new_table=true leaves the table, its formulas and its charts as they are and puts a sorted copy of its values (no formulas) in a new table on the same sheet (named new_table_name, default " sorted"). Chart the copy with keynote_build_deck. Needs macOS + Numbers, file closed. dry_run=true previews the change on a copy without touching the file. Use to reorder body rows by one column; header rows stay on top. If it refuses because formulas read other rows, call it again with to_new_table=true for a sorted copy; never rewrite the formulas to force it. Needs the Numbers app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the .numbers file (absolute, or starting with ~).
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.
columnYesColumn letter to sort by, e.g. "C".
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.
descendingNotrue = largest/last first.
to_new_tableNotrue = leave the table as it is and put a sorted copy of its values (no formulas) in a new table on the same sheet. Use it when the table's formulas read other rows.
new_table_nameNoName for the new table (with to_new_table); default "<table> sorted".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.0
    • addedInput schema / properties / new_table_name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Name for the new table (with to_new_table); default \"<table> sorted\".",
+  "title": "New Table Name"
+}
    • addedInput schema / properties / to_new_table
      Added value: +{
+  "default": false,
+  "description": "true = leave the table as it is and put a sorted copy of its values (no formulas) in a new table on the same sheet. Use it when the table's formulas read other rows.",
+  "title": "To New Table",
+  "type": "boolean"
+}
  2. Changed6 schema fields changedv2.4.1
    • addedInput schema / properties / column / description
      Added value: +"Column letter to sort by, e.g. \"C\"."
    • addedInput schema / properties / descending / description
      Added value: +"true = largest/last first."
    • 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 / 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."
  3. First observedv2.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only give destructiveHint=false and idempotentHint=false; the description adds the refusal condition (formulas that read other rows), what to_new_table preserves (table, formulas, charts) versus omits (formulas in the copy), the default copy name, environmental prerequisites (macOS + Numbers, file closed), and what dry_run actually does (runs on a throwaway copy). This is substantial context the structured fields do not carry.

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?

Front-loaded and dense, but it repeats itself: 'header rows stay on top' appears in both the opening and again in 'Use to reorder body rows by one column; header rows stay on top,' and the keynote_build_deck plug is tangential. A tighter version would preserve all the guidance without the duplication.

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?

An output schema exists so return values need no explanation, and the description covers the risky edge case, the recovery path, prerequisites, and the dry-run preview. Nothing an agent needs to invoke this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds rationale the schema lacks: why to_new_table exists, that the copy contains values with no formulas, the default naming pattern, and that dry_run previews without touching the file. It reinforces rather than merely repeats the 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 first sentence states a precise verb and resource: 'Sort a table's body rows by a column letter (header rows stay on top).' No sibling tool performs row reordering, and the scope (body rows only, headers fixed) is stated up front.

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

Usage Guidelines5/5

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

Explicitly says to use it to reorder body rows by one column, names the fallback path (to_new_table=true) when the tool refuses, and adds a prohibition ('never rewrite the formulas to force it'). The when/when-not/alternative matrix is complete.

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