Loading ToolBench
MCP servers for PDF processing and advanced note management with merge capabilities and template support
The Sibyl MCP server exhibits moderate definition quality with significant gaps. Tool naming is generally action-oriented (read_, write_, create_, list_, search_, merge_), which is correct per pattern:tool. However, descriptions are present but often terse (many 50-80 chars, below the 194-char baseline). Critically, PARAMETER DESCRIPTIONS ARE MOSTLY ABSENT OR MINIMAL. The schema audit reveals that most tools declare input parameters with basic type info but lack the detailed descriptions required for LLM reasoning (per pattern:tool-description). Output schemas are UNDOCUMENTED, tools return data but callers cannot infer the response structure. Error handling is minimal; no recovery guidance or error categorization is visible. The server has 13 tools: 11 in notes (file/folder operations, templates, merge) and 2 in PDF handling. Tool composition is reasonable (each does one thing), but critical parameter details needed for proper LLM usage are missing across the board.
Append content to an existing note file
Convert PDF to Markdown using simplified 3-step process: PDF->PNG, PDF->Mathpix OCR, PNG+OCR->LLM refinement
Create a new folder in the notes vault
Create a new note from a template with variable substitution
Get list of available note templates with their descriptions and use cases
List all folders in the notes vault or a specified folder
List all note files in the vault or a specified folder
Merge content into an existing note using specified strategy
Parameter descriptions are missing or minimal. Tools like `read_note` declare a 'path' parameter with only 'Path to the note file to read' (generic, minimal context). LLMs need domain guidance: 'Absolute or relative path (from vault root) to a .md or .markdown file. Must exist.'
Output/response schemas are completely undocumented. Tools return data but there is no visible schema definition showing what fields, types, and structure the LLM should expect. For example, list_notes() likely returns an array of note objects, but with which fields (path, name, size, modified, etc.)? This forces LLMs to guess and rely on trial-and-error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Preview how content would be merged into a note without applying the merge
Read the content of a note file
Search for notes containing specific text
Search for PDF files in Google Drive
Write content to a note file, creating the file and directories if they do not exist
Tool descriptions are too terse (most 50-80 chars, well below the 194-char baseline). 'Read the content of a note file' lacks context: When should the LLM call this vs. list_notes? What happens if the file doesn't exist? Does it support partial reads? Descriptions should be 100-200 chars with WHEN/HOW/WHY guidance.
Parameter constraints and formats are missing. For example, 'strategy' in merge_note accepts 'append, prepend, replace, or topic_merge', but this is only in the description, not as a JSON Schema enum. LLMs cannot parse this constraint and will likely hallucinate invalid values. Use enum=['append', 'prepend', 'replace', 'topic_merge'] in schema.
Error handling is invisible. No tool visibly documents what error conditions exist, how to recognize them, or what to do next. E.g., read_note: what if the file doesn't exist? search_notes: what if the query is empty? Pattern:recovery-guide requires LLM-actionable error responses with next steps.
No pagination documented for list_notes and list_folders. If a vault contains thousands of notes, these tools will return unbounded results, risking context window exhaustion. Pattern:paginated-result requires limit/offset/next_cursor and total count.
Destructive tools (write_note, append_note, create_folder, merge_note) lack confirmation or dry-run capability. Pattern:confirmation-request recommends preview/confirm steps for irreversible operations. merge_note has preview_merge (good), but write_note and append_note do not.
Missing idempotency guidance. write_note overwrites files; append_note always adds. If an LLM retries due to ambiguity, these tools may produce duplicate content or silent overwrites. Document idempotency per tool and consider unique-key strategies where applicable.
Parameter naming inconsistencies. search_pdfs uses 'max_files' (snake_case with number); other tools use singular 'path'. Consider consistent naming convention across the server (e.g., max_results, limit, page_size).