Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

add_comments

DestructiveIdempotent

Add up to 100 review comments—highlights, underlines, notes, text boxes, or replies—to a PDF copy so feedback displays consistently in viewers and print.

Instructions

Add review comments to a copy of a PDF (default "_commented.pdf"). Each is drawn so it looks the same in every viewer and prints, and carries its text, author (the author argument) and date where viewers show comments. Up to 100 per call:

  • highlight / underline / strikeout / squiggly: over "text" (found as search_text finds it, ignoring case unless match_case; whole_word optional; every place it is found, up to 100, on "page" or on all pages), or over "rects" on "page" ([[left, bottom, right, top], ...] in PDF points, in the page's own coordinates, as search_text gives rectangles). "comment" adds a note to it.

  • note: a sticky note with its "comment", beside "text" (where it is first found, on "page" or in the PDF) or at "at" [x, y] (its top-left) on "page".

  • text_box: "text" drawn in a box at "rect" on "page" (Latin characters; font_size 4-72, default 12; border true by default); "comment" is its subject.

  • reply: a "comment" answering the comment whose id "to" names (list_comments gives ids; replies show with the comment they answer).

"color" is #rrggbb or a colour name (defaults: yellow highlights and notes, blue underlines, red strikeouts, green squiggles, black text boxes). Returns each comment's new ids. Nothing is written if any comment fails (e.g. text not found). Needs the owner password if the PDF forbids changing comments. Signed PDFs are refused (the change would invalidate the signature).

Any password argument can be "ask": the user then types it on a local page, so it never passes through the chat.

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": {
      "input_path": "<input_path>",
      "comments": "<comments>"
    },
    "name": "add_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
authorNo
commentsYes
passwordNo
overwriteNo
input_pathYes
output_pathNo

Output Schema

NameRequiredDescriptionDefault
addedYes
outputYes
commentsYes
password_protectedYes
user_password_changedYes
permissions_restrictedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint, idempotentHint) by disclosing atomicity ("Nothing is written if any comment fails"), the owner-password requirement for comment-locked PDFs, refusal of signed PDFs, the 100-per-call cap, and the "ask" password flow that keeps secrets out of chat. This is exactly the operational context an agent needs before mutating a file.

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

Conciseness5/5

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

Long, but front-loaded with the outcome and default filename, then organized into a tight bullet list keyed by comment type. Given seven variants and their differing arguments, almost every sentence conveys needed information.

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

Completeness4/5

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

An output schema exists and the description still summarizes the return ("Returns each comment's new ids"). Coverage of the nested CommentInput fields is thorough; only the "overwrite" behavior is left undocumented for a 6-parameter mutating tool.

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?

With 0% schema description coverage the description carries the load, and it does: it explains text/rects/page/at/rect semantics, units and coordinate space, color defaults per type, font_size range and default, border default, match_case/whole_word, and "to" for replies. The one gap is the top-level "overwrite" parameter, whose effect is never explained.

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?

States a specific verb and resource ("Add review comments to a copy of a PDF"), names the default output file, and enumerates all seven supported comment types, so an agent can immediately tell this is comment creation and not reading (list_comments) or text search (search_text).

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?

Per-type bullets make clear which arguments apply when, and it explicitly points at siblings for prerequisites ("found as search_text finds it", "list_comments gives ids"). It lacks an explicit when-not-to-use statement, but the operational context is unusually clear.

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