Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Scored across 13 tools
Each tool has a distinct purpose: conversions follow a clear source-target format, and PDF operations (merge, split, rotate, watermark, page count, page numbers) are clearly separated. The what_can_you_do meta-tool further helps route ambiguous tasks. There is no meaningful overlap between tools.
Conversion tools consistently use source_to_target naming (md_to_docx, docx_to_md), but PDF tools mix verb_first (merge_pdf, split_pdf) with noun_first (pdf_page_count, pdf_rotate, pdf_add_page_numbers). The names are readable and searchable, but the pattern is not uniform across the set.
13 tools is well within the ideal range for a document-conversion and PDF processing server. Each tool provides a meaningful, distinct operation. The set does not feel padded or overly narrow.
The server covers the common conversion flows (DOCX to MD, MD to various formats) and core PDF operations like merge, split, rotate, watermark, and page numbering. Minor gaps are the lack of direct PDF-to-editable-format conversion and non-document input handling, but the described workflows are well covered through chaining.
Word .docx (by URL) → clean Markdown. Feed documents to your agent pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the input is a URL and output is Markdown, but doesn't disclose any behavioral traits like whether the file is downloaded, if there are size limits, if it handles .docx only or other formats, or what happens on failure. For a conversion tool with no annotations, this is a significant gap.
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 very short (one sentence) and front-loaded with the key info. It's efficient, but could add a bit more detail without becoming verbose. No wasted words.
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 the tool has 1 param, no annotations, no output schema, and the description is minimal, it's incomplete. It doesn't explain the conversion process, any limitations, or what the Markdown output looks like. For a tool that takes a URL and converts, more context is needed for an agent to use it correctly.
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 schema has 1 parameter (url) with 0% description coverage, and the schema itself provides no type or description. The tool description mentions 'by URL' which adds some meaning, but it doesn't explain the URL format, whether it must be publicly accessible, or any constraints. The description partially compensates but not enough.
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 converts Word .docx files (by URL) to clean Markdown, which is a specific verb+resource+output format. It distinguishes from siblings like md_to_docx (reverse direction) and other md_to_* converters, though it doesn't explicitly name them.
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: feed documents to an agent pipeline, and the input is a URL. However, it doesn't explicitly state when to use this vs alternatives (e.g., when you have a local file vs URL, or when you need other formats). The context is clear but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown → Word (.docx). The deliverable your non-technical colleagues actually open.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the conversion goal and a use case, but does not mention how inputs are handled, output structure, limitations, or side effects. The description adds minimal behavioral context beyond the literal conversion.
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 very short with two sentences. The first sentence front-loads the core purpose, and the second adds a light context. No wasted words, though the second sentence is somewhat fluff, it is acceptable. It could have used space to explain parameters instead.
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 tool with two undocumented parameters and no output schema, the description is incomplete. It lacks input semantics, output details, and any constraints. While the conversion concept is simple, the agent has insufficient information to invoke correctly without guessing parameter roles.
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 the description does not mention either parameter (url or markdown). The parameters are completely undocumented in both schema and description, leaving the agent without any semantic understanding of what inputs are expected.
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 purpose: 'Markdown → Word (.docx)' which is a specific verb-resource mapping (conversion to a specific format). It also distinguishes from sibling tools by naming the .docx output, making it unique among md_to_* converters.
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 gives a hint about when to use it: 'The deliverable your non-technical colleagues actually open.' This implies use when a Word document is needed for non-technical audiences, but it does not explicitly compare to alternatives like md_to_pdf or md_to_html, nor provide exclusions. It is merely implied, not clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown → EPUB e-book, with title and author metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| title | No | ||
| author | No | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions only the inclusion of title and author metadata but does not disclose whether the tool is destructive, requires network access (via url), what happens to the input, or any side effects. The mention of 'url' implies fetching external content but no disclosure about rate limits or security.
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, very concise and front-loaded with the core purpose. However, it omits essential parameter details and usage guidelines, so while it's brief, it may be under-specified.
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 the moderate complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the role of 'url' vs 'markdown', nor any return value or error handling. The presence of sibling tools suggests the need for more distinction, but the description only covers the basic conversion.
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%, meaning the description must explain the parameters. It mentions title and author briefly, but 'url' and 'markdown' are left unexplained, and it's unclear which is required or how they interact. This does not sufficiently compensate for the lack of schema 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 description uses a clear verb ('converts') and specifies the input format (Markdown) and output format (EPUB e-book), distinguishing it from sibling tools like md_to_html and md_to_pdf. However, it doesn't explicitly state that it uses a URL or inline markdown, which is partially covered by the schema.
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 when to use it (when converting Markdown to EPUB) but does not explicitly mention alternatives or when not to use it. Given the presence of sibling tools like md_to_docx and md_to_pdf, it doesn't provide explicit guidance on selecting among them, but the purpose clarity helps infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown → standalone styled HTML page (single file, inline CSS).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It adds some useful detail: output is a single file with inline CSS. However, it omits critical behaviors such as input handling (e.g., whether both parameters are expected, precedence if both are provided), potential network fetches for URL, error cases, or side effects. This is insufficient for safe agent use.
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 with no fluff. It communicates the core transformation efficiently. However, given the lack of parameter info, it might be too terse, but conciseness itself is good.
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?
The tool is a conversion with two parameters and no schema details or output schema. The description only covers the output format, leaving input requirements and usage context entirely absent. It is not complete enough for an agent to reliably invoke the 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?
The schema has zero description coverage and the parameters are completely undocumented in the schema (empty type objects). The description does not mention 'url' or 'markdown' at all, leaving agents clueless about what inputs are required, optional, or how they interact.
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 function: converting Markdown to a standalone styled HTML page. It uses a specific verb (implied by arrow) and resource, and distinguishes from sibling tools that target other formats like docx, epub, and pdf.
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?
No guidance is provided on when to use this tool versus alternatives such as md_to_pdf or md_to_epub. The description only states what it does, not the context or criteria for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown → styled PDF. Send markdown text or a URL to a .md file, get a print-ready PDF back.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It discloses the input delivery modes (text or URL) and output style (styled, print-ready), but does not address authentication, network access for URLs, error handling, or confirm that no mutation of source files occurs.
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 entire description is one compact sentence with the conversion concept front-loaded via 'Markdown → styled PDF'. Every word adds value, and there is no redundancy or filler.
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 tool with only 2 parameters, no output schema, and no annotations, the description sufficiently covers the input modes and output quality. It lacks edge-case or limitation details, but is complete enough for a straightforward 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 coverage is 0%, so the description must compensate. It does so by explicitly mapping 'markdown text' to the markdown parameter and 'URL to a .md file' to the url parameter. It does not explain optionality or behavior when both are supplied, but the core semantics are clear.
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 opens with 'Markdown → styled PDF', a specific verb+resource conversion. It clearly states input types (markdown text or URL to a .md file) and output (print-ready PDF), distinguishing it from sibling tools by the target format (PDF vs HTML, DOCX, EPUB, etc.).
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 makes it clear when to use this tool: whenever a PDF is needed from markdown content. However, it neither mentions alternatives nor explicitly states when not to use it, so it falls short of offering comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown (heading per slide) → PowerPoint .pptx. Fastest structured route to a deck.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the key 'heading per slide' convention, but it does not explain how source content is processed beyond that, how url vs markdown inputs behave, what kind of output is returned, or whether any side effects occur.
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 short, front-loaded, and has little wasted text. It immediately communicates the core transformation and the key slide structuring rule before adding a positioning sentence.
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 tool with no annotations, no output schema, and an input schema with zero descriptions, the description is too sparse to fully guide an agent. It covers the basic conversion purpose but omits how to choose between url and markdown input, what output the agent should expect, and when this tool is preferable to the many sibling conversion tools.
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 the description does not compensate for the two parameters 'url' and 'markdown'. It does not explain whether one or both are needed, which input should take precedence, or what format is expected. The description adds essentially no meaning beyond the raw property names in the 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?
The description clearly identifies the tool as converting Markdown into a PowerPoint .pptx file, with the notable mapping that each heading becomes a slide. It distinguishes itself from sibling conversion tools by naming the target format. However, it lacks an explicit verb like 'converts' and relies on the arrow notation and context.
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?
'Fastest structured route to a deck' gives an implied use case: when the user wants a presentation deck from structured Markdown. It does not explicitly mention alternatives or state when not to use the tool, but the positioning provides minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge several PDFs (by URL) into one. urls = comma-separated links, in order.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only explains the parameter format but does not state what the tool returns, whether it saves to file, or any limitations. This is insufficient for a tool that creates new data.
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 concise sentences, front-loaded with the core purpose. There is no unnecessary fluff, and it efficiently conveys the essential 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 tool with a single parameter and no output schema, the description covers the main purpose and parameter format. However, it omits what the resulting merged PDF is (returned, saved, etc.) and any potential constraints like size limits. This leaves some gaps for a complete understanding.
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 description adds critical meaning to the 'urls' parameter by specifying comma-separated links in order. Schema coverage is 0%, so this is the only explanation. It clearly defines the format and ordering, which is helpful for correct invocation.
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's purpose: merging multiple PDFs by URL into one. This is a specific verb+resource, and it distinguishes itself from siblings like split_pdf or pdf_rotate by focusing on merging.
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: when you need to combine multiple PDFs. However, there is no explicit guidance on when to use this versus alternatives, or any exclusions. For a simple tool, implied usage is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stamp page numbers or footer text onto every page of a PDF. Supports a starting number, roman numerals, skipping a cover page, position and font size — the combination Acrobat cannot do without scripting. Template supports {n} and {total}, e.g. "Page {n} of {total}".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL of the PDF. | |
| text | No | Template, default "{n}". Use {n} and {total}. | |
| style | No | arabic (default) | roman (i, ii, iii) | ROMAN (I, II, III) | |
| position | No | bottom-center (default) | bottom-left | bottom-right | top-center | top-left | top-right | |
| start_at | No | Number to start from (default 1). | |
| font_size | No | Font size, default 10. | |
| skip_first | No | Leave this many leading pages unnumbered, e.g. 1 for a cover. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool safe (read-only, idempotent, non-destructive). The description adds behavioral details like template syntax and options but does not disclose side effects such as output generation or potential limitations. Given the annotations cover safety, the additional context earns a moderate score.
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 concise, just two sentences, with the primary action front-loaded. It avoids fluff and includes a concrete example, making every sentence useful.
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 7 parameters and existing output schema and annotations, the description provides a good summary of capabilities and the critical template example. It doesn't explicitly mention return format, but the output schema covers that. Some edge-case guidance is missing, but overall sufficient.
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 schema provides 100% parameter descriptions, setting a baseline of 3. The description adds value by explaining the template format with {n} and {total} and giving an example, which clarifies how parameters combine. It also summarizes parameters in natural language, enhancing 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 tool's function: 'Stamp page numbers or footer text onto every page of a PDF.' It distinguishes itself from siblings by listing specific features like starting number, roman numerals, and template support, making it unique among PDF 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 implies usage for adding page numbers or footer text but does not explicitly contrast with sibling tools like pdf_watermark or pdf_rotate. It provides context by mentioning 'the combination Acrobat cannot do without scripting' but lacks explicit when-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count pages and report each page size of a PDF (by URL).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Count' and 'report' imply a non-destructive read operation, but the description does not disclose network-fetching behavior, error handling for invalid URLs or non-PDFs, or the units/format of reported page sizes.
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 with no filler: it states the verb, target, and output intent directly. Every word contributes to understanding the tool.
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 one-parameter, read-only utility, the description covers the essential input (URL) and output (page count and per-page sizes). It is not fully complete because there is no output schema and the exact return structure is implicit, but the low complexity makes the one-liner nearly sufficient.
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 exposes only a bare `url` property with no type, description, or required flag, and schema coverage is 0%. The description's '(by URL)' adds minimal clarification over the property name and does not specify URL schemes, requiredness, or how additional properties should be handled.
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 uses a specific verb ('Count') and resource ('pages ... of a PDF'), and also specifies the output behavior ('report each page size'). This clearly distinguishes it from sibling PDF tools such as pdf_to_markdown or pdf_add_page_numbers.
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?
It is clear that the tool is for page counting and page-size reporting, and that the PDF is accessed by URL. However, no explicit when-to-use guidance or comparison with alternative tools is provided; the usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate all pages of a PDF (by URL) by 90/180/270 degrees.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| degrees | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and degrees but does not mention whether the operation is destructive, how the output is returned, or any error conditions (e.g., invalid URL). This is a significant gap for a transformation tool.
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 with no redundancy. Every word adds value: action, resource, input method, and allowed values. It is appropriately concise for a simple tool.
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 the low complexity and minimal schema, the description covers the core operation but omits important details like the output format, whether the original PDF is modified, and any error handling. While it is adequate for a simple tool, it leaves room for ambiguity, so it is not fully complete.
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 schema has zero description coverage for parameters, so the description must compensate. It does clarify that 'url' refers to the PDF source and 'degrees' is limited to 90/180/270, but it does not specify the URL format, whether the parameter is required, or any other constraints. It adds moderate value 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?
The description clearly states the action (rotate), the resource (all pages of a PDF), the input method (by URL), and the allowed degrees (90/180/270). It is specific and distinguishes from sibling tools like split_pdf or merge_pdf, which serve different purposes.
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 its use case: when a PDF needs its pages rotated. It provides clear context but does not explicitly mention when not to use it or name alternatives. Since sibling tools perform distinct operations, the use case is clear enough without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stamp diagonal text watermark on every page of a PDF (by URL). text = the watermark.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full disclosure burden. It discloses the stamping behavior but does not clarify whether the original PDF is modified, whether a new watermarked PDF is returned, what the output format is, or whether authentication is needed.
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 exceptionally concise: one sentence captures the action, scope, styling, and input source; another single sentence defines the text parameter. There is no redundant information or filler.
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 no annotations and no output schema, the description is incomplete. It tells the agent what the tool does but omits the tool's return value, side effects on the input PDF, and any limitation or access requirements around the URL input.
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 description partially compensates for the schema having 0% coverage: it explicitly says 'text = the watermark' and hints that the PDF is referenced by URL. However, it does not define the required format or whether the url parameter is required, leaving an important gap for a two-parameter tool.
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 uses a specific verb and resource: 'Stamp diagonal text watermark on every page of a PDF (by URL).' It also clarifies that the text argument is the watermark, making the tool's purpose clear and differentiating it from sibling tools like pdf_add_page_numbers or pdf_to_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 implies the usage context: watermark a PDF page-by-page using a URL and text. However, it does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusion conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a page range from a PDF (by URL) into a new PDF. from/to are 1-based page numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| url | No | ||
| from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the core operation (extract a page range into a new PDF) but does not disclose side effects (e.g., whether the original PDF is modified), error handling (e.g., out-of-range pages), authorization requirements, or the return format. The absence of these details leaves significant gaps for an AI agent, especially since this creates a new file, implying write operations without clarity on safety.
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 extremely concise: one sentence plus a short note. It front-loads the primary function and includes only essential detail (1-based page numbers). There is zero redundant or extraneous text, making it efficient for an AI agent to parse quickly.
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 tool that creates a new PDF from a URL with page range parameters, the description is incomplete. It does not explain error cases (e.g., invalid URL, out-of-bound pages), the output format (path, content, or binary), or any required permissions. Since there is no output schema or annotations, the description is the sole source of info, and it falls short for a multi-parameter mutation-like operation.
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 schema has 0% description coverage, so the description must compensate. It adds meaning for 'from' and 'to' (1-based page numbers) and context for 'url' (by URL), but it fails to explain that 'from' and 'to' are inclusive, whether they are required (schema shows 0 required), or what the URL format should be. It does not describe the output beyond 'a new PDF,' leaving ambiguity about the actual return value. These gaps mean the description only partially covers parameter semantics.
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 action: 'Extract a page range from a PDF (by URL) into a new PDF.' This specifies the verb (extract), resource (PDF), and scope (page range), distinguishing it from sibling tools like merge_pdf (combining documents) or pdf_page_count (counting pages). It leaves no ambiguity about what the tool does.
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 provides implicit guidance on when to use this tool (to extract a page range from a PDF), but it lacks explicit exclusions or alternatives. It does not mention that merge_pdf is for combining, or that pdf_rotate is for rotating pages. The instruction that 'from/to are 1-based' is a useful constraint, but there is no explicit statement of prerequisites or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a task in plain language (any language) and get back exactly which tools on this server do it, with ready-to-run example calls — instead of reading the whole catalogue and guessing. Also returns multi-step recipes when a task needs several tools chained (invoices to a ledger, a bank statement reconciled, a messy CSV turned into a deliverable). Deterministic and free: it calls no model, costs nothing, and never runs out of quota. Call this FIRST when you are not sure what this server offers.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you are trying to do, e.g. "reconcile a bank statement against my books" or "把一堆发票整理成能入账的表格" |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral traits not visible in annotations: deterministic, calls no model, costs nothing, and never runs out of quota. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the core purpose in the first sentence and supported by recipes, cost/quota guarantees, and when-to-use guidance. Every sentence earns its place; no filler or repetition.
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 the simple context (single required string parameter, rich annotations, and an output schema), the description is complete. It covers the tool's behavior, return value highlights, performance/cost characteristics, and usage context without leaving important gaps.
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 already describes the 'task' parameter with examples, and schema coverage is 100%. The description adds the nuance 'plain language (any language)' and emphasizes that example calls are generated, providing modest additional meaning beyond the 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?
The description clearly states the tool's purpose with a specific verb+resource: describe a task and get back exactly which tools on the server do it, with ready-to-run example calls. It explicitly distinguishes itself from sibling tools by positioning itself as the meta-guide that prevents 'reading the whole catalogue and guessing.'
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?
Provides explicit when-to-use guidance: 'Call this FIRST when you are not sure what this server offers.' It also clarifies the intended use case (plain-language task discovery) and contrasts with the alternative of scanning the catalogue manually, which is sufficient for a meta-tool.
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.
docx_to_md1 field changedInput schema / properties / urlAdded value: +{}md_to_docx2 fields changedInput schema / properties / markdownAdded value: +{}Input schema / properties / urlAdded value: +{}md_to_epub4 fields changedInput schema / properties / authorAdded value: +{
+ "type": "string"
+}Input schema / properties / markdownAdded value: +{}Input schema / properties / titleAdded value: +{
+ "type": "string"
+}Input schema / properties / urlAdded value: +{}md_to_html2 fields changedInput schema / properties / markdownAdded value: +{}Input schema / properties / urlAdded value: +{}md_to_pdf2 fields changedInput schema / properties / markdownAdded value: +{}Input schema / properties / urlAdded value: +{}md_to_pptx2 fields changedInput schema / properties / markdownAdded value: +{}Input schema / properties / urlAdded value: +{}merge_pdf1 field changedInput schema / properties / urlsAdded value: +{
+ "type": "string"
+}pdf_page_count1 field changedInput schema / properties / urlAdded value: +{}pdf_rotate2 fields changedInput schema / properties / degreesAdded value: +{
+ "type": "number"
+}Input schema / properties / urlAdded value: +{}pdf_watermark2 fields changedInput schema / properties / textAdded value: +{
+ "type": "string"
+}Input schema / properties / urlAdded value: +{}split_pdf3 fields changedInput schema / properties / fromAdded value: +{
+ "type": "number"
+}Input schema / properties / toAdded value: +{
+ "type": "number"
+}Input schema / properties / urlAdded value: +{}docx_to_mdmd_to_docxmd_to_epubmd_to_htmlmd_to_pdfmd_to_pptxmerge_pdfpdf_add_page_numberspdf_page_countpdf_rotatepdf_watermarksplit_pdfwhat_can_you_doConvert PDFs/images to Word, Excel, and Markdown. Split, merge, and watermark PDF files.
Generate PDF/DOCX/XLSX/PPTX from templates+JSON. Convert Office/HTML/MD to PDF. Universal templating
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
Markdown to PDF: headings, bold, code, lists, rules. A4/Letter/Legal. Free 30/hr. MCP + REST.
Add one secure layer between your agents and this server.
