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

With no annotations, the description carries the full burden, and it does disclose genuine behavior: the operation copies the notebook, inserts pages at the end or after a 1-based index, and describes the rendering outcomes in detail. However, it never clarifies whether 'path' is the source or the destination copy, whether the original is preserved, whether the call is repeatable, or what is returned — material gaps for a write-style tool with 13 parameters.

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

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

The purpose is helpfully front-loaded in sentence one, but the body is an unstructured ~500-word wall that mixes a markdown DSL manual, an SVG drawing tutorial, and parameter docs into one paragraph. The long SVG section and formatting arcana belong in a reference doc or example_pages, not inline; an agent must scan the whole block to find the two or three sentences that constrain correct invocation.

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

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

For a rendering-heavy tool the description is unusually rich on the output-authoring side, and with no output schema it rightly spends its budget on what the pages will look like. But the operational essentials an agent needs before calling — what 'path' means, where the copy lands, what a successful response looks like, and what size/ink/open_in_noteful do — are absent, leaving a complete picture of formatting and an incomplete picture of the call itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and no enums are declared, so the description is the only source of parameter semantics — and it delivers real value, enumerating look values and their meaning, theme light/dark semantics, paper (dot|grid|ruled|blank), seven fonts, three hand styles, and two pens, plus after_page indexing. Gaps remain: 'size', 'ink', 'open_in_noteful', and the required 'path' are never explained, and the accent list (coral, amber, sky, purple, teal, pink) omits the declared default 'blue'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a concrete compound verb and resource: copy a notebook and append/insert handwritten pages, with the placement rule (end, or after page N, 1-based) spelled out. That is enough to tell it apart from render_page or page_layout in practice, but the description never names a sibling or explicitly contrasts them, so it stops short of a 5.

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

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

Usage is implied by the imperative phrasing rather than stated: an agent can infer 'use this to author new pages in a copy of a notebook'. The one explicit workflow cue is 'Read an example first: example_pages', which points at a sibling but only as a prerequisite, not as an alternative. There is no when-not-to-use guidance versus design_page, write_on_page, or design_mockup.

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

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

With no annotations, the description carries the full burden; it does disclose that the tool inserts a new page immediately after the target page, implying a document mutation and page reindexing. It says nothing about permissions, whether the original page is preserved, failure/error behavior, or the side effect of the default open_in_noteful=true. Moderate disclosure for a mutation tool.

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

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

Purpose and workflow are correctly front-loaded in the first two clauses, which is good. But the remainder is a single dense run-on block cramming the markdown DSL, styling options, and SVG drawing rules together with no headings or list structure, making it hard to scan for a specific directive.

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

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

For a 12-parameter, no-annotation, no-output-schema tool, the description covers the hard part (the markdown/DSL grammar) thoroughly and even cautions about SVG scaling and fill behavior. Gaps remain around three undocumented parameters and the absence of any statement about what the tool returns or how the original page is handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 12 parameters, so the description must compensate, and it largely does: look, theme, paper, font, hand, pen are all given value sets and defaults, and markdown's grammar is exhaustively documented. However, `ink`, `accent`, and `open_in_noteful` are never mentioned, and `path`/`page` semantics are only implied ("the given page").

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and effect: "insert a neat handwritten rewrite right after the given page." That distinguishes it from the rendering/inspection siblings (render_page, page_ink) and from write_on_page. It never names a sibling to route away from, so it stops short of a 5.

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

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

Explicit workflow is given: "First call render_page and read the messy page yourself; then pass the cleaned, well structured content as markdown," plus "Read an example first: example_pages." These name real siblings and the order to call them in. No when-not-to-use condition or comparison against write_on_page/design_page, so not a 5.

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

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

With no annotations, the description carries the full burden and delivers unusual behavioral detail: fills are flattened to pastel highlighter, later shapes occlude earlier ones, and SVG strokes are converted to hand-drawn ink. It omits side effects an agent would care about, notably what open_in_noteful does and where the created notebook lives, which keeps it off 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.

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

