Loading ToolBench
Scribe MCP server, tooling, and universal CLI for documentation management and log entry handling
Scribe MCP provides 4 tools with mostly complete schemas and descriptions, but exhibits mixed quality across naming, parameter clarity, and output documentation. All tools have descriptions (40 - 200+ chars), and input schemas are visible with type definitions. However, naming conventions are inconsistent, some parameters lack sufficient constraint documentation, and output schemas are not formally documented. Error handling guidance is minimal. The server shows solid foundational design but falls short of production-grade polish.
**PRIMARY TOOL** - Add structured log entries with metadata. Supports single entry and bulk modes with automatic multiline detection.
Discover available projects with intelligent filtering and pagination. Auto-excludes test/temp projects and provides context-safe responses.
Advanced log searching and filtering with pagination. Supports text search, date ranges, agent filtering, and metadata filtering.
Create/select project and bootstrap docs. Auto-generates all 4 documentation files (ARCHITECTURE_GUIDE.md, PHASE_PLAN.md, CHECKLIST.md, PROGRESS_LOG.md).
Naming ambiguity in 'set_project', verb 'set' does not clearly convey 'create/bootstrap/select'. LLMs may confuse this with a configuration update tool. Should be 'create_project' or 'initialize_project'.
Output schemas not documented for any tool. Callers do not know what fields to expect (e.g., query_entries returns 'entries' with what structure?). LLMs cannot plan downstream calls or extract required chaining IDs (project_id, entry_id, etc.).
'items' and 'items_list' parameters in append_entry are redundant and confusing. The description mentions 'backwards compatibility' but does not explain when to use which or what happens if both are provided. Violates single-responsibility principle.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | 1.26.0+ | v1 |
Parameter 'auto_split' in append_entry is not visible in the schema input shown but is referenced in the description ('auto_splits multiline if auto_split=True'). Schema mismatch creates ambiguity about whether this parameter exists.
Enum constraints for 'status' parameter in append_entry (info|success|warn|error|bug|plan) are documented only in the description, not in the JSON Schema. LLMs may not parse these from text reliably.
query_entries parameter 'message_mode' defaults to 'substring' but does not document valid enum values in schema (substring, regex, exact). LLMs may hallucinate other modes.
list_projects 'limit' parameter defaults to 5 'for context safety' but maximum/minimum bounds are not declared. LLMs may pass unbounded values causing API load.
No error handling guidance documented. Tools do not specify what errors may occur, what they mean, or how LLMs should recover (retry, lookup alternative, ask user). Pattern:recovery-guide not followed.
'meta' parameter in append_entry is described as 'Metadata dictionary' but does not specify which keys are valid, required, or constrained. LLMs may pass arbitrary metadata, risking data inconsistency.