Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

search_text

Read-onlyIdempotent

Finds a literal word or phrase in a PDF and returns each match's page, surrounding snippet, and page-coordinate rectangles, with optional page range, case, whole-word, and result limits.

Instructions

Find a word or phrase in a PDF's text (literal text, not a pattern), on all pages or a page spec (e.g. "1-3,7"). Each match has its page, the matched text, a snippet of the text around it, and its rectangles on the page ([left, bottom, right, top] in PDF points, in the page's own coordinates before rotation; one or more per line).

The query is normalized (NFKC; whitespace runs count as one space; surrounding spaces are ignored, so use whole_word to match whole words only). A space can match across a line break. Matching ignores case (simple case folding) unless match_case. Emoji and other characters beyond U+FFFF can't be searched.

Returns up to max_results (1-1000) in page order; truncated means there are more. pages_without_text lists pages with no extractable text (e.g. scans; ocr_pdf makes them searchable); pages_skipped lists pages with too much content to search safely; complete is false if the 60 s time limit stopped the search early. Needs the owner password if the PDF forbids copying.

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

Input Schema

NameRequiredDescriptionDefault
pagesNo
queryYes
passwordNo
input_pathYes
match_caseNo
whole_wordNo
max_resultsNo

Output Schema

NameRequiredDescriptionDefault
pathYes
queryYes
matchesYes
completeYes
truncatedYes
match_countYes
pages_skippedYes
pages_searchedYes
pages_without_textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond readOnlyHint/idempotentHint: discloses query normalization (NFKC, whitespace collapsing), case-folding default, an explicit limitation (characters beyond U+FFFF), truncation semantics of max_results, a 60 s time limit that can set complete=false, pages_skipped for oversized pages, and the owner-password requirement when copying is forbidden. The 'ask' password mode explains that a secret never passes through the chat, which is exactly the kind of operational context annotations cannot carry.

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-loads the action and the literal-vs-pattern constraint, then layers matching rules, then return/edge-case behavior in a readable progression. It is dense rather than padded, but the enumeration of per-match fields (page, snippet, rectangles) is partly redundant given an output schema exists, so a little trimming was possible.

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 7-parameter search tool with an output schema and modest annotations, the description supplies everything an agent needs to call it correctly: input formats, matching semantics, result limits, failure/degradation signals (truncated, complete, pages_skipped, pages_without_text), and the password path.

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

Parameters5/5

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

With 0% schema description coverage, the description must carry all parameter meaning and largely does: pages accepts a spec like "1-3,7", query is normalized as described, match_case and whole_word are explained behaviorally, max_results is bounded to 1-1000 with truncation semantics, and password explains both the owner-password need and the "ask" value. Only input_path is left implicit, which is self-evident.

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 concrete verb+resource ('Find a word or phrase in a PDF's text') and immediately bounds the scope with '(literal text, not a pattern)', which distinguishes it from any regex/pattern search and from extraction siblings. An agent knows exactly what the operation does 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.

Usage Guidelines4/5

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

Gives real routing and option-selection guidance: 'use whole_word to match whole words only', and 'ocr_pdf makes them searchable' for pages without extractable text. It does not explicitly contrast with extract_text, but the literal-vs-pattern framing and the OCR pointer cover the main decision points.

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