Kamy

Convert file to PDF

convert_document

Convert a file you already hold — .docx, .xlsx or .csv — into a PDF, preserving its existing content. Pass the bytes base64-encoded together with the original filename, which is what the API uses to detect the input type. This is the inbound direction: it consumes an existing document, whereas render_docx / render_xlsx / render_pptx GENERATE new documents from structured data, and render_pdf builds one from a template. Returns a stored render { id, url, bytes, durationMs, name } whose id can be fed straight into merge_pdfs, split_pdf, edit_pdf, create_signature_request or create_envelope. Counts one render against the monthly quota. Files over 10 MB are refused by this tool because the bytes travel through the tool call. Requires a Kamy API key with the render scope; without a key, returns dashboard setup instructions.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Label for the resulting render row. Defaults to the source filename.
`filename`	Yes	Source filename including its extension — the route detects the input type from it. Must end in .docx, .xlsx or .csv.
`fileBase64`	Yes	Base64-encoded bytes of the source file.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already indicate non-readOnly and non-destructive. The description adds significant behavioral context: quota consumption (1 render), file size limit (10 MB), authentication requirement (render scope key), and return structure (id, url, bytes, durationMs, name). No contradiction with annotations.

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

Conciseness5/5

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

Single focused paragraph, logically ordered: purpose, input method, contrast with siblings, return type, quota/size/auth. Every sentence adds meaningful information. No redundancy or filler.

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

Completeness4/5

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

While no output schema exists, the description adequately covers return structure and error conditions (size limit, auth failure). It mentions quota consumption and API key scope. Minor lack: no mention of error behavior for invalid file content. Still very complete given complexity.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that the filename is used for input type detection and that the 'name' parameter defaults to the source filename. This clarifies usage beyond the schema.

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

Purpose5/5

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

The description clearly states the tool converts .docx, .xlsx, or .csv files to PDF, preserving content. It distinguishes from sibling generation tools like render_docx by emphasizing the 'inbound direction'. The verb 'Convert' and resource 'file to PDF' are specific and unambiguous.

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

Usage Guidelines5/5

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

Explicitly tells when to use (converting existing documents) vs. alternatives (generating from data via render_* tools). Also provides practical constraints: files over 10 MB refused, counts against monthly quota, requires API key with `render` scope. Clear guidance on when not to use and prerequisites.

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

All Kamy tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with detailed descriptions that differentiate similar tools (e.g., render_pdf vs render_async vs render_batch, create_signature_request vs create_envelope). No two tools overlap in a way that would cause confusion.

Naming Consistency5/5

All tool names follow a consistent lower_snake_case verb_noun pattern (e.g., attest_artifact, convert_document, list_renders). No mixing of conventions or ambiguous verb choices.

Tool Count4/5

47 tools is high but reflects the broad scope of the platform (document generation, signing, auditing, scheduling, webhooks, verification). Some informational tools could be merged, but the count is still reasonable for the domain.

Completeness3/5

The tool set covers the core document lifecycle well but has notable gaps: no tool to delete renders, no tool to void/cancel signature requests, and no CRUD for templates (only list and schema). The inability to pause schedules via MCP is also a gap.

Resources

Need Help?