Loading ToolBench
PDF slaytlarını 4-up yerleşimle dönüştüren MCP sunucusu
The server defines a single tool with a documented purpose but has several critical quality gaps. The tool name 'convert_pdf_4up' is verb-noun formatted (positive), but the description is written in Turkish and lacks proper structure for LLM consumption. The input schema is present with type definitions, but parameter descriptions are minimal and lack guidance on constraints or usage patterns. The output schema is implicit (dictionary with filename, pdf_base64, mime_type fields) and not formally documented. Error handling returns error objects but provides minimal recovery guidance. Overall, the tool is functional but falls short of production-grade definition quality.
Verilen PDF'i her sayfada 4 küçük slayt olacak şekilde yeni bir PDF'e dönüştürür. Girdi olarak base64 kodlu PDF verisi veya yerel dosya yolu alır; çıktı olarak base64 kodlu dönüştürülmüş PDF verir. - input_pdf_base64: Base64 kodlu orijinal PDF baytları - input_pdf_path: Yerel PDF dosya yolu (alternatif) - dpi: Render DPI (varsayılan 72)
Tool description written in Turkish; LLM-facing descriptions must be in English for reliable agent tool selection and reasoning. Current description: 'Verilen PDF'i her sayfada 4 küçük slayt olacak şekilde yeni bir PDF'e dönüştürür...'
Output schema is implicit and undocumented. While the function returns {'filename': '...', 'pdf_base64': '...', 'mime_type': '...'} or {'error': '...'}, there is no formal schema declaration visible in the tool registration. LLMs cannot reliably parse undocumented outputs.
Parameter descriptions lack constraint information. 'input_pdf_base64' and 'input_pdf_path' are described as encoding/path but do not explain: (a) mutually exclusive relationship, (b) expected encoding format (must be valid base64), (c) file size limits, (d) which one takes precedence if both provided. This forces LLMs to guess and risks malformed inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Error handling is basic. When both input_pdf_base64 and input_pdf_path are empty, or when PDF conversion fails, the tool returns {'error': '...'} with only a message string. No recovery guidance (e.g., 'Try with smaller DPI' or 'Ensure PDF is not password-protected'). No error classification (retryable vs. fatal).
DPI parameter lacks bounds. The description states 'Render DPI (varsayılan 72)' with default 72, but does not specify valid range (e.g., 72 - 300, or 50 - 600). Unbounded numeric parameters allow LLMs to pass absurd values (DPI=99999) that may consume excessive memory or time.
Mutually exclusive parameters not clearly documented. The description hints 'alternatif' (alternative) for input_pdf_path, but does not explicitly state: 'Provide exactly one of input_pdf_base64 or input_pdf_path. If both are provided, input_pdf_base64 takes precedence.' Current code silently prefers base64, which LLMs may not predict.
No documentation of performance characteristics or limits. Tool does not specify: maximum input PDF size, expected latency, maximum page count, memory usage. Agents cannot reason about whether this tool is appropriate for a 500-page PDF or if they should split work.