Genera una factura profesional en PDF. Cuesta 8 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Items: [{description, quantity, price}] | |
| notes | No | Notas adicionales (opcional) | |
| client | No | Datos del cliente: name, email, address | |
| company | No | Datos de tu empresa: name, address | |
| due_date | No | Fecha de vencimiento (opcional) | |
| invoice_number | No | Número de factura |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions 'Cuesta 8 créditos' (costs 8 credits), which is a behavioral trait, but it does not explain the return value (e.g., file path, URL), whether the PDF is saved, or any side effects. This leaves significant unknowns for the agent.
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 consists of two short sentences, front-loaded with the primary action. It is highly concise with no redundant wording or filler, making it easy to parse quickly.
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 6 parameters including nested objects and no output schema. The description does not explain what the agent receives after generation (e.g., a download link or file reference) or any prerequisites for using the tool. It is too sparse for a tool that charges credits and has significant complexity.
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 description coverage is 100%, as every parameter has an inline description in the schema. The description adds no additional parameter detail, but the baseline of 3 is appropriate when the schema fully documents parameters.
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 generates a professional invoice PDF, using the specific term 'factura' which distinguishes it from sibling tools like html_to_pdf and markdown_to_pdf. The verb 'Genera' and resource 'factura en PDF' precisely define the action and output.
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?
No explicit usage guidance is provided; the description only states what the tool does. The cost mention implies a paid service, but it does not contrast with alternatives or specify when to choose this over other PDF tools. Usage context is implied but not articulated.
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.
Each tool has a distinct purpose: HTML to PDF, Markdown to PDF, invoice generation, and report generation. No two tools overlap in function, so an agent can clearly select the right tool based on input format or document type.
All tool names use lowercase with underscores and end with '_pdf'. While there are two patterns ('X_to_pdf' and 'X_pdf'), they are both clear and follow a predictable structure, so the overall convention is consistent.
With 4 tools, the set is well-scoped for a PDF generation server. Each tool covers a specific need without bloat, staying well within the ideal range for a focused service.
The server covers common PDF generation tasks: two conversion formats and two document types. Minor gaps like generic text-to-PDF or PDF manipulation exist, but the core workflows are well represented for its stated purpose.