Skip to main content
Glama

view_sheet

Render a plan sheet or cropped region to a PNG image for visual inspection, with optional calibrated measuring grid, committed-shape overlay, and disclosure marks.

Instructions

SEE the sheet — render the page (or a crop of it) to a PNG image. This is your eyes on the plan, so CROP, DON'T SQUINT: the render downsamples to the px budget (≤2000 long side), which on an E-size sheet is ~4 sheet pixels per returned pixel — a full-sheet render finds WHERE things are, and only a tight region crop can tell you what the linework and labels actually say. Never audit a trace or read a dimension off a full-sheet render. region is in image px — the same space as every other tool — so a feature at pixel (ix, iy) of the returned image sits at x = region_x0 + ix × (region_x1 − region_x0) / img_w (same for y), and those coordinates go straight into measure_polygon, or read_sheet_text. overlay:true burns the session's committed shapes into the render (human-affirmed ink solid red, unreviewed machine shapes dashed blue) — render again after committing to verify your geometry landed where you intended, and sanity-check what you see: a fixture-sized ring where a room should be means the seed landed inside a stall or casework; an outsized ring means the flood escaped through an opening. To MEASURE rather than guess, pass grid: a calibrated measuring grid is burned in — thin lines every 1 ft, heavy blue every 5 ft, foot labels along the crop edges, feet counted from the crop's top-left corner. Count grid cells between walls exactly like an estimator scaling a plan; never derive a dimension by eye when the grid can give it to you. grid "auto" uses the sheet's set scale; before set_scale, pass the drawing scale read off the title block as inches-per-foot — "1/4" for a 1/4" = 1'-0" plan, "3/16", "0.25". marks (#297) burns DISCLOSURE layers into the render, so what a reply names, the picture shows: pass the coordinate lists a tool disclosed — question: withheld placements (orange ?-circles), struck: rejections a counter-example or luminance gate refused (magenta struck ×), ring: reference points like the sweep's own seed (violet double ring). The colors sit deliberately off the common CAD pens so they cannot vanish into color-plotted work. An overlay audit without marks shows only committed ink — the validation trap where 37 disclosed near-misses read as "it missed them". Rendering needs the optional native canvas (@napi-rs/canvas); where it isn't installed this tool errors cleanly and every other tool still works. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sheet": "<sheet>"
    },
    "name": "view_sheet"
  }
}

Input Schema

NameRequiredDescriptionDefault
pxNoLong-side pixel budget of the returned image (default 1400) — small region + high px = readable dimension strings
gridNoBurn in a calibrated 1-ft/5-ft measuring grid: "auto" = the sheet's set scale; otherwise the drawing scale as inches-per-foot, e.g. "1/4", "3/16", "0.25"
marksNoDisclosure marks to burn into the render (#297): what the reply names, the picture shows. Coordinates in image px
sheetYes
regionNoCrop rect in image px (origin top-left, y down); omit for the full sheet
overlayNoBurn committed shapes into the render (solid = human-affirmed, dashed = unreviewed)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / marks / additionalProperties
      Removed value: -false
    • addedInput schema / properties / marks / properties / question / items / additionalItems
      Added value: +false
    • removedInput schema / properties / marks / properties / ring / items / $ref
      Removed value: -"#/properties/marks/properties/question/items"
    • addedInput schema / properties / marks / properties / ring / items / additionalItems
      Added value: +false
    • addedInput schema / properties / marks / properties / ring / items / items
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "number"
      +  }
      +]
    • addedInput schema / properties / marks / properties / ring / items / maxItems
      Added value: +2
    • addedInput schema / properties / marks / properties / ring / items / minItems
      Added value: +2
    • addedInput schema / properties / marks / properties / ring / items / type
      Added value: +"array"
    • removedInput schema / properties / marks / properties / struck / items / $ref
      Removed value: -"#/properties/marks/properties/question/items"
    • addedInput schema / properties / marks / properties / struck / items / additionalItems
      Added value: +false
    • addedInput schema / properties / marks / properties / struck / items / items
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "number"
      +  }
      +]
    • addedInput schema / properties / marks / properties / struck / items / maxItems
      Added value: +2
    • addedInput schema / properties / marks / properties / struck / items / minItems
      Added value: +2
    • addedInput schema / properties / marks / properties / struck / items / type
      Added value: +"array"
    • removedInput schema / properties / region / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv0.1.19
    • addedInput schema / properties / marks
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Disclosure marks to burn into the render (#297): what the reply names, the picture shows. Coordinates in image px",
      +  "properties": {
      +    "question": {
      +      "description": "Open questions — withheld placements, spots to look at. Orange ?-in-circle",
      +      "items": {
      +        "items": [
      +          {
      +            "type": "number"
      +          },
      +          {
      +            "type": "number"
      +          }
      +        ],
      +        "maxItems": 2,
      +        "minItems": 2,
      +        "type": "array"
      +      },
      +      "type": "array"
      +    },
      +    "ring": {
      +      "description": "Reference points — the sweep's seed.center, an anchor. Violet double ring",
      +      "items": {
      +        "$ref": "#/properties/marks/properties/question/items"
      +      },
      +      "type": "array"
      +    },
      +    "struck": {
      +      "description": "Refusals — rejected[] placements, lum_gate.at. Magenta struck ×",
      +      "items": {
      +        "$ref": "#/properties/marks/properties/question/items"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  3. Addedv0.1.5

TDQS

A4.6/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 most of it: downsampling to a 2000-px long side and the resulting ~4:1 pixel ratio on an E-size sheet, the exact image-px coordinate space and the region->sheet transform formula, overlay color semantics (solid red affirmed vs dashed blue unreviewed), and a clean failure mode when @napi-rs/canvas is absent. It does not explicitly state the return container (inline image vs path), which is the one behavioral gap.

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 one-line purpose, then ordered by decision (crop vs full -> coordinates -> overlay -> grid -> marks -> environment caveat). Dense and mostly earned, but the parenthetical seed/flood diagnostics and repeated "don't squint / don't guess" exhortations push it past what a first read needs.

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 a no-output-schema render tool with nested mark objects and a coordinate transform, the description supplies everything needed to call it correctly and interpret the result: resolution, coordinate space and scale (PDF pt x 2, y down), overlay/grid/marks visual conventions, and the dependency failure mode.

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?

Adds real meaning beyond the 83%-covered schema: px is framed as an information-budget tradeoff (small region + high px = readable dimensions), grid explains "auto" vs an inches-per-foot literal like "1/4", and marks spells out what each coordinate list represents and why the colors are off-standard CAD pens. region's coordinate convention is restated with a worked formula rather than just "image px".

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?

"SEE the sheet — render the page (or a crop of it) to a PNG image" gives a concrete verb and resource, and the surrounding text implicitly distinguishes it from the vector/text siblings (get_sheet_vectors, read_sheet_text) by positioning it as the visual channel. An agent knows exactly what it gets back: a raster render, optionally cropped.

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?

Explicit routing: full-sheet render to find WHERE things are, tight crop to read linework and labels, plus a hard exclusion ("Never audit a trace or read a dimension off a full-sheet render"). It also names the downstream tools the returned coordinates feed into (measure_polygon, read_sheet_text) and states when to prefer grid over eyeballing.

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