Loading ToolBench
CLI + MCP server for managing shared LLM context stores with document search, folder management, and semantic indexing
OpenContext MCP provides 10 tools with reasonable naming consistency (all start with 'oc_' prefix) and explicit schemas visible in src/mcp/server.js. However, the server has significant quality gaps: descriptions are present but many are sparse or generic (e.g., oc_manifest lacks detail about output format and use cases), most parameter descriptions are minimal, output schemas are not documented, and error handling/recovery guidance is absent. The codebase shows TypeScript/Node.js implementation with @modelcontextprotocol/sdk ^1.24.3, indicating awareness of MCP conventions, but execution falls short of production standards. Tool composition is reasonable (single responsibility per tool), but the server lacks pagination details, result limits, and per-field response documentation that LLMs need for reliable chaining.
在指定目录创建空文档（可附带描述）
Create a new folder in OpenContext. Safe to call if folder already exists.
Get the stable link (oc://doc/<stable_id>) for a document. Use this when citing documents.
Check search index status. Use this to determine if oc_search is available.
列出指定目录下的文档
列出 OpenContext 中的目录列表（scope=all 表示包含子目录）
输出该目录（含子目录）文档的 JSON manifest，供 Agent 按路径读取上下文
Output schemas not documented. LLMs cannot determine what fields to extract from responses (e.g., what does oc_manifest return? Does oc_search return stable_ids, file paths, content snippets, or all three?). This forces agents to guess and retry on unexpected fields.
Sparse parameter descriptions. Several parameters lack context about valid values, constraints, or examples. E.g., 'folder_path' appears in 5 tools but descriptions vary (sometimes 'relative to contexts/', sometimes 'relative contexts/'). Inconsistent parameter documentation forces LLMs to infer semantics.
No result limits or pagination documented. oc_list_folders claims to return 'all' directories when scope='all', but how many is reasonable? No mention of result count caps, pagination cursors, or max result size. Large result sets risk context window exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Resolve a stable_id (UUID) to the current document path and metadata. Use this to follow oc://doc/<stable_id> links.
Search OpenContext documents by query. Returns matching content/docs/folders with file paths and stable_ids for citation.
更新文档描述，便于后续搜索/筛选
Missing error recovery guidance. No tool description includes 'what to do if it fails' or actionable error messages. E.g., if oc_search fails, should the agent retry, call oc_index_status, or fall back to oc_list_docs? Undocumented recovery paths leave agents stuck.
oc_manifest description is cryptic. Phrase 'JSON manifest' tells LLMs nothing about structure. Is it a file tree? A document list? A metadata index? The description should explain what it returns and when to call it (e.g., 'Call before reading docs to see available files and folder structure').
No idempotency or safety documentation. Write tools (oc_create_doc, oc_set_doc_desc, oc_folder_create) should declare whether they are idempotent. E.g., oc_folder_create notes 'Safe to call if folder already exists', but others do not. Agents retrying failed writes need this clarity.
Field naming inconsistencies risk chaining failures. oc_search mentions 'stable_ids' and 'file paths' in description but schema field names are not visible. If a downstream tool expects 'doc_id' but search returns 'stable_id', the agent must map fields manually, increasing error surface.
oc_list_docs and oc_list_folders use 'scope' and 'recursive' parameters with slightly different semantics. 'scope: [root|all]' vs 'recursive: boolean', inconsistent naming confuses agents. Consolidate to a single depth/recursion param across list tools.