Skip to main content
Glama
ng-galien

Maket

by ng-galien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

maket_preview

View Maket documents in your browser, as PNG snapshots, or inside the conversation. Open live previews, rasterize pages, or show selected pages to users.

Instructions

When to use: view documents outside the agent. open flips the live preview URL into the user's browser; snapshot rasterises a single page to PNG at its true mm size; show puts pages in front of the user inside the conversation.

open — launch the live preview URL (localhost) in the default browser. No params. snapshot — render a page via headless Chromium. Returns the full-size PNG as a file path on disk, the page's reading path in Maket, and the image inline (at most 1600 px on its longest side and 1 MB of base64, downscaled when larger; beyond a 2:1 ratio, the top or left part of the page). On hosts that render MCP Apps, the Maket reader also opens on that page. show — on hosts that render MCP Apps, open the Maket reader in the conversation: doc, pages ("all", 3, "3-5" or [1,4]), layout (scroll | page), start (page to open at), zoom (fit-width | actual). The user can then switch layout, jump through the page list, zoom and open the document in Maket. Other hosts get the reading path. Returns no image: use snapshot to inspect a page yourself.

Input Schema

NameRequiredDescriptionDefault
docNoDocument name. Required for snapshot and show.
pageNo1-based page number. Required for snapshot.
pathNoFor snapshot: output PNG path. Defaults to EXPORTS_DIR/<doc>.png.
zoomNoFor show: fit-width (default) or actual size.
pagesNoFor show: "all" (default), a page number, a range such as "3-5", or a list of page numbers.
startNoFor show: the page number to open at, one of the shown pages (default: the first).
actionYesOperation to run. See the tool description for the action table.
layoutNoFor show: scroll (default) shows the pages one after another; page shows one at a time with previous and next.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.2.0
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "open",
-  "snapshot"
-]New value: +[
+  "open",
+  "snapshot",
+  "show"
+]
    • changedInput schema / properties / doc / description
      Previous value: -"Document name. Required for snapshot."New value: +"Document name. Required for snapshot and show."
    • addedInput schema / properties / layout
      Added value: +{
+  "description": "For show: scroll (default) shows the pages one after another; page shows one at a time with previous and next.",
+  "enum": [
+    "scroll",
+    "page"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / pages
      Added value: +{
+  "anyOf": [
+    {
+      "const": "all",
+      "type": "string"
+    },
+    {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    {
+      "pattern": "^\\d+\\s*-\\s*\\d+$",
+      "type": "string"
+    },
+    {
+      "items": {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      "minItems": 1,
+      "type": "array"
+    }
+  ],
+  "description": "For show: \"all\" (default), a page number, a range such as \"3-5\", or a list of page numbers."
+}
    • addedInput schema / properties / start
      Added value: +{
+  "description": "For show: the page number to open at, one of the shown pages (default: the first).",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / zoom
      Added value: +{
+  "description": "For show: fit-width (default) or actual size.",
+  "enum": [
+    "fit-width",
+    "actual"
+  ],
+  "type": "string"
+}
  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.5/5.0
Behavior5/5

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

With no annotations at all, the description carries the full behavioral burden and does so well: headless Chromium rendering, a PNG written to a file path on disk, inline image caps (1600 px longest side, 1 MB base64, downscaling, 2:1 ratio cropping to the top/left), and host-dependent side effects (reader opening, browser launch). This is far more than the schema or annotations convey.

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?

The block is dense but well structured: a when-to-use header followed by an aligned action table, with no filler sentences. It loses a point because the `show` line re-enumerates doc/pages/layout/start/zoom values that the 100%-covered schema already lists, which is mild duplication.

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, three-mode tool with no output schema and no annotations, the description covers what each action returns (file path, reading path, inline image, or nothing), which parameters each action needs, and host-dependent variations. An agent has everything required to pick an action and call it correctly.

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 description coverage is already 100%, so the baseline is 3. The description goes beyond it by giving concrete syntax for `pages` ('all', 3, "3-5", [1,4]) and a semantic constraint for `start` ('one of the shown pages, default: the first'), which the schema's generic integer description does not state.

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 opening line states a specific purpose ('view documents outside the agent') and the action table gives a precise verb+resource for each of the three modes (open = launch live preview URL, snapshot = rasterise a page to PNG, show = display pages in the conversation). It does not, however, differentiate itself from any of the 15 sibling tools (e.g. maket_reader, maket_pdf, maket_canvas), so an agent cannot rule those out from this text alone.

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?

Usage is front-loaded ('When to use: view documents outside the agent') and each action carries its own selection condition. It even routes away from itself explicitly: 'Returns no image: use snapshot to inspect a page yourself', and notes host-conditional behavior ('on hosts that render MCP Apps... Other hosts get the reading path').

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