This server provides Lockstep's agent-facing API for coordinating decisions, changes, questions, tasks, dependencies, and product context across sessions and teams.
Decision ledger — propose, acknowledge, and list durable decisions; refresh local decision packs.
Change & impact routing — notify the server about surface changes with risk tier, diff hash, and verification status; receive and acknowledge routed inbox items.
Questions & answers — ask scope-scoped questions, mark them urgent, and answer pending questions from the ledger.
Task delegation — delegate tasks to teammates and complete delegated tasks with notes.
Dependency graph — register produced surfaces, query consumers of a surface, and look up ownership of a path.
Product context — fetch product context for a scope and set active feature context by capability reference.
Integrates with GitHub for authentication and repository connection, enabling GitHub sign-in, linking repos to a shared project, and running a PR-time reconciliation gate through a GitHub Action.
Yesterday, you and Claude renamed POST /login to POST /session. Today, a fresh session writes a client against the old route. The decision was made; the next session never received it.
Lockstep gives developers and product managers two ways to start independently:
Developers: keep accepted decisions across Claude Code sessions and check whether changed code may contradict them.
Product managers: turn a product brief into reviewed requirements, track revisions, and copy a useful implementation brief before a developer joins.
Teams: share the same ledger, route interface changes to affected services, and retain existing integrations, permissions, and PR enforcement.
For example, accept “exports expire after 24 hours, except internal previews.” A later Claude session receives that decision without another explanation. A PM can trace the requirement to its source, revise it for review, and share its accepted version with a developer.
Start with one real repo or brief. Invite a colleague when there is useful context to share; company-wide onboarding is not required.
npx lockstep-cli onboardNothing | Slack / docs | CODEOWNERS | Lockstep | |
Agents learn what other agents decided | ❌ | Manual | ❌ | ✅ Automatic |
Decisions ranked by blast radius | ❌ | ❌ | ❌ | ✅ Usage graph |
Changes routed to the services that consume them | ❌ | ❌ | ❌ | ✅ Dependency graph |
"Does anyone use this endpoint?" answered instantly | ❌ | Manual | Partial | ✅ From the graph |
Claude Code session continuity | — | Manual | — | ✅ Briefings + decision packs |
Start with your own next session:
You accept: “Use POST /session; POST /login is retired.”
→ Lockstep keeps the accepted decision.
→ Your next Claude session receives it before you start coding.
→ An opted-in check can flag changed code that may contradict it.A decision is a durable rule or architectural choice that shapes future work. A change is a routine event — captured, but only surfaced when it matters. A PM can establish the same continuity by reviewing requirements from a brief before any code is connected.
The same ledger grows into coordination across developers and repos. For example, a route change in one service can reach the developers whose services consume it:
Dev A's agent Lockstep Dev B's agent
───────────── ──────── ─────────────
logs a decision ───────▶ ┌─────────────────┐
"auth → /session" │ Decision ledger │
│ Usage graph │ blast radius
changes a surface ──────▶ │ Impact ranking │ decides who
POST /session │ Inboxes │ cares & how much
└────────┬─────────┘
│ routes to the services that
▼ consume the changed surface
Dev B's next session begins with:
⚠ [impact 3] auth: /login → /session (binding)
→ B's agent uses /session before writing a lineCapture — A coding-agent hook diffs the working tree and publishes changes with a canonical surface ID (http:POST /session, proto:auth.v1.Auth/Login). When an agent makes a real decision, it logs it with propose_decision.
Rank — Each decision and change gets an impact score = how many services consume the affected surface (its blast radius). This is what keeps signal high and noise quiet.
Route — Changes fan out to exactly the repos that declared a dependency on the changed surface (lockstep.yaml). The agent can also ask consumers("http:GET /orders/:id") — "does anyone use this?" — and get an answer from the graph instead of pinging a human.
Replay — On session start, each agent receives a briefing of what changed and what's binding since it was last here, highest blast radius first — so it's aware before it acts.
Bind — Cross-cutting decisions (high impact) stay open until an affected team acknowledges them; own-area decisions bind on assertion. A PR-time gate fails any contract change with no binding decision.
Related MCP server: Tages
Choose your starting point: developer or product manager. Both use the full dashboard and the same project history.
Pilot release status: CLI 0.3.0 is published on npm and listed in the MCP registry, alongside the matching API and dashboard changes in this repository. Hosted rollout and a real authenticated Claude-session verification are still pending, so the hosted links may run an earlier release. Complete those checks before inviting pilot participants.
Requires Node.js 20+, Claude Code, a GitHub account, and a Git repo with an origin remote.
cd your-project
npx lockstep-cli onboardPreview locally. Inspect candidate documentation and proposed Claude configuration changes before approving setup. Select which documents to upload, or skip import and enter a decision manually.
Connect, scan, and review. Sign in with GitHub and connect the intended project. Onboarding runs scan --apply: it writes or merges lockstep.yaml, preserving existing entries, and seeds the graph with detected produced surfaces and matched dependencies. Then review up to five decision proposals. Remaining drafts stay in Review. Imports do not become accepted decisions automatically.
Choose hosted checks separately. Automatic code checks have their own remembered opt-in. Declining them leaves decision continuity available.
Open Claude Code. Approve the project MCP server when prompted. Onboarding distinguishes configured, connected, decisions ready, and agent verified. Use npx lockstep-cli status to inspect configuration and recorded agent verification. Configuration alone is not activation.
Return, share, and invite. Later sessions receive current decisions and relevant updates. Use the dashboard's Preview decision brief → Copy decision brief, or print Markdown with npx lockstep-cli brief. When the scan finds outbound calls with no declared producer and relevant Git history, onboarding also suggests recent contributors to the calling files and prints an invite command.
For example, an unmatched http:POST /billing/charge call in src/checkout.ts can point you to a colleague who recently edited that file. These are leads to ask about the missing dependency, not verified owners; an unmatched call may also target an external service. Confirm the GitHub handle and invite each person you choose:
npx lockstep-cli invite <github-handle>Suggestions do not send invitations automatically. You can share a useful brief with the colleague first.
npx lockstep-cli onboard --dry-run # preview without configuring or uploading
npx lockstep-cli check --upload # explicitly authorize this one working-diff check
npx lockstep-cli check --base main --upload
npx lockstep-cli checks on # enable automatic hosted checks for this checkout
npx lockstep-cli checks off # disable them independently of the ledgerFor non-interactive runs, authenticate first and use --yes to proceed beyond preview:
npx lockstep-cli onboard --yes --no-docs --disable-checks
npx lockstep-cli onboard --yes --upload-docs --docs CLAUDE.md,docs/adr/auth.md --disable-checks--yes approves setup; it does not authorize document uploads or enable hosted checks. --no-docs skips documentation import, while --upload-docs explicitly authorizes uploading the selected candidate documents (--docs narrows that selection). Neither skips the repository scan and graph setup. Non-interactive imports remain drafts for dashboard review. Use --enable-checks or --disable-checks to set check consent explicitly; otherwise saved consent is retained.
Checks are advisory and report completed, partial, skipped, or unavailable. Missing providers or applicable rules do not produce a pass. Automatic checks have a six-second API deadline and never block Claude. Raw diff hunks are processed transiently; stored results contain status, decision references, locations, and feedback.
Onboarding respects LOCKSTEP_API_URL and saved API settings; hosted is the default only when neither exists. Generated Claude commands use a version-pinned npm invocation, so a global Lockstep installation is unnecessary. Decision packs stay local and Git-ignored.
Start with a brief, without a repo, CLI, or developer. Sign in with GitHub at the dashboard, then:
Create a project. Use Start with one product brief on the dashboard home page. New pilot projects enable the product layer; joining an existing project preserves its settings.
Paste your brief in Sources. Give it a title and, optionally, a feature reference such as feature:private-exports. Save it and inspect the extracted requirements alongside their source evidence. If extraction is unavailable, open the saved brief and use Select requirements manually to choose exact source passages.
Review and ratify. Inspect the source, set its state to active when ready, and edit, reject, or ratify requirements through Review and Decisions. Drafts and questions remain distinct from accepted requirements.
Use the implementation brief. Open the source and choose Preview implementation brief, review the Markdown, then Copy implementation brief. It includes accepted requirements, rationale and source references, drafts, unresolved questions, and recorded concerns. You have a useful handoff before anyone installs Lockstep.
Revise with history. Edit the saved source when the product brief changes. Previous source versions remain available; changed requirements return to review before the accepted brief is regenerated. Pasted briefs are manually maintained, not synchronized with an external document.
Invite a developer when ready. Use Members & Repos to invite their GitHub handle to this exact project. Share the brief and its project/feature connection command. Their Claude sessions can then receive the relevant ratified requirements.
For example, a PM can start with “exports expire after 24 hours; internal previews are exempt; bulk downloads are out of scope.” Review those requirements, leave “Should expiry be configurable?” as an unresolved question, and copy the implementation context before involving engineering.
Once development is connected, use the existing decision, feature, check, and activity views to review recorded context and concerns. Delivered requirements and no recorded concerns do not mean a feature is complete. Useful-concern, false-positive, and intentional-exception feedback does not silently change a decision.
Copying Markdown does not publish it, send a message, or grant access. Dashboard links remain authenticated. A product colleague joining a developer-created project uses the same dashboard and ledger, with no CLI setup.
After the project owner invites your GitHub handle, sign in again to activate the invitation. Developers connect their repo to the supplied project ID:
npx lockstep-cli onboard --project-id <project-id> --feature feature:private-exportsOmit --feature when no feature is selected. This reuses the project's ledger and history. Each developer installs personal Claude hooks; product colleagues work in the dashboard.
Existing B2B integrations, roles, review requirements, and GitHub PR checks remain available. The new semantic code checks are advisory; they do not replace the existing contract gate. The individual pilot starts with Claude Code; other adapters are deferred.
Onboarding already runs scan --apply to establish lockstep.yaml and seed the surface graph. When routes or dependencies change, use npx lockstep-cli scan to preview updates and npx lockstep-cli scan --apply to merge and sync them. The standalone command also retries a scan that was incomplete during onboarding. See lockstep.example.yaml. Independent login, init, connect, scan, and pack commands remain available.
git clone https://github.com/lockstep-team-agent/lockstep.git
cd lockstep
cp .env.example .env
docker compose up --build # Postgres + API (:8080) + dashboard (:3000)Point the CLI at your server:
npx lockstep-cli login --api http://localhost:8080For local development with the dev-login bypass enabled, use:
npx lockstep-cli login --api http://localhost:8080 --dev --dev-id 1 --dev-login aliceThe API needs an extraction provider (ANTHROPIC_API_KEY, or the existing TYPESAFE_API_KEY provider) for automatic imports, and TYPESAFE_API_KEY for advisory checks. Manual requirements remain usable without extraction. Set LOCKSTEP_CHECKS_ENABLED=0 to disable semantic checking server-side without disabling the ledger or existing B2B PR checks.
For production, configure real GitHub authentication, set NODE_ENV=production and LOCKSTEP_DEV_LOGIN=0, apply migrations, and verify provider configuration, request limits, backups, and both onboarding paths. See DEPLOY.md.
Object | What it is |
Decision | A durable rule or architectural choice. The hero. Impact-ranked, versioned (CAS). |
Change | A routine event on a canonical surface. Routed to consumers by blast radius. |
Question | A cross-team ask, ideally answered from the ledger before a human is pinged. |
Task | Delegated work, fanned out to the assignee's inbox. |
The individual pilot supports Claude Code only, with session-start briefings, MCP tools, local decision packs, and optional completion checks. Explicit CLI/MCP operations remain available if hooks are unavailable. No model calls run after every edit.
The ledger remains vendor-neutral and the existing team integrations are retained. Codex and other individual-onboarding adapters are deferred.
Use npx lockstep-cli <command> without installing a global binary, or lockstep <command> if installed globally.
Command | What it does |
| Preview inputs, connect, scan the repo, review decisions, and configure Claude |
| Proceed past setup confirmation and skip documentation import |
| Approve setup and document upload; optionally narrow candidates with comma-separated paths |
| Authenticate with GitHub and optionally save your server |
| Configure Claude independently of onboarding |
| Create or join the intended project |
| Preview/apply a dependency manifest, or sync the existing manifest |
| Refresh the local decision pack or check its freshness |
| Check tracked changes against relevant accepted decisions |
| Enable or revoke automatic hosted diff checks |
| Print a copyable project decision brief |
| Invite a colleague to the connected project |
| Inspect configuration, connection, and verification status |
| Remove Lockstep-managed Claude entries while retaining ledger history |
packages/core/ # Fastify API + PostgreSQL (Drizzle ORM), RLS-isolated, append-only ledger
packages/cli/ # lockstep-cli — onboarding, continuity, advisory checks, MCP server
packages/web/ # Next.js dashboard — briefs, review, decisions, features, team workflows
actions/pr-check # GitHub Action — PR-time reconciliation gateDeploy · Contributing · Security · Changelog
Built on row-level-security Postgres, an append-only CAS-versioned decision ledger, and vendor-neutral MCP adapters. Self-host with docker compose or deploy to Railway.
Apache 2.0 © 2026 Naman Jain
| Name | Required | Description | Default |
|---|---|---|---|
| verdict | No | ||
| version | Yes | ||
| decisionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| itemIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| response | Yes | ||
| questionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| urgent | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| surface | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| refs | No | ||
| task | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | ||
| surface | No | ||
| diffHash | No | ||
| riskTier | No | ||
| verified | No | ||
| capabilityRef | No | ||
| contractDelta | No | ||
| verifiedAgainst | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| reviewAt | No | ||
| ruleText | Yes | ||
| scopeRef | Yes | ||
| rationale | No | ||
| scopeKind | Yes | ||
| baseVersion | Yes | ||
| alternatives | No | ||
| decisionType | No | ||
| capabilityRef | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| producedRepoId | No | ||
| producedSurface | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| capabilityRef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ack_decisionack_inboxansweraskcompleteconsumersdecisionsdelegateget_product_contextinboxnotifypropose_decisionqueryrefresh_decision_packregister_dependencyset_feature_contextwhoownsScored across 17 tools
With no descriptions, tools like 'inbox', 'ack_inbox', 'notify', 'query', and 'ask' have unclear boundaries and could easily be confused. Several names suggest overlapping actions (e.g., 'query' vs 'ask', 'decisions' vs 'propose_decision'), making it hard for an agent to reliably select the right one.
Naming conventions are mixed: single-word verbs (inbox, notify, query, ask) appear alongside verb_noun compounds (ack_inbox, propose_decision, refresh_decision_pack) and bare nouns (decisions, consumers). The pattern is inconsistent and does not follow a uniform grammatical structure, though some names like 'get_product_context' are descriptive.
17 tools is on the heavy side of the typical range (3-15) and feels borderline for a workflow-focused server. Without descriptions, it is plausible some tools could be consolidated, but the count is not extreme. It remains within a workable range.
The names suggest a workflow covering inbox management, decisions, notifications, and context, but obvious lifecycle operations are missing or unclear, such as rejecting a decision, updating a decision, or removing dependencies. There are no dead ends apparent, but the lack of descriptions makes it hard to confirm whether the surface fully covers the intended domain.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Give your AI agent persistent, governed memory for every project. At task start it recalls the approved decisions, conventions, risks and architecture (semantic search, ranked by importance); at close it proposes what was learned as typed memories that you review and approve — governance, not a notes dump. Agents propose, humans govern: edits go back to pending and deletion is human-only by design. Connect Claude Code, Cursor, Claude Desktop or any MCP client in two minutes with just your API key — hosted (nothing to install) or locally via `uvx solucortex-mcp`. Built by SoluAI and dogfooded daily: SoluCortex is developed using its own living memory.
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
