Loading ToolBench
Neutral, cross-vendor system-of-record that keeps developers' coding agents in lockstep. Shared decisions, contracts, ownership and dependencies across repos.
The lockstep MCP server provides 19 well-named tools covering team coordination, decision management, and code ownership queries. Naming is strong (verb_noun patterns like 'notify', 'ask', 'delegate', 'propose_decision'). Descriptions are present and moderately detailed for all tools. However, parameter documentation is inconsistent, some parameters lack descriptions or type details, and schema depth varies significantly. Output schemas are not documented. Error handling guidance is absent from descriptions. The server uses STDIO transport, which is a hard cap at 50 for protocol readiness but does not degrade definition quality scoring.
Acknowledge a decision with a version number and optional verdict
Acknowledge inbox items by marking them as read
Respond to a question asked by a team member
Ask a question to team members, optionally marked as urgent
Perform an advisory decision check on tracked code changes
Mark a task as complete with optional completion note
Query which repos consume a given surface
Output schemas are not documented for any tool. Agents cannot know what fields to expect in responses, forcing them to infer structure or fail on unexpected formats.
Error handling and recovery guidance absent. Descriptions do not explain what happens on failure (e.g., 'if questionId not found', 'if contractDelta validation fails'). Agents have no guidance on retryability or next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List all decisions, optionally filtered by scope
Delegate a task to a team member with optional references
Get product-layer constraints and context for a given scope
Retrieve the agent's inbox containing changes, questions, tasks, and decisions
Notify lockstep of code changes with optional risk tier, verification status, and contract delta information
Propose a new decision (rule, architecture, or principle) with scope, text, and optional rationale
Query the ledger with a question about the codebase, optionally scoped
Refresh the compiled decision pack skill by fetching the latest from the ledger and writing it locally
Register a dependency on a produced surface from another repo
Get session briefing with continuity information and binding decisions
Set the current feature/capability context for the agent session
Query ownership information for a given file path
Generic or underspecified parameter types. 'contractDelta' and 'refs' are typed as 'any', with no documentation of expected structure. LLMs cannot reason about what to pass.
Weak or noun-only tool names reduce clarity. 'whoowns' is unconventional; 'consumers' is a noun without verb context; 'query' and 'decisions' are generic. Names like 'get_file_owner', 'list_surface_consumers', 'search_ledger', 'list_decisions' would be clearer.
Missing pagination and limit documentation. Tools that return lists (e.g., 'decisions', 'consumers', 'inbox') do not document how many results to expect, whether pagination is available, or what the limit is.
Incomplete parameter descriptions. Many parameters lack context on valid values, expected format, or when they should be used. E.g., 'scope' in 'query' and 'decisions' does not explain valid scope values.