Loading ToolBench
MCP server for software engineering knowledge from 41 books + 21 Anthropic articles
Shudaizi MCP demonstrates solid foundational quality with strong naming conventions, clear verb-driven tool names (get_, list_, add_, update_), and comprehensive descriptions. All 5 tools have complete schemas with typed parameters and sensible defaults. However, output schemas are not documented, the tool descriptions explain what is returned semantically, but there is no formal schema definition for response structures. Error handling lacks recovery guidance (no 'try this next' patterns). Tool composition is good: 3 read tools enable discovery and checklists; 2 write tools enable knowledge base extension. The description for get_task_checklist is exceptionally well-crafted with explicit proactive usage guidance (54 pattern: tool-description, mxe:chat-data-model). Parameter descriptions are consistent and include actionable format hints. However, critical security and output schema documentation gaps prevent a higher score.
Add a new book, article, or blog post to the knowledge base. You provide the research content (following the standard template with Key Ideas, Patterns, Tradeoffs, etc.), and this tool handles file creation, index updates, and routing. The research template is in book_research_prompts.md.
Retrieve knowledge from a specific book or Anthropic article. Returns the requested section for deep-dive context. Use when you need deeper understanding of a principle cited in a checklist (e.g., [01] → book 01).
Get a curated checklist for a software engineering task. Returns actionable items drawn from 41 books and 21 Anthropic articles, each citing its source. IMPORTANT: Call this tool proactively in these situations: - Before writing code that involves async/concurrent I/O, external API calls, or new module/class/service design - Before reviewing any code, architecture, or security-sensitive changes - Before designing APIs, data visualizations, or deployment pipelines - When the user asks about best practices, patterns, or tradeoffs Match the user's intent to a task_type: architecture_review, code_review, security_audit, test_strategy, bug_fix, feature_design, api_design, data_viz_review, product_doc, presentation, devops, ai_ml_design, refactoring, observability, ux_review, agent_design
List all available knowledge in the system: task checklists, books, and articles. Use this to discover what's available before requesting specifics.
Output schemas not documented. Tool descriptions explain semantic behavior, but formal response schemas (field names, types, structure) are absent. LLMs cannot reliably extract nested fields, plan downstream tool calls, or validate results without this.
Error handling lacks recovery guidance. No error responses include 'try this next' or error classification (retryable vs user-fixable vs fatal). If a book_id is invalid, the LLM gets a bare error with no actionable path forward.
add_knowledge_source and update_checklist accept file path operations and arbitrary markdown content but lack input validation rules. No mention of sanitization against malicious paths (../../../etc/passwd) or injection attacks in markdown fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Update a task checklist by adding, removing, or replacing items. Use after adding a new knowledge source to incorporate its insights into relevant checklists.
add_knowledge_source and update_checklist are state-mutating tools but lack dry-run/confirmation steps. An LLM mistake could corrupt the knowledge base by adding malformed entries or removing critical checklist sections without recourse.
list_available_knowledge and get_book_knowledge return unspecified counts of items. No pagination parameters (limit, offset, cursor), no total count field. If 100+ books exist, returning all of them in one response wastes tokens and risks context window exhaustion.
get_task_checklist's 'focus' parameter description says 'comma-separated' but does not validate the format or document what happens if an invalid focus is provided. LLMs may pass 'security,scalability,nonexistent_field' without knowing if the third term will be silently ignored or cause an error.