Skip to main content
Glama
Arkanji

iWork Studio MCP Server

by Arkanji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check rendered formatting

iwork_verify_format
Read-onlyIdempotent

Verify formatting of text in Numbers, Keynote, or Pages files by exporting a PDF and confirming font, size, color, bold, and page size.

Instructions

Independent check of formatting: export a PDF through the app and confirm text is drawn with the given font (name contains), size (pt), color (#RRGGBB), bold, and page size (pt). Needs macOS + the app. Use to prove how a piece of text is drawn (font, size, colour, page size). To check text is merely present use iwork_verify_render.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boldNoExpected bold (true) or not bold (false).
fontNoExpected font; matches when the drawn font name contains it, e.g. "Avenir".
pathYesPath to the .numbers, .key or .pages file (absolute, or starting with ~).
sizeNoExpected size in points (±0.6).
textYesText that must appear in the rendered PDF; for Arabic, one word (multi-word RTL text is reordered).
colorNoExpected text colour "#RRGGBB".
page_widthNoExpected page width in points.
page_heightNoExpected page height in points.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.4.1
    • addedInput schema / properties / bold / description
      Added value: +"Expected bold (true) or not bold (false)."
    • addedInput schema / properties / color / description
      Added value: +"Expected text colour \"#RRGGBB\"."
    • addedInput schema / properties / font / description
      Added value: +"Expected font; matches when the drawn font name contains it, e.g. \"Avenir\"."
    • addedInput schema / properties / page_height / description
      Added value: +"Expected page height in points."
    • addedInput schema / properties / page_width / description
      Added value: +"Expected page width in points."
    • addedInput schema / properties / path / description
      Added value: +"Path to the .numbers, .key or .pages file (absolute, or starting with ~)."
    • addedInput schema / properties / size / description
      Added value: +"Expected size in points (±0.6)."
    • addedInput schema / properties / text / description
      Added value: +"Text that must appear in the rendered PDF; for Arabic, one word (multi-word RTL text is reordered)."
  2. First observedv2.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful non-annotation context: the tool performs an actual PDF export through the app, requires macOS and the application installed, and that font matching is substring-based. It stops short of noting runtime cost or failure modes for a launch-and-export operation.

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?

Three tightly packed sentences, front-loaded with the mechanism, then usage, then the sibling disambiguation. Dense but every sentence earns its place; minor parenthetical clutter ('name contains', unit lists) slightly reduces readability.

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 an 8-parameter read-only verification tool with an output schema, the description covers mechanism, environment prerequisite, matching semantics, and sibling routing. Return-value detail is unnecessary given the output schema exists, so nothing material is 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 each parameter's meaning and units (points, #RRGGBB, name-contains). The description reinforces the same matching semantics but adds no new parameter detail beyond what the schema provides, so the baseline of 3 applies.

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 (verify formatting) and explains the mechanism precisely: export a PDF through the app and confirm `text` is drawn with a given font, size, color, bold, and page size. It explicitly names the sibling it is not (iwork_verify_render), so an agent can route correctly without opening schemas.

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 to prove how a piece of text is drawn') and an explicit alternative with its selection condition ('To check text is merely present use iwork_verify_render'). It also states the prerequisite environment ('Needs macOS + the app'), leaving nothing to inference.

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