Extract local PDF tables to CSV

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

Well beyond the annotations (which only say it isn't read-only and isn't destructive): the description discloses output encoding (UTF-8 BOM, comma, CRLF, blank rows between tables), date normalization rules for ambiguous auto dates, formula escaping, and a conservative filter preflight with refusal conditions. Gap: it never says whether an existing output_path is overwritten, and 'blocked PDF names printed in text' is opaque jargon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core verb and resource, and every clause carries information — output format, normalization, escaping, accuracy caveat. Density is high but the sentence fragments and the final preflight sentence read as compressed internal jargon rather than agent-facing guidance.

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

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

With 7 parameters, 57% schema coverage, and no output schema, the description carries the output-format burden and does so thoroughly (delimiter, encoding, line endings, multi-table layout). Missing pieces are error/overwrite behavior and any indication of how many tables or what a failure looks like.

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

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

Schema coverage is only 57%, and the description compensates for the undocumented ones: date_order's 'auto' behavior is explained (ambiguous dates fall back to day/month/year) and spreadsheet_safe is explained via formula-like text escaping. pages, table_index, and include_headers still rely entirely on the schema, leaving partial coverage.

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

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

Opens with a specific verb and resource: infer selectable-text tables from an unencrypted local PDF and write them as CSV. It's immediately distinguishable from siblings like abox_pdf_split or abox_pdf_merge, though no sibling is named explicitly and the closest alternative (abox_receipt_extract / OCR-style extraction) is never referenced.

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

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

Clear applicability conditions: unencrypted, local, selectable-text PDFs only, with 'No OCR' as an explicit exclusion, and 'Review the CSV; structural verification does not prove accuracy' telling the agent not to trust the output blindly. It stops short of naming an alternative tool for scanned/image PDFs.

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