Render a DSL template + data to a preview PDF. Free (no credits), always watermarked 'PREVIEW — NOT FOR USE'. Returns JSON metadata plus the PDF bytes as an embedded base64 resource. Mirrors POST /api/v1/preview.
| Name | Required | Description | Default |
|---|---|---|---|
| dsl | Yes | The builder DSL script. | |
| data | No | Optional binding data. Falls back to the script's sampleData when omitted. | |
| title | No | Optional document title (shown in PDF metadata). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the cost model (free/no credits), the always-on watermark, and the return format (JSON metadata plus PDF bytes as base64). It stops short of stating side-effect behavior or error conditions, but 'preview' and the endpoint reference imply a non-destructive render.
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?
Three short sentences, each earning its place: the action, the constraints/cost, and the output format/endpoint. There is no filler, repetition, or unnecessary detail, and the key preview semantics are front-loaded.
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 description covers the essential context: what the tool does, cost, watermarking, and return value shape. Since there is no output schema, the explicit statement of 'JSON metadata plus the PDF bytes as an embedded base64 resource' is important and present. It does not address error cases or prerequisites, but those are minor for a simple preview endpoint.
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 mentions 'DSL template + data' in prose but adds no parameter-specific meaning beyond what the schema already documents; the schema itself covers dsl, the data fallback to sampleData, and title metadata.
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 opens with a specific verb ('Render') and resource ('a DSL template + data to a preview PDF'), making the core action unambiguous. It also distinguishes itself from the sibling render_template by emphasizing 'preview', the watermark, and the explicit endpoint reference 'POST /api/v1/preview'.
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 gives clear usage context: it is free, consumes no credits, always watermarked, and explicitly marked 'PREVIEW — NOT FOR USE', which implies it should not be used for production output. However, it does not explicitly name the alternative render_template or state the condition that should select the production render, so the guidance is contextual rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.