Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

list_comments

Read-onlyIdempotent

List review comments on PDF pages—sticky notes, highlights, shapes, stamps, and attachments—with ids, authors, text, dates, colors, and positions. Filter by page spec and returns up to 1,000.

Instructions

List the review comments on all pages or a page spec (e.g. "1-3,7"): sticky notes, highlights, underlines, strikeouts, squiggles, text boxes, shapes, ink, stamps and file attachments (not links or form fields). Each has its id ("p-", what add_comments' replies refer to), page, type, author, comment text, subject, created and modified dates (ISO 8601), color, rect ([left, bottom, right, top] in PDF points, in the page's own coordinates) and reply_to (the id of the comment it answers). Highlights and other text markup also give marked_text, the text under them, unless the PDF forbids copying (marked_text_withheld is then true; the owner password gives it). Up to 1,000 comments; truncated means there are more (list fewer pages).

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>"
    },
    "name": "list_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
pagesNo
passwordNo
input_pathYes

Output Schema

NameRequiredDescriptionDefault
pathYes
countYes
commentsYes
truncatedYes
text_withheldYes
marked_text_completeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral facts: a 1,000-comment ceiling with a truncation flag, the marked_text withholding rule tied to PDF copy permissions and the owner password, and the "ask" password flow that keeps secrets out of chat. The only gap is pagination or ordering behavior for large result sets.

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

Conciseness2/5

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

The purpose and page-spec syntax are front-loaded, but a long middle passage enumerates every returned field (id, page, type, author, dates, color, rect, reply_to, marked_text) even though an output schema already exists. That enumeration consumes most of the text without adding agent-facing value, and the security note trails at the end.

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?

For a three-parameter read tool with annotations and an output schema, the definition covers the notable risks (truncation, withheld text, password handling) well. Completeness is slightly diluted by detailing return fields instead of the undocumented input_path parameter.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry the load. It does explain the pages syntax ("1-3,7") and the password semantics including the special "ask" value, but input_path is never mentioned and no parameter is described exhaustively.

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 description names a specific verb and resource ("List the review comments") plus the scope ("on all pages or a page spec") and then enumerates the exact annotation types returned. It explicitly rules out links and form fields, which cleanly separates it from siblings like list_attachments and list_form_fields.

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?

Usage is clear: call this to read review annotations, optionally narrowed by a page spec, and use a smaller page range when the result is truncated. The exclusions ("not links or form fields") implicitly route the agent to the sibling list tools, but no alternative is named explicitly for those cases.

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