Skip to main content
Glama
Arkanji

iWork Studio MCP Server

by Arkanji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Extract design kit

iwork_extract_design_kit
Idempotent

Make a design kit from the user's own deck or table: heading and body fonts (Latin and Arabic) and the title, body and brand colours.

Instructions

Make a design kit from the user's own deck or table: heading and body fonts (Latin and Arabic) and the title, body and brand colours. .numbers reads the table's header and body styles (no app); .key reads every slide's title and body (needs macOS + Keynote). Parts the file doesn't show come from the nearest preset and are listed in notes. save=true with a name keeps it for reuse by name (contrast must pass). The file is never changed. Use when the user has a deck or table that already has their brand look. If they give colours and fonts directly use iwork_save_design_kit instead.

Input Schema

NameRequiredDescriptionDefault
nameNoName for the kit, e.g. "Acme" (required with save=true).
pathYesA .key deck or .numbers table that already has the look to capture.
saveNotrue = save it under name for reuse; contrast must pass.
sheetNoFor .numbers: the sheet holding the styled table.
tableNoFor .numbers: the styled table.
overwriteNotrue = replace a saved kit with the same name.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.6.1
    • changedInput schema / properties / name / description
      Previous value: -"Name for the kit, e.g. \"Resal\" (required with save=true)."New value: +"Name for the kit, e.g. \"Acme\" (required with save=true)."
  2. Changed6 schema fields changedv2.4.1
    • addedInput schema / properties / name / description
      Added value: +"Name for the kit, e.g. \"Resal\" (required with save=true)."
    • addedInput schema / properties / overwrite / description
      Added value: +"true = replace a saved kit with the same name."
    • addedInput schema / properties / path / description
      Added value: +"A .key deck or .numbers table that already has the look to capture."
    • addedInput schema / properties / save / description
      Added value: +"true = save it under name for reuse; contrast must pass."
    • addedInput schema / properties / sheet / description
      Added value: +"For .numbers: the sheet holding the styled table."
    • addedInput schema / properties / table / description
      Added value: +"For .numbers: the styled table."
  3. First observedv2.4.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: it discloses OS/app prerequisites (.numbers needs no app, .key needs macOS + Keynote), that unshown parts fall back to the nearest preset and are listed in notes, that save=true persists the kit only if contrast passes, and that overwrite replaces a same-named kit. It also clarifies the readOnlyHint=false nuance by stating the source file is never modified.

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?

Front-loaded with the outcome, then per-format mechanics, then the save rule, then the routing sentence. Dense but nearly every clause carries information; the terse 'no app' phrasing is slightly compressed but still parseable.

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?

With an output schema present, return values need not be described. The description covers platform requirements, fallback/preset behavior, save semantics, and safety (file unchanged), leaving no material gap for a 6-parameter tool.

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 baseline is 3, but the description adds real meaning: save=true requires a name and a passing contrast check, sheet/table scope the .numbers read, and overwrite governs name collisions. The only gap is that name-required-with-save is repeated from the schema rather than extended.

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?

States a specific verb and resource ('Make a design kit from the user's own deck or table') and enumerates exactly what is captured: heading/body fonts (Latin and Arabic) and title/body/brand colours. It also distinguishes itself from the sibling iwork_save_design_kit by input source (existing file vs. user-supplied values).

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?

Gives an explicit trigger ('Use when the user has a deck or table that already has their brand look') and names the alternative with its selecting condition ('If they give colours and fonts directly use iwork_save_design_kit instead'). Both the when and the when-not are stated.

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