Skip to main content
Glama
Arkanji

iWork Studio MCP Server

by Arkanji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Save design kit

iwork_save_design_kit
Idempotent

Save a design kit by name for reuse anywhere a kit is accepted. kit = {"fonts": {...}, "colors": {...}, "theme": "...", "background": "#RRGGBB"} (missing parts come from the "executive" preset, or from "base": ""), or a preset name…

Instructions

Save a design kit by name for reuse anywhere a kit is accepted. kit = {"fonts": {...}, "colors": {...}, "theme": "...", "background": "#RRGGBB"} (missing parts come from the "executive" preset, or from "base": ""), or a preset name to copy. Contrast is checked (4.5:1). Never replaces a saved kit unless overwrite=true; can't reuse a preset's name. Use when the user gives brand colours and fonts directly. To capture them from an existing file use iwork_extract_design_kit.

Input Schema

NameRequiredDescriptionDefault
kitYes{"fonts": {...}, "colors": {...}, "theme": "...", "background": "#RRGGBB", "base": "<preset>"} or a preset name to copy.
nameYesName to save under, e.g. "Acme" (letters, digits, spaces, - or _; not a preset name).
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 to save under, e.g. \"Resal\" (letters, digits, spaces, - or _; not a preset name)."New value: +"Name to save under, e.g. \"Acme\" (letters, digits, spaces, - or _; not a preset name)."
  2. Changed3 schema fields changedv2.4.1
    • addedInput schema / properties / kit / description
      Added value: +"{\"fonts\": {...}, \"colors\": {...}, \"theme\": \"...\", \"background\": \"#RRGGBB\", \"base\": \"<preset>\"} or a preset name to copy."
    • addedInput schema / properties / name / description
      Added value: +"Name to save under, e.g. \"Resal\" (letters, digits, spaces, - or _; not a preset name)."
    • addedInput schema / properties / overwrite / description
      Added value: +"true = replace a saved kit with the same name."
  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?

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=true), while the description adds the real behavior: contrast is validated at 4.5:1, a saved kit is never replaced unless overwrite=true, preset names cannot be reused, and unspecified parts are filled from the 'executive' preset or a named 'base'. This is meaningful disclosure well beyond the annotations, and it does not contradict them.

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-loads purpose, then constraints, then the routing alternative – a sensible order with no filler sentences. It is dense and slightly long, and the inline kit JSON partially restates the schema, but every clause carries a rule an agent needs.

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 3-parameter write tool with a full output schema and safety annotations, the description covers everything an agent needs to call it correctly: input shape, preset fallback, validation, collision behavior, name constraints, and the sibling alternative. Nothing material 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 description coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: the inheritance rule (missing parts come from the 'executive' preset, or a 'base' preset) and the overwrite guard on name collisions. It stops short of documenting the fonts/colors sub-structure, but that is a fair division of labor with 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?

Opens with a specific verb+resource+scope: 'Save a design kit by name for reuse anywhere a kit is accepted.' It also names the sibling it is not (iwork_extract_design_kit) and the sibling store it belongs to (saved kits, presets), so an agent can distinguish it without opening any schema.

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?

Explicit when-to-use ('Use when the user gives brand colours and fonts directly') paired with the explicit alternative for the opposite case ('To capture them from an existing file use iwork_extract_design_kit'). The selection condition is unambiguous.

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