Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

export_markdown

DestructiveIdempotent

Saves PDF text as a UTF-8 Markdown file, choosing output path, bypassing extraction character limits, and handling password-protected PDFs.

Instructions

Save a PDF's text as a Markdown file (UTF-8, ending in .md or .markdown; default ".md" next to the PDF), read as pdf_to_markdown reads it, without its max_chars limit. Limits, pages_skipped and pages_without_text are as for pdf_to_markdown. 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>"
    },
    "name": "export_markdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
pagesNo
passwordNo
overwriteNo
input_pathYes
output_pathNo
page_markersNo
include_tablesNo

Output Schema

NameRequiredDescriptionDefault
outputYes
tablesYes
completeYes
headingsYes
truncatedYes
charactersYes
pages_readYes
pages_skippedYes
pages_without_textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the bar is lower. The description adds real context beyond them - password requirement for copy-protected PDFs, the 'ask' interactive password path, and that it preserves pdf_to_markdown's limits/pages_skipped/pages_without_text semantics - but never explains the destructive flag's practical meaning, i.e. whether an existing file at the default path is silently replaced (the 'overwrite' parameter goes unmentioned).

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-loaded with the primary action and default, then the pertinent details; no filler sentences. The parenthetical in the first sentence is dense but every clause carries information, and the trailing password note is a compact general rule that earns its place.

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, so return values need not be described, and the description covers the write destination, encoding, naming, and cross-tool fidelity. For a destructive file-writing tool with 7 parameters the main omission is overwrite/overwrite-on-collision behavior, which matters given destructiveHint=true.

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 parameter meaning, and it does explain output_path defaulting/naming, the password 'ask' sentinel, and pages via the pdf_to_markdown reference. However three of seven parameters - overwrite, page_markers, include_tables - receive no mention anywhere, leaving meaningful gaps at low coverage.

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 ('Save a PDF's text as a Markdown file') plus the file format, encoding, extension and default filename. It explicitly distinguishes itself from the sibling by noting it reads 'as pdf_to_markdown reads it, without its max_chars limit', so an agent can separate the two without opening schemas.

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?

The contrast with pdf_to_markdown ('without its max_chars limit', saves to a file rather than returning text) gives a clear condition for preferring this tool. It stops short of an explicit 'use this instead of X when' statement or any when-not guidance, so a 4 rather than a 5.

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