FileToPDF
Server Details
Convert files, HTML, and Markdown to PDF via the FileToPDF API. Bring your own API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: convert_file handles files from URLs with auto-detection, convert_html handles raw HTML strings, convert_markdown handles raw Markdown, and get_account checks API status. There is no overlap.
All tool names follow a consistent verb_noun pattern with underscores (convert_file, convert_html, convert_markdown, get_account), making them predictable and easy to understand.
With 4 tools, the server is well-scoped for file conversion and account management. Each tool earns its place without being excessive or insufficient.
The tool set covers the core domain comprehensively: converting files from URLs (including many formats), raw HTML, raw Markdown, and checking account status. No obvious gaps for the stated functionality.
Available Tools
4 toolsconvert_fileConvert a file (by URL) to PDFAInspect
Convert a file fetched from a public URL into a PDF. Auto-detects the engine from the extension: Office docs (DOCX, XLSX, PPTX, ODT, RTF, TXT, CSV…), images (PNG, JPG, WebP…), HTML, Markdown, or an existing PDF (passthrough). Costs 1 credit on success. Returns the PDF as an embedded resource.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of the file to download and convert. | |
| pdfa | No | PDF/A conformance level, e.g. "PDF/A-2b". (Pro/Scale/trial only.) | |
| pdfua | No | Produce an accessible PDF/UA document. | |
| password | No | Password to open a protected source document. | |
| landscape | No | Render in landscape orientation. (Pro/Scale/trial only.) | |
| save_path | No | Optional absolute path to also write the PDF to on disk. | |
| userPassword | No | Password required to open the resulting PDF. | |
| ownerPassword | No | Owner password controlling permissions on the resulting PDF. | |
| nativePageRanges | No | Page ranges to include, e.g. "1-3". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail of costing 1 credit on success and returning the PDF as an embedded resource. Annotations only provide openWorldHint, so the description carries the burden. It lacks mention of failure behavior or authentication needs.
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 two sentences with a clear front-loaded main purpose and supporting detail. Every sentence is informative with no waste.
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?
Given 9 parameters and 100% schema coverage, the description adequately covers the main behavior and return format. However, it does not address edge cases or error handling, which would be useful for a tool with many optional parameters.
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 coverage is 100%, so parameter descriptions already exist. The description adds value by explaining engine auto-detection from file extension and the passthrough behavior for PDF inputs, which are not in individual parameter descriptions.
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 title and description clearly state the tool converts a file to PDF, specifying the verb 'convert' and the resource 'file to PDF'. It auto-detects the engine from the extension and lists supported formats, distinguishing it from siblings like convert_html and convert_markdown.
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 specifies that the file must be fetched from a public URL and lists supported formats, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_htmlConvert HTML to PDFAInspect
Render a raw HTML string to a PDF using Chromium, with optional CSS and layout options. Costs 1 credit on success. Returns the PDF as an embedded resource.
| Name | Required | Description | Default |
|---|---|---|---|
| css | No | Optional CSS, injected into the document <head>. | |
| html | Yes | The HTML markup to render. | |
| pdfa | No | PDF/A conformance level, e.g. "PDF/A-2b". (Pro/Scale/trial only.) | |
| pdfua | No | Produce an accessible PDF/UA document. | |
| scale | No | Render scale, 0.1–2.0. | |
| landscape | No | Render in landscape orientation. (Pro/Scale/trial only.) | |
| marginTop | No | Top margin in inches. | |
| save_path | No | Optional absolute path to also write the PDF to on disk. | |
| marginLeft | No | Left margin in inches. | |
| paperWidth | No | Paper width in inches, or with a unit e.g. "210mm". | |
| marginRight | No | Right margin in inches. | |
| paperHeight | No | Paper height in inches. | |
| marginBottom | No | Bottom margin in inches. | |
| userPassword | No | Password required to open the resulting PDF. | |
| ownerPassword | No | Owner password controlling permissions on the resulting PDF. | |
| printBackground | No | Print background graphics/colors. | |
| nativePageRanges | No | Page ranges to include, e.g. "1-3,5". | |
| preferCssPageSize | No | Use the page size declared in CSS @page rules. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool costs 1 credit and returns the PDF as an embedded resource, which adds value beyond the openWorldHint annotation. It does not contradict the annotation, and the use of Chromium is transparent.
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 sentence with a fragment, containing zero wasted words. It front-loads the core action and key details (cost, return format), earning its 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?
Given full schema coverage and no output schema, the description adequately explains the output as an embedded PDF. It mentions cost and technology, covering the necessary context for a conversion tool with many options.
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 provides 100% coverage with descriptions for all 18 parameters. The description only summarily mentions 'optional CSS and layout options,' adding no further meaning beyond the schema, so a baseline 3 is appropriate.
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 renders raw HTML to PDF using Chromium, with optional CSS and layout options. This distinguishes it from sibling tools convert_file and convert_markdown, which handle files or markdown. The verb 'render' and resource 'raw HTML string to PDF' are specific.
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 implies usage for raw HTML strings, and the sibling tools suggest alternatives. However, it lacks explicit when-not-to-use or direct comparisons, which would provide clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_markdownConvert Markdown to PDFAInspect
Render a raw Markdown string to a PDF, with optional CSS and layout options. A sensible default stylesheet is applied when no CSS is given. Costs 1 credit on success. Returns the PDF as an embedded resource.
| Name | Required | Description | Default |
|---|---|---|---|
| css | No | Optional CSS to style the rendered Markdown (overrides the default stylesheet). | |
| pdfa | No | PDF/A conformance level, e.g. "PDF/A-2b". (Pro/Scale/trial only.) | |
| pdfua | No | Produce an accessible PDF/UA document. | |
| scale | No | Render scale, 0.1–2.0. | |
| markdown | Yes | The Markdown content to render. | |
| landscape | No | Render in landscape orientation. (Pro/Scale/trial only.) | |
| marginTop | No | Top margin in inches. | |
| save_path | No | Optional absolute path to also write the PDF to on disk. | |
| marginLeft | No | Left margin in inches. | |
| paperWidth | No | Paper width in inches, or with a unit e.g. "210mm". | |
| marginRight | No | Right margin in inches. | |
| paperHeight | No | Paper height in inches. | |
| marginBottom | No | Bottom margin in inches. | |
| userPassword | No | Password required to open the resulting PDF. | |
| ownerPassword | No | Owner password controlling permissions on the resulting PDF. | |
| printBackground | No | Print background graphics/colors. | |
| nativePageRanges | No | Page ranges to include, e.g. "1-3,5". | |
| preferCssPageSize | No | Use the page size declared in CSS @page rules. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint annotation, the description carries the burden for behavioral disclosure. It states credit cost, return format (embedded resource), and default behavior. It does not mention potential side effects or limitations, but the core behavior is adequately described.
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 three sentences, front-loaded with the main purpose, followed by key details (default stylesheet, credit cost, return format). Every sentence adds necessary information without redundancy.
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?
Given 18 parameters with full schema coverage and no output schema, the description explains the return format ('embedded resource') and default behavior. It lacks error handling details or rate limits, but the core functionality is sufficiently covered for a conversion tool.
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 baseline is 3. The description adds value beyond the schema by explaining the default stylesheet and the credit cost. It does not repeat parameter details but provides useful context, enhancing overall parameter understanding.
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 verb ('Render') and resource ('raw Markdown string to a PDF'). It distinguishes from sibling tools like convert_html and convert_file by specifying Markdown input. The purpose is unambiguous and specific.
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 mentions a default stylesheet when no CSS is given and notes a credit cost on success. It does not explicitly contrast with siblings (e.g., when to use convert_html instead), but the context is clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountGet FileToPDF account statusARead-onlyInspect
Check the FileToPDF API key and return the plan, remaining conversion credits, and subscription status. Free — costs no credits. Use this to verify the connection works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds that it is free and costs no credits, providing useful behavioral context.
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?
Two concise sentences with no wasted words, front-loaded with key information.
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?
For a simple 0-parameter tool without output schema, the description sufficiently covers purpose and behavior, though error conditions are omitted.
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?
No parameters exist, so schema coverage is 100%; description adds no parameter info, but none is needed. Baseline of 4 applies.
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 checks an API key and returns plan, credits, and status, distinguishing it from sibling conversion tools.
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 explicitly says to use this to verify the connection works, but does not mention when not to use it or provide alternatives beyond implied sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!