Skip to main content
Glama

ReMCP

by site.remcp
OverviewDiscussionsAdmin

Pdf Info

pdf_info
Read-onlyIdempotent

Use this when the user asks to inspect an existing local PDF file on an explicitly paired computer and retrieve its metadata and properties, such as page count, title, author or PDF version when the local pdfinfo utility is available. Supply the permitted PDF path. Without pdfinfo, the fallback reports file size in bytes and annotation count. This is read-only: it does not extract page text, edit annotations, write output or replace the source PDF.

Input Schema

NameRequiredDescriptionDefault
pathYesPermitted local filesystem path.
deviceYesReMCP device id returned by list_devices. Required for every device operation.

Output Schema

NameRequiredDescriptionDefault
dataNoPDF action structured result for pdf_action. Stable fields are declared explicitly; platform-specific fields may be added. Large results may return truncated/bytes/preview instead of the full payload.
textYesConcise human-readable result of the tool call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / output
      Removed value: -{
-  "description": "Optional permitted output path; when omitted the tool may update the input according to its action.",
-  "type": "string"
-}
    • removedInput schema / properties / output_dir
      Removed value: -{
-  "description": "Permitted directory for generated output files.",
-  "type": "string"
-}
    • removedInput schema / properties / pattern
      Removed value: -{
-  "description": "Output filename pattern where supported.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "device"
-]New value: +[
+  "device",
+  "path"
+]
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds genuine context: the dependency on the local pdfinfo utility and the concrete fallback behavior (reports file size in bytes and annotation count) when it is absent. The 'explicitly paired computer' / 'permitted path' wording also signals an authorization prerequisite.

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 trigger condition and the core action, then adds fallback and boundary sentences that each carry information. It is slightly dense across four sentences but nothing is redundant.

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?

With an output schema covering return values and annotations covering the safety profile, the description needs only to convey purpose, prerequisites and fallback behavior, all of which it does. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so both parameters are already documented in the schema. The description adds only marginal value ('Supply the permitted PDF path'), which reinforces but does not extend the schema's semantics.

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 (inspect a local PDF and retrieve its metadata/properties) and enumerates the concrete fields returned (page count, title, author, PDF version). It explicitly carves itself out from siblings like pdf_extract_pages and pdf_annotations by stating it does not extract text or edit annotations.

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 clear triggering context ('when the user asks to inspect an existing local PDF file on an explicitly paired computer') and notes the pdfinfo availability condition plus the fallback path. It describes boundaries rather than naming the specific alternative tools to use instead, so it stops short of a full when/when-not routing.

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

All ReMCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources