Loading ToolBench
AI agent session viewer and unified session workspace. MCP server for accessing and managing AI agent sessions across multiple platforms (Claude Code, Cursor, VS Code Copilot, Windsurf) with shared learnings.
Windback provides 10 tools with consistent naming (verb_noun pattern) and reasonable descriptions. However, schemas are present but lack depth in parameter constraints, and output schemas are not documented. Error handling guidance is minimal. The server manages session and learning storage for multi-agent workspaces, a coherent domain. Tool names clearly map to actions (list, read, save, delete, search, sample). Descriptions average ~120 chars and explain the purpose, which meets baseline expectations. All tools have required parameters marked. Major gaps: no enums for constrained values (e.g., agent key should be an enum), output schemas entirely undocumented, no pagination parameters despite list tools, missing error recovery guidance, and sparse parameter descriptions (many lack constraint details).
Remove a learning by ID.
Remove a session from the unified workspace.
List stored learnings. Filter by agent, workspace, or tags.
List all sessions saved in the unified workspace. Filter by agent key.
Read the full message history of a stored session. Accepts the session ID or the readable name (e.g. 'dark-ocean').
Get a sample set of stored learnings to inject into your context at session start. Call this at the beginning of each session to load relevant knowledge from past work. Returns workspace-specific learnings first, then global ones.
Store a learning or insight so all agents can benefit from it. Call this whenever you discover something worth remembering: a pattern that works, a pitfall to avoid, a user preference, or any reusable knowledge.
No output schemas documented. Tools like list_sessions, read_session, and sample_learnings return unspecified structures. LLMs cannot plan downstream calls or extract required fields without knowing response shape (e.g., does list_sessions return session objects with id, agent, workspace, messageCount fields?).
Agent and agentKey parameters accept free-form strings instead of enums. Valid values are hardcoded in descriptions ('claude | cursor | copilot | windsurf') but not enforced in schema. LLMs frequently hallucinate invalid agent keys like 'claude-3-opus' or 'gpt-4'. Should declare enum constraint.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Save or update a session in the unified workspace. Upserts by agentKey+workspace.
Full-text search across all stored learnings (content, tags, workspace).
Search sessions by workspace path, agent name, or message content.
List tools (list_sessions, list_learnings) lack pagination parameters (page/limit/cursor). No mention of result count limits. Returning unbounded lists risks context window exhaustion. Should document max results returned and provide pagination controls.
Destructive operations (delete_session, delete_learning) have no confirmation step or dry-run capability. Agents can permanently erase sessions or learnings without explicit user approval. save_session supports optional id parameter for idempotency, but delete operations are irreversible.
Error responses provide no recovery guidance. Tools likely return generic errors (e.g., 'Session not found') without suggesting next steps. Descriptions lack conditional logic ('If session not found, call search_sessions()'). LLMs cannot self-recover from failures.
Parameter descriptions often missing or minimal. E.g., save_session's 'messages' param says 'Array of {role, content} message objects' but doesn't specify allowed role values (user/assistant?), max message count, or content length limits. LLMs cannot validate input without these constraints.
search_sessions and search_learnings accept free-form query strings but provide no hint about search semantics. Are they full-text, regex, or fuzzy? Can queries include filters like 'agent:claude workspace:/path'? Vague query syntax invites misuse.
sample_learnings description says 'returns workspace-specific learnings first, then global ones' but parameter 'limit' defaults are vague ('default 20'). No mention of ranking algorithm, deduplication, or what 'relevant' means. LLMs cannot reason about result ordering.