Genera un reporte profesional en PDF. Cuesta 10 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Fecha (opcional) | |
| title | Yes | Título del reporte | |
| author | No | Autor (opcional) | |
| sections | Yes | Secciones: [{title, content}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the cost of 10 credits, which is useful, but it does not disclose output format, side effects, permissions, or how the PDF is returned. This is minimal disclosure.
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 very concise, consisting of two short sentences, with the main action front-loaded. It earns its place by including the cost detail, though it could be more informative without losing conciseness.
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 no annotations, no output schema, and only a minimal description, the tool lacks critical context such as return behavior, error handling, or how sections are structured. It is incomplete for a tool of this 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%, so the baseline is 3. The description adds no extra parameter meaning beyond the schema's own descriptions, so no adjustment is warranted.
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 it generates a professional PDF report, which is specific enough to understand the core function. However, it does not differentiate from sibling tools like html_to_pdf or markdown_to_pdf, so it lacks explicit sibling distinction.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention any exclusions or comparisons to sibling tools, leaving the agent to infer usage context only from the word 'professional'.
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.