Loading ToolBench
Active context management MCP server with portable skills for LLM agents
Alexandria demonstrates solid tool design with clear, action-oriented naming (search, index_build, lint_structural, scaffold, detect_new, extract_session) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 6 tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, tool.execute() returns results but the structure is not formally specified. Error handling is basic (generic JSON error wrapping). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the spec. Parameter descriptions are good but could be more prescriptive about constraints (e.g., staleDays range, limit bounds). The wikiPath parameter is repeated across tools without clear guidance on precedence or resolution logic.
List source files in the wiki's raw/ directory that have not yet been ingested into any wiki page. Call this when the user says they've added new sources, dropped files, or wants to know what's pending — and as the first step of any ingest workflow. Returns the new files (with path, name, type, size, frontmatter if present) plus the already-processed files for reference. Read each new file before discussing or filing it.
Return Alexandria's session-extraction prompt for filing durable knowledge back into the wiki. Call this when the user asks to preserve, file, or extract what happened in the conversation — especially near the end of a long session on hosts without real session-end hooks. After applying the prompt, update the relevant wiki pages, append to log.md if something durable was filed, and call index_build.
Rebuild the wiki's search index. Call this AFTER any operation that creates, modifies, or deletes wiki pages — including wiki-ingest, wiki-lint fixes, or direct page edits. The search tool depends on this index; stale indexes return stale results. Parses all wiki pages, rebuilds the wikilink graph, recomputes PageRank, and writes a fresh BM25 term index to search-index.json at the wiki root. Cheap to run; prefer running it once at the end of a batch of edits over skipping it.
Run a structural health check on the user's wiki. Call this when the user asks to lint, audit, clean up, or check the wiki — or when you suspect drift after many changes. Reports orphan pages (no inbound wikilinks), broken wikilinks, missing required frontmatter, pages absent from index.md, stale pages (default >30 days), and raw/ files not referenced by any wiki page. Zero token cost — pure file-system logic. After reviewing the report, propose fixes to the user, apply approved ones, then call index_build to refresh the search index.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'ranked pages with snippets'), but formal JSON Schema for response structure is absent. LLMs cannot plan downstream operations without knowing response field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The spec lists risk classifications (READ_ONLY, WRITE) but these are not exposed via MCP tool annotations. Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
Parameter constraints not formalized. staleDays defaults to 30 but no min/max bounds specified. limit defaults to 10 but no upper bound documented. LLMs may pass invalid values (negative days, limit=10000) without validation guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Initialize a brand-new wiki for the user. Call this ONLY when the user explicitly says they want to create, set up, or start a new wiki — never auto-trigger and never use it on an existing wiki. Asks for path, name, and purpose, then creates the folder structure (raw/assets/, wiki/), schema files (CLAUDE.md + AGENTS.md), index.md, log.md, .alexandria.json (at both wiki root and ~/.alexandria.json), and an initial empty search index so day-one queries work.
Search the user's persistent wiki knowledge base. Call this BEFORE answering any question that references past work, named projects, prior decisions, ongoing ideas, or topics the user treats as already-known. The wiki is the source of truth across sessions; conversation memory is not — do not answer from memory when the wiki might know. Returns ranked pages (BM25 + PageRank) with snippets plus the most recent activity log entries. Read the top 2-4 hits in full before responding. Do not announce that you searched — integrate the knowledge naturally into your answer.
Error handling is generic. CallToolRequestSchema handler returns JSON-wrapped errors with no recovery guidance. Errors like 'Tool not found' or 'wikiPath resolution failed' do not suggest next steps (e.g., 'Check .alexandria.json in home or current directory').
wikiPath parameter resolution logic is implicit. Six tools accept optional wikiPath with fallback to .alexandria.json lookup, but the precedence and error cases are not documented. If lookup fails, what happens? Does the tool fail, or does it use a default?