Skip to main content
Glama

hpe_fill_slots

Inject answers into PDF form slots by ID to populate worksheets, with baseline-snapped text, centered options, multi-line wrapping, and clean output containing only answers.

Instructions

Inject answers into the PDF using Slot IDs (e.g. {"S01": "answer", "S02": "B"}). Guarantees:

  • 100% baseline snap on printed lines (zero floating text).

  • 100% center alignment in boxes (zero off-center boxes).

  • Automatic multi-line wrapping across consecutive lines for long answers.

  • Automatic font scaling to avoid text collision or overflow.

  • 100% CLEAN OUTPUT: Final PDF contains ONLY answers (zero grid lines, zero badges). Args: pdf_path: Path to target PDF. page_number: 1-based page number. slot_answers_json: JSON string mapping slot tags to answers: e.g. '{"S01": "went", "S02": ["line 1 text", "line 2 text"], "circle_option": "A"}'

output_path: Optional output path. If omitted, overwrites safely via atomic replace. Returns status JSON with saved path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pdf_pathYes
output_pathNo
page_numberYes
slot_answers_jsonYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/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 behavioral burden and does so well: it discloses overwrite-via-atomic-replace when output_path is omitted, wrapping behavior, font auto-scaling, and that the output contains only answers. It stops short of failure modes or how invalid slot IDs are handled.

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 core action and then an Args list, so it is easy to scan. The repeated emphatic '100% ... zero ...' guarantee phrasing is slightly padded but each line does convey a distinct behavioral trait.

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 4-param mutation tool with an output schema, the description covers the action, every parameter, and the return shape ('status JSON with saved path'). The main omission is any tie-breaking against the near-identical sibling tools.

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?

Schema description coverage is 0%, yet the Args block documents all four parameters, including that page_number is 1-based and that output_path is optional with atomic-replace semantics. The slot_answers_json entry adds concrete JSON examples covering plain strings, multi-line arrays, and a special key, far exceeding the bare schema.

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?

States a specific verb and resource ('Inject answers into the PDF using Slot IDs') and shows the data shape immediately. However, it never distinguishes itself from the very similar sibling hpe_snap_fill, so an agent must infer the difference without help.

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 implied by the description (fill slot IDs on a given page) but there is no explicit when-to-use or when-not guidance, and no routing to alternatives such as hpe_snap_fill or hpe_render_verify. The agent is left to infer selection.

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