Convert XLS spreadsheets to modern document, image and spreadsheet formats.
Scored across 4 tools
get_api_usage, get_conversion_status, and list_converters are clearly distinct, but convert_image_url is misleadingly named: it actually submits a spreadsheet URL to a converter slug, not an image URL, so an agent may misselect or avoid it. The slug-based flow also overlaps conceptually with list_converters, requiring the agent to understand the ordering.
All four tools follow a clean verb_noun snake_case pattern (convert_*, get_*, list_*), which is fully consistent. The only flaw is that the noun in convert_image_url misrepresents what the tool does, undermining the otherwise predictable scheme.
Four tools is well-scoped for a conversion API: catalog discovery, job submission, status polling, and account quota. Each tool clearly earns its place with no redundancy.
No, completeness is 3: the surface covers the core catalog -> submit -> poll -> usage lifecycle, but only accepts public URLs with no local file upload path, and offers no job listing or cancellation for failed/stuck jobs. These gaps will force workarounds for common agent workflows involving local spreadsheets.
Download a publicly accessible XLS or supported spreadsheet URL, submit it to XLS.now using a converter slug, and optionally wait for the result. Private-network URLs and embedded URL credentials are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| height | No | ||
| quality | No | ||
| converter | Yes | ||
| source_url | Yes | ||
| strip_metadata | No | ||
| timeout_seconds | No | ||
| background_color | No | ||
| wait_for_completion | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: the source URL must be publicly accessible, private-network URLs are rejected, embedded URL credentials are rejected, and the tool can optionally wait. Annotations already cover readOnly=false, openWorld=true, and idempotent=false, so this added security and flow context is strong.
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 compact, front-loads the main operation, and the second sentence adds an important constraint without wasting space. It is slightly dense with multiple clauses in one sentence but remains appropriately sized.
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 nine-parameter conversion tool with no schema parameter descriptions, the description covers only the basic required path and security constraints. It omits the meaning of most optional parameters and does not explain the relationship with list_converters or get_conversion_status, though the output schema and annotations reduce the burden somewhat.
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 0% across nine parameters, and the description explains only source_url, converter, and wait_for_completion at a high level. It does not clarify width, height, quality, strip_metadata, timeout_seconds, or background_color, leaving most optional parameters undocumented.
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 states a specific action: download a publicly accessible spreadsheet URL, submit it to XLS.now with a converter slug, and optionally wait. That is enough to distinguish the core operation from sibling status/list/usage tools, though the name/title mismatch between image conversion and spreadsheet conversion introduces avoidable ambiguity.
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 says the wait behavior is optional but does not explain when to set wait_for_completion or how to retrieve results via the sibling get_conversion_status tool. It also does not mention using list_converters to obtain the required converter slug, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the caller's XLS.now API credits, usage, and rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already provide the 'readOnlyHint: true', the description adds crucial behavioral detail by listing the specific metrics returned (credits, usage, rate limit). This provides valuable context about the nature of the data returned.
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 definition is concise, consisting of a single sentence that contains all necessary information without waste or fluff.
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 that there are no parameters and an output schema exists, the description successfully summarizes the intended output content. It is complete for a usage-reporting 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?
With zero parameters, the description is perfectly sized, and the 100% coverage means it receives the baseline score of 4 for parameter utility.
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 is highly specific, stating that the tool returns 'credits, usage, and rate limit' regarding the 'caller's API' usage. This clearly defines the resource and action.
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 usage is implied by the function's title and description—monitoring limits. Since no competing tools are mentioned within the description text, it falls to a general implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a XLS.now conversion job. A completed job includes an absolute, temporary download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that a completed job returns an absolute, temporary download URL, meaning the URL expires — but says nothing about polling behavior, failure states, or how long the URL stays valid.
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 short sentences with no filler, and the core action is front-loaded. It is arguably under-specified rather than overwritten, but nothing is wasted.
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?
An output schema exists, so return values need no explanation here. However, for a status-polling tool with a required identifier and zero schema documentation, the description should at minimum say where job_id is obtained and whether repeated calls are expected.
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 0%, so the lone parameter job_id is documented nowhere except by its type. The description does not explain where a job_id comes from (presumably returned by convert_image_url) or what form it takes, leaving the agent to infer the entire parameter contract.
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?
States a specific verb and resource: check the status of an XLS.now conversion job. It is distinguishable from convert_image_url (which starts a conversion) and from list_converters / get_api_usage, though the description never names those siblings explicitly to reinforce the 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?
Usage is only implied — 'Check a XLS.now conversion job' suggests it follows a conversion submission, but there is no explicit when-to-use statement, no polling cadence guidance, and no mention of what to do while a job is pending versus after it completes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live XLS.now converter catalog and return valid converter slugs such as xls-to-xlsx, xls-to-csv, xls-to-pdf, and xlsx-to-xls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context that the catalog is 'live' and that results are slugs, but says nothing about pagination, ordering, whether search is substring or exact, or what happens when a search matches nothing — real behavioral gaps for a search endpoint.
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?
A single well-formed sentence that front-loads the action and catalog, then lists example output values. No filler; the example slugs earn their place by showing the expected return format, though one more clause on search behavior would have been worth the space.
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?
An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, with two undocumented parameters and no guidance about how to page or search the catalog, the definition leaves the agent guessing on the mechanics of the call.
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 0% and neither of the two parameters (limit, search) is mentioned in the description. It never explains that limit caps results at 100 by default 50, nor how the search string is matched, so the description contributes essentially nothing beyond the bare schema.
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?
A specific verb (search/list) plus a specific resource (XLS.now converter catalog) and the nature of the return value (valid converter slugs) with concrete examples such as xls-to-xlsx and xls-to-csv. It is clearly distinct from siblings like convert_image_url or get_conversion_status, though it never explicitly names them to differentiate.
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?
Usage is only implied: an agent can infer this is a discovery/lookup step to find slug values before performing a conversion, but the description never states when to use it versus alternatives or that a slug from here is a prerequisite for other tools. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
convert_image_urlget_api_usageget_conversion_statuslist_convertersConvert XLSX spreadsheets to and from XLS, CSV, PDF, JPG, HTML and ODS.
Convert between 200+ format pairs: JSON, CSV, XML, YAML, PDF, Excel, DOCX and more.
Convert DOCX documents to and from PDF, TXT, HTML, ODT, JPG and RTF.
Convert files between 44 formats: documents, spreadsheets, images, ebooks, email and subtitles.
Add one secure layer between your agents and this server.