Loading ToolBench
Federated Agents Versioned Audit Trail. VCS-backed memory for AI agents via MCP. Provides 17 MCP tools for versioned agent memory via JJ (Jujutsu) VCS.
FAVA Trails presents a well-structured 18-tool MCP server with consistent naming conventions (verb_noun pattern), comprehensive parameter schemas, and documented input types. However, tool descriptions lack depth and actionability for LLM selection, output schemas are not explicitly documented, and error handling guidance is absent from tool definitions. The server demonstrates solid foundational quality but falls short of production excellence due to missing recovery guidance and incomplete schema documentation.
Approve a proposed thought as ground truth in a scope. Requires authorization.
Delete a thought from a scope. Records deletion in audit trail.
Export all thoughts from a scope as JSON or markdown.
Run garbage collection on a scope to optimize storage.
Get the current validation and sync status of a scope.
Get server version, configuration, and MCP protocol information.
Retrieve a single thought by ID from a scope.
Tool descriptions lack actionability for LLM tool selection. Most descriptions (55-70 chars) state WHAT the tool does but not WHEN to use it or how it differs from related tools. For example, 'recall' vs 'get_thought' vs 'search_thoughts' are not disambiguated by their descriptions.
Output schemas are not documented in tool definitions. While input parameters are well-defined (enum constraints present for namespace/validation_status), the response structure for each tool is not specified. LLMs cannot predict what fields to extract from responses or what data chains downstream tools can use.
No error handling or recovery guidance in tool descriptions. Tools like 'approve_thought', 'sync_trails', and 'initialize_scope' perform state-mutating operations but provide no guidance on failure modes, retryability, or recovery steps. An LLM encountering a 'scope already exists' error has no direction.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | 1.0.0+ | v1 |
Retrieve the lineage (parent-child relationships) of a thought.
Initialize a new scope for agent use.
List all scopes (trails) in the data repository. Returns scope names and basic metadata.
List all thoughts in a scope with optional filtering by namespace or status.
Propose a thought as ground truth in a scope. Submits for approval via Trust Gate (LLM policy enforcement).
Retrieve thoughts from a scope by filters: thought_id, parent_id, namespace, validation_status, or fetch all thoughts.
Reject a proposed thought in a scope. Records the rejection with optional reason.
Save a thought to a scope's versioned thought store. Creates or updates a markdown thought record with YAML frontmatter in the trails directory.
Search thoughts in a scope by content or metadata.
Synchronize trails with remote VCS repository (fetch and push). Implements eventual consistency.
Update the body and/or metadata of an existing thought.
Parameter descriptions lack actionable constraints. 'trail_name' is described as 'Scope path (e.g. mw/eng/fava-trails)' but does not specify format rules (alphanumeric with slashes?), length limits, or what happens with invalid paths. This invites LLM-generated invalid inputs.
Similar tool names obscure their differences. 'get_thought' (fetch one by ID) vs 'recall' (fetch by multiple filters) vs 'search_thoughts' (fetch by query) are functionally distinct but their names do not clarify the selection criteria. 'recall' is particularly ambiguous, it could also mean 'retrieve by memory context'.
Destructive operations lack confirmation workflow. 'delete_thought' is marked DESTRUCTIVE but has no dry-run, confirmation, or undo mechanism. The rubric requires 'Irreversible operations should support a dry-run or confirmation step.' An agent can permanently delete thought records without safeguards.
No permission gating or scope declarations on tools. Tools like 'approve_thought' and 'delete_thought' should declare required permissions (e.g., 'requires: write:scope, governance:approve'). The rubric requires 'Each tool should declare what permissions it requires'. No scopes declared in tool definitions.
Pagination not explicitly declared. 'list_thoughts' and 'list_scopes' accept optional filtering but do not declare page/offset/limit parameters or specify result limits. The rubric requires 'Tools returning lists should accept page/offset and limit parameters and return a total count.' Without pagination, large result sets could exhaust context.
Optional parameters lack clear defaults or mutual exclusivity rules. 'recall' has four optional filter parameters (thought_id, parent_id, namespace, validation_status) with no guidance on what happens if none are provided (fetch all?) or if multiple are combined (AND or OR logic?). This ambiguity forces LLMs to guess intent.