Skip to main content
Glama
Sign In
Precision PDF MCP Server

Precision PDF MCP Server

by zuan412
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

hpe_inspect_virtual_grid

Generate a temporary Excel-style grid overlay with Set-of-Marks slot badges to visually inspect PDF form fields and map detected answer slots without altering the original.

Instructions

Generate a temporary Virtual Excel Grid Inspector Image with Set-of-Marks (SoM) slot badges. This image overlays:

  • Top Excel column letters (A, B, C...)

  • Left Excel row numbers (1, 2, 3...)

  • Labeled slot pill badges: [S01], [S02], [S03]... on every detected blank, underline, or box. Returns JSON containing:

  • inspector_image_path: Path to the image (view it via view_file to visually inspect the layout!)

  • slots: Catalog of detected slots with tag, type, baseline, and Excel grid address (e.g. Col K, Row 9). NOTE: This is strictly a virtual guide for the agent's eyes; it does NOT alter the PDF!

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": {
      "pdf_path": "<pdf_path>",
      "page_number": "<page_number>"
    },
    "name": "hpe_inspect_virtual_grid"
  }
}

Input Schema

NameRequiredDescriptionDefault
dpiNo
pdf_pathYes
page_numberYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explicitly discloses that it is 'strictly a virtual guide for the agent's eyes; it does NOT alter the PDF', and it documents the returned fields (image path, slot catalog). It stops short of covering lifecycle concerns such as temporary-file cleanup or processing cost.

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?

The description is front-loaded and bullet-structured, with the artifact defined first, then overlays, then returns. Every line carries information, including the useful closing NOTE; it is slightly longer than strictly necessary but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so describing return values is a bonus rather than a requirement, and the read-only nature is well covered. The remaining hole is total silence on the three input parameters, which for a tool with no annotations leaves an avoidable gap before invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, and it adds essentially no parameter meaning: pdf_path, page_number, and dpi are never mentioned or explained. A caller gets no guidance on accepted path formats, valid page ranges, or how dpi affects the badge rendering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Generate a temporary Virtual Excel Grid Inspector Image with Set-of-Marks (SoM) slot badges', and even enumerates the overlays it produces. It is clearly distinguishable from a plain render or a fill tool, though it never names a sibling (e.g. hpe_inspect_geometry) to sharpen the boundary.

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

Usage Guidelines3/5

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

Usage is only implied: it says to view the output via view_file 'to visually inspect the layout', which hints at a pre-fill inspection workflow. There is no explicit when-to-use vs hpe_inspect_geometry/hpe_snap_fill guidance, and no stated prerequisites or exclusions.

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

Deploy Server

Other Tools