The bulk is a semicolon-chained markdown/DSL reference crammed into a single run-on block, which is poorly front-loaded and far larger than a tool description should be. The content is high-value but belongs in a referenced doc; as prose structure it is almost unusable for scanning.

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

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

For a 13-parameter creation tool with no annotations and no output schema, the description covers the hard part (page markdown grammar and drawing conventions) but is silent on creation side effects, the open_in_noteful toggle, and what the call returns. Adequate for authoring content, incomplete for invoking the tool safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must document 13 parameters, and it substantively does for look, theme, paper, font, hand, pen, and the entire markdown dialect. It leaves ink, seed, size, accent, open_in_noteful, and title unexplained, so roughly a third of the surface is still bare.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Create a new notebook') plus the distinguishing medium: pages in natural handwriting ink. It does not, however, distinguish itself from page-producing siblings like design_page, render_page, or design_mockup, so an agent must infer the boundary.

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

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

It gives real conditional guidance for parameter choices ('look: study ... or classic', 'theme: light for summaries | dark for question/tree pages') and points at example_pages to read first. What it never says is when to call this tool instead of siblings such as add_pages or design_page, so tool-level routing is left implicit.

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

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

With no annotations, the description carries the full burden and does add real operational context: the image model runs on the user's own Google account via GEMINI_API_KEY or NOTEFUL_VERTEX_PROJECT, and it returns the mockup path, mockup, and grid. It omits cost/latency implications of image generation, whether the mockup is persisted into a notebook or output folder, and how many reference names exist.

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

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

Front-loaded with the action and the payoff before parameters. Dense parameter walkthrough uses colons to pack a lot in, but the run-on 'content:'/'look:' clause is harder to scan than separate sentences would be.

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

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

No output schema, yet the returns are described (path, mockup, grid); no annotations, yet auth and environment prerequisites are disclosed. A generative tool with cost and persistence implications would benefit from one line on where the mockup is written and whether repeat calls are expensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate entirely, and it does: content is defined as page contents plus rough placement with the instruction to quote exact titles and labels; look gets both enum values, the default, and concrete visual meaning; theme lists light|dark; reference covers per-theme defaults and the 'previous page's mockup path' consistency case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Draw a picture of a study page with an image model') and ties it to its downstream consumer, design_page, which converts the mockup into ink. That contrast alone distinguishes it from siblings like design_page, clean_copy and render_page.

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

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

Gives real decision guidance: default to 'calm' and reserve 'rich' for visual summary pages, with an explicit warning that a notebook full of rich pages looks overdone. Reference defaults are conditioned on theme (clean-copy for rich light, answers-tree for dark, none for calm). It does not name siblings such as example_pages for browsing the gallery, so the 'gallery example name' reference is left slightly ungrounded.

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

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

With no annotations, the description carries the full burden and does most of it: items are drawn in order, 'auto' colours are sampled from the mockup at that spot, image-model body text is garbled so the agent must supply correct words, and trace/erase lets labels be dropped from traced drawings. It does not state overwrite/reversibility semantics for target pages, nor what open_in_noteful does, which keeps it from 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.

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

The workflow and spec format are front-loaded and useful, but the opening intent is restated three times ('Write pages that copy page designs…', 'Copy a page design into real ink.', 'Copy a page design (an image model's mockup) into real Noteful ink.'), and the spec block is long and dense. Much of the length is justified by the 0% schema coverage, but the redundant framing sentences do not earn their place.

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

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

For a parameterless-output write tool with a complex free-form nested 'pages' array and no annotations, the description supplies the item-type vocabulary, coordinate conventions, inline markup syntax, and workflow needed to actually construct a call. The remaining holes are the undocumented open_in_noteful flag and the return value, which there is no output schema to cover.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and has no nested descriptions, so the description must compensate: it explains pages (one spec per page), title (new notebook), path (append to existing/live notebook), and after_page (1-based insertion point). It also documents the entire nested spec object in detail. The one clear gap is open_in_noteful, which is never mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb (write/copy) and resource (pages of ink reproducing a mockup), and the workflow line names the sibling tools it depends on (design_mockup, mockup_grid, render_page). An agent can distinguish this from design_mockup (which produces the mockup) and write_on_page without opening any schema.

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

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

It gives an explicit ordered workflow: design_mockup (or a user-supplied picture) -> mockup_grid to read coordinates -> design_page -> render_page to compare and fix. It also states the branch condition for output target: 'Either title (a new notebook) or path (add to that notebook after after_page, 1-based; live notebooks too)'.

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

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

With no annotations, the description carries the weight and discloses the return behavior for each mode: the example list plus style guide without a name, the source (Markdown/SVG) and a preview image with a name. What it omits is failure behavior when a name is unknown and whether names must match exactly.

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

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

Three short, front-loaded sentences: identity, mode split, then the usage instruction. Minimal waste; only the parenthetical 'study Markdown or SVG' is slightly clunky phrasing.

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

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

There is no output schema and just one optional parameter, and the description covers both modes and the workflow prerequisite, so an agent can call it correctly. Missing only edge details such as name format or what happens on an unknown name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the only field is a nullable 'name' with no description, so the description must supply the meaning — and it does, explaining that absence yields the list and presence yields source plus preview. That is a real addition beyond the schema's default-null declaration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (example pages and drawings with source and appearance) and, by naming the tools that should consume it, implicitly distinguishes it from render_page/page_layout siblings. It stops short of saying how it differs from a live library or preview tool, but the purpose is unambiguous.

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

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

Explicitly prescribes when to use it: read the matching example before create_notebook, add_pages, clean_copy, or a write_on_page drawing, and follow its structure. It also splits behavior by mode (no name vs. name), so an agent knows both when and how to call it.

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

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

With no annotations, the description carries the full burden. It usefully discloses that backgrounds, ink, and images are all included, but says nothing about whether a file is written/overwritten, where it lands, permission or licensing requirements, or how scale affects fidelity.

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

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

One sentence, front-loaded with the verb and resource, no filler. The parenthetical earns its place by enumerating rendered layers.

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

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

An output schema exists, so return values need not be explained, but with zero annotation coverage and three undocumented parameters the definition is not sufficient to call it confidently — the path/out relationship and scale meaning are unresolved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description mentions no parameters at all, leaving 'path' (required), 'out' (optional, and confusingly overlapping with path), and 'scale' (default 1.5) entirely unexplained. The description adds nothing beyond the raw schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ('Render the whole notebook ... into a PDF') with a parenthetical enumerating what is rendered. The word 'whole' implicitly distinguishes it from page-level siblings like render_page and render_region, though it never names them.

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

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

Usage is only implied through the scope word 'whole notebook'; an agent can infer this is the export-everything option rather than a single page. There is no explicit when-to-use statement, no exclusion, and no sibling is named despite render_page/render_region/design_mockup being nearby alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says files are saved to a folder but does not disclose overwrite behavior, directory creation, permissions, failure modes, or whether the operation is destructive to existing files.

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

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

The definition is a single, front-loaded sentence with no wasted words. It states the core action and scope immediately.

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

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

Although an output schema exists, the description leaves critical input semantics undocumented: what path refers to and how out_dir defaults when null. For a file-writing tool with no annotations and 0% schema description coverage, this is incomplete for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for both parameters. It only vaguely implies an output folder via 'to a folder' and says nothing specific about the required path parameter or what happens when out_dir is null.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: save embedded PDFs and images (backgrounds, pasted pictures) to a folder. It is clearer than the generic tool name extract_files, but it does not distinguish this from sibling tools like export_pdf or output_folder that also write files.

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

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

The only implied usage cue is that the tool handles embedded PDFs and images, but there is no explicit guidance on when to use this instead of export_pdf, render_page, or output_folder. No prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden and discloses almost nothing: not whether the operation is read-only, not whether archive_json is a filesystem path or raw JSON text, and not whether large archives are truncated or paginated. The existence of an output schema removes the need to describe return values, but the input-side and safety behavior remain opaque.

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

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

