Skip to main content
Glama
Sign In
indesign-mcp-server

indesign-mcp-server

by lucdesign
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

zoom_to_page

Change the InDesign view to a specified page by zooming or fitting it within the screen. Options include fit page, spread, actual size, or zoom to selection.

Instructions

Zoom and fit page in view

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "zoom_to_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
fitOptionNoFIT_PAGE
pageIndexNoPage index to zoom to

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without explaining side effects, view changes, or interactions with pageIndex and fitOption. It does not reveal whether the zoom is temporary or persists, nor does it mention any prerequisites.

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?

The description is a single short phrase, which is structurally brief and front-loaded, but it is overly terse and omits necessary context. It is concise but at the expense of clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters, an enum, and no output schema, the description is far too minimal to provide complete context. It does not explain the fit options, the meaning of pageIndex, or how this tool fits among view-related siblings, leaving significant gaps.

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

Parameters2/5

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

Schema coverage is 50% with only pageIndex having a description. The description does not elaborate on fitOption's meaning or how it interacts with pageIndex. It fails to compensate for the lack of schema documentation on the enum parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Zoom and fit page in view' identifies the core action (zoom/fit) and target (page in view). It clearly indicates the tool's primary function, though it does not explicitly mention the fit options or differentiate from sibling tools like navigate_to_page.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives such as navigate_to_page or view_document. The description lacks context about typical scenarios or exclusions, leaving the agent to infer usage.

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