Loading ToolBench
MCP Learning Extension Server - Extends the official Obsidian MCP server with learning and second-brain features
This server implements 11 learning-focused tools with clear verb-noun naming and reasonable schema coverage. However, there are critical gaps: (1) Output schemas are NOT documented, the source shows tool definitions but no documented return types, which violates the 'document the output schema' rule; (2) Parameter descriptions exist but are inconsistent in depth and actionability; (3) No error handling guidance is visible, tools return success/failure but offer no recovery hints or categorization; (4) No pagination or result limits are specified for list operations, risking context window exhaustion; (5) No permission checks or security gates are evident despite tools modifying user learning data. The naming convention is solid (create_challenge, list_challenges, update_challenge_status, record_progress, etc.), but the implementation falls short of production-grade composition and error resilience.
Analyze your vault and progress to identify knowledge gaps and weak areas
Mark a review as completed and schedule next review based on performance
Create a learning challenge for a specific topic with AI-generated content
Get detailed information about a specific challenge
Get all reviews that are due today or overdue
Get learning progress statistics and analytics
List all challenges with optional filtering by status or difficulty
Output schemas completely undocumented across all 11 tools. No tool declares what fields, types, or structures are returned. LLMs cannot plan downstream tool calls or extract required data without documented outputs.
No pagination or result limit enforcement on list_challenges, get_due_reviews, or suggest_next_topic. Without limit/offset/cursor parameters and documented max results, large datasets could exhaust context windows.
No error handling guidance. No tool description mentions what to do if a resource is not found, a parameter is invalid, or an operation fails. Responses will likely be raw errors with no recovery hints for the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Record learning progress for a topic or challenge
Schedule a spaced repetition review for a topic
Get AI-powered suggestions for what to study next based on progress and gaps
Update the status of a challenge
No idempotency or confirmation patterns for destructive operations. record_progress, update_challenge_status, and complete_review modify state but offer no dry-run, confirmation, or idempotency assurance. Agents retrying failed calls risk duplicate entries or state corruption.
No permission checks or audit trails visible in the source. Tools that record progress, schedule reviews, and create challenges modify user learning data without documented access control or logging. No evidence of 'read:learning', 'write:learning' scope declarations.
Incomplete parameter descriptions for discovery tools. suggest_next_topic and analyze_knowledge_gaps both have optional 'area'/'focus_area' parameters with minimal guidance on what values are valid or how they affect filtering. Parameter descriptions should be 'prompt-engineering' complete.
Tool composition lacks natural reference chaining. If create_challenge returns a challenge_id, that ID should be directly usable by get_challenge or update_challenge_status (which it is), but the LACK of documented output fields means the LLM cannot know the ID is present in the response without trial-and-error.