It is a single short phrase with no filler, so nothing is wasted. However, the brevity comes at the cost of under-specification rather than tight, information-dense phrasing — a noun phrase with no verb is not truly front-loaded with actionable intent.

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

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

An output schema exists, so return values need not be described. But for a tool with zero annotation coverage and a completely undocumented required parameter, the description should at minimum clarify the input format and the read-only nature; it does neither, leaving an agent with real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single required parameter, so the description must compensate. It hints that the value relates to an 'archive.json' from a Noteful export, but never clarifies whether the string is a path, a URL, or serialized JSON content — the single most important ambiguity for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The fragment 'Folder / notebook tree from a Noteful export's archive.json' names the resource that comes back, but there is no verb and no indication of whether it reads, builds, or extracts the tree. It also does not distinguish itself from siblings like list_notebooks or live_library, which plausibly return similar hierarchy information.

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

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

There is no when-to-use guidance at all: no mention of when this tree view is preferable to list_notebooks, live_library, or notebook_info. The only contextual hook is 'from a Noteful export's archive.json', which implies an offline/exported archive scenario but never states it as a selection condition.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior — that folder paths are resolved from archive.json 'when present' (implying some notebooks lack them) and that scanning defaults to configured roots such as iCloud Drive/Downloads backups and the MCP output folder. It does not state recursion behavior, read-only/disk-access implications, or expected cost of scanning large roots.

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

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

It is short and front-loads the purpose, then parameter notes. Two sentences earn their place, but the parenthetical default-roots example is long-winded and the parameter glosses are packed into one dense paragraph rather than cleanly separated.

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

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

With an output schema present, return values needn't be described, and the tool only has two optional params with defaults. Still, an agent must guess whether subfolders are recursed, whether results are sorted, and whether 'root' composes with the configured roots or replaces them — gaps that matter for a filesystem-listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it largely does: 'root' is defined as the folder to scan with a stated default, and 'query' is defined as a case-insensitive filter over title AND path. Remaining ambiguity is format-level (is root a single path? are multiple roots accepted?) rather than conceptual.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line gives a specific verb+resource: 'List .noteful notebooks', plus the useful detail that folder paths come from archive.json when present. It doesn't name the sibling it is not (library_tree, live_library, notebook_info), so the differentiation from adjacent notebook-listing tools is left to inference.

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

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

The description explains what the two optional parameters do and what happens when omitted (defaults to configured roots), which implies the basic usage pattern. But it never states when to pick this tool over siblings like library_tree or live_library, nor any exclusions or prerequisites.

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

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

With no annotations, the description carries the load and does disclose real behavioral traits: it reads the iCloud-synced live library rather than a snapshot, and it degrades to listing exported .noteful files when Noteful for Mac is absent. That environmental dependency is exactly the kind of thing an agent otherwise cannot know. It stops short of stating read-only/side-effect status or refresh/caching behavior.

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

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

Four short lines, front-loaded with what the tool returns before the query semantics and the fallback caveat. No padding. Slightly clipped phrasing in the opening line ('Folder / notebook tree...') costs a little clarity.

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

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

An output schema exists, so the return shape does not need spelling out, and the description usefully covers the live-ref format. The gaps are `include_archived` being undefined and the absence of any disambiguation from `library_tree`, which for a tool with a near-duplicate sibling is a meaningful omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully explains `query` (optional, case-insensitive, matches folder path or title), which is genuinely useful, but `include_archived` is never mentioned anywhere, leaving one of two parameters undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: a folder/notebook tree of the *live* Noteful library, with page counts and 'live:<id>' refs. The 'live' qualifier meaningfully separates it from static/exported output, though it never names the near-identical sibling `library_tree`, leaving the agent to infer the distinction.

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

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

The line about 'live:<id>' being 'usable by every read tool' implies a workflow (fetch ids here, then pass to read/render tools) and the fallback case is stated. But there is no explicit rule for choosing this over `library_tree`, `list_notebooks`, or `notebook_info`, which are the obvious alternatives.

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

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

