Skip to main content
Glama

switch_page

Switch to a specific Figma page using its unique page ID. Use without arguments to retrieve the full list of pages.

Instructions

Navigate between pages in the Figma file. ID-driven — names are not addressable (they can collide and change).

Two modes:

  • switch_page({}) → return the page roster only, no switch (use to discover IDs on first call)

  • switch_page({pageId: "1:23"}) → switch and return the updated state + roster

Pages are top-level containers under the file root. Most read/write operations default to figma.currentPage. Call this when you need to operate on nodes that live on a different page than the current one.

Returns:

  • currentPageId, currentPageName — the now-current page (always present)

  • pages — full roster [{id, name}] of every page in the file (always present)

  • previousPageId, previousPageName — what you switched from (only when an actual switch happened)

  • unchanged — true if target was already current

Typical flow:

  1. switch_page({}) // get IDs

  2. switch_page({pageId: ""}) // switch

When to call:

  • User mentions content on a different page than the current one

  • A previous tool reported a node ID is on a non-current page

  • You need to inspect/modify nodes outside the active page

Don't call:

  • For nodes already on the current page — figma.currentPage is the default scope, this would just waste an iteration

  • Repeatedly to "explore" — every call returns the full pages roster, cache it

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageIdNoTarget page ID (e.g., "0:1"). Omit to just fetch the page roster without switching.
Behavior5/5

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

Despite no annotations, the description fully discloses behavior: ID-driven (names not addressable), two modes, return fields, side effects (switching page), and that most operations default to current page. No contradictions.

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?

Well-structured with sections and bullet points, but slightly verbose. Front-loaded with key behaviors and modes, which is good. Could trim redundant phrasing.

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?

Complete despite no output schema: explains all return fields, two modes, typical flow, and operational context (default page scope). No gaps left for agent to guess.

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 covers the single parameter fully with description identical to the tool description. No additional parameter-level insight beyond schema, but the overall description provides context for parameter usage. Baseline 3 due to 100% schema coverage.

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?

Clearly defines the tool as navigating between pages in a Figma file, with two distinct modes (roster-only vs switch). Distinguished from siblings by focusing on page-level navigation, which no other tool does.

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?

Provides explicit when-to-call scenarios (user mentions different page, node on non-current page) and when not to call (current page, repetitive exploration). Includes a typical flow and caching advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/musepy/genable'

If you have feedback or need assistance with the MCP directory API, please join our Discord server