Skip to main content
Glama

maket_page

Manage document pages: add, remove, rename, reorder, or list pages, and set or read JSON Forms templates. Use for page structure, not page content.

Instructions

When to use: manage page structure within a document — add, remove, rename, reorder, list. For page content, use maket_html instead.

Manage pages within a document. HTML can embed the current JSON Forms template at . add — append a page with html, json_forms, or both with one form slot; sets it active. remove — delete a page by 1-based index or name; refused if it's the last page. rename — rename a page by index or current name. reorder — move a page from one 1-based position to another; activePage adjusts. list — list pages with their template format; the active page is marked ●. set_form — replace the current form, preserving HTML with a form slot; without a slot, switch to a full-page form. get_form — read one page's JSON Forms template.

Note: charte compliance (token-literal colours, font-family, box-shadow) is enforced by maket_html set/patch, not by maket_page add. If the new page must match a charte, follow maket_page add with maket_html set to validate.

Input Schema

NameRequiredDescriptionDefault
toNoFor reorder: target 1-based position.
docYesDocument name (always required).
fromNoFor reorder: source 1-based position.
htmlNoFor add: HTML body for the new page. Relative image src values are normalized to /assets/...
nameNoFor add/rename: page name (new page name, or rename target).
pageNoFor remove/rename: target page — either 1-based index or page name.
actionYesOperation to run. See the tool description for the action table.
json_formsNoFor add/set_form: JSON Forms template. Omit uischema to generate the form from the document-state JSON Schema.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.2.0
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "add",
      -  "remove",
      -  "rename",
      -  "reorder",
      -  "list"
      -]New value: +[
      +  "add",
      +  "remove",
      +  "rename",
      +  "reorder",
      +  "list",
      +  "set_form",
      +  "get_form"
      +]
    • addedInput schema / properties / json_forms
      Added value: +{
      +  "description": "For add/set_form: JSON Forms template. Omit uischema to generate the form from the document-state JSON Schema.",
      +  "properties": {
      +    "uischema": {
      +      "additionalProperties": {},
      +      "propertyNames": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changedv1.7.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: remove is 'refused if it's the last page', add 'sets it active', reorder makes 'activePage adjust', list marks the active page with ●, and set_form preserves HTML when a slot exists. It omits error shapes, permission/auth requirements, and whether rename/reorder are atomic, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the when-to-use decision, then a scannable one-line-per-action table, then a caveat note. Every sentence maps to a decision the agent must make; nothing is padding.

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

Completeness4/5

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

For an 8-parameter, 7-action tool with no annotations and no output schema, the description is substantially complete: it covers each action, side effects, the last-page guard, and the charte-validation follow-up. It stops short of describing return payloads beyond the list marker and any failure modes other than the last-page refusal.

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 coverage is 100% and the schema already documents from/to/page/name/html per action, so the description's action table largely restates structured data. It adds a little beyond the schema (one form slot per page, activePage side effects, uischema omission generating a form), but the baseline of 3 for high-coverage schemas is the right level.

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+resource ('Manage pages within a document') and enumerates the exact operations (add, remove, rename, reorder, list, set_form, get_form). It explicitly distinguishes itself from the sibling maket_html by scope: structure here, content there.

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?

Opens with an explicit 'When to use' clause and names the alternative for the excluded case ('For page content, use maket_html instead'). The trailing note further routes the agent: charte compliance must be validated via maket_html set, not via this tool.

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