Long-running agent work fails in a predictable way: decisions and assumptions drift out of view as sessions grow, agents report work done that is not done, and after a few months the codebase no longer matches what anyone believes about it, so nobody can say why a given line exists.
Grove fits reasoning-heavy work that outlives a single session: long refactors, multi-session features, security and compliance work where every conclusion needs an audit trail. The protocol picks the next step, so you stop re-explaining the project to every new session.
What this gives you:
Atomic progress: every task is mechanically proven, not just claimed.
Hierarchy over compression: context is strictly structured, never lossily summarized.
Absolute reproducibility: every action is recorded, so any step, decision, or assumption can be replayed and retraced.
Continuity across agents: if an agent stops mid-goal, another agent on another client or model resumes from verified state.
Total ownership: every goal, decision, task, question, and assumption is stored in a persistent historical graph that belongs entirely to you.
Grove enforces its rules as deterministic invariants stored in a single checksummed lockfile: the agent cannot declare work done without falsifiable evidence, start unready tasks, or hallucinate progress. Instead of lossy prompt compression or summarization, project state lives in a typed reasoning graph with machine-checkable edges, and each step receives exactly the execution packet it needs, and nothing more.
Works with Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, GitHub Copilot, and any other agent. Grove includes a CLI, a built-in MCP server, and a drop-in agent skill bundle so you can integrate it into your workspace immediately.
A note on the desktop app shown below. It exists to make the graph, the evidence, and the health of a project visible at a glance, but it is still experimental and has not been tested on macOS yet. The CLI and the MCP server are the stable, tested interfaces. The UI is implemented without any JavaScript framework, mostly plain HTML, CSS, and Tauri, which keeps it fast, and the graph is rendered with WebGL.
Long-running agents suffer from context amnesia. Decisions, assumptions, and dependencies drift out of view as the session grows. A related failure is unreliable self-reporting: the agent declares work complete without sufficient evidence. This happens not out of deception, but because nothing in the environment prevents it.
Standard task trackers inherently trust the executor. When a human checks a box in Jira, the work is assumed done. That is a reasonable default for humans. For autonomous agents it is a silent failure mode. Premature "done" declarations compound across long sessions into structural errors, until the codebase no longer matches what anyone believes it to be, and nobody can say why a given line exists.
This is not theoretical. Grove evolved from a crude Markdown hypothesis into a protocol that today manages Merlin Guild, a closed-source production project of 200k+ lines of Rust and TypeScript, heavy on blockchain and cryptography. It scales because the protocol does not rely on the agent remembering or obeying the workflow correctly.
Related MCP server: Stratum MCP Server
The obvious response to context amnesia is more tooling: summarization, compaction, retrieval. All of these compress context, and compression loses information while hoping the loss does not matter.
Grove does not compress context. It structures it.
As a project evolves, its work is continuously organized into areas, goals, questions, assumptions, decisions, and executable work items. This hierarchy gives the agent a way to identify the context relevant to the current step instead of repeatedly carrying the entire project history into its context window.
The result is not just better continuity; it also reduces token usage. The agent no longer loads unrelated project context simply to recover where it is and why the current task exists.
What happens when you point a frontier model at a raw codebase with Grove attached?
Without a protocol, an agent skims the files, hallucinates a quick summary, and loses the plot after a few steps. With Grove, it maps the territory. In a real-world test on a complex codebase, a single prompt initiated a 5-hour autonomous Discovery session.
The agent burned through its context window limit, but the result was a fully populated reasoning graph: 44 Areas, 47 Goals, and 89 Work items targeting test coverage gaps and logic bugs. It didn't just dump a flat to-do list; it formally declared its open unknowns as Questions and grouped related efforts into Themes.
Here is the exact prompt used to bootstrap the project:
Load the Grove skill and connect to the MCP server. Study the skill fully to understand the protocol constraints.
Your objective is to run a complete Discovery phase across the entire codebase. Do not write implementation code yet, your job is project analysis and graph construction.
Break the project down into Areas. Note that a single package may contain multiple logical areas.
Iterate through each Area and create Goals to address missing test coverage and explicit logic bugs.
For each Goal, create Work items strictly formatted according to the Grove protocol.
Group related work into Themes.
Declare open unknowns as Questions and formalize architectural choices as Decisions where necessary.
Because Grove enforces a Definition of Ready (DoR), the agent couldn't fake progress. Over the next day, the agent systematically executed the delivery phase, turning 75 tasks to Done. The remaining tasks correctly stalled in proposed or ready states, waiting for human answers to the blocking Questions the agent had raised.
The unit of memory is not the conversation. It is the project.
The unit of progress is not the agent's claim. It is verified evidence.
Grove replaces polite prompt instructions with a strict, mechanically enforced protocol. Agents interact with project state through the CLI, MCP, and desktop interfaces. The protocol itself enforces the rules:
A work item cannot be marked done without an evidence record.
Work cannot start until every precondition is machine-verified.
Goal progress cannot be updated by hand; fitness deltas are applied atomically at close time or not at all.
The state either satisfies the protocol, or Grove refuses to advance it. An agent cannot advance protocol state by merely claiming that work is complete.
Grove forces the agent to decompose the product into a strict typed hierarchy. Instead of a raw list of tasks, every piece of planning context lives explicitly in a node taxonomy. Nothing hides in side documents or the agent's internal state:
Node | ID | What it holds |
Area |
| Permanent scope skeleton above goals; never archived. |
Goal |
| Outcome with a measurable fitness function. |
Theme |
| Optional grouping of related work items. |
Work |
| Executable unit with Definition of Ready + Definition of Done. |
Decision |
| ADR: immutable once accepted, superseded only with recorded rationale. |
Question |
| Open unknown, declared instead of pretended away. |
Assumption |
| Falsifiable hypothesis with a validation method and result. |
Discovery |
| Reusable, evidence-backed knowledge distilled from finished work. |
Typed edges connect these nodes into a graph, with blocks remaining acyclic. This structure lets Grove answer both why does this task exist? and what breaks if I change it? without relying on the agent's internal state.
Once this graph exists, the routing promised above becomes mechanical. grove next picks the current step; grove packet emits exactly its context. Nothing irrelevant enters the context window.
Before touching a line of code, the agent queries the causality cone. grove packet W-NN --cone maps the backward cone (everything that must finish first, in topological contraction order), the forward cone (the blast radius if this item changes), and a fragility score per affected goal.
Grove introduces a unified methodology for AI-driven software development, informed by Dual-Track Agile, Hypothesis-Driven Development, ADRs, Continuous Discovery, Cynefin, and the Mikado method. These influences are integrated into a single workflow designed around the constraints of autonomous LLM agents and enforced through machine-checkable invariants.
Most AI workflows are tiny waterfalls: specify everything, then build everything. Grove runs discovery and delivery in parallel, each track feeding the other:
Discovery takes open unknowns and operationalizes them. A question becomes a falsifiable assumption; validated outcomes become curated discoveries.
Delivery executes ready work items and writes verified code on top of those assumptions.
The joints are mechanical. Questions are asked against goals; assumptions target work and gate it; discoveries guide the next goals; finished work distills back into discoveries. When a test falsifies an assumption, the plan reshapes at once; dependent work cannot proceed on a broken foundation.
Grove does not treat distilled knowledge as permanent truth. Discoveries can become stale as the project evolves; reactivating one requires a fresh anchor. Distillation debt is tracked rather than silently accumulating, while goal fitness is re-derived on every close.
The dashboard reflects actual protocol state after every mutation, not intended state. Grove assumes that a project keeps moving: knowledge changes, assumptions are invalidated, and unfinished reasoning accumulates. The protocol makes those changes visible instead of letting them disappear into project history.
Discovery and Delivery run in parallel (Dual-Track Agile, Cagan). A work item cannot enter Delivery until every open question and unvalidated assumption that blocks it is resolved in Discovery.
Every executable unit has explicit acceptance criteria before code is written (HDD, Definition of Ready). The DoR is not a checklist anyone can override; it is a boolean conjunction the CLI evaluates on every status=progress transition.
Long-lived design choices are first-class artifacts (ADR, Nygard). Decisions are immutable once accepted. They cannot be quietly revised; they can only be superseded by a new decision with a recorded rationale.
Open unknowns are first-class artifacts; agents declare them rather than pretend to know (Continuous Discovery; Cynefin). A question tagged chaotic halts the agent and requires human resolution.
Assumptions are falsifiable gates, not comments. An assumption in state invalidated_blocking prevents any dependent work item from becoming ready. The agent cannot proceed by ignoring it.
Refactoring uses a Mikado-style dependency graph distinguishing causation, sequencing, implementation, and inquiry. This makes the blast radius of a change explicit before the first line is touched.
Verified goals archive only after distillation: their validated assumptions, answered questions, and accepted decisions become Discoveries (Y), curated domain axioms that are never archived and that feed future packets.
Areas (A) are a permanent scope skeleton above goals. Every goal belongs to exactly one area, enforced by the CLI at creation (I₁₃); areas are never archived, so the structure outlives any single goal.
Spec-driven development makes specifications explicit. Grove goes one step further: it makes the development process itself executable and verifiable.
A specification describes what the system should do. Grove additionally models the state of the work around it: what is proven, what is assumed, what is blocked, what is ready, what is done, and on what evidence. These are not instructions for the agent to follow; they are protocol state that gates what the agent is allowed to do next.
This changes the workflow from document-driven execution to state-driven execution. There is no single specification to regenerate the project from and no fixed waterfall per feature. Discovery and delivery run continuously, and when an assumption is falsified, the graph and the execution plan change with it. Every state transition is mechanically gated rather than relying on the agent to follow the process correctly.
Specifications remain useful. In Grove, they can live as decisions, acceptance criteria, and other structured project knowledge attached to the work. What changes is what enforces them: the specification describes the intended outcome; the protocol determines whether the project is allowed to advance.
A task cannot even start until a Definition of Ready passes. This is a strict boolean conjunction evaluated by the protocol on every status=progress transition, not a checklist anyone can override. Once ready, Grove emits an execution packet: exactly the context the step needs (the work item, its acceptance criteria, its open questions, its assumption chain, and the decisions that constrain it) and nothing more.
Closing requires falsifiable evidence: test outputs, commit hashes, build logs. A self-reported finished is not accepted. The transition to done is atomic; goal fitness deltas and status re-derivation are applied in the same write, or not at all.
All state lives in .grove/state.lock, a single line-oriented text file with a SHA-256 checksum rewritten on every mutation. Any manual edit, rogue script, or bad merge is detected on the next protocol operation, and all state transitions are blocked until the file is repaired.
The lockfile can live inside the project repository, so the history of project reasoning evolves alongside the code, or outside it in a separate directory or repository. Both topologies are supported. When committed to version control, the lockfile's history becomes the history of the project's reasoning, not just its code.
A typical race occurs when two branches advance project state independently:
Branch A merges into main and advances the project state.
Branch B was created earlier and still contains the previous state checksum.
Merging the branches produces a checksum mismatch.
Grove detects the divergence instead of silently accepting inconsistent state.
Resolution is mechanical:
Resolve textual conflicts, keeping records from both sides.
Run grove repair --confirm to re-canonicalize and re-checksum the state.
Run grove check to surface any invariant violations.
Run grove renumber if ID collisions occurred between branches.
For parallel worktrees, grove init --id-stride/--id-offset allocates disjoint ID ranges so collisions do not happen in the first place.
On a single machine, concurrent mutations are protected by an exclusive flock, while claimed work is protected by session tokens.
Multi-machine writes to a single lockfile are out of scope by design. Remote state transitions must be routed through a single canonical writer, such as a primary CI agent.
Git versions code. Grove versions the reasoning that produced it. Most agent harnesses and SDD (Spec-Driven Development) tools lose the "why" the moment a task is closed. Grove records every action into a persistent, executable journal, giving you something unprecedented: a full undo and replay at the level of project decisions.
Every mutation appends one JSON line to .grove/journal.log holding the command, the UTC timestamp, the session token that wrote it, and the exact inverse of the change.
{"v":1,"ts":"2026-07-19T12:35:19Z","cmd":"set","inv":{"op":"set_status_plain","id":"B-01","old_status":"testing"},"session":"host:0123456789abcdef"}Because every record carries its own inverse, the journal is executable. grove undo replays these inverses in reverse order, restoring the exact prior state down to goal statuses, fitness deltas, and session claims. Git rolls back the implementation; Grove rolls back the hypothesis, the assumption status, and the goal fitness that justified it.
This unlocks true project replay. You can take the state at t=0 and replay the journal to see exactly how the project arrived at its current shape. It acts as a git blame for decisions: instead of just seeing who wrote a line of code, you retrace what assumption was validated, what evidence forced a pivot, and why a specific path was chosen.
The journal also captures the agent's invisible work. When the Definition of Ready (DoR) guard rejects a transition, the journal records the exact conjuncts that failed. Audit records such as gate runs, rejections, and undos are never inverted and never truncated. This captures what the agent attempted, not only what it changed.
This persistent trail powers grove log and grove stats: reconstructing cycle times, DoR first-pass rates, and content health at any point in history. Because it is written in plain JSON lines, it requires no special permissions to read, serving as the raw material for building your own metrics or conducting post-mortem analyses of agent failure patterns.
A work item in progress carries an exclusive session token (only the session that claimed it can mutate it). If a provider goes down mid-goal, or a tough refactor calls for a different model, another agent on another client takes over via grove handoff. Alternatively, it adopts the session via grove resume.
All reasoning and proof live in the lockfile, so grove next and grove packet rebuild the working context instantly. The invariants keep the new agent honest; the rest of the progress cannot be faked.
The real test of agent-driven development is exactly this: when the agent stops mid-goal, the next one picks the project up without reconstructing intent from chat logs.
The result is not only continuity for agents. It is explainability for the people who own the project.
You can answer why a piece of code exists, what it depends on, what assumptions it rests on, and what evidence justified it months after the original work was completed.
Grove is designed to be installed once and then used as the persistent workflow layer for your project.
The installation guide covers the CLI, MCP server, desktop application, and agent skill bundle. Then run grove init in your project root to create the checksummed state file. Connect the MCP server, add the signed skill, and bootstrap your first session with a prompt template. From then on, grove next drives every session.
Not sure if Grove fits your workflow? The Gemini Notebook holds the full documentation. Start with a simple question, like "How does Grove stop an agent from marking work done without evidence?" or "When is Grove the wrong tool for my project?"
Grove is most useful when work is long-running, reasoning-heavy, and performed by autonomous agents.
Security and research workflows: security work stretches over months and runs on hypotheses: most leads die, some become critical paths. Grove fits this shape natively. Every closed item carries evidence, so the audit trail is the project itself - the append-only journal, immutable decisions, and evidence-bound closes answer "who concluded what, when, and on which basis" without a separate reporting process. Priorities stop being a feeling: the critical path, per-goal fitness, and DoR gates decide what runs next, formally.
Architecture and compliance work: assumptions in Grove carry a validation method and a result; decisions carry rationale; discoveries anchor invariants to concrete surfaces. "Do we still meet our SLOs" becomes a question the state answers through goal fitness metrics, and "why is it built this way" stays answerable months later - each architectural choice points to the questions, assumptions, and evidence that produced it.
Long refactors and multi-session features: the Mikado-style dependency graph and the causality cone make blast radius explicit before the first edit, and session continuity lets the work survive agent and provider changes.
Grove is usually the wrong tool for short-lived prototypes, one-prompt tasks, and projects where the code will not outlive the session.
Grove is not a task manager, code-context tool, or multi-agent orchestrator. It is a protocol for maintaining verified project state for autonomous agents.
I₁: ∀ w ∈ W with status = progress, DoR(w) ≡ ⊤.
I₂: ∀ w with type = spike ∧ status = done,
produces(w) ⊆ D ∪ Q ∪ B ∪ Y ∧ produces(w) ≠ ∅.
I₃: ∀ w with status = done, ∃ ev ∈ Evidence, satisfies(ev, AC(w)).
I₄: |{ w ∈ W : status(w) = progress }| ≤ WIP_LIMIT (default 2).
I₅: ∀ (n₁, blocks, n₂) ∈ E, terminal⁺(n₁) before status(n₂) may transition to progress.
I₆: ∀ t ∈ T, status(t) = done ⟺ ∀ w ∈ WI(t), status(w) ∈ { done, rejected, archived }.
I₇: graph (N, E ∩ (· × {blocks} × ·)) is a DAG.
I₈: ∀ q ∈ Q with cynefin(q) = chaotic, status transitions only via human.
I₉: ∀ w ∈ W with type = feature, DoR(w) ⇒
∀ b ∈ BChain(w), status(b) ∈ { validated, invalidated_acceptable }.
I₁₀: status transition w → done is atomic with applying fitness deltas
to each g ∈ goals(w) and re-deriving status(g). Either both succeed or
neither does. The CLI rejects status=done unless deltas are staged
in the same call (or pre-staged via `grove fitness` since the last
status mutation of w).
I₁₁: ∀ w ∈ W with status = progress, the session that set it is the only
session permitted to mutate w until terminal(w) or w leaves `progress`
(e.g. `revert` or another guarded status change). Persisted as header
attrs `session` and `session_at` (UTC); `check` rejects a missing token
(`grove resume` adopts; see protocol §2.6).
I₁₂: ∀ y ∈ Y: (≥1 provenance edge: (w, produces, y) ∨ (y, distills, d/q/b))
∧ (surface(y) ≠ ∅ ∨ why(y) ≠ ∅) ∧ tags(y) ≠ ∅ (≥1 glossary term).
`proposed → active` is refused while any conjunct fails; `stale → active`
only via `grove revalidate` paid with a fresh anchor.
I₁₃: ∀ g ∈ G: ∃ a ∈ A with area(g) = a.id, recorded as the mandatory `area`
field and enforced at creation (`grove add g --area=A-NN`); re-partition
via `grove set G-NN area=A-NN`. An area-less goal in the lock is a
violation, never silently repaired.with terminality:
terminal(w ∈ W) ⟺ status(w) ∈ { done, rejected, archived }
terminal⁺(g ∈ G) ⟺ status(g) = verified (strict for blocks edges)
terminal(g ∈ G) ⟺ status(g) ∈ { verified, declined }
terminal(d ∈ D) ⟺ status(d) ∈ { accepted, rejected, superseded }
terminal(q ∈ Q) ⟺ status(q) ∈ { answered, deferred, dropped }
terminal(b ∈ B) ⟺ status(b) ∈ { validated, invalidated_acceptable, invalidated_blocking }
terminal(t ∈ T) ⟺ status(t) = done
terminal(y ∈ Y) ⟺ status(y) = superseded
terminal(a ∈ A) ⟺ ⊥ (areas have no lifecycle)terminal⁺ is the strict variant used for blocks edges: a declined goal does not unblock dependents. Other relations use the lax terminal.
assumptions(w) ≜ { b ∈ B | (b, targets, w) ∈ E }
BChain(w) ≜ assumptions(w) ∪ { b ∈ B | ∃ q, (q, asks, w) ∈ E ∧ (b, tests, q) ∈ E }
produces(w) ≜ { n ∈ D ∪ Q ∪ B ∪ Y | (w, produces, n) ∈ E }
goals(w) ≜ as recorded in `goals` field of w
WI(t) ≜ { w ∈ W | theme(w) = t }How does the state file work?
All state lives in .grove/state.lock, a single line-oriented text file with a SHA-256 checksum on every write. Any manual edit is detected immediately on the next protocol operation, and all state transitions are blocked until the file is repaired. The agent never reads or writes the file directly; it interacts only through Grove interfaces (CLI, MCP).
This design makes the entire workflow auditable and diff-friendly. Every transition is a single atomic write. The lockfile can be committed to version control; its history is the history of the project's reasoning, not just its code.
How does an agent work with Grove efficiently? Does it need to read the whole skill and write essays into the lock?
No on both counts. The skill's index.md is the minimal safe contract - one screen, complete for operation; every other page is depth you open only when the task touches its topic. And when a command's shape is unclear, the CLI itself is the instructor: refusals like add g: --area is required or DoR ≢ ⊤; see grove dor W-NN say exactly what is missing. Even an agent that never opened the skill cannot corrupt state, because the invariants (DoR gates, evidence gates, the checksum) are enforced by the protocol, not by the document - partial reading degrades process quality, never integrity.
Writing works by compression, not by transcription. The agent deliberates in its own context for as long as it needs, then stores only the conclusions: one acceptance criterion per line, one sentence per hypothesis, a compact context/options block on a decision node. Dozens of small CLI calls are normal and cheap - they batch into a single shell invocation per node (add + fields + fitness). What never belongs in the lock is the reasoning itself: if a fact does not change what a future agent does, it is not recorded. And grove next / grove packet exist precisely so the agent never re-reads the state file to plan.
GNU Affero General Public License v3.0 (AGPL-3.0). Copyright (c) 2026 Alex Shelepenok. Free to use, study, modify, and redistribute under the license terms, including network use: offering Grove as a network service requires offering its source. See LICENSE for the full text.
Create one node of the given kind and return its assigned id (for example W-12); nothing else is printed. Only kind and title are always required; other fields apply per kind (goals and theme for w, surface or why for y, fitness for g, supersedes for d, targets for q and b) and invalid combinations are rejected on write. To modify an existing node use set or field; to connect nodes use link.
| Name | Required | Description | Default |
|---|---|---|---|
| why | No | anchor rationale (y; xor surface) | |
| area | No | owning area A-NN (required for kind g) | |
| from | No | comma-separated provenance ids (y) | |
| kind | Yes | node kind | |
| tags | No | comma-separated glossary terms (y) | |
| type | No | work item type (w) | |
| goals | No | comma-separated goal ids (w) | |
| tests | No | comma-separated question ids (b) | |
| theme | No | theme id T-NN (w) | |
| title | Yes | short node title, stamped verbatim | |
| status | No | initial status override | |
| cynefin | No | cynefin class (w, q, b) | |
| fitness | No | retired legacy fitness label (g; writes are rejected, use fitness_kind + fitness_target) | |
| surface | No | comma-separated paths (w, y, a) | |
| targets | No | comma-separated target ids (q, b) | |
| supersedes | No | comma-separated superseded decision ids (d) | |
| fitness_kind | No | structured fitness kind (g; some fitness value is required for kind g) | |
| fitness_target | No | structured fitness target (g) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so they carry little behavioral signal, and the description takes on the burden. It discloses that the tool writes a new node, returns only the assigned id, prints nothing else, and rejects invalid combinations on write. It omits details like side effects or rollback behavior, but for a create tool this is strong transparency.
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?
Three sentences, each earning its place: output behavior, required fields plus per-kind applicability, and routing to sibling tools. The essential information is front-loaded, and there is no fluff or repetition of schema content.
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?
Given 18 parameters, no output schema, and uninformative annotations, the description supplies the crucial context: what is returned, what is required, which fields are relevant per kind, and when to use alternatives. It loses one point because the 'fitness for g' statement conflicts with the schema's rejected-field behavior, which could lead an agent to construct an invalid call.
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?
Schema coverage is 100%, so the description need not restate every parameter, and it does add a compact per-kind summarization of which fields apply. However, the summary says 'fitness for g', while the schema explicitly says the fitness parameter is a retired legacy label whose writes are rejected for g, recommending fitness_kind + fitness_target instead. This active inconsistency undermines the guidance and prevents a score above baseline.
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?
The description opens with a specific verb and resource: 'Create one node of the given kind and return its assigned id'. It even gives an example id format, W-12, so the tool's core function is unmistakable. It also differentiates the tool from siblings by pointing to set, field, and link for other operations. This is a model of purpose clarity.
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?
The description explicitly says 'To modify an existing node use set or field; to connect nodes use link', giving clear routing to alternatives. It also warns that invalid kind/field combinations are rejected on write, which tells agents to validate their parameter choices before calling. There is no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a verified goal together with its exclusive subgraph (w, d, q, b, t) by setting their archived flag; archived nodes stay in the lock but leave active views, so this is a soft removal, not a deletion, and hard to reverse. Requires distillation first: a linked Discovery or a null-distill attestation from distill; gate reports whether the goal is due.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | goal id G-NN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say destructiveHint=trueaine, but the description goes much further: it reveals that this is a soft removal, how it affects active views, that it is hard to reverse, and what state changes occur. This significantly exceeds the annotation signal and fully discloses the operation's consequences.
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?
The description is two sentences, front-loaded with the core action, and every clause adds necessary context: the subgraph scope, soft-removal semantics, reversal difficulty, and the distillation prerequisite. Nothing is wasted.
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?
For a single-parameter tool with no output schema, the description covers what the tool does, what it affects, when it can be used, and what the consequences are. An agent has enough information to decide to call it and to understand the result.
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?
Schema coverage is 100% and the single id parameter is described as 'goal id G-NN'. The description adds no further parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.
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?
The description names a specific verb ('Archive') and resource ('verified goal together with its exclusive subgraph'), and explains the mechanism (setting archived flags). It also explicitly distinguishes the operation from deletion, which helps separate it from destructive siblings like revert or undo.
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?
The description gives clear preconditions: the goal must be verified distilled first, and gate reports whether the goal is due. It does not name alternative tools or explicitly say when not to use it, but the prerequisites and soft-removal framing provide strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the state.lock checksum and all structural invariants. Returns ok on success, otherwise the first failing invariant; on a checksum mismatch after a deliberate edit see repair.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value by specifying the return behavior: 'ok' on success or the first failing invariant, and by noting the repair path for deliberate checksum mismatches.
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?
Two sentences with no filler. The primary action is front-loaded, followed by return behavior and a targeted repair pointer. Every clause contributes essential information.
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?
For a parameterless, read-only verification tool with rich annotations, the description is complete. It explains what is checked, what is returned, and what to do in the one notable failure scenario, leaving no critical gap for an agent to call it correctly.
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?
The tool has zero parameters, so the schema fully covers parameter semantics. The description correctly focuses on behavior rather than parameters, matching the baseline for a parameterless tool.
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?
The description uses a specific verb ('Verify') and names the exact resource ('state.lock checksum and all structural invariants'). It clearly distinguishes the tool from siblings by defining its scope as invariant verification, not mutation or repair.
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?
The description establishes when to use the tool: to verify checksum and structural invariants. It also provides an explicit alternative by directing users to 'repair' on a checksum mismatch after a deliberate edit, though it does not enumerate other sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transitive predecessors over blocks edges: every node that must finish before the given node can start, returned as one id per line in dependency order. impact is the downstream mirror; path shows the whole critical chain.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | target node id, e.g. W-12, G-03 or D-40 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the annotations: it states the output format (one id per line) and ordering (dependency order), and specifies it works over 'blocks edges.' These details are not present in the annotations (which only cover readOnly, idempotent, non-destructive). No contradiction, and the extra context is useful.
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?
The description is two concise sentences, with the core function front-loaded followed by a useful comparison to related tools. Every phrase contributes meaning; there is no filler or redundancy.
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?
Given a single parameter, full schema coverage, and annotations that establish safety, the description provides enough context to call the tool correctly: it explains what is returned and how, and notes related tools for alternative needs. It is complete for practical use.
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?
The schema already covers the single parameter 'id' with a description and examples, and coverage is 100%. The tool description adds no additional parameter-specific semantics beyond what the schema provides, so the baseline of 3 is appropriate.
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?
The description clearly states a specific function: list every node that must finish before a given node starts, returned as one id per line in dependency order. It also names alternatives (impact, path) and differentiates itself from them, so an agent can identify this tool's unique role among many siblings.
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?
The description explicitly explains when to use it (for upstream blockers) and explicitly contrasts with alternatives: 'impact is the downstream mirror; path shows the whole critical chain.' This gives clear guidance on when not to use it and routes the agent to the correct sibling for other dependency queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structural diff of nodes and edges against a git ref (since, default HEAD): grove structures, not text hunks. Requires the project root to be a git repository; outside one it fails with a not a git repository error naming the root. log shows who changed what and when.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | git ref to diff against (default HEAD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: it states the tool fails with a 'not a git repository' error outside a git repo, and clarifies the diff is structural rather than textual. This goes beyond the annotations without contradicting them.
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?
The description is three sentences with no redundant words. It front-loads the core purpose in the first sentence, then quickly covers prerequisites and a contrast with log. Every clause earns its place.
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?
For a simple tool with one optional parameter and no output schema, the description covers the main functionality, the git prerequisite, and the distinction from log. It does not detail the exact output format, but 'structural diff of nodes and edges' gives a reasonable expectation. The omission is minor given the simplicity.
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?
The schema has 100% coverage for the single 'since' parameter, describing it as a git ref with default HEAD. The description repeats this ('since, default HEAD') without adding significant new meaning. Baseline of 3 is appropriate since the schema already documents the parameter fully.
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?
The description states a clear verb ('diff') and resource ('nodes and edges'), and explicitly differentiates from text hunks by saying 'grove structures, not text hunks.' It also mentions the git ref parameter. This is specific and distinguishes the tool from siblings like log and show.
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?
The description provides a clear use case (structural diff against a git ref) and explicitly notes the prerequisite that the project root must be a git repository, including the failure mode. It also contrasts with the sibling log ('log shows who changed what and when'), giving an implied when-not-to-use directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Print the distillation worksheet for a verified goal: what its subgraph produced and what should survive in Discoveries before archive. Refuses with the current status when the goal is not verified. Read-only unless null=true, which appends a null-distill attestation to the audit journal; state.lock itself is not mutated. Run this before archive when no Discovery captures the goal.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | goal id G-NN | |
| null | No | write a null-distill attestation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing the default read-only behavior, the null=true side effect of appending a null-distill attestation, and the explicit guarantee that state.lock is not mutated. It also discloses the refusal behavior for unverified goals. This adds substantial behavioral context beyond the structured annotations.
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?
The description is three dense, purposeful sentences with no filler. The core purpose is front-loaded, followed by behavioral caveats and a workflow placement statement. Every sentence earns its place.
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?
For a two-parameter tool with no output schema, the description covers prerequisites, side effects, workflow timing, and failure behavior. It explains what the worksheet contains and when null should be used. Nothing essential is missing for an agent to decide whether and how to call it correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance to the null parameter by explaining what appending a null-distill attestation means and that state.lock is not mutated. It also frames the id parameter as a verified goal, which clarifies the expected input context beyond the schema's 'goal id G-NN'.
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?
The description states a specific verb ('Print'), a concrete resource ('distillation worksheet'), and a clear selection condition ('for a verified goal'). It explains what the worksheet reports and ties the tool to the archive workflow, distinguishing it from sibling tools like archive, show, and status.
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?
The description explicitly says when to invoke the tool: 'Run this before archive when no Discovery captures the goal.' It also warns that unverified goals are refused with current status, which tells the agent to check verification before calling. This gives a clear routing rule despite not naming many alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Definition-of-Ready breakdown for one work item: one line per conjunct with its current pass or fail and a final result line. Run it before resume to confirm a work item is actually startable; set status=progress consults the same conjuncts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details: the line-per-conjunct output format, pass/fail evaluation, final result line, and its relationship to the resume/status workflow.
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?
Two sentences, front-loaded with the core function and output shape, followed by actionable usage context. Every clause earns its place with no redundant or filler content.
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?
For a read-only, single-parameter tool with no output schema, the description explains what the tool returns, when to invoke it, and how it relates to the surrounding workflow. Nothing essential is missing.
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?
The single parameter id is fully documented in the schema with the description 'work item id W-NN', so the schema carries the semantic weight. The tool description adds no additional parameter-level meaning beyond referring to 'one work item', which is consistent but not augmentative.
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?
The description states a specific action and object: it produces a Definition-of-Ready breakdown for one work item, with one line per conjunct, pass/fail status, and a final result line. This clearly distinguishes it from sibling tools like ready, status, and resume.
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?
The description explicitly says to run it before resume to confirm a work item is startable, and it names set status=progress as an alternative that consults the same conjuncts. This gives concrete when-to-use guidance and points to a related behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append one evidence line to a work item's evidence field: the canonical way to record done-work proof, which dor, gate and distill read. Success is silent. Equivalent to field with field=evidence and op=add, but self-documenting.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN | |
| text | Yes | evidence line to append |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'Success is silent,' a useful behavioral trait not present in the annotations and especially relevant given the absence of an output schema. It also notes that dor, gate, and distill read the evidence, providing downstream context, though it does not cover auth, failure modes, or reversibility.
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?
Two short sentences with no filler: the action, canonical status, downstream readers, silent success, and equivalence to field are all communicated efficiently. The key information is front-loaded and every clause earns its place.
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?
For a simple two-parameter append operation, the description is complete: it defines the purpose, the canonical use case, downstream consumers, and the silent success behavior. No critical invocation detail is missing.
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?
The input schema already fully describes both parameters, so the description adds little parameter-specific meaning. It reinforces that text is an evidence line, but this is largely a restatement of the schema 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?
States a precise action: appending one evidence line to a work item's evidence field. It also positions itself as the canonical way to record done-work proof and explicitly compares to field with op=add, which separates it from generic field manipulation.
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?
Describes the tool as 'the canonical way' to record evidence and explains the equivalence to field with field=evidence and op=add, giving clear context for when it should be chosen. It does not explicitly state when to avoid it, but the 'canonical' framing and comparison make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit one list-valued field of a node (ac, hypothesis, evidence_strategy, evidence, outcome, goals, surface, and so on): op add appends value, rm removes the entry at the 1-based index given in value, clear empties the field. Success is silent. For scalar attributes use set; for done-work proof on a work item prefer evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | target node id, e.g. W-12, G-03 or D-40 | |
| op | Yes | field operation | |
| field | Yes | field name (ac, hypothesis, evidence_strategy, evidence, outcome, goals, surface, ...) | |
| value | No | entry text (add) or 1-based index (rm) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses mutation semantics: add appends, rm removes by 1-based index, clear empties the field. It also reveals that 'Success is silent', which is important given there is no output schema. None of this contradicts the annotations, so the description carries the behavioral burden well.
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?
The description is compact and front-loaded, with no filler. Every sentence adds operational or routing information, and the operation semantics are packed efficiently into one sentence.
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?
For a mutating tool with no output schema, the description covers field scope, operations, value semantics, silent success, and key alternatives. It could more explicitly state that add/rm require value while clear does not, but this is inferable and the overall guidance is strong.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining what value means for each operation: entry text for add, 1-based index for rm, and no value for clear. This materially helps an agent use the parameters correctly.
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?
The description states a specific action ('Edit') on a specific resource ('one list-valued field of a node') and lists representative fields and the supported operations. It also differentiates itself from the sibling tools set and evidence, so an agent can identify exactly what this tool does.
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?
It explicitly says to use this tool for list-valued fields and provides clear routing guidance: 'For scalar attributes use set; for done-work proof on a work item prefer evidence.' This gives both when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record how much one work item contributes toward one goal: the per-goal delta, where +N advances the goal, 0 is neutral and -N regresses it. Typically set at creation and re-set when scope changes (the last write wins); the deltas surface in dor breakdowns and execution packets. Success is silent; an unknown work item or goal id fails with missing: <id> (exit 5). Use set for scalar attributes and field for list fields; this tool only edits the delta.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN | |
| goal | Yes | goal id G-NN | |
| delta | Yes | per-goal delta (+N, 0, or -N) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since all annotations are false, the description carries the full burden. It discloses write semantics ('last write wins'), silent success, and the exact failure mode with 'missing: <id>' and exit 5, plus data surfacing in DOR breakdowns and execution packets. No contradiction with annotations.
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?
Three sentences, each earning its place: definition, typical usage/timing, and error/alternative routing. Front-loaded with the core semantics and no fluff.
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?
For a simple 3-parameter write tool with no output schema, the description covers purpose, semantics, timing, side effects (DOR breakdowns/execution packets), error behavior, and alternative tool routing. An agent has all the information needed to invoke it correctly.
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?
Schema coverage is 100%, so baseline is 3; the description adds conceptual meaning on top by explaining that +N advances the goal, 0 is neutral, and -N regresses it, and by clarifying that unknown work item or goal ids fail with a specific error. This modest added value justifies a 4.
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?
The description uses a specific verb ('Record') and resource ('how much one work item contributes toward one goal') and defines the delta semantics (+N advances, 0 neutral, -N regresses). It explicitly differentiates from sibling tools by stating 'this tool only edits the delta' and naming set/field as alternatives.
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?
Provides explicit when-to-use context: 'Typically set at creation and re-set when scope changes.' It also gives alternative routing: 'Use set for scalar attributes and field for list fields; this tool only edits the delta,' telling the agent when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether the project passes the distillation gate: baseline, treewidth delta, work items done since baseline and what would distill (thresholds theta default 0 and n default 5). Appends a gate record to the audit journal but never mutates state.lock; distill is the worksheet and archive is the action.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | done-count threshold (default 5) | |
| theta | No | surface overflow threshold (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations alone only say readOnlyHint=false, so the description carries the side-effect disclosure burden. It explicitly states the tool appends a gate record to the audit journal and never mutates state.lock, going beyond the annotations and giving an agent a clear behavioral model.
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?
The description is two sentences with the main purpose and report scope front-loaded, followed by the key side-effect and sibling differentiation. No filler, and both sentences earn their place.
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?
For a tool with no output schema and only two optional parameters, the description is complete: it names what the report includes, the thresholds, the side effect, and the distinction from distill and archive. An agent has enough to invoke it correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description mentions thresholds theta and n with defaults, which adds context but largely repeats what the schema already documents; it does not provide substantial new parameter semantics beyond the schema.
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?
The description states a specific verb and resource: 'Report whether the project passes the distillation gate', and enumerates the report contents (baseline, treewidth delta, work items done, what would distill). It also distinguishes itself from related tools by noting 'distill is the worksheet and archive is the action'.
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?
The description clearly frames gate as a reporting/evaluation tool and distinguishes it from distill and archive, which are the worksheet and action respectively. It communicates that gate does not mutate state.lock, but it does not explicitly spell out all conditions for when to choose gate over other siblings like check or status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atomically rename one glossary term in glossary.md and rewrite the Discovery tags that reference it: both halves change together or not at all. Refuses when the term is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| new | Yes | replacement term | |
| old | Yes | existing glossary term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond the annotations: the operation is atomic, both sides change together or not at all, and it refuses unknown terms. It does not mention conflict behavior when the replacement term already exists, but the key mutation semantics are clear.
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?
A single compact sentence conveys the operation, the file affected, the side effect, the atomicity guarantee, and a failure condition. There is no filler or repetition of schema information.
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?
For a simple two-parameter mutation with no output schema, the description provides the target file, the reference rewrite side effect, atomicity, and refusal behavior. Minor gaps such as handling duplicate replacement names or response shape are not critical for correct invocation.
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?
The schema already fully documents both parameters with 100% coverage, so the baseline applies. The description's 'refuses when the term is unknown' reinforces but does not significantly extend the schema's 'existing glossary term' description, and it adds no new constraints for the replacement term.
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?
The description states a specific action, 'rename one glossary term in glossary.md,' and the secondary effect of rewriting Discovery tags. This clearly distinguishes it from sibling tools like add, set, field, and renumber, which have different operations.
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?
The intended use is implied by the title and the verb: this is the tool for renaming a glossary term and updating its references. However, it names no sibling alternatives and gives no explicit when/not-when guidance for choosing this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the whole graph as a fenced mermaid flowchart block: one node per id with status classes and labelled edges. Read-only; deps and impact give a single node's neighborhood.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds concrete behavioral context beyond annotations by specifying the output format (fenced mermaid block), the node representation (one per id with status classes), and edge labelling. It could add more detail about status classes or output size, but for a parameterless read-only tool this is sufficient.
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?
Two tightly written sentences with the primary action and output format front-loaded. The first sentence delivers the essential behavior, and the second sentence usefully routes to alternatives. No filler or redundant schema repetition.
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?
For a parameterless, read-only, idempotent render operation, the description covers the output format, scope, and intended use case, and clearly contrasts with sibling tools. The annotations complete the safety picture. Nothing essential is missing for an agent to invoke this tool correctly.
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?
The tool has zero parameters, so the baseline is 4. There is no parameter detail needed, and the description correctly focuses on behavior and scope rather than input semantics.
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?
The description names a specific verb ('Render'), a clear resource ('the whole graph'), and an exact output format ('fenced mermaid flowchart block'). It also differentiates itself from siblings by explicitly contrasting with 'deps and impact', which return a single node's neighborhood. An agent can immediately understand what this tool does and how it differs from nearby alternatives.
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?
The description states the primary use case (rendering the whole graph) and explicitly points to sibling tools ('deps and impact') for a narrower, node-scoped view. This provides clear when-to-use and when-not-to-use guidance without requiring the agent to open other tool schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer ownership of a progress work item to another session token; only the current holder can. resume is how the receiving session picks the item up.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN | |
| to | Yes | new owner session token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate a non-read-only, non-idempotent, non-destructive operation. The description adds meaningful behavioral context: the transfer is restricted to the current holder and the receiving session must use resume to pick up the item. This workflow coupling is not present in the structured annotations.
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?
Two concise sentences that front-load the primary action, then give the key constraint and the sibling relationship. No filler or repetition. Every sentence contributes useful information.
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?
For a simple 2-parameter tool with no output schema, the description covers the operation, the authorization constraint, and the follow-up workflow (resume). It omits possible error behavior, but this is a minor gap for such a straightforward transfer action.
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?
Schema description coverage is 100%, so the parameter meanings are fully documented in the input schema. The description references 'session token' in line with the schema's 'new owner session token' but does not add further semantic detail beyond what the schema already provides. Baseline 3 is appropriate.
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?
The description states a specific action ('Transfer ownership') and resource ('progress work item') to a specific target ('another session token'), and further clarifies the scope with 'only the current holder can'. It also explicitly contrasts with the sibling tool 'resume', making it easy for an agent to distinguish handoff from the receiving-side operation.
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?
The description gives clear usage context: use handoff to transfer ownership and resume to pick it up on the receiving side. It also notes a key prerequisite ('only the current holder can'). It does not, however, enumerate explicit when-not-to-use conditions beyond the holder constraint, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transitive successors over blocks edges: every node the given node blocks from starting, returned as one id per line. deps is the upstream mirror.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | target node id, e.g. W-12, G-03 or D-40 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuine behavioral value beyond these: the traversal semantics (transitive, following blocking edges from the given node) and the output format (one id per line). No contradiction with annotations.
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?
Two sentences, zero filler. The core computation is front-loaded, the output format is stated compactly, and the sibling contrast ('deps is the upstream mirror') earns its place by disambiguating the tool. Nothing redundant.
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?
For a single-parameter, read-only query tool with 100% schema coverage and full safety annotations, the description covers what it computes, the starting node, the output format, and the primary sibling. A minor gap is the unexplained domain jargon 'blocks edges', which an agent unfamiliar with the model would have to infer.
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?
Schema description coverage is 100% — the schema already documents the single 'id' parameter with examples. The description adds a small semantic link by clarifying that id is the traversal starting point ('the given node blocks from starting'), but this is marginal enrichment over an already well-documented parameter, so the baseline 3 applies.
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?
The description states a specific computation — transitive successors over block edges — and clarifies the resource ('every node the given node blocks from starting') and output format ('one id per line'). It also names the sibling tool 'deps' as the upstream mirror, so an agent can distinguish impact from deps without inspecting schemas.
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?
The description gives clear selection context by stating that 'deps is the upstream mirror', implying impact is the downstream counterpart and routing the agent to the correct sibling for upstream queries. However, this is implied rather than explicit ('use impact when you need downstream, deps when upstream'), and no other alternatives are addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialise a grove project: create .grove/state.lock, index.md and glossary.md under the project root. Run once per project; every other tool fails until the lock exists, and a second run refuses rather than overwrites. id-stride, id-offset and id-width tune numeric id allocation for new nodes. Returns the initialised .grove path.
| Name | Required | Description | Default |
|---|---|---|---|
| id_width | No | minimum digit padding for new ids | |
| id_offset | No | first suffix when a family allocator is empty | |
| id_stride | No | additive gap between successive numeric id suffixes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavior: it creates specific lock and documentation files, refuses to overwrite on a second invocation, and returns the initialised .grove path. This adds context the annotations alone do not provide, such as the refusal behavior and project-wide dependency on the lock.
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?
The description is compact and well-structured: it opens with the core action and artifacts, follows with the essential usage constraint, then summarizes parameters, and closes with the return value. Every sentence contributes necessary information without redundancy.
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?
For a tool with three optional parameters and no output schema, the description covers the full picture: what is created, when to use it, what happens on misuse, what the parameters affect, and what to expect as a return value. Nothing critical is missing for an agent to invoke it correctly.
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?
The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds a layer of meaning by explaining that id-stride, id-offset, and id-width tune 'numeric id allocation for new nodes', connecting the parameters to their purpose beyond their individual schema descriptions.
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?
The description gives a specific verb and resource: 'Initialise a grove project' and names the exact artifacts created (.grove/state.lock, index.md, glossary.md). It is clearly differentiated from the many sibling tools by describing a one-time setup action with a concrete outcome.
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?
It explicitly states when to run this tool: 'Run once per project.' It also explains consequences of not running it ('every other tool fails until the lock exists') and that a second run refuses rather than overwrites, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a directed edge from one node to another with a label: blocks, implements, asks, tests, targets, produces, causes, supersedes or distills. Edges feed the ready, next, path, deps and impact analytics and are checked by invariants, so invalid combinations are rejected; success is silent. To remove an edge use unlink.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | target node id | |
| from | Yes | source node id | |
| label | Yes | edge label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false) but do not cover side effects or error behavior. The description adds 'success is silent' and 'invalid combinations are rejected by invariants,' which are valuable behavioral details beyond annotations. No contradiction with annotations.
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?
Three sentences, front-loaded with the primary action, then consequences and alternative. No filler or repetition. Every sentence earns its place.
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?
With three required parameters and no output schema, the description covers the operation's purpose, label options, validation behavior, side effects on analytics, and the removal path. Nothing an agent needs to call this tool correctly is missing.
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?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description does not add additional parameter-specific meaning beyond saying 'from one node to another,' which is already implied by source/target node ids. Baseline 3 applies because the schema handles the semantics.
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?
The description clearly states the action: 'Create a directed edge from one node to another with a label.' It enumerates the allowed labels, which is explicit. It also distinguishes itself from unlink by naming the removal counterpart, making the purpose unambiguous.
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?
The description provides clear context for when to use this tool: to create edges between nodes, with the note that edges feed analytics. It explicitly directs users to unlink for removal, but it doesn't discuss alternatives like add or set, so it's slightly short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List nodes filtered by required kind (g, w, d, q, b, t, y or a), one tab-separated line per node: id, status, title. Optional status and cynefin filters (cynefin = the clear/complicated/complex/chaotic complexity class) narrow the set; when nothing matches, nothing is printed. show dumps one record in full; status summarises the whole project.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | node kind | |
| status | No | status filter | |
| cynefin | No | cynefin filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: the tab-separated output format, the no-output behavior when nothing matches, and the narrowing effect of optional filters. This covers the relevant runtime behavior for a listing tool.
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?
The description is compact, front-loaded with the core purpose, and every clause earns its place: filters, output format, no-match behavior, and sibling differentiation are all covered in three dense sentences without repetition.
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?
For a simple read-only list tool, the description covers the required kind, optional filters, output format, and empty-result behavior. Minor gaps remain, such as no mention of pagination, ordering, or a limit on results, but these are not critical given the tool's apparent scope and the strong annotation coverage.
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?
Schema coverage is 100%, so the baseline is 3. The description adds a helpful explanation of cynefin ('the clear/complicated/complex/chaotic complexity class') and restates the kind enum, but it does not explain what each kind letter means or what values the status filter accepts. It adds some value but does not fully compensate for those semantics.
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?
The description states a specific verb and resource: 'List nodes filtered by required kind', and defines the exact output as 'one tab-separated line per node: id, status, title'. It also distinguishes itself from siblings by contrasting with 'show dumps one record in full; status summarises the whole project'.
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?
The description clearly indicates list is for node sets with optional filters, and mentions alternatives: 'show dumps one record in full; status summarises the whole project'. It does not spell out explicit when/when-not rules, but the contrast is clear enough for an agent to choose the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timeline of node and edge timestamps plus raw journal records, newest first, one line each; optional id filter and limit (default 200 rows, 0 for unlimited). stats aggregates the same history into metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | optional node id filter | |
| limit | No | row cap (default 200; 0 = unlimited) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details beyond annotations: newest-first ordering, one-line-per-record formatting, default limit of 200, and the 0-means-unlimited behavior. These details help the agent understand what invoking the tool will produce.
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?
The description is a single dense sentence with no filler. It front-loads the core behavior (timeline of timestamps and raw records), then adds optional filtering, limits, and the alternative stats tool, all in around 25 words.
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?
For a low-complexity, read-only tool with only two optional parameters and no required fields, the description covers what the agent needs to invoke it correctly: output ordering, line format, filter behavior, and row limits. The lack of an output schema is not a major gap here, though more detail about the exact fields within each raw journal line would make it fully complete.
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?
Schema description coverage is 100%, and both parameters are already fully described in the input schema: 'id' as an optional node id filter and 'limit' as a row cap with default 200 and 0 meaning unlimited. The description echoes this information without adding new semantic depth, so the baseline score of 3 is appropriate.
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?
The description clearly states what the tool returns: a timeline of node and edge timestamps plus raw journal records, ordered newest first, one line each. The phrase 'timeline' combined with the title 'Journal timeline' gives a specific action and resource, and explicitly contrasts with 'stats aggregates the same history into metrics,' which helps distinguish it from the sibling 'stats' tool.
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?
The description provides clear usage context: it is a read-only chronological journal view with optional id filtering and a limit. Mentioning that 'stats aggregates the same history into metrics' signals the alternative for aggregated views, though it does not explicitly state 'use log for raw records, use stats for metrics.' This is still enough contextual guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose the single next work item to execute and return its full execution packet: the same markdown bundle packet produces, prefixed by the skill banner. The start-of-session default; ready shows the whole queue instead, and packet fetches an arbitrary work item.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by explaining the output format: the same markdown bundle packet produces, prefixed by the skill banner. This goes beyond what annotations provide.
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?
Two dense sentences carry the full purpose, output details, and sibling comparisons without waste. The core action and output are front-loaded, and every clause adds useful information.
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?
There is no output schema, so the description bears the responsibility of explaining the return value. It does so clearly and completely: the full execution packet, same markdown bundle as packet produces, prefixed by the skill banner. Combined with annotations and sibling contrasts, an agent has everything needed to invoke this zero-parameter tool correctly.
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?
The tool has zero parameters and the schema is empty with 100% coverage, so there is no parameter semantics to document. The 0-parameter baseline applies, and no additional param explanation is needed.
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?
The description clearly states a specific verb and resource: propose the single next work item to execute. It further differentiates itself from siblings by contrasting with ready (whole queue) and packet (arbitrary work item).
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?
The description explicitly identifies this as the start-of-session default and names the alternative tools and their conditions: ready shows the whole queue, packet fetches an arbitrary work item. This gives an agent clear guidance on when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full execution packet for one work item as markdown: record, goals and fitness contribution, hypotheses, linked decisions, blocking questions and the outcome of every blocker. Fetch this before starting or resuming any work item; next returns the same bundle only for its single proposal, and show prints the bare record without execution context. cone=true appends multi-hop structural context over blocks edges (cone-depth default 4, cone-max default 50 nodes); deps returns just the blocker ids. An unknown id fails with not found (exit 5).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN | |
| cone | No | append multi-hop structural context on blocks | |
| cone_max | No | cone node cap (default 50) | |
| cone_depth | No | cone BFS hops (default 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail beyond that: the markdown return format, the full set of returned components, cone expansion behavior with defaults, and the failure mode ('not found' exit 5). No contradiction with annotations.
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?
Every clause earns its place: the packet contents, usage timing, sibling differentiation, cone parameters and defaults, and error behavior. It is dense but well-structured, with the core purpose front-loaded and no filler.
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?
For a read-only retrieval tool with no output schema, the description is complete: it states what the agent receives, when to fetch it, how cone modifies the result, and what happens on invalid ids. The only omitted detail is the exact markdown layout, which is not necessary for correct invocation.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that cone appends structural context over blocks edges, clarifying the relationship to deps, and specifying the unknown-id error behavior. It reinforces id's role implicitly through the error case and explains the cone parameters' effects.
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?
The description opens with a specific verb and resource: 'Full execution packet for one work item as markdown' followed by the exact contents. It distinguishes itself from siblings by contrasting with next, show, and deps, so an agent can pick it without opening schemas.
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?
Explicitly states when to use the tool: 'Fetch this before starting or resuming any work item.' It also names alternatives and their scopes—next returns the bundle for a single proposal and show prints the bare record—so the agent knows exactly when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Print the critical path: the longest chain of unfinished blocks edges, as one id per line in chain order. Use it to see the current bottleneck end to end; deps and impact cover a single node's neighborhood.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context about output format ('one id per line in chain order') and scope ('unfinished blocks edges'), going beyond the annotations without contradicting them.
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?
Two sentences with no filler. The definition and output format come first, followed by usage guidance and sibling differentiation. Every sentence earns its place.
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?
For a zero-parameter read-only tool, the description fully covers what the tool does, what output to expect, when to use it, and how it differs from related tools. Annotations cover the safety profile, so nothing essential is missing.
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?
The tool has zero parameters, so the baseline is 4. There is no parameter information needed, and the description correctly focuses on behavior and output rather than input semantics.
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?
States a specific verb and resource: 'Print the critical path', and defines it precisely as 'the longest chain of unfinished blocks edges, as one id per line in chain order'. This clearly distinguishes it from sibling tools like deps and impact.
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?
Explicitly says when to use it: 'to see the current bottleneck end to end', and names the alternatives: 'deps and impact cover a single node's neighborhood'. This gives an agent clear routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the project registry, one line per project: name, path and last-opened time. Entries are created and refreshed automatically as grove commands run inside a project; this server is bound to a single root at startup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: entries are created/refreshed automatically by grove commands, and the server is scoped to a single root at startup. No contradiction with annotations.
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?
The description is two compact sentences with no filler. The core operation and output format are front-loaded, and the second sentence adds relevant lifecycle context without unnecessary detail.
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?
For a zero-parameter read-only listing tool with no output schema, the description covers the return value (one line per project with name, path, last-opened time) and explains how entries get populated. Minor details like ordering are unspecified, but nothing essential is missing for invoking the tool correctly.
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?
The input schema is empty, so there are no parameters requiring documentation. The description instead clarifies what the output contains, which is the only semantic information an agent needs for this tool.
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?
The description states a specific verb and resource: 'List the project registry' and specifies the exact output format (name, path, last-opened time). This makes the tool's function unambiguous and distinguishes it from general sibling tools like 'list' or 'show'.
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?
The description does not explicitly name alternatives or state when not to use this tool. It does give useful contextual guidance—entries are auto-created and refreshed as grove commands run, and the server is bound to a single root—so an agent can infer when this tool is appropriate, but the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy a Discovery into another project (registry name or directory) with origin provenance; the copy arrives as proposed and the target project's state is written, unlike revalidate, which refreshes in place.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | discovery id Y-NN | |
| to | Yes | target project (directory or registry name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the copy carries origin provenance, arrives as proposed, and that the target project's state is written. This adds meaningful behavioral context about side effects. It aligns with the readOnlyHint=false and destructiveHint=false annotations.
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?
One sentence front-loaded with the verb and object, with no filler. The parenthetical destination detail and the revalidate contrast both contribute essential information without bloating the 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?
For a two-parameter mutation tool with no output schema, this covers the core action, destination semantics, provenance, and state side effect. It could elaborate on what 'proposed' means for downstream approval, but the agent has enough to invoke it correctly.
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?
The input schema already documents both parameters fully, including the Y-NN format for id and the target project for 'to'. The description mostly restates the destination concept without adding new format or constraint details. A baseline of 3 is appropriate given 100% schema coverage.
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?
Clearly states a specific verb and resource: 'Copy a Discovery into another project'. It also names the destination form and the key side effect, distinguishing it from revalidate. An agent can immediately tell what this tool does and how it differs from its closest sibling.
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?
The description gives a clear use case: promoting/copying a Discovery across projects. It explicitly names revalidate as the alternative and explains the behavioral difference, which is enough to route an agent correctly. It does not cover every possible sibling, but it addresses the most relevant one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List work items in status ready, one line per item (id, title, and a [crit] marker when the item sits on the critical path), critical-path first. Use this for the whole queue; use next when you want a single recommendation, or packet for one item's full context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses concrete output behavior beyond annotations: one line per item, id/title fields, a [crit] marker for critical-path items, and critical-path-first ordering. Since there is no output schema, this return-format and sort-order detail is essential and well-covered.
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?
Two sentences with no filler: the first packs action, scope, output format, and sorting; the second gives alternative-tool routing. Everything included earns its place.
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?
For a zero-parameter read-only list, the description fully covers scope, output format, marker semantics, sort order, and sibling-tool differentiation. Nothing needed for correct invocation or interpretation is missing.
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?
The input schema is empty and required parameters are zero, so there are no parameter semantics to document. The description implicitly signals a no-argument list command, which is appropriate for a zero-parameter tool.
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?
States a specific action (List) and resource (work items in status ready), and includes the output shape and ordering. The description distinguishes this tool from siblings by explicitly naming `next` and `packet` as alternatives.
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?
Provides explicit routing guidance: use `ready` for the whole queue, `next` for a single recommendation, and `packet` for one item's full context. This leaves no ambiguity about when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regenerate index.md from the current state.lock. Idempotent, safe to re-run and silent on success; most mutating tools already auto-render, so use it after out-of-band edits or when index.md looks stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry idempotentHint=true and destructiveHint=false; the description adds 'silent on success,' which is not in the annotations, and clarifies that output is regenerated from state.lock. A small gap: failure behavior is not mentioned.
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?
Two sentences with no fluff; the core action is front-loaded and the usage guidance follows immediately. 'Safe to re-run' is slightly redundant with idempotent, but overall it earns its place.
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?
For a parameterless, low-risk tool with an existing idempotency annotation, the description covers what it does, when to use it, and behavior on success. Nothing essential is missing.
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?
The tool has zero parameters, and schema coverage is trivially 100%, so there is little for the description to add. It still provides useful context by naming the input and output artifacts.
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?
Names a specific verb (regenerate), a concrete artifact (index.md), and the input source (state.lock). This is enough to distinguish it from sibling tools without needing to open schemas.
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?
Explicitly states the intended scenarios ('after out-of-band edits or when index.md looks stale') and warns that most mutating tools already auto-render, so the agent knows when NOT to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a node's id and rewrite every reference to it across the graph. Refuses while the old id appears in done-work evidence; success is silent. Journal-recorded, but ids quoted in external documents will dangle.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | current node id | |
| to | Yes | new id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, disclosing that success is silent, that the operation is journal-recorded, that it refuses under a specific evidence condition, and that external document references will dangle. This is exactly the behavioral context an agent needs for a mutating tool with no output schema.
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?
Three dense sentences with no filler. The core action is front-loaded, followed by critical refusal behavior, output expectation, and side-effect warning. Every sentence earns its place.
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?
For a two-parameter tool with no output schema, this description is complete: it explains the action, the failure condition, the silent success, the journaling, and the external-document caveat. An agent has enough to invoke it and anticipate outcomes.
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?
Schema description coverage is 100%, so the schema already documents both parameters clearly. The description adds operational context but no additional meaning about the id and to parameters beyond what the schema states. Baseline 3 is appropriate.
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?
The description states a specific verb and resource ('Change a node's id') and expands the scope ('rewrite every reference to it across the graph'). It is immediately clear what the tool does and how it differs from generic siblings like set or field.
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?
The operation itself implies when to use it: when a node id must change and references need updating. It also gives a clear when-not condition ('Refuses while the old id appears in done-work evidence'). It does not name an alternative tool, but none is obviously needed given the unique operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept whatever is currently in state.lock and recompute its checksum; confirm=true is required. Last resort when check reports a checksum mismatch after a manual edit or merge: it blesses the file as-is, so inspect the contents first.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | accept current lock contents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly=false, idempotent=true, and destructive=false, but the description adds important context: confirm=true is mandatory, the file is blessed as-is, and the caller should inspect contents first. This meaningfully goes beyond the structured annotations without contradicting them.
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?
Two sentences, front-loaded with the core action and parameter requirement, followed by usage context and caution. No wasted words.
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?
For a single-boolean-parameter tool with no output schema, the description fully covers what the tool does, when to use it, and what to be careful about. Nothing essential is missing.
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?
With only one parameter and 100% schema coverage, the schema already documents confirm well. The description adds value by clarifying that confirm=true is explicitly required for acceptance, not merely that the parameter must be present.
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?
States a specific action on a specific resource: accept current state.lock contents and recompute its checksum. Clearly distinguishes itself from the sibling check tool, which verifies mismatches rather than repairing them.
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?
Explicitly scopes usage to a last resort after check reports a checksum mismatch following manual edit or merge. It also tells the agent to inspect contents first, providing a clear safety check before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adopt this session's token on a progress work item, taking ownership of it: on success the item stays in progress with the session id and timestamp stamped on it (visible as session= in show output) and nothing is printed. Refuses when the item is not in progress. handoff transfers ownership to another session; revert drops the claim and returns the work item to ready.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, etc.), the description discloses that success mutates the item by stamping session id/timestamp, that output is silent, and that the operation fails if the item is not in progress. These are behavioral facts the annotations do not convey. No contradiction with the annotations.
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?
Every clause contributes: the ownership behavior, the success effect and silent output, the refusal condition, and the key alternatives. It is compact yet information-dense, with the central action front-loaded.
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?
For a one-parameter state-changing tool with no output schema, the description covers success behavior, output, failure condition, and how it relates to adjacent operations. Nothing essential is missing.
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?
The schema already documents the sole parameter id with 100% coverage. The description adds no parameter-specific detail, but none is needed because the schema fully explains the required input. This matches the baseline of 3 for high schema coverage.
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?
The description uses a precise verb phrase, 'Adopt this session's token on a progress work item, taking ownership of it', which makes the action concrete and distinguishes resume from generic resume/continue semantics. It also explicitly names handoff and revert as different operations, reinforcing sibling differentiation.
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?
It states the precondition ('Refuses when the item is not in progress') and contrasts the tool with handoff (ownership to another session) and revert (drop claim and return to ready). This is explicit enough for an agent to decide whether resume is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a stale Discovery back to active by paying a fresh anchor: new surface paths and/or provenance ids. Success is silent; the Discovery's new status and revalidation log are visible via show. An unknown id fails with not found (exit 5). To copy a Discovery into another project use promote.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | discovery id Y-NN | |
| from | No | comma-separated provenance ids | |
| surface | No | comma-separated fresh anchor paths |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: success is silent, status and revalidation log are available via 'show', and an unknown id fails with `not found` (exit 5). This materially helps an agent anticipate outcomes without a return schema.
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?
Three sentences with no filler: the core operation is first, then observable success/failure behavior, then the key sibling alternative. Every sentence earns its place.
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?
Given no output schema, the description fully covers what an agent needs: effect, silent success, failure mode, where to verify, and the relevant alternative tool. It is complete for the complexity of this mutation tool.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by tying 'surface' and 'from' together as the 'fresh anchor' and indicating they can be used in combination ('and/or'). It does not, however, detail constraints beyond what the schema already provides.
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?
The description states a specific verb and resource: 'Move a stale Discovery back to active', with a clear mechanism ('paying a fresh anchor: new surface paths and/or provenance ids'). It also distinguishes itself from 'promote' by explicitly naming the copy-to-another-project alternative.
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?
It gives concrete when-to-use context: a stale Discovery that needs a fresh anchor. It also explicitly routes the agent to 'promote' for copying a Discovery into another project, and to 'show' for observing status and logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a progress work item to ready and clear its session claim (holder or stale claim only); refuses when the item is not in progress. For rolling back graph mutations use undo.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | work item id W-NN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only mutability annotations and no destructive hint details, the description carries the burden and discloses the claim-scope ('holder or stale claim only') and the precondition. It could be more explicit about the exact failure mode, but it already goes beyond the annotations.
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?
Two dense sentences front-load the action and resource, state constraints, and point to the alternative tool. There is no filler or repetition of schema fields.
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?
For a single-parameter state-change tool with no output schema, the description covers purpose, precondition, mutation scope, refusal behavior, and the key sibling alternative. Nothing essential for a correct invocation is missing.
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?
The schema documents 'id' as 'work item id W-NN' with 100% coverage, so the baseline is 3. The description adds the crucial constraint that the id must refer to a progress work item, which is not stated in the schema.
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?
The description names a specific action ('Return a progress work item to ready'), a target resource ('progress work item'), and a side effect ('clear its session claim'). It explicitly distinguishes itself from 'undo', which prevents confusion with a similarly named sibling.
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?
It states the applicable situation (returning an in-progress item to ready), a refusal condition ('refuses when the item is not in progress'), and the alternative ('For rolling back graph mutations use undo'). This gives an agent clear routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply one guarded transition of a scalar attribute on a node: status, cynefin, type, title, fitness_kind, fitness_target, area or requires_coverage. Illegal transitions (a status skip, a work item whose DoR is not met) are rejected with the reason and a pointer to dor; success is silent. For list-valued fields such as ac or evidence use field.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | target node id, e.g. W-12, G-03 or D-40 | |
| key | Yes | attribute key: status|cynefin|type|title|fitness_kind|fitness_target|area|requires_coverage | |
| value | Yes | new value for the attribute key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the full burden, and it delivers: it discloses that transitions are guarded, that illegal transitions are rejected with a reason and pointer to 'dor', and that success is silent. This is meaningful behavioral context beyond the structured hints.
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?
Two dense sentences with no filler: the first defines scope and allowed keys, the second defines failure and success behavior plus the sibling to use for lists. Every phrase contributes.
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?
Given no output schema, the description still explains the response semantics: silent success and error payloads containing a reason and a dor pointer. It also scopes the tool to scalar attributes and redirects list-valued mutations, making it complete enough for correct invocation.
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?
Schema coverage is 100%, so the schema already documents id, key, and value. The description adds useful context like example node IDs (W-12, G-03, D-40) and the scalar-vs-list distinction, but it does not substantially redefine parameter meanings beyond what the schema provides.
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?
The description uses a specific verb and resource: 'Apply one guarded transition of a scalar attribute on a node,' and enumerates the exact accepted attribute keys. It also distinguishes itself from 'field' by explicitly naming list-valued fields as out of scope.
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?
It clearly states that list-valued fields such as 'ac' or 'evidence' should use 'field' instead, which is an explicit alternative. It could further contrast with transition-oriented siblings like 'promote' or 'ready', but the guidance given is sufficient for the primary decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dump one node's full record as plain text: kind, status, timestamps, every populated field and incident edges. An unknown id fails with no output (exit code 5). list filters many nodes by kind or status; packet wraps a work item's record in execution context.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | target node id, e.g. W-12, G-03 or D-40 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the exact failure behavior (unknown id fails with no output, exit code 5) and the output format (plain text, with a list of included fields). This is useful contextual information not present in the annotations.
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?
The description is two sentences with no wasted words. The core purpose is front-loaded, the failure condition is stated compactly, and the sibling routing is given in the second sentence. Every phrase earns its place.
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?
For a read-only, single-object retrieval tool, the description covers everything an agent needs: what the output contains, the failure mode, and how it differs from list and packet. There is no output schema, but the description describes the output well enough. No gaps remain.
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?
The schema already describes the id parameter with a 100% coverage, so the baseline is 3. The description adds concrete examples of valid id formats (W-12, G-03, D-40), which helps an agent construct valid inputs. That is a meaningful increment beyond the schema alone.
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?
The description opens with a specific verb-resource pairing ('Dump one node's full record') and enumerates exactly what the output contains (kind, status, timestamps, every populated field, incident edges). It also explicitly contrasts with list and packet, so an agent can immediately tell this tool apart from those siblings.
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?
The description names the two most likely alternatives (list for many nodes filtered by kind/status, packet for wrapping a work item in execution context) and states the conditions that select them. It also notes the failure mode for an unknown id, which helps an agent decide whether this is the right tool and how to handle errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Print the embedded agent skill (the SKILL.md workflow guide with frontmatter), or install it as a skill directory when install names one. The same content is also readable as the grove://skill resource.
| Name | Required | Description | Default |
|---|---|---|---|
| install | No | directory to install the skill into (omit to print) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds the side effect of installing a skill directory and mentions the alternative grove://skill resource, but does not elaborate on overwriting, permissions, or what exactly gets written. This is useful but modest additional context beyond the annotations.
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?
The description is two concise sentences with no wasted words. The primary action is front-loaded ('Print the embedded agent skill...'), and the second sentence adds relevant information about an alternative resource without bloat.
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?
The tool is simple: one optional parameter, no output schema, and annotations cover the safety profile. The description explains both print and install modes, defines what the skill is, and notes an alternative access path. Nothing essential for correct invocation is missing.
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?
Schema description coverage is 100% and the install parameter already has a clear description ('directory to install the skill into (omit to print)'). The tool description only restates the conditional without adding new semantic details like formats, defaults, or edge cases. Baseline 3 applies because the schema fully documents the parameter.
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?
The description states a specific verb-resource pair: 'Print the embedded agent skill (the SKILL.md workflow guide with frontmatter)', and clearly explains a second mode 'install it as a skill directory when install names one'. It distinguishes between print and install without ambiguity, and the reference to the SKILL.md guide makes the resource concrete.
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?
The description provides clear context for when to use the two modes: print by default, install when the install parameter names a directory. However, it does not mention any sibling tools or exclusions, so the agent receives no explicit routing guidance about when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only telemetry computed from the journal and the lock, in metric sections: record and mutation counts, cycle time, DoR first-pass rate, bets, discovery, undo and surprise. status summarises current state instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read-only telemetry' aligns with but does not significantly extend the safety profile. It adds context that data is computed from the journal and lock, which is useful, but it does not disclose other behavioral traits like potential performance cost or historical scope. Given annotations cover the core, a 3 is appropriate.
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?
The description is a single, dense sentence that front-loads the read-only nature and enumerates metric sections without fluff. The closing comparison to 'status' is efficiently placed. Every word contributes to understanding the tool's purpose and scope.
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?
With no parameters and no output schema, the description must convey what the tool returns. It lists the metric sections, giving an agent a clear idea of the expected fields. It does not describe the exact structure or format, but for a read-only telemetry tool with no inputs, this is reasonably complete. A dedicated output schema could compensate, but its absence makes the description sufficient.
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?
The tool has zero parameters and schema coverage is 100% (vacuously). The description adds no parameter-specific info, but none is needed. Per rubric, a 0-param tool warrants a baseline of 4. The description's mention of metric sections indirectly hints at what the output contains, which helps parameter-less usage.
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?
The description clearly states the tool computes read-only telemetry metrics and enumerates the specific metric sections (record/mutation counts, cycle time, DoR first-pass rate, bets, discovery, undo, surprise). It explicitly distinguishes itself from 'status' which summarizes current state, so an agent can differentiate it from siblings without ambiguity.
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?
The description provides a clear alternative by noting 'status summarises current state instead,' implying stats is for telemetry metrics rather than state. This is a useful when-not signal, though it does not elaborate on specific conditions for choosing stats over other siblings (e.g., list, show). Still, it gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-screen markdown project summary: work in progress, alignment triggers and invariant notes, prefixed by the embedded-skill banner. stats is the historical counterpart; check is pass-or-fail on invariants.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable behavioral detail: output is a one-screen markdown summary, includes specific content types, and is prefixed by an embedded-skill banner. This goes beyond what annotations convey.
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?
Two sentences with no wasted words. The primary purpose is front-loaded, followed by a concise comparison to two siblings. Every clause earns its place.
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?
For a parameterless, read-only tool with a rich annotation set, the description is complete: it specifies output format, content scope, banner behavior, and distinguishes from the most relevant alternative tools. Nothing essential is missing.
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?
The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameter semantics, and the baseline of 4 applies.
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?
The description clearly states the tool produces a 'One-screen markdown project summary' covering work in progress, alignment triggers, and invariant notes, with an embedded-skill banner. It also explicitly distinguishes itself from siblings stats and check, so an agent can tell them apart without inspecting other definitions.
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?
The description names the historical counterpart (stats) and the pass/fail invariant tool (check), giving clear context for when status is the right choice for a current project snapshot. It does not explicitly say 'use this when you need current state' but the differentiation is strong enough to infer the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank open work items by discovery need in a table (coverage, chi-square, fragility, suggestion). Read-only advisory input for deciding which work item needs a Discovery next; gate is the pass-or-fail check on the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description reinforces read-only status and adds the table output format with specific columns, plus the advisory nature and the gate check context. This adds value beyond the annotations without contradicting them.
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?
Two sentences, no fluff. The core action and output are front-loaded, and the advisory/read-only clarification follows naturally. Every phrase earns its place.
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?
For a parameterless, read-only tool with no output schema, the description covers what it does, what it returns (a table with named columns), and its purpose in the workflow. Nothing an agent needs to invoke it correctly is missing.
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?
The schema has zero parameters, so there is nothing to document. Baseline for 0 params is 4, and the description correctly focuses on behavior and output rather than parameters, so it fully meets expectations.
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?
States a specific action (rank) and resource (open work items) with an explicit output (a table with named columns). The purpose is unambiguous and distinct from the sibling tools, none of which appear to offer a similar ranking/advisory function.
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?
Provides clear context: it's a read-only advisory input for deciding which work item needs a Discovery next, and references the gate check. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roll back the last N mutations (steps, default 1) by truncating the journal and replaying it. Destructive to audit history: the undone journal records are gone for good, and success is silent. For session claims use revert instead.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | number of mutations to revert (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds crucial behavioral details: journal truncation, permanent loss of audit records, silent success, and the replay mechanism. This provides meaningful context that annotations alone do not convey.
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?
The description is two sentences with no wasted words. The primary action is front-loaded, followed by critical destructive consequences and a clear pointer to the alternative tool.
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?
For a single-parameter, destructive tool with annotations and sibling guidance, the description is complete. It covers what the tool does, how it operates, its destructive side effects, the silent outcome, and when not to use it, leaving no essential gap for correct invocation.
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?
The input schema already fully describes the 'steps' parameter as the number of mutations to revert with a default of 1, and schema coverage is 100%. The description reinforces this by referencing 'N mutations (steps, default 1)' but adds no new semantic information beyond the schema.
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?
The description clearly states the tool rolls back the last N mutations by truncating the journal and replaying it, which is specific and distinguishes it from siblings. It also names the sibling tool 'revert' for a different use case, making the purpose unambiguous.
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?
It explicitly says to use 'revert' instead for session claims, providing a clear alternative and when-not-to-use guidance. It also describes the operational context of rolling back mutations with a configurable step count and default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one directed edge identified by its from node, label and to node. Refuses when the removal would break graph invariants; success is silent. To create an edge use link.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | target node id | |
| from | Yes | source node id | |
| label | Yes | edge label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool may refuse based on invariant checks and that success yields no output ('silent'). This adds useful behavioral context not present in the annotations, which already indicate it is a mutation (readOnlyHint=false).
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?
Two concise sentences: the first states the action and key behavior, the second provides the alternative tool. Every clause earns its place, and the critical information (removal and refusal) is front-loaded.
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?
With no output schema, the description covers the return behavior ('success is silent') and the main failure mode (refusal on invariant breakage). It does not detail other potential errors or side effects, but for a single-edge removal tool with guarded invariants, it is sufficiently complete for an agent to invoke it correctly.
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?
The schema covers all parameters (100% description coverage), so the baseline is 3. The description adds the notion of a 'directed edge' and that the three parameters together identify a unique edge, which clarifies their role beyond the individual schema descriptions. This incremental meaning justifies a 4.
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?
The description clearly states the verb 'Remove' and the resource 'one directed edge', specifying the identifying parameters (from, label, to). It also names the sibling 'link' as the alternative for creating edges, distinguishing it from the rest of the sibling list.
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?
It explains when the operation will refuse (if it would break graph invariants) and notes that success is silent. It also provides an explicit alternative ('To create an edge use link'), giving the agent a clear routing cue, though it does not enumerate all possible alternative tools beyond link.
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.2.1add1 field changedInput schema / properties / title / descriptionPrevious value: -"node title"New value: +"short node title, stamped verbatim"deps1 field changedInput schema / properties / id / descriptionPrevious value: -"node id"New value: +"target node id, e.g. W-12, G-03 or D-40"field1 field changedInput schema / properties / id / descriptionPrevious value: -"node id"New value: +"target node id, e.g. W-12, G-03 or D-40"impact1 field changedInput schema / properties / id / descriptionPrevious value: -"node id"New value: +"target node id, e.g. W-12, G-03 or D-40"set2 fields changedInput schema / properties / id / descriptionPrevious value: -"node id"New value: +"target node id, e.g. W-12, G-03 or D-40"Input schema / properties / value / descriptionPrevious value: -"new value"New value: +"new value for the attribute key"show1 field changedInput schema / properties / id / descriptionPrevious value: -"node id"New value: +"target node id, e.g. W-12, G-03 or D-40"v0.2.0addarchivecheckdepsdiffdistilldorevidencefieldfitnessgateglossarygraphhandoffimpactinitlinklistlognextpacketpathprojectspromotereadyrenderrenumberrepairresumerevalidaterevertsetshowskillstatsstatustriageundounlinkScored across 39 tools
Every tool has a distinct purpose and the detailed descriptions clearly separate overlapping concepts (e.g., ready vs next vs packet, deps vs impact vs path, set vs field vs evidence). There is little to no risk of misselection.
All 39 tool names are single lowercase words or familiar abbreviations (deps, dor, stats), with no camelCase, underscores, or mixed verb styles. The uniform CLI-style naming is highly predictable.
With 39 tools, the surface is significantly larger than the recommended 3-15 range and exceeds even the 25-tool threshold for 'too many'. While each tool appears purposeful, the sheer number makes the server feel heavy and harder to navigate.
The tool set thoroughly covers creation, editing, linking, querying, lifecycle, and distillation workflows, but lacks a permanent node deletion tool and free-text search. Workarounds like archive and undo only partially fill these gaps.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Goal and task planning MCP for Codex and AI agents, with evidence-backed completion.
