Loading ToolBench
A MCP server for interacting with your Logseq Personal Knowledge Management system using custom instructions
Server has 3 tools with adequate naming and basic descriptions, but significant gaps in schema documentation, parameter descriptions, and error handling. Tool names follow verb-noun pattern (get_*) appropriately. However, input schemas lack formal type constraints and enumerations. Parameter descriptions are minimal or absent in schema definitions. Output format (markdown) is documented in tool descriptions but return types are not formally specified. Error handling relies on basic exception propagation without recovery guidance. This is a fair-to-poor implementation typical of community PKM integrations.
Retrieve personal notes from Logseq. Use this to find relavant information about a specific topic or about user preferences. It will return all information that is tagged with the topics from the user's personal knowledge base. The information is returned in markdown format, each item in the list is a separate unit of information. Hierachical information is returned as a nested list. The returning markdown contains text in double square brackets, like this: `[[topic]]`. These are links to other topics, you can follow them to get more information. Try variations of the topic to find the most relevant information. Dates are expressed as: 1. today|yesterday|tomorrow|now 2. <number><unit> like 1d, 2w, 3m, 4y, 2h, 30min
Get instructions on how to use the get_personal_notes tool. This will return instructions on how the user organizes their personal notes in Logseq. It will contain common tags (topics), what they mean, and the workflows the user uses to organize their notes.
Retrieve the todo list from Logseq. Use this to get a list of all the todos in the user's personal knowledge base. Dates are expressed as: 1. today|yesterday|tomorrow|now 2. <number><unit> like 1d, 2w, 3m, 4y, 2h, 30min
Parameter descriptions missing in formal schema. The schema shows 'topics', 'from_date', 'to_date' as array/string types, but lacks description fields required by the MCP spec. Descriptions exist in the Python docstring but are not exposed in the schema metadata that LLMs receive.
No input validation or constraint specification. Parameters like 'from_date' and 'to_date' accept free-form strings with documented formats (today|yesterday|tomorrow|<number><unit>) but no enum or pattern constraint in schema. LLMs cannot reliably generate valid date formats without enumeration.
Output schema not formally documented. Tools return markdown strings but return type documentation (structure, fields, format) is absent from schema. Descriptions mention markdown format and field naming (e.g., '[[topic]]' links), but formal return type schemas are missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No error recovery guidance. The code calls req() → request() → api, and errors propagate as raw exceptions. McpError is raised with basic messages ('Invalid API token', 'API request failed', 'Network error') but no actionable recovery steps for the LLM (e.g., 'check credentials', 'retry after 5s', 'verify Logseq is running').
No result pagination or limits documented. get_personal_notes and get_todo_list can return unbounded results. The tool descriptions do not mention limits, pagination cursors, or guidance on when results may be truncated. This risks context window exhaustion when querying large topic sets.
Endpoint complexity not abstracted. get_personal_notes implements a two-phase search (tag-based, then full-text fallback) and falls back to guide() if no topics/dates provided. This fallback behavior is not documented and may surprise agents expecting consistent output structure.
Resource 'logseq://guide' endpoint documentation missing. The resource is defined but never formally documented in the server's capabilities or returned resource schemas. Clients cannot discover what logseq://guide provides without reading code.