No annotations exist, so the description carries the whole burden. It discloses the visual behavior of region zooming to a finer grid, which is genuinely useful, but says nothing about what the tool actually returns (image data, a file on disk, a path), whether it writes anything, or any permission/cost constraints.

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

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

Two short sentences, no filler, with the tool's purpose front-loaded and the region behavior following. Every clause contributes information the agent cannot get from the schema.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description should do more: the return format of a grid-overlay image tool is unspecified, and two of three parameters (path, step) are undocumented anywhere. Only region is adequately covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameters. It does well for region, giving the exact [x, y, w, h] ordering and the effect of zooming to a finer grid, but path and step are never explained — step's default of 50 and its role in grid density are left entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete output: a page picture overlaid with a labelled pixel grid whose purpose is extracting coordinates for a design_page spec. That is specific enough to separate it from rendering siblings like render_page or render_region, though it never names those siblings to make the distinction explicit.

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

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

The purpose chain is implied clearly: use this to read coordinates that a design_page spec needs. But there is no explicit 'use when / don't use when', no mention that it precedes design_page, and no reference to the alternatives (design_mockup, render_region) that could plausibly be confused with it.

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

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

With no annotations, the description carries the burden of disclosure. It adds some useful behavioral context by enumerating the metadata and per-page details returned, implying a read-only metadata lookup, but it never explicitly confirms read-only behavior, side effects, or access requirements.

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

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

The description is a compact single sentence fragment with no wasted words. Its structure is slightly weak because it begins with a noun list rather than an action, but it is appropriately sized.

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

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

The tool is simple and has an output schema, so the description does not need to detail return formatting. However, it omits key context such as what the path parameter refers to and when this metadata retrieval is preferable to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single required path parameter has 0% schema description coverage, and the description does not mention the path parameter at all. An agent must infer that path identifies the target notebook from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists the information returned (title, dates, folder, per-page details), which implies retrieval for a notebook, but it lacks an explicit verb and does not distinguish this tool from siblings such as list_notebooks or page_layout. The purpose is inferable but not crisply stated.

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

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

There is no indication of when to use notebook_info versus list_notebooks, search_text, or the page-specific siblings. No alternatives, prerequisites, or exclusions are mentioned.

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

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

With no annotations, the description must carry the full behavioral burden, but it does not say whether invoking the tool has side effects, whether it is read-only, or what kind of value it returns. The output schema exists, so return format need not be explained, but basic behavior remains undisclosed.

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

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

The definition is a single short sentence with a useful parenthetical, so it is appropriately sized and front-loaded. It is concise, though the fragmentary wording leaves the core action implicit.

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

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

Given zero parameters and an output schema, the description need not explain return values, but it still fails to say what calling the tool does. For an agent choosing among notebook and page tools, the definition is too thin to be reliably actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and nothing in the schema coverage creates a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description says what the folder is for ('Where written notebooks go') and adds an import hint, but it never states the action the tool performs, such as returning the output folder path. An agent can infer it relates to output location, but the purpose is vague rather than a specific verb+resource.

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

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

There is no explicit guidance on when to use this tool versus siblings like list_notebooks or export_pdf. The parenthetical 'import them in Noteful via Files' hints at a workflow but does not say when the agent should call this tool.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only statistics operation but never confirms that, nor does it say whether the page must exist, what happens for blank pages, or whether path refers to a notebook or page file. Only the returned fields are hinted at.

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

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

A single front-loaded sentence with no filler; the metric list is efficient. The telegraphic phrasing is compact but borders on under-specification rather than waste.

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

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

An output schema exists, so return values needn't be explained, but with zero annotation coverage and two completely undocumented parameters the description leaves too much for the agent to guess. For a statistics tool that takes a path and page index, the minimum context on inputs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not document either parameter. 'of a page' vaguely gestures at the page parameter but gives no numbering base or default, and the required path parameter is not explained at all (notebook path? page file path?). The description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (a page) and enumerates exactly what it reports: stroke count, colours, pen widths, written area. That distinguishes it reasonably well from render_page and page_layout, though it never explicitly contrasts with the closely related page_marks. Clear purpose, weak sibling differentiation.

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

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

