Reasonbook

Overview Schema Source Related Servers Discussions Admin

Sprints

rbook_sprint

Destructive

Manage project sprints by adding, updating, completing, listing, or analyzing them, and carry forward pending work to a target Reasonbook address.

Instructions

Manage sprints. Except list/analytics, supply sprintId. add needs title; update needs fields; complete needs summary. retro reports outcomes; analytics compares sprints; carry_forward sends to targetAddress. complete closes the sprint, archiving its decisions and learnings only with archive=true; add demotes other open sprints by default; list and show only read.

Input Schema

Name	Required	Description
`page`	No	1-based page
`send`	No	false for a dry run
`focus`	No	add: the theme
`limit`	No	Per page, or the comparison window
`title`	No	add: sprint title
`action`	Yes
`fields`	No	update: nest changed values here
`status`	No	Filter, or the sprint's status
`archive`	No	Archive sprint decisions/learnings; default false
`endDate`	No	add: ISO date
`summary`	No	Required to complete
`sprintId`	No	The sprint; add: the new id
`startDate`	No	add: ISO date
`projectRoot`	No	Folder/rbook:// address; inferred
`condensation`	No	complete: context condensation
`forceComplete`	No	No-op
`targetAddress`	No	rbook:// address to carry work to
`targetSizePercent`	No	complete: condensation target

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv4.7.2Oct 31, 2026
- addedInput schema / properties / condensation / description
```
Added value: +"complete: context condensation"
```
- addedInput schema / properties / endDate / description
```
Added value: +"add: ISO date"
```
- addedInput schema / properties / focus / description
```
Added value: +"add: the theme"
```
- addedInput schema / properties / limit / description
```
Added value: +"Per page, or the comparison window"
```
- addedInput schema / properties / page
```
Added value: +{
+  "description": "1-based page",
+  "minimum": 1,
+  "type": "integer"
+}
```
- addedInput schema / properties / sprintId / description
```
Added value: +"The sprint; add: the new id"
```
- addedInput schema / properties / startDate / description
```
Added value: +"add: ISO date"
```
- addedInput schema / properties / targetSizePercent / description
```
Added value: +"complete: condensation target"
```
- addedInput schema / properties / title / description
```
Added value: +"add: sprint title"
```

Changed3 schema fields changedv4.7.1Oct 29, 2026

changedInput schema / properties / archive / description

Previous value: -"Also archive sprint decisions/learnings; default false"New value: +"Archive sprint decisions/learnings; default false"

changedInput schema / properties / forceComplete / description

Previous value: -"No-op, kept for compatibility"New value: +"No-op"

changedInput schema / properties / projectRoot / description

Previous value: -"Folder or rbook:// address; inferred"New value: +"Folder/rbook:// address; inferred"

First observedv4.7.0Oct 28, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, yet the description adds real value beyond them: archiving of decisions/learnings only with archive=true, and the non-obvious side effect that add demotes other open sprints. It stops short of saying what happens to decisions/learnings when complete runs with archive=false, which is the key destructive ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences with the routing precondition front-loaded and zero filler; every clause carries action-specific information. The telegraphic style ("add needs title") is efficient but occasionally reads as cryptic shorthand rather than clear prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter, 8-action multiplexed tool with no output schema, the description covers the required-parameter rules per action and the main side effects, which is the bulk of what an agent needs. Gaps remain around pagination, the condensation/targetSizePercent controls, and what each action returns, but the essentials are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 94%, so the baseline is 3; the description earns above that by mapping parameters to actions ("add needs title", "update needs fields", "complete needs summary", "carry_forward sends to targetAddress"). It does not clarify the overloaded semantics of limit (per-page vs comparison window) or status (filter vs value) beyond what the schema already hints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Manage sprints" names a specific resource and the description disambiguates the eight action verbs by function (retro reports outcomes, analytics compares sprints, carry_forward sends to targetAddress). It is clearly distinguishable from siblings like rbook_mission or rbook_decisions, though the umbrella verb "manage" is less precise than naming sprint lifecycle operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition rule ("Except list/analytics, supply sprintId") and per-action requirements (add needs title, update needs fields, complete needs summary). It also flags which actions are read-only ("list and show only read"), but never states when to choose sprint analytics over retro, or any when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Sprints

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools