Skip to main content
Glama

write_on_page

Add handwriting ink, highlights, shapes, and diagrams to an existing notebook page at specified coordinates.

Instructions

Copy a notebook and draw on an existing page (1-based) in handwriting ink.

items is a list of objects, coordinates in page units (A4 = 1091 x 1543, origin top-left):
  {"type":"text","text":"...","x":100,"y":300,"width":800,"color":"red","size":11,"font":"patrick",
   "hand":"natural","pen":"ballpoint"}
    (y = first baseline; wraps inside width)
  {"type":"markdown","text":"...","x":100,"y":300,"width":800}
  {"type":"line"|"arrow","from":[x,y],"to":[x,y],"color":"blue"}
  {"type":"rect","x":..,"y":..,"w":..,"h":..,"color":"green","radius":0}
  {"type":"ellipse","cx":..,"cy":..,"rx":..,"ry":..,"color":"red"}
  {"type":"underline","x0":..,"x1":..,"y":..,"double":false}
  {"type":"check"|"star","x":..,"y":..,"size":18}
  {"type":"tape","x":..,"y":..,"w":230,"h":40,"angle":0.05,"palette":"mint","pattern":"stripes|dots|grid"}
  {"type":"highlight","x":..,"y":..,"w":..,"h":24,"color":"yellow"}  covers a box (e.g. a line
    of existing writing: y = top of the letters, h ~ 24 per line)
  {"type":"highlight_line","from":[x,y],"to":[x,y],"width":24,"color":"pink"}
    highlighter colours: yellow, pink, mint, lavender, peach, blue (Turkish names work) or #hex.
    These are real Noteful highlighter strokes, drawn translucent under the ink.
  {"type":"drawing","svg":"<svg viewBox=...>...</svg>","x":..,"y":..,"width":400}
    a diagram drawn by you; see the drawing notes below.
Aim with page_layout: it numbers the handwriting on the page and gives each item's bbox, so
a tick goes at x1 + 30, a circle around the bbox, the right answer gets a highlight. To grade
a quiz: render_page to read the answers, page_layout to find the options, then one
write_on_page call with every mark (and a score near the title).
The result is opened in Noteful for Mac when it is installed; the reply says which option to
pick in Noteful's dialog. Notebooks of the live library are never modified.
Drawings (organs, cells, models, circuits, graphs): write a plain SVG with a viewBox 400-650 wide. It is scaled to the width given ('!draw 480' = 480 page units, the page is 1091 wide; inside '!columns' it is capped by the column), so labels need font-size 18-22 in that viewBox to stay readable. Outlines: stroke="#1f2233" stroke-width="2" become hand-drawn ink. Fills become pastel highlighter colouring, even dark ones, so separate stacked parts with outlines, not with darker fills; later shapes cover earlier ones (draw the organ, then its parts). Labels: <text x y font-size text-anchor> become handwriting, placed outside the drawing and joined to the part with a <line>. Use curves (C/Q/A) for organic shapes; keep it schematic like a textbook sketch. See the drawing examples.

Input Schema

NameRequiredDescriptionDefault
pageYes
pathYes
itemsYes
open_in_notefulNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 safety burden and does so: it states the notebook is copied, that live-library notebooks are never modified, and that the result opens in Noteful for Mac with a dialog choice reported back. It omits failure modes and any cost/limits for large item lists.

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?

Long, but front-loaded with purpose then the item reference, and the length is justified by the 0% schema coverage. Some drag: the trailing 'See the drawing examples' is a dangling pointer and the drawing paragraph could be tightened.

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 complex, unannotated, no-output-schema mutation tool, the description supplies the coordinate model, every item type, a cross-tool workflow, non-destructiveness guarantees, and post-call behavior. An agent could invoke this correctly without further exploration.

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 0% (items is an untyped object array), so the description does the heavy lifting and documents the item mini-language in detail, including coordinate system, A4 units, origin, and per-type fields. Gaps remain: 'path' is never explained and 'open_in_noteful' is only implied by the opening behavior sentence, never named.

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?

The opening sentence names a specific verb pair and resource: copy a notebook and draw handwriting ink on an existing page, including the 1-based page convention. This is immediately distinguishable from read-only siblings like page_ink or render_page.

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?

It gives an explicit operating procedure: aim with page_layout, read answers with render_page, then issue one write_on_page call, plus a concrete quiz-grading recipe. It stops short of naming alternatives for the overlapping cases (design_page, example_pages, clean_copy) or stating when not to use this tool.

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