Loading ToolBench
Project context, session memory, and code understanding for AI agents. Briefings, agent sessions, semantic memory, and code indexing — pair with unMute for Discord/GitHub/Linear/X signals.
OpenBriefing provides 11 tools with generally clear naming and purpose statements, but descriptions lack actionable detail and parameter schemas are incomplete. Tool names are verb-forward and appropriate (index_codebase, get_agent_briefing, start_agent_session). Descriptions range 80 - 350 chars and cover the general purpose, but many lack dependency hints, success/failure criteria, or guidance on when to call the tool vs alternatives. Parameter annotations are present but minimal, most are 20 - 50 chars and lack format constraints, valid value ranges, or mutual exclusivity hints. Output schemas are not documented in the visible code. Error handling and recovery guidance are absent. The codebase shows active use of Prisma for persistence and TypeScript, suggesting mature implementation, but the tool definitions themselves feel more like API endpoints documented for humans than LLM-optimized interfaces. No tool declares permissions, scope, or security constraints. Session/briefing workflow is well-designed for agent memory continuity, but individual tool invocations are not optimized for agentic decision-making.
Analyze codebase commit history to determine code ownership by engineers. Calculates what percentage of code belongs to each engineer, then maps to features for recommended assignees. This enables automatic assignment suggestions in Linear issues based on who has worked on related code.
End an agent session and record the final work summary. Call this when you're done with a meaningful work session. Record: decisions_made, files_edited, open_items, related_insights, and a summary. This session data will power the next agent's briefing.
Get a briefing on the current project state: recent decisions, open items, actionable next steps, code index/codebase notes, and recommended context for the current agent. Call this at the START of every session to understand the project context before diving into work.
Get the history of previous agent sessions: what work was completed, what decisions were made, what open items remain, and what insights were documented. Use this to avoid duplicating past work and to understand what the previous agent accomplished.
Proactively index code for all features (similar to documentation workflow). This searches and indexes code for each feature, matches code sections to features, and saves embeddings. This should be run before computing feature embeddings to ensure code context is available. Auto-detects the current git repository root if called from within a git repo. Otherwise uses LOCAL_REPO_PATH from config, or falls back to GITHUB_REPO_URL. Can be called from any repository context - uses semantic search with LLM embeddings to find relevant code.
Output schemas are not documented. Tools return results but nowhere in the visible code are return types specified, LLMs cannot predict what fields to extract or chain to downstream tools.
Parameter descriptions are minimal (20 - 50 chars) and lack constraints. For example, 'search_query' in index_codebase is described as 'Search query to find relevant code (e.g., SSO authentication, session management)' but does not specify: length limits, regex patterns, required format, or what 'relevant' means. 'force' parameter lacks rationale for when to use it.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Manually search and index code from a project's repository for a specific query. Useful for pre-indexing or re-indexing after code changes. Indexed code is tagged with the resolved project id (owner/repo or folder name) so multiple projects coexist. Repo path precedence: repo_path arg → PROJECT_REPOS[project] → LOCAL_REPO_PATH → GITHUB_REPO_URL. IMPORTANT: pass 'project' (detect it from the workspace git remote owner/repo or folder name) and, for a monorepo or non-default project, 'repo_path'.
Investigate a GitHub issue or Linear issue by analyzing its description, comments, related code, and context. Returns detailed context including issue description, related code sections, commit history, and suggested next steps.
Learn from a pull request by analyzing its changes, code review comments, and design decisions. Returns detailed context including PR description, code changes, review feedback, and key learnings.
Link an external event (Slack thread, GitHub PR, Linear issue, Discord thread, etc.) to the project briefing. This adds context from outside systems to the agent's knowledge base. The tool constructs the proper external reference structure based on the source type.
Start an agent session to record the scope of work. Call this at the beginning of a meaningful work session with the areas/features you'll be working on (e.g., ['agent-auth', 'mcp-tools']). The session data powers the next agent's briefing.
Update an agent session periodically to record progress mid-session. Call this as you make progress to document work completed, decisions, and open items discovered.
No error handling or recovery guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do if a call fails. E.g., index_codebase silently fails if 'repo_path' is invalid; investigate_issue offers no guidance if the issue URL is not found.
Mutual parameter exclusivity is undocumented. 'index_codebase' accepts 'project' with fallback to 'repo_path', 'LOCAL_REPO_PATH', and 'GITHUB_REPO_URL', but does not explain precedence or when LLMs should omit one in favor of another. 'link_external_event' has 'channel', 'ts', 'pageId', etc. that apply only to specific 'source' values, but this dependency is not declared.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish which tools are safe to retry (idempotent) vs which modify state (destructive). All 11 tools lack these hints.
Permission/scope declarations missing. No tool states what permissions it requires (e.g., 'read:git', 'write:session-memory', 'read:github'). This prevents least-privilege configuration and audit trails.
No pagination or result-limiting guidance. 'index_code_for_features' accepts 'max_files' (0 - 500) but does not state what the tool returns if max_files is reached, does it return partial results? An error? LLMs cannot plan around this ambiguity.