Befüllt erkannte Felder eines gescannten (nicht-AcroForm-)PDFs: Text auf Schreiblinien, X in Checkboxen — per Ratio-Positionen (z. B. aus einer Feld-Erkennung).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Sprachhinweis für die Schrift (optional). | |
| fields | Yes | Erkannte Felder. | |
| values | Yes | Feld-id → Wert (Text; "true" für Checkbox). | |
| filename | No | Dateiname (optional). | |
| pdfBase64 | Yes | Das gescannte PDF (base64). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits fully. It describes the mechanism (ratio positions) and the actions (fill text/checkboxes), but does not state any side effects, prerequisites, permissions, or what the function returns (e.g., a modified PDF or success indicator). This leaves significant ambiguity for an agent deciding on invocation.
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?
The description is a single, well-structured sentence that immediately states the verb and the object. It is concise, front-loaded with the core purpose, and contains no redundant information or fluff.
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?
The tool has moderate complexity with nested objects and 5 parameters. The description gives a high-level workflow hint ('e.g., from a field recognition') and clarifies the non-AcroForm context, but it omits details about return values, error conditions, or whether the PDF is modified in place or returned as base64. This makes it somewhat incomplete for fully autonomous invocation.
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?
The input schema has 100% coverage for parameter descriptions, so the baseline is 3. The description adds minimal extra meaning beyond the schema, such as clarifying the purpose of ratio positions and field types, but these are largely already documented in the schema properties.
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?
The description clearly states the tool 'fills recognized fields of a scanned (non-AcroForm) PDF' with specifics about writing text on lines and placing X in checkboxes. It distinguishes itself from siblings by focusing on scanned PDFs and ratio-based positioning, which is a distinct use case.
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?
The description provides clear context for when to use this tool: for scanned, non-AcroForm PDFs, using ratio positions from field detection. It implies a workflow and sets an exclusion (non-AcroForm), but does not explicitly name alternative tools like fill_pdf for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct action and resource: fax, brief, envelope, template, account, etc. There is no noticeable overlap; even fill_pdf and fill_template are clearly differentiated by type of PDF.
All tool names follow a consistent verb_noun pattern with underscores (e.g., account_balance, fax_confirm, search_templates). No mixing of conventions or irregular styles.
With 33 tools, the server covers multiple subdomains (PDF, fax, postal, signatures, templates). This is on the higher side but still reasonable for a comprehensive document processing server. However, it could benefit from consolidation.
The tool surface covers core document workflows: fill, sign, scan, fax, mail, template exploration, and account management. Minor gaps exist (e.g., PDF merging or splitting), but most user journeys are supported.