There is no when-to-use guidance at all — no statement of what question this answers that page_marks or page_layout would not, and no exclusions. The agent must infer usage entirely from the tool name and sibling list.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses that results are numbered, in reading order, and that coordinates are in page units with bbox format [x0, y0, x1, y1]. It stops short of explaining the effects of image/scale or the exact response structure (JSON items vs. rendered image).

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

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

Two short paragraphs, front-loaded with what the tool returns before the workflow guidance, and no filler. The coordinate example ('a check at x1 + 20, (y0 + y1) / 2') is dense but earns its place by making the placement math unambiguous.

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

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

With no annotations, no output schema, and 0% schema coverage on four parameters, the description should explain more. It covers the return semantics and cross-tool workflow well, but leaves the meaning of path, page, and scale entirely to inference, which is a real gap for an agent invoking it the first time.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters, so the description must compensate and largely doesn't. It never explains path (the notebook file), page (default 1), or scale (default 0.9); only the image parameter is indirectly hinted at via 'read the numbered image'. The bbox/coordinate explanation is useful but describes output semantics rather than the inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely (the page's ink) and specifies the output shape: numbered items of words/phrases per line, bounding boxes in page units, in reading order. That level of detail lets an agent distinguish it from siblings like page_ink, page_marks, and render_page without opening the schema.

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

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

It gives an explicit use case and the alternative it precedes: 'Use it before write_on_page to aim marks', then walks through the concrete workflow of reading the numbered image and placing a check relative to a bbox. It doesn't say when NOT to use it, and doesn't clarify the boundary against overlapping siblings like page_ink or page_marks.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: tape states ("covered" hides content, "revealed" was tapped open), the 12-crop cap, and that crops reveal tapes. It never states error behavior for a bad path, permissions, or that this is a read-only operation.

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

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

Front-loaded summary sentence followed by labeled blocks for highlights, tapes, and crops — no filler. Slightly dense prose, but each clause adds information an agent needs.

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

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

There is no output schema and no annotations, so the description must describe the return shape; it does this reasonably (regions with colour and bbox, tapes with bbox and state). The gap is the undocumented path parameter, which is required to call the tool at all.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for all three params. It adds real meaning for crops (zoomed region crops, max 12, tapes revealed) and page (1-based), but says nothing about path, the required parameter, leaving the most important argument undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Highlighter and tape marks of a page (1-based)" names a specific resource and content type that is clearly distinct from sibling extractors like page_ink and page_layout. It stops short of explicitly contrasting itself with those siblings, but an agent can tell what it retrieves.

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

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

Usage is only implied — the agent must infer that this is the tool to call when it needs existing highlights/tape regions. It does route to render_page/render_region with reveal_tapes=True for hidden content, which is a useful alternative pointer, but no when-not-to-use condition is stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it fails: whether the original notebook is preserved (as "Copy" implies) or replaced (as "rename" implies) is left contradictory and unstated. Nothing is said about permissions, whether an existing notebook with the target title is overwritten, or side effects, which is a serious gap for a mutating tool with zero annotation coverage.

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

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

The single sentence is front-loaded and free of waste, which is good, but at this length it reads as under-specification rather than conciseness. It could carry the source/destination and copy-vs-rename clarification without bloat.

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

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

An output schema exists, so return values need not be explained, but for a two-parameter mutating tool with no annotations and 0% schema coverage the description provides almost nothing: not the meaning of path, not whether the source survives, not what happens on title collision. It is not complete enough for an agent to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so both parameters (path, title) are bare strings with no explanation in either schema or description. "under a new title" weakly implies title is the new name, but it is never said whether path is the source notebook's path or the destination location, nor what format either accepts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource ("Copy a notebook under a new title"), but it conflicts with the tool name rename_notebook. An agent reading the name expects in-place renaming, while the description describes creating a copy, and the sibling list contains create_notebook and clean_copy, so the ambiguity is real and unresolved.

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

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

