Loading ToolBench
Recover, manage, search, and back up your OneTab data. CLI and MCP server for tab management with OneTab LevelDB recovery, storage, search, deduplication, and git-backed sync.
Tablitz is a Rust MCP server for tab management with 11 tools spread across multiple crates. Most tools have readable descriptions (averaging ~80-120 chars) and visible input schemas with enums for constrained parameters. However, descriptions lack depth, they state WHAT the tool does but rarely explain WHEN to use it vs. a similar tool, or what prerequisites exist. Parameter descriptions are sparse or missing entirely. Output schemas are not documented, we cannot see what fields each tool returns, forcing LLMs to guess. Error handling is not visible in the tool definitions. Several parameter descriptions are trivial or absent (e.g., 'snapshot' tools have minimal guidance). The server uses rmcp 0.10 with schemars for schema generation, which is positive, but schema completeness is inconsistent. Tool composition is reasonable (each does one thing), but lack of documented output shapes and missing error guidance significantly limit production readiness.
Deduplicate and normalize tab data using various strategies (exact URL, normalized URL, or URL+title matching)
Export tab data from the store in specified format (JSON, Markdown, or TOML)
Import tab data into the tablitz store from various sources (OneTab export, OneTab LevelDB, or tablitz native format)
Initialize tablitz by creating the config directory
List tab groups with optional filtering
Recover OneTab data from a browser LevelDB store
Restore the store from a git-backed snapshot at a specific commit or the latest version
Search the tablitz store using fuzzy or full-text search modes
Output schemas are completely undocumented. Tool definitions show input parameters but never declare what each tool returns (field names, types, nesting). LLMs cannot plan downstream calls or extract relevant data from results.
Descriptions lack actionable context. Most tool descriptions state what the tool does but omit WHEN to use it, prerequisites, or how it relates to other tools. E.g., 'search' doesn't explain whether to use fuzzy vs full-text, or how results differ from 'list'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Create a snapshot of the store to a git-backed repository
List recent snapshots in a git-backed repository with commit metadata
Show store statistics including total groups, tabs, and domain distribution
Parameter descriptions are minimal or absent in many tools. 'filter' appears in list/export but is not explained (regex? substring? label matching?). 'limit' defaults are stated in descriptions instead of using JSON Schema minumum/maximum constraints.
Error handling is invisible. Tool definitions do not document recovery paths, retryability, or what errors are possible. E.g., 'import' could fail if file not found, format invalid, or store corrupted, but there is no guidance on which are user-fixable vs fatal.
Confirmation/dry-run patterns are incomplete. 'dedup' and 'snapshot' offer dry_run flags, but 'import', 'restore', and 'recover' lack them despite being potentially destructive. No tool explicitly asks for confirmation before irreversible operations.
'init' is poorly named and described. It is not a verb-noun pair, should be 'initialize' or 'init_store'. Description is only 37 chars ('Initialize tablitz by creating the config directory') and does not explain what config is created or when to call this first.
Tool composition clarity is weak. 'recover' and 'import' overlap, both ingest tab data. When should an LLM use recover vs import? Descriptions do not clarify that recover targets LevelDB while import accepts multiple formats.