The server has three tools with reasonable naming and generally clear descriptions. However, there are critical gaps in schema completeness, missing parameter descriptions in nested objects, and no documented output schemas. The convert_document tool has the most comprehensive schema, but the nested 'options' object lacks individual property descriptions. Parameter validation rules and error handling guidance are not visible in the code excerpt. Tool names follow verb_noun convention appropriately, but descriptions lack depth about WHEN to use each tool and what the LLM should expect as output.
Tools (3)
can_convertread onlysource verified73/100
Check if conversion from source format to target format is supported
convert_documentwritesource verified73/100
Convert a document from one format to another. Supports conversion between Markdown, HTML, DOCX, PDF, and Text formats.
convert_document description lacks specificity about output behavior, error conditions, and when to use it vs alternatives. Does not state whether the operation is idempotent, whether it modifies input files, or what happens on format compatibility failures.
Nested 'options' object in convert_document schema has property descriptions for template, css, preserve_metadata, and extract_images, but these descriptions are minimal (e.g. 'Template name', 'Custom CSS styles'). LLMs cannot infer what template names are valid or how CSS should be formatted.
No output schema documented for any tool. LLMs cannot plan downstream operations or extract relevant data from responses. convert_document should document returned file paths, file sizes, or success indicators. list_supported_formats should document the structure of format metadata. can_convert should document the boolean result and any reason field.
convert_documentlist_supported_formatscan_convert
Recommendations
Add detailed output schemas for each tool. For convert_document, document: {'output_path': string, 'file_size': integer, 'conversion_time_ms': integer, 'success': boolean}. For list_supported_formats, document the array of format objects with fields like name, description, readableFormats, writableFormats. For can_convert, document: {'supported': boolean, 'reason': string}.
Enhance convert_document description to ~150 characters explaining: 'Converts documents between formats (Markdown, HTML, DOCX, PDF, Text). Writes output file to disk. Use this when you need to change file format. If conversion fails due to unsupported format combination, check can_convert() first.' Add that it is a write operation.
Add individual descriptions to all nested properties in convert_document options. E.g., template: 'Name of a predefined template (e.g. default, minimal, professional); omit for auto-selected template.' css: 'Custom CSS stylesheet as a string; applied only to HTML output. Ignored for other formats.'
Clarify convert_document output_path behavior: 'Output directory. If omitted, uses source file directory. If output_path is a directory, filename defaults to source filename with target_format extension.' Alternatively, split into output_directory and output_filename parameters.
Add explicit error handling guidance in descriptions. For convert_document: 'If source format is not detected, provide source_format explicitly. If conversion is unsupported, call can_convert(source_format, target_format) to confirm before retrying.'
convert_document 'output_path' parameter description states it 'defaults to source filename' but does not specify the directory where the output file is created. This ambiguity can cause LLM confusion about whether files overwrite, go to a temp directory, or use a default output folder.
convert_document 'source_format' parameter description says 'auto-detected from file extension' but does not explain fallback behavior if auto-detection fails or if the file extension does not match the actual format. Error handling guidance is missing.
Error handling code is not visible in the source excerpt. No evidence of actionable error messages that tell the LLM what to do next (e.g., 'Unsupported format X. Supported formats: Y, Z. Try a different source_format.'). Error responses likely fail to guide recovery.
convert_document has a destructive WRITE risk (modifies filesystem by creating output files) but the tool description does not make this explicit or offer a dry-run parameter for safety. Agents cannot test a conversion without committing the output.
convert_document
Add a dry_run boolean parameter to convert_document (default false) to allow agents to validate conversions without writing output. Or document that repeated calls with identical parameters are safe and idempotent.
For list_supported_formats and can_convert, add 1-2 sentences about when to call them. E.g., list_supported_formats: 'Call this first to discover available document formats and their compatibility. Use the result to help users choose target formats.' can_convert: 'Check format compatibility before calling convert_document. Returns true if conversion is possible.'
Add parameter constraints to template and css. E.g., template: 'Template name (string, 1-50 chars, alphanumeric + underscore). Valid templates listed in list_supported_formats() output.' css: 'CSS rules as a valid stylesheet string (max 10KB).'
Ensure error responses from tool implementations include: (1) the invalid value that was provided, (2) the constraint violated, (3) a recovery suggestion. E.g., 'Invalid source_format: "docx", did you mean "docx"? Supported formats: markdown, html, docx, pdf, text. Call list_supported_formats() to see all options.'
Document idempotency. State: 'Safe to retry. Calling convert_document with identical parameters on the same source file produces the same output. Output file is overwritten if it exists.' This helps agents understand retry semantics.