There is no statement of when to use this tool, when not to, or which sibling to prefer for copying versus creating versus renaming. The agent must infer from the tool name alone that this is the right choice over create_notebook or clean_copy.

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

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

With no annotations, the description carries the burden and does disclose a non-obvious behavioral trait: covered tapes render striped as on the iPad, and reveal_tapes=True outlines them so hidden content shows. It omits whether rendering is read-only/side-effect free and what the returned payload looks like.

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

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

Two short sentences, purpose front-loaded, followed by only practical rendering tips. Every clause (scale values, tape rendering, reveal behavior) earns its place with no filler.

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

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

For a 5-param tool with no annotations and no output schema, the description covers rendering semantics and two behavioral edge cases well. Gaps remain around the meaning of `path` (notebook path vs. file path) and what `background` toggles, which an agent would still have to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for three of five params: page is 1-based, scale has concrete pixel implications, and reveal_tapes has an explicit visual effect. The required `path` and the `background` toggle are left completely undefined, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Render a page ... as PNG") plus the downstream purpose (read handwriting and drawings) and the 1-based indexing convention. The whole-page scope implicitly separates it from render_region, but no sibling is named explicitly.

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

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

Provides in-context guidance on scale (0.9 gives ~980px wide; 1.5+ to zoom into small writing), which is genuinely actionable. However, it never says when to prefer this over render_region, page_ink, or page_layout, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden, and it only partially discharges it. The coordinate-unit convention (page units, A4 = 1091 x 1543) is genuinely valuable context, but the description says nothing about output format, what scale does, what reveal_tapes exposes, or whether path must reference an existing PDF.

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

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

Two short sentences, front-loaded with the action and followed immediately by the detail an agent most needs before computing coordinates. No filler, though the terseness shades into under-specification rather than true efficiency.

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

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

With no annotations, no output schema, and 8 undocumented parameters, the description leaves too much unresolved for an agent to call this confidently — particularly around scale semantics, the reveal_tapes flag, and what the call returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must compensate. It clarifies units for x/y/w/h but leaves path, page, scale, and especially reveal_tapes entirely unexplained — over half the surface remains opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Zoomed crop of a page" gives a specific verb (crop/render) and resource, and the word "zoomed" distinguishes it from the full-page sibling render_page without naming it. It falls short of a 5 because the sibling is never mentioned and the output form (image vs. file) is left implicit.

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

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

Usage is only implied: an agent can infer this is the tool for examining a small area of a page rather than the whole page, since render_page exists as a sibling. There is no explicit when-to-use, when-not-to-use, or named alternative.

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

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

No annotations are provided, so the description carries the full burden; it does disclose the key behavioral constraint (indexing scope covers only four content types, handwriting excluded) and that results point back to notebooks. It says nothing about permissions, result ordering, or pagination behavior, which matters given the limit parameter.

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

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

Two tight sentences with no filler; the scope statement comes first and the exclusion/remediation second. Every sentence earns its place.

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

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

The output schema covers return values, so the description needn't explain them, and the indexing-scope limitation is well covered. But for a parameterized search tool with zero schema documentation, the description leaves query syntax and the limit parameter entirely unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate. It mentions no parameter at all — neither the required 'text' query nor the 'limit' cap (default 50) — leaving the agent to infer semantics such as whether text is a phrase, substring, or boolean query.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) and resource (the live library's indexed text), and enumerates exactly which content types are indexed: pdf text, typed text boxes, outlines, bookmarks. This distinguishes it from content-reading siblings like render_page or page_ink without needing to open any schema.

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

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

Explicitly excludes handwriting content and redirects to render_page on the hit notebooks, which is a clear when-not-to-use plus alternative. It does not, however, say when to prefer text search over other navigation siblings (library_tree, notebook_info), so routing is only partially covered.

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

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.

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.

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.

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.

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.

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.