Convert XLSX spreadsheets to and from XLS, CSV, PDF, JPG, HTML and ODS.
Scored across 4 tools
Each tool broadly targets a distinct operation: submission, status checking, catalog listing, and usage retrieval. However, convert_image_url is misleading because its name suggests image conversion while its description is about spreadsheet URL conversion, which could cause confusion with the conversion-status tool.
Most tools follow a clear snake_case verb_noun pattern: get_api_usage, get_conversion_status, and list_converters. convert_image_url deviates semantically because the noun 'image_url' does not match the spreadsheet-conversion behavior described.
Four tools is a well-scoped count for a focused spreadsheet-conversion service. Each tool has a clear role in the workflow, and the surface does not feel bloated or arbitrarily thin.
The core URL-based conversion workflow is covered: discover converters, submit a public URL, poll status, and check usage. However, there is no way to upload a local spreadsheet file or specify conversion options, which are notable gaps for a spreadsheet conversion server.
Download a publicly accessible XLSX or supported spreadsheet URL, submit it to XLSX.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?
Annotations already indicate a non-read-only, open-world, non-idempotent operation. The description adds valuable context: it downloads from a URL, submits to an external service, optionally waits, and rejects private-network URLs and embedded credentials. It does not contradict annotations and provides useful behavioral details beyond them.
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, front-loaded sentence that efficiently covers the workflow and key constraints. It is dense but well-organized, with no redundant 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?
Given nine parameters, an output schema, and annotations, the description covers the essential flow and security constraints but fails to explain most optional parameters. It is adequate for an agent to invoke the tool using defaults, but incomplete for leveraging the full parameter set.
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 description must compensate. It only clarifies 'converter' (as a slug), 'source_url' (URL), and 'wait_for_completion' (optional wait). The remaining six parameters (width, height, quality, strip_metadata, timeout_seconds, background_color) are not mentioned at all, leaving significant gaps.
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 verb and resource: download a spreadsheet URL, submit it to XLSX.now with a converter slug, and optionally wait. It clearly conveys the core action and process, though it does not explicitly differentiate from siblings (which are not direct alternatives).
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 implied: use this tool to convert a spreadsheet from a URL, with an option to wait for the result. There is no explicit guidance on when to use this versus polling via get_conversion_status, nor are any exclusions or prerequisites stated beyond the URL security constraints.
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 XLSX.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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that results are scoped to 'the caller' (authenticated identity), which is useful context not in the annotations, but says nothing about rate-limit semantics (whether the rate limit value is a live readout, a ceiling, or reset timing).
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?
One front-loaded sentence with no filler; the resource and the three returned data categories are stated immediately. Nothing is redundant or padded.
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?
With zero parameters, an output schema, and annotations covering safety, the description needs little more. The only missing piece an agent might want is whether the rate-limit figure is a live counter versus a configured policy value, but the output schema can carry that detail.
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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The single sentence correctly implies no inputs are required to get the caller's usage.
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 ('Return') and resource ('the caller's XLSX.now API credits, usage, and rate limit'), which is clearly an account/quota endpoint rather than a conversion operation. It does not explicitly contrast with the conversion siblings, but the resource is distinct enough that confusion is unlikely.
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 pre-flight quota check before calling convert_* tools, but the description never says when to call it, when not to, or that it pairs with the conversion tools. No alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a XLSX.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 safety is covered. The description adds one genuinely useful behavioral fact — that the download URL is absolute and temporary (i.e., expires) — but says nothing about job states, retention, or polling cadence, so it only partially lightens the annotation burden.
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, no padding, with the core purpose front-loaded and the download-URL note following. Nothing here could be cut without losing 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?
An output schema exists, so return values needn't be restated, and annotations cover the safety profile. However, for a polling tool the description should mention how to obtain job_id and what intermediate (non-completed) states look like — those gaps remain for the agent.
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% for the single job_id parameter, and the description does not explain where the job_id comes from, its format, or how it relates to the conversion request. With one undocumented required parameter, the description needed to compensate and does not.
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?
"Check a XLSX.now conversion job" gives a specific verb and resource, and the tool is clearly a status poller rather than a converter or listing tool. It stops short of explicitly contrasting itself with convert_image_url or list_converters, but an agent can still place it correctly among the siblings.
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 wording implies the tool is called on an existing job, but it never states when to call it (after submitting a conversion), whether to poll or wait, or what to do if the job is still running. Usage is inferable from the name and the word "completed," not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live XLSX.now converter catalog and return valid converter slugs such as xlsx-to-xls, xlsx-to-csv, xlsx-to-pdf, and csv-to-xlsx.
| 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 the safety profile is covered. The description adds that the catalog is 'live' and that results are validated slugs usable elsewhere, which is real context, but says nothing about pagination, result ordering, or how 'live' interacts with a closed-world catalog.
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 sentence with the action and resource front-loaded and the example slugs doing useful illustrative work. Nothing is padding.
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-shape explanation is unnecessary, and the tool is a simple read-only lookup. However, with two undocumented parameters and no explicit guidance on when to use it versus the conversion siblings, the definition leaves gaps an agent must guess at.
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 description must carry the parameter meaning; it only weakly implies a search/filter capability through the verb 'Search'. The 'limit' parameter (default 50, max 100) and the exact matching semantics of 'search' are never mentioned.
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 ('Search') and resource ('live XLSX.now converter catalog') and shows the shape of the result (slug examples like xlsx-to-csv), so an agent immediately knows this is a discovery tool, not a conversion tool. No ambiguity against siblings such as convert_image_url or get_conversion_status.
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 only implied: an agent can infer it should call this to obtain valid converter slugs before requesting a conversion, but the description never says so outright. No alternatives, exclusions, or conditions (e.g., when to skip searching and use a known slug) are 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 XLS spreadsheets to modern document, image and spreadsheet formats.
Convert DOCX documents to and from PDF, TXT, HTML, ODT, JPG and RTF.
Convert between 200+ format pairs: JSON, CSV, XML, YAML, PDF, Excel, DOCX and more.
Convert files between 44 formats: documents, spreadsheets, images, ebooks, email and subtitles.
Add one secure layer between your agents and this server.