Loading ToolBench
Local MCP server for VibeBasket that provides catalog search, installation planning, stack management, and target configuration for bundled MCP servers, skills, rules, and workflows across AI IDEs.
VibeBasket defines 15 tools with consistent naming (verb_noun pattern: session.get_state, targets.list, catalog.search, install.plan, rollback.restore). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with typed parameters and enums (e.g., catalog.search has type, trust, freshness enums). However, parameter descriptions are sparse or missing context. For example, 'scope' appears in 6 tools but is described only as 'Optional scope (user or project)', no guidance on when to use which. Output schemas are not documented anywhere in the source; LLMs cannot predict what catalog.search or install.plan return. Error handling is minimal, no recovery guidance, no actionable error messages. Risk annotations (READ_ONLY, WRITE, IRREVERSIBLE) are present but not formalized as tool annotations in the schema. Overall: solid naming and basic structure, but missing output documentation and parameter depth.
Fetch one catalog item by ID.
Refresh the MCP session's cached view of the VibeBasket catalog with cooldown protection.
Search the VibeBasket catalog for MCPs, skills, rules, and workflows.
Apply a VibeBasket installation plan to one or more targets.
Dry-run a VibeBasket installation plan for selected catalog items and targets.
List available IDE configuration backups for rollback.
Restore an IDE configuration from a backup.
Output schemas not documented. LLMs cannot predict what catalog.search, install.plan, or stack.load return. This forces agents to guess field names and types, increasing errors and wasting tokens on exploratory calls.
Parameter descriptions lack actionable context. 'scope' (used in 6 tools) is described as 'Optional scope (user or project)' but does not explain when to use each, what the default is, or how it affects behavior. LLMs cannot reason about scope without guidance.
No error handling or recovery guidance. Tools like install.apply (IRREVERSIBLE) and catalog.refresh (WRITE) have no documented error cases, retry logic, or what to do if they fail. Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Report the current VibeBasket MCP session capabilities and local state.
List locally saved VibeBasket stacks available to this machine.
Load a locally saved VibeBasket stack by ID.
Attempt to save a stack to the authenticated VibeBasket profile. Phase 1 reports availability and guidance only.
Save the current selection as a local reusable VibeBasket stack on this machine.
Return the native MCP config fragment for one target and scope so the client can wire VibeBasket MCP without guessing the config shape.
Explain how to connect the local VibeBasket MCP server or install surface for a specific target and scope.
List the supported VibeBasket install targets and their capabilities.
Risk annotations (READ_ONLY, WRITE, IRREVERSIBLE, REVERSIBLE) are metadata but not formalized as tool annotations in the schema. MCP spec supports readOnlyHint, destructiveHint, idempotentHint, these should be declared in tool definitions so clients can enforce safety policies.
Parameter constraints not fully specified. 'stackId' in stack.load has a regex pattern '^[a-z0-9-]+$' in the description, but this should be a JSON Schema pattern property. 'limit' in catalog.search says '1-50' but no minItems/maxItems in schema. LLMs cannot parse text constraints reliably.