Loading ToolBench
Comprehensive research and knowledge platform with web search, GitHub trawling, arXiv academic research, TV Tropes narrative analysis, document ingestion, RAG vector search, and research-driven skill creation
The server defines 11 tools with mixed quality. Most tools have descriptions and basic schemas, placing it solidly in the 'Fair' range (60-69). Strengths: verb-based naming (write_, read_, search_, build_, list_), presence of parameter descriptions, and reasonable default values. Weaknesses: missing output schemas for all tools, generic descriptions that don't explain WHEN to use each tool or what distinguishes similar tools (e.g., read_note vs read_knowledge_note), inconsistent parameter naming conventions (page/page_size vs results_per_page), and critical tool 'agentic_content_workflow' relies on deprecated Sampling pattern. Tool descriptions are typically 50-150 chars, falling within acceptable range but often lack guidance on tool selection and recovery patterns.
Execute agentic content workflows using FastMCP 2.14.1+ sampling with tools. Uses ctx.sample() so the client's LLM autonomously orchestrates complex knowledge management operations without client round-trips.
Get context needed to continue a discussion by gathering related notes and activity.
Get recently created or modified notes from the knowledge base. Returns a markdown list of recent notes with titles and timestamps.
List notes and subfolders in a knowledge base folder. Returns a directory listing with note titles.
Read the full markdown content of a note by its title or permalink. Returns the complete note text including observations and relations.
Read a markdown note from the knowledge base by identifier (title or permalink).
No output schemas documented for any tool. LLMs cannot predict return types, forcing them to treat responses as unstructured text. This violates the 'Document the output schema' critical check and wastes tokens parsing results.
Tool 'agentic_content_workflow' directly relies on deprecated server-initiated Sampling (ctx.sample()). Sampling was removed in 2026-07-28. The tool description explicitly states 'Uses ctx.sample() so the client's LLM autonomously orchestrates', this pattern is obsolete.
Duplicate/overlapping tools create LLM confusion. Tools 'read_note' and 'read_knowledge_note' perform identical operations but with different parameters (identifier vs title/permalink). Similarly, 'write_note' and 'write_knowledge_note' overlap. LLMs waste reasoning cycles deciding between them.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get recent activity across the knowledge base within a specified timeframe.
Search the knowledge base for notes matching the query. Returns a markdown-formatted list of matching notes with titles and excerpts. Use boolean operators: AND, OR, NOT. Phrase search: "exact phrase".
Search across all content in the knowledge base using various search methods.
Write a new note to the knowledge base. Returns confirmation with the created file path.
Create or update a markdown note. Content can be provided as an argument or read from stdin.
Inconsistent parameter naming conventions across tools. Some use 'page' + 'page_size', others use 'results_per_page'. 'folder' vs 'folder_path'. 'identifier' vs 'url'. This forces LLMs to reason about parameter names rather than focus on semantics.
Descriptions lack WHEN-to-use guidance. 'Search across all content in the knowledge base using various search methods' doesn't explain when to use search_notes vs search_knowledge_base or how search_type differentiates behavior. LLMs cannot distinguish tool selection criteria.
Parameter descriptions lack actionable constraints. 'depth', 'page', 'page_size', 'max_results', 'max_related' have no documented min/max bounds. An LLM could pass depth=999 or page_size=10000, causing timeouts or memory issues.
Time-based parameters ('after_date', 'timeframe') have vague formats. 'e.g. 2d, 1 week' is an example, not a formal specification. LLMs cannot parse natural language time expressions reliably. Specify ISO 8601 or regex pattern.
No error handling guidance. Tools lack descriptions of what errors are possible, which are retryable, and what recovery steps exist. LLMs will not know whether to retry, ask the user, or abandon a failed operation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools like write_note and write_knowledge_note should be marked destructive. Tools like read_note should be marked read-only. Annotations are required by current MCP spec and help clients understand safety implications.