Skip to main content
Glama
ng-galien

Maket

by ng-galien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

maket_canvas

Configure or update a document's page frame with format, orientation, background, and margins before adding content or switching formats.

Instructions

When to use: set or update the canvas (physical frame) of a document — format, orientation, background, margins. Call this before adding content to a fresh doc, or when switching a doc between formats.

Coordinates are in mm. Paper sizes — A2=420×594, A3=297×420, A4=210×297, A5=148×210, A6=105×148, A7=74×105, A8=52×74. Screen sizes — DESKTOP=288×205 (1440×1024), TABLET=167×239 (834×1194), MOBILE=79×170 (393×852). AUTO — width in mm is required; each page height follows its content. Orientation is ignored. Use normal HTML flow rather than a fixed-height wrapper. Unspecified fields keep their current value.

Input Schema

NameRequiredDescriptionDefault
docYesDocument name.
widthNoWidth in millimetres for AUTO format; required on creation. Height follows each page content.
formatNoPaper (A2–A8, mm) or screen (DESKTOP/TABLET/MOBILE, mm-equivalent). Unspecified keeps the current value.
marginsNoPer-side safe-zone insets in mm: {top, right, bottom, left}. The layout verdict reports `tight` when blocks cross into any band, and the client draws dashed guides at these insets. Unspecified keeps the current value.
backgroundNoCSS background colour. Unspecified keeps the current value. Prefer var(--charte-color-bg) when a charte is loaded.
orientationNoPage orientation. Unspecified keeps the current value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.2.0
    • changedInput schema / properties / format / enum
      Previous value: -[
-  "A2",
-  "A3",
-  "A4",
-  "A5",
-  "A6",
-  "A7",
-  "A8",
-  "DESKTOP",
-  "TABLET",
-  "MOBILE"
-]New value: +[
+  "A2",
+  "A3",
+  "A4",
+  "A5",
+  "A6",
+  "A7",
+  "A8",
+  "DESKTOP",
+  "TABLET",
+  "MOBILE",
+  "AUTO"
+]
    • addedInput schema / properties / width
      Added value: +{
+  "description": "Width in millimetres for AUTO format; required on creation. Height follows each page content.",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
  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.3/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: it states that unspecified fields retain current values (partial-update semantics), that AUTO only requires width, and that orientation is ignored in AUTO mode and normal HTML flow should be used. It omits permission/auth requirements and what happens on a nonexistent or locked document.

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-loaded with the when-to-use condition, then reference data in compact labeled lists. The size tables are dense but genuinely reference material an agent needs; slightly list-heavy formatting keeps it from a 5.

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 a 6-param mutating tool with a nested margins object, no annotations, and no output schema, the description covers units, defaults retention, and enum semantics well. It could still say more about failure modes or whether the canvas can be created implicitly.

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 coverage is already 100%, so baseline is 3; the description earns a bump by supplying the actual paper and screen dimensions (A2=420×594 … MOBILE=79×170) and the AUTO width/orientation interaction, information the schema's enum does not carry. Remaining params (margins, background) mostly restate 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: 'set or update the canvas (physical frame) of a document', then enumerates the four attributes it governs (format, orientation, background, margins). The 'physical frame' framing cleanly separates it from content-oriented siblings like maket_page, maket_html, and maket_doc.

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

Usage Guidelines4/5

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

Explicit 'When to use' plus two concrete triggers: before adding content to a fresh doc, or when switching formats. No alternatives or when-not guidance is offered, so it stops short of the top band.

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