Skip to main content
Glama
tobiasGuta

PrecisionPDF-MCP

by tobiasGuta

list_pdfs

Lists PDF files in the configured local workspace, returning up to 200 items so you can select documents for reading, highlighting, or annotation.

Instructions

List PDF files within the configured local workspace (up to 200).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses a hard cap ('up to 200'), which signals possible truncation, but omits whether listing recurses into subdirectories, what order results come in, or what happens when the workspace holds more than 200 files.

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?

A single tight sentence with the resource and scope front-loaded and the result cap appended. No filler or redundancy; every clause carries 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?

For a zero-parameter listing tool with no output schema and no annotations, the description covers the essentials (what is listed, from where, and the cap). It stops short of describing the return shape (names vs. paths) or the behavior past the 200-file limit, but the low tool complexity makes this nearly complete.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-arg tool applies. The description appropriately adds no invented parameter detail.

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 gives a specific verb ('List') and resource ('PDF files') scoped to a 'configured local workspace,' which is unambiguous. It is inherently distinguishable from siblings like read_pdf_page, render_pdf_page, and list_annotations, which operate on page contents or annotations rather than enumerated files.

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

Usage Guidelines2/5

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

There is no explicit statement of when to use this tool versus alternatives, nor any prerequisites (e.g., whether a workspace must be pre-configured). The intended discovery role is only inferable from the name and the sibling set, so guidance is essentially absent.

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