Skip to main content
Glama
pdfdotco

PDF.co MCP Server

Official
by pdfdotco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

excel_to_pdf

Convert Excel XLS or XLSX files from a URL into PDF documents for sharing, printing, or archiving.

Instructions

Convert Excel(XLS, XLSX) to PDF.
Ref: https://developer.pdf.co/api/convert-from-excel/pdf.md

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to the source file (XLS, XLSX). Supports publicly accessible links including Google Drive, Dropbox, PDF.co Built-In Files Storage. Use 'upload_file' tool to upload local files.
nameNoFile name for the generated output. (Optional)
api_keyNoPDF.co API key. If not provided, will use X_API_KEY environment variable. (Optional)
profilesNoExtra engine options for this endpoint as a JSON object encoded in a string. The options differ per endpoint; see https://developer.pdf.co/api/profiles. (Optional)
expirationNoLifetime of the output link in minutes; the output file is deleted afterwards. API default is 60; the maximum depends on the plan. (Optional)
httppasswordNoHTTP auth password if required to access source url. (Optional)
httpusernameNoHTTP auth user name if required to access source url. (Optional)
worksheetIndexNoIndex of the worksheet to convert. (Optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.0.11
    • addedInput schema / properties / expiration
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Lifetime of the output link in minutes; the output file is deleted afterwards. API default is 60; the maximum depends on the plan. (Optional)",
+  "title": "Expiration"
+}
    • addedInput schema / properties / profiles
      Added value: +{
+  "default": "",
+  "description": "Extra engine options for this endpoint as a JSON object encoded in a string. The options differ per endpoint; see https://developer.pdf.co/api/profiles. (Optional)",
+  "title": "Profiles",
+  "type": "string"
+}
  2. First observed

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It does not say whether the call is synchronous or a job that must be polled with get_job_check or wait_job_completion, what the response contains (an output link?), whether credits are consumed, or how the 'expiration' lifetime affects the result. Only a bare documentation link is offered.

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

Conciseness4/5

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

One short sentence plus a reference link, front-loaded with the conversion direction and free of filler. It is efficient, though arguably too terse for an 8-parameter service endpoint.

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

Completeness2/5

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

For an 8-parameter conversion endpoint with no annotations and no output schema, the description should at least explain what is returned and whether a job must be polled. The schema covers the inputs well, but the agent gets no information about the output artifact or the asynchronous flow, and it must infer both.

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

Parameters3/5

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

Schema description coverage is 100%, and each of the 8 parameters is documented in the schema itself, including url sources, api_key fallback, profiles, and expiration semantics. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

Purpose4/5

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

Names a specific verb ('Convert') and both the source formats (XLS, XLSX) and target format (PDF), which is enough to tell it apart from excel_to_csv, excel_to_json, and csv_to_pdf without opening the schema. It does not explicitly name a sibling or a boundary condition, so it falls short of a 5.

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

Usage Guidelines2/5

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

The description gives no guidance on when to pick this tool over document_to_pdf, excel_to_html, or the other converters. The only usage hint, namely that local files should go through upload_file, lives in the url parameter's schema text rather than in the description.

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

Deploy Server

Other Tools