Paperboy

Official

Overview Schema Source Related Servers Discussions Admin

list_form_fields

Read-onlyIdempotent

Lists a PDF form’s fields—name, type, current value, allowed options, flags, and page—so you can identify inputs before filling them.

Instructions

List a PDF form's fields: full name, type, current value, allowed options, flags, page.

Use the names with fill_form. If copying is forbidden and only the open password is given, values are withheld (values_hidden) but the fields are still listed.

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": "list_form_fields"
  }
}

Input Schema

Name	Required	Description	Default
`password`	No
`input_path`	Yes

Output Schema

Name	Required	Description	Default
`path`	Yes
`count`	Yes
`fields`	Yes
`has_form`	Yes
`values_hidden`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, closed-world), and the description adds genuinely new behavioral facts beyond them: values are withheld (values_hidden) when copying is forbidden and only the open password is supplied, and the fields are still listed. It also explains the "ask" sentinel's security behavior, where the password is typed on a local page and never passes through the chat.

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?

Front-loads the core purpose in one line, then adds two short paragraphs on usage and password/withholding behavior. Every sentence carries non-redundant information; no filler.

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?

An output schema exists, so return values need not be spelled out, yet the description still flags the values_hidden edge case that affects interpreting the output. For a two-parameter read-only tool, nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 0%, so the description must carry parameter meaning, and it does define the critical semantic of the password argument via the "ask" sentinel and the open-password restriction. The input_path argument is only implied by context rather than explained, which keeps it from a 5.

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 ("List a PDF form's fields") and enumerates exactly what is returned: full name, type, current value, allowed options, flags, page. It also implicitly separates itself from the write-side sibling by saying the names are meant for fill_form.

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 a concrete downstream usage rule: use the returned field names with fill_form, which routes the agent correctly among siblings. It does not state explicit when-not conditions (e.g., when to use inspect_hidden_data or check_pdf instead), so it falls short of a full 5.

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