Model Context Protocol server providing file tools and browser automation for PDF editing and document processing
This server exhibits significant definition quality gaps across all dimensions. Tool names lack consistent verb-noun structure (e.g., 'file.sandbox', 'browser.puppeteer' are not action-oriented). Descriptions are present but often generic and under 50 chars, failing to explain WHEN to use tools or what they return. Input schemas exist for most tools but lack depth: many parameters have minimal descriptions, no format constraints, and no guidance on valid ranges or dependencies. Output schemas are entirely undocumented, LLMs cannot predict what these tools return. Error handling is absent from all tool definitions. Security concerns are unaddressed (browser automation tools expose significant capabilities without permission gates or audit trails). The 21 tools span disparate domains (file ops, browser automation, PDF editing) with inconsistent naming conventions and no clear composition patterns.
Automate browser interactions using Playwright
Automate browser interactions using Puppeteer
Apply currently selected tool at canvas coordinates.
Create a new blank PDF document.
Delete the currently selected annotation.
Email the current PDF (with annotations) through desktop email_smoke integration.
Get current editor status summary.
No output schemas documented for any tool. LLMs cannot predict return types, forcing them to guess what fields are available for downstream tool chaining. This violates the response-shaper pattern and breaks composition.
Browser automation tools (browser.puppeteer, browser.playwright) lack permission gates, audit trails, and security scoping. These tools can execute arbitrary JavaScript and interact with any website, no mention of rate limits, timeout handling, or permission checks.
Inconsistent naming conventions. File tools use 'file.verb' (file.read, file.write), browser tools use 'browser.tool' (browser.puppeteer), and editor tools use 'editor.verb' (editor.set_tool). This inconsistency forces LLMs to reason about namespace prefixes rather than focusing on intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Navigate to a page number.
Open file picker to load a PDF document.
Open merge modal to combine multiple PDFs.
Save the current PDF with annotations.
Switch active editing tool.
Increase zoom level.
Decrease zoom level.
Delete a file or directory
List files and directories in a sandbox directory
Create a directory
Move or rename a file or directory
Read the contents of a file
Get sandbox configuration and enabled status for file tools
Write content to a file
Parameter descriptions are minimal or absent. 'actions' in browser tools is described only as 'Array of browser actions to perform', no guidance on valid action types, format, or examples. 'path' in file tools lacks format constraints (absolute vs relative, allowed characters).
No error handling guidance in any tool definition. Destructive tools (file.delete, editor.delete_selected_annotation) lack confirmation patterns or recovery guidance. No mention of retryability, timeout behavior, or what to do on failure.