Open and Async — MCP Server brings async-first working practices into your editor, giving you method tools for drafting artifacts and reference tools for querying the book's thinking.
Draft decision docs — draft_decision_doc turns a decision plus options into a structured ADR (context, tradeoffs, call, reversibility).
Convert meetings to async — convert_meeting_to_async proposes the artifact, owner, and deadline that replaces a meeting.
Score status updates — score_status_update grades a draft against the "work loudly / no surprises" rubric and suggests fixes.
Run standups without a meeting — run_async_standup returns an adoptable async-standup template.
Settle sync vs. async — triage_sync_vs_async recommends one or the other with the decision rule.
Navigate the book — book_outline, get_chapter_summary, and search_principles give the map, chapter TL;DRs, and cited snippets.
Handle pushback — handle_objection maps skepticism like "async is slow" to the book's reframe.
Get role-aware guidance — get_guidance returns manager/IC-specific advice, and get_taglines surfaces shareable quotes and quote-card URLs.
Read resources — book://outline, book://taglines, and book://about expose the same data as JSON.
Run composed prompts — coach triages, generates the artifact, adds role guidance, and caps with a tagline in one deliverable; async-standup, write-adr, meeting-to-issue, and weekly-update handle single tasks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Open and Async MCP Server Should we do the design review sync or async? Triage it for me."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Bring async-first working practices into your editor and AI assistant. This Model Context Protocol server gives your AI the tools to draft a decision doc, turn a meeting into an async artifact, pressure-test a status update, or settle a sync-vs-async debate — without leaving the tools you already work in.
It's the method from Open and Async — the collaborative software-development playbook for remote and distributed teams — as working tools, not reading.
Stop writing decision docs from a blank page. Hand your AI the decision and the options; get back a structured ADR scaffold — context, tradeoffs, the call, and how reversible it is.
Turn "let's hop on a call" into an artifact. Give it a meeting's purpose and agenda; get the async equivalent with an owner and a deadline.
Ship status updates that don't blindside anyone. Score a draft against the "work loudly / no surprises" rubric and get concrete fixes before you post it.
Settle sync vs. async in seconds. Describe the task; get a recommendation and the rule behind it.
Run a standup without a meeting. Drop in a structured async-standup template your team can adopt today.
Win the "async is too slow" argument. Map common objections to a ready reframe, pull role-aware guidance, or search the book's principles — each answer cited and linked.
Get coached end to end. Run the coach prompt with a situation and it triages
sync vs. async, generates the right artifact, adds role guidance, and caps with a
shareable line — one composed answer, or a nudge to just have the conversation when
that's the better call.
Related MCP server: Asana MCP Server
Claude Code:
claude mcp add open-async -- npx -y @open-and-async/mcpClaude Desktop: download open-and-async.mcpb and open it. Claude Desktop installs it in one click, with no config file and no separate Node.js install.
Or add it by hand to claude_desktop_config.json:
{
"mcpServers": {
"open-async": {
"command": "npx",
"args": ["-y", "@open-and-async/mcp"]
}
}
}Any MCP client that speaks stdio works the same way: run npx @open-and-async/mcp.
In the browser (WebMCP): @open-and-async/mcp/browser registers the same tools with a page's model context, so an agent in a WebMCP browser can call them without installing anything. It exists for open-and-async.com, the place to use them. The data license doesn't cover serving the book data from other sites. WebMCP carries tools only, not resources or prompts.
import { registerWebMcpTools } from "@open-and-async/mcp/browser";
const modelContext = document.modelContext ?? navigator.modelContext;
// book: the parsed contents of data/book.json.br. Browsers can't decode Brotli
// streams, so the site re-encodes it as gzip at build time.
if (modelContext) registerWebMcpTools({ book, modelContext });Tool | What it does |
| Decision + options → a structured ADR/decision-doc scaffold (context, options, tradeoffs, decision, reversibility). |
| Meeting purpose/agenda → the async equivalent (artifact, owner, deadline). |
| Scores a draft update against the "work loudly / no surprises" rubric and suggests fixes. |
| A structured async-standup template a team can adopt. |
| Recommends sync vs async for a task, with the decision rule. |
Tool | What it does |
| Sections + chapters + one-line TL;DRs. The map. |
| A chapter's TL;DR + taglines + read-the-chapter link. |
| Keyword search over the summary corpus; short cited snippets. |
| Maps skepticism ("async is slow") to the book's reframe. |
| Role-aware ( |
| Taglines + their |
book://outline — sections, chapters, TL;DRs (JSON)
book://taglines — taglines + quote-card URLs (JSON)
book://about — what this server is, what it does and doesn't contain, and where to get the book
Invoke these directly from your client (e.g. as slash commands):
coach — the full method on one situation. Triages sync vs. async, generates
the right artifact, enriches with role guidance, and caps with a shareable tagline —
one composed deliverable. Stops and recommends a real-time conversation when the
situation genuinely needs one.
async-standup, write-adr, meeting-to-issue, weekly-update — parameterized
templates for a single task.
It's a real tool, not a paywall. The method tools work on their own — no book required. The reference tools answer from the book's already-public summaries and a paraphrased framework layer, always capped and always cited so you can trace any snippet to its chapter. The "get the book" link surfaces about once per session, not on every line — it's a tool, not an ad. No verbatim book prose is bundled (the only data file is data/book.json.br), so what you install is genuinely useful, not a teaser.
Staying current. data/book.json.br ships with a version that tracks the book's edition, so the server can tell you which edition it's based on and re-sync when a new one lands.
Generated output is a template, not the author speaking. The method tools format your input into decision docs, standups, and triage calls. That output is generated guidance to adapt — it is not a personal statement, quote, or endorsement by Ben Balter or Open & Async LLC, and shouldn't be presented as one. Reference-tool snippets are summaries the tool cites back to the book, not verbatim prose.
This package is split-licensed — see LICENSE for the overview:
Code (everything under src/) — MIT.
Data (data/book.json.br) — proprietary; © Open & Async LLC. You may use it only as part of running this software. No redistribution as a standalone dataset, no derivative datasets, no model training. See DATA-LICENSE.md.
The full work — the stories, the voice, the complete argument — lives in the book: open-and-async.com.
The map of Open and Async: every section and chapter with a one-line TL;DR. Use it to find the right chapter for a topic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. With no output schema, the description usefully carries the return-shape burden by stating the result is every section/chapter paired with a one-line TL;DR, though it says nothing about size limits or pagination.
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 compact sentences: the first defines the content, the second the purpose. Zero waste and the identifying information 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?
For a zero-param read tool with annotation coverage and no output schema, the description adequately conveys what comes back and why to call it. Only minor gaps remain, such as scale of the returned outline.
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?
Zero parameters, so per the rubric the baseline is 4. There is nothing further for the description to disambiguate about inputs.
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 resource and its content: the full section/chapter map of the book with one-line TL;DRs. The closing phrase implies its navigation role versus summary tools like get_chapter_summary, but no sibling is named explicitly.
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?
"Use it to find the right chapter for a topic" gives a clear triggering context distinct from get_chapter_summary (which would be the follow-up step). No when-not guidance or named alternative is provided, keeping it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a meeting's purpose or agenda, propose the async equivalent: the artifact that replaces it, where it lives, who decides, and the deadline. Meetings are a point of escalation, not the default.
| Name | Required | Description | Default |
|---|---|---|---|
| agenda | No | Agenda items, if any. | |
| purpose | Yes | Why the meeting exists / what it's meant to accomplish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description usefully signals that the output is a structured proposal (artifact/location/decider/deadline), but adds nothing about cost, rate limits, or whether the proposal is persisted anywhere.
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 zero filler; the operative verb leads and the scoping rationale closes. Nothing is redundant with the title or schema.
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 carries the burden of describing the return value — and it does, listing the four elements of the proposed async equivalent. Slightly short on how the proposal handles an empty/absent agenda, but otherwise complete for this two-parameter advisory 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 description coverage is 100%: both 'purpose' and 'agenda' are documented in the schema, and the description only restates them ('a meeting's purpose or agenda'). No additional format, length, or fallback behavior is provided, so this sits at the 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?
States a specific verb ('propose the async equivalent') and resource ('meeting'), and enumerates the components of the proposal: artifact, location, decision owner, and deadline. It does not, however, distinguish this from the sibling triage_sync_vs_async, which an agent could plausibly confuse with this 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 closing line 'Meetings are a point of escalation, not the default' gives a philosophy of when async conversion is warranted, but there is no explicit when-to-use/when-not guidance and no routing to the sibling tools (e.g., triage_sync_vs_async). Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a decision plus its options into a structured, async-friendly decision record (ADR): context, options with tradeoffs, the decision, and its reversibility. Write the decision down so others can follow it without a meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Background: what forces this decision now. | |
| options | No | Candidate options. Two or three is plenty. | |
| decision | Yes | The decision to be made, in one line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful disclosure of the produced artifact's structure (context, options with tradeoffs, decision, reversibility), which the agent needs since there is no output schema. It stops short of saying whether the draft is persisted or merely returned.
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 a tight second sentence explaining the payoff. No filler, though the enumerated output sections and the rationale sentence slightly overlap.
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 three-parameter, no-output-schema tool, the description substitutes for the missing output schema by describing the ADR's sections. The only real gap is whether the doc is saved or just returned, which the readOnly annotation implies but the description does not state.
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 all three parameters, which sets the baseline at 3. The description reinforces the mapping and adds a hint that each option should carry tradeoffs, but supplies no syntax or format details 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?
States a specific transform (a decision plus its options -> a structured ADR) and enumerates the resulting sections. It is clearly distinguishable from siblings like convert_meeting_to_async or book_outline, though it never names or contrasts a sibling explicitly.
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?
Usage is only implied via 'so others can follow it without a meeting', which gestures at the async theme shared with siblings but gives no explicit when-to-use or when-not-to-use. No alternative tool is named for capturing a decision another way.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a chapter's TL;DR plus its taglines and a link to read the full chapter. Summary only — no body text.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Chapter slug, e.g. 'impact-over-input' (from book_outline). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful context about what is and isn't returned (no body text, includes a link), but discloses nothing about errors, auth, or rate limits.
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, front-loaded with the return payload and ending with the scoping exclusion. Every clause carries information and nothing is padded.
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 tool this is nearly complete, and with no output schema the description helpfully names the return contents (TL;DR, taglines, link). It stops short of describing the return shape or what happens for an unknown slug.
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?
Only one parameter (slug) and schema description coverage is 100%, with the schema itself supplying the format example and origin ('from book_outline'). The description adds no parameter-level meaning, 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?
States a specific verb (Return) and resource (a chapter's summary) and enumerates the payload: TL;DR, taglines, and a read link. The exclusion 'Summary only — no body text' sharpens scope against a full-text fetch, though it doesn't explicitly name a sibling like get_taglines to route the agent.
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?
There is no explicit when-to-use or when-not-to-use statement and no named alternative tool. The phrase 'Summary only — no body text' implicitly signals the intended use case (quick overview rather than full read), which is adequate but requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Role-aware guidance (manager or IC) for a topic, paraphrased from the book's role callouts, with a chapter citation.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Audience: 'manager', 'ic', or 'any' (default). | |
| topic | Yes | The topic you want guidance on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish a safe, read-only, idempotent, closed-corpus read. The description adds important context beyond them: results are paraphrased (not verbatim quotes) and always include a chapter citation, so the output shape and provenance are predictable. It does not cover what happens for an unknown topic or how long the guidance is.
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?
It is a single front-loaded sentence with no filler. The role scoping and the content/provenance claim each carry weight.
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, yet the sentence discloses the essential return characteristics: paraphrased guidance and a chapter citation. For a two-parameter read tool with full annotation coverage, that is nearly complete. The one gap is behavior on out-of-scope topics for a closed-corpus 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%, and the role enum is documented with its 'any' default, so the schema already does the heavy lifting. The description adds only a little: it signals that guidance changes with role. It gives no topic-scoping detail beyond 'the topic you want guidance on.'
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 first sentence names a concrete resource (role-aware guidance about a topic) and states the output form: paraphrased book role callouts plus a chapter citation. This separates it from adjacent retrieval and reference tools, such as search_principles and get_chapter_summary. It does not name a sibling explicitly, however, so the score is 4 rather than 5.
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 implies intended use ('guidance for a topic,' qualified by role), but it never says when to prefer this tool over search_principles, get_chapter_summary, or handle_objection. There are no exclusions or prerequisites, so an agent has to infer where this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the book's shareable taglines and their quote-card URLs. Optionally filter to one chapter.
| Name | Required | Description | Default |
|---|---|---|---|
| chapter | No | Chapter slug to filter by (omit for all). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe, read-only, idempotent, closed-world read, so the safety profile is fully covered. The description adds the return contents (taglines with quote-card URLs), which is useful context, but says nothing about ordering, pagination, or edge cases when a chapter has no taglines.
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, front-loaded with what is returned and followed by the optional filter. Every phrase carries information and 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?
There is no output schema, so the description carries the burden of describing returns, which it does by naming taglines and quote-card URLs. For a one-optional-param read tool this is nearly complete, though it could note behavior when no taglines exist for the filtered chapter.
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 there is a single optional parameter already documented as 'Chapter slug to filter by (omit for all).' The description's 'optionally filter to one chapter' merely restates the schema's optionality without adding syntax or format detail, 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 gives a specific verb ('Return') and resource ('the book's shareable taglines and their quote-card URLs'), which is clear enough to distinguish it from siblings like book_outline or get_chapter_summary. It stops short of explicitly naming or contrasting any sibling, so it is clear but not fully differentiated.
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?
'Optionally filter to one chapter' implies how the tool is used and when the filter applies, but there is no guidance on when to prefer this tool over related sibling tools or any exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a common objection to open/async work ('async is slow', 'remote kills culture') to the book's reframe, with a chapter citation.
| Name | Required | Description | Default |
|---|---|---|---|
| objection | Yes | The skepticism or pushback to address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description adds that the result is a reframe plus a chapter citation. It also implicitly constrains scope to 'common' objections, but doesn't say what happens for an unrecognized or unmapped objection.
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 with the purpose and the return value front-loaded; no filler or repetition of the title.
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 usefully characterizes the return (a reframe with chapter citation), and annotations cover the safety profile. The only gap is the fallback behavior when an objection isn't in the book's set of reframes.
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 already 100% for the single parameter, so baseline is 3, but the description adds real meaning beyond the schema by supplying example objection phrasings ('async is slow', 'remote kills culture') that show the expected input shape.
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 ('Map') and resource ('a common objection to open/async work') and even names the output ('the book's reframe, with a chapter citation'). The two quoted example objections make the intent concrete enough to distinguish it from generic guidance tools like get_guidance or search_principles.
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 signals the triggering context (an objection or pushback to address, with concrete examples) but never states when to prefer a sibling such as get_guidance or search_principles, nor any exclusion for objections the book doesn't cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a structured async-standup prompt a team can adopt in any chat or issue — replaces the daily sync standup with a written, searchable thread that respects every time zone.
| Name | Required | Description | Default |
|---|---|---|---|
| cadence | No | e.g. 'daily', 'twice a week'. Defaults to daily. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds useful context beyond them: the return value is a reusable prompt/template ('a team can adopt in any chat or issue'), not a posted message, and it is time-zone agnostic. It does not discuss side effects, but there are none to disclose.
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 front-loaded sentence with the core action first. The trailing clauses ('searchable thread', 'respects every time zone') lean slightly promotional but still convey the value proposition without padding.
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-required-param, read-only generator with no output schema, the description covers what the tool produces and why it matters. The only real omission is routing guidance against the async-related siblings, which is a minor gap given the low complexity.
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 optional 'cadence' parameter is fully documented in the schema (100% coverage), so the schema does the heavy lifting. The description adds nothing about cadence or its default, which is acceptable at this coverage level — baseline 3.
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: 'Return a structured async-standup prompt' that a team can adopt. That is clearly distinct from siblings like convert_meeting_to_async or draft_decision_doc, though it never explicitly names or contrasts with 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?
Usage is only implied by the framing 'replaces the daily sync standup', which signals the async-standup context. There is no explicit when-to-use, when-not-to-use, or comparison to the closely related siblings (convert_meeting_to_async, triage_sync_vs_async).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a draft status update against the 'work loudly / no surprises' rubric and suggest fixes. Good updates surface blockers early, state outcomes over activity, and link to the work.
| Name | Required | Description | Default |
|---|---|---|---|
| update | Yes | The draft status update to score. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing the evaluation rubric and clarifying that the tool returns suggested fixes, not just a score — meaningful output-shape context given there is 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?
Two sentences: the first front-loads the core action and the rubric, the second supplies the rubric's substance. No filler, nothing repeated from the schema or annotations.
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 one-parameter, read-only scoring tool with no output schema, the description covers what is evaluated and that fixes are suggested, which is what the agent needs to act. It could add a bit about the response format (e.g., score scale), but the remaining gap is minor.
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 a single parameter at 100% schema description coverage, the schema fully documents `update`. The description adds no syntax, length, or format guidance beyond what the schema already says, 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?
States a specific verb (score), resource (draft status update), and the rubric it applies, plus the secondary action of suggesting fixes. No sibling tool overlaps (draft_decision_doc, triage_sync_vs_async, etc.), so the agent can route to it 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 never states when to reach for this tool versus alternatives or any prerequisites (e.g., only after a draft exists). The sentence about what makes a good update describes evaluation criteria, not invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across the book's summary corpus (TL;DRs, key-takeaways, taglines, and reviewed frameworks). Returns short, cited snippets — a snippet view, not full text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5, capped at 10). | |
| query | Yes | What you're looking for. |
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 genuinely useful behavioral context by disclosing what the tool searches over and that results are short, cited snippets rather than full text — a real expectation-setting detail 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 sentences, no filler, and the core scope (what corpus, what output shape) is front-loaded. 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?
With no output schema, the description usefully characterizes the return (short cited snippets) and the corpus searched. It omits ranking/relevance behavior and result ordering, which are minor gaps for a simple two-parameter search 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 description coverage is 100% with only 2 parameters, so the schema already documents 'query' and the 'limit' default/cap. The description adds no syntax, matching behavior, or query-construction guidance, so the baseline 3 is appropriate when structured fields do the work.
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 (keyword search) and resource (the book's summary corpus), enumerates the corpus contents (TL;DRs, key-takeaways, taglines, reviewed frameworks), and explicitly scopes the output as 'a snippet view, not full text'. This distinguishes it from siblings like get_taglines and get_chapter_summary, which return individual artifacts rather than cross-corpus snippets.
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 'snippet view, not full text' clause implicitly signals when to prefer this over a full-text or per-chapter retrieval tool, and the corpus enumeration bounds what can be found. However, no sibling is named and there is no explicit when-not or 'use X instead' routing, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend whether a task should be handled synchronously or asynchronously, using the decision rule from 'meetings are a point of escalation.' Async is the default; sync is the escalation.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task, conversation, or decision to triage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the heuristic that governs the recommendation, which is useful, but says nothing about permissions, latency, or what form the recommendation takes.
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 tight sentences that front-load the action and then the governing rule; every clause carries information and there is 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, single-parameter triage tool with annotations covering the safety profile and full schema coverage, the description is nearly sufficient. The one gap is the absence of any output schema combined with no description of the shape of the recommendation (e.g., which side it lands on and why), though the stated default/escalation rule partly compensates.
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% with a single required parameter, and the description merely restates the same phrasing ('task, conversation, or decision to triage') already present in the schema. This meets the baseline of 3 rather than adding syntax or format detail.
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 (recommend/triage) and resource (sync vs async handling of a task), which is unambiguous and distinct from action-oriented siblings like convert_meeting_to_async. It does not explicitly name a sibling to contrast against, but the purpose is immediately legible.
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 decision rule the tool applies ('Async is the default; sync is the escalation'), but this is output logic rather than invocation guidance. There is no explicit when-to-use, when-not-to-use, or named alternative among the ten siblings, leaving the agent to infer that this is a consult/recommend step rather than an action step.
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.
v1.0.2book_outlineconvert_meeting_to_asyncdraft_decision_docget_chapter_summaryget_guidanceget_taglineshandle_objectionrun_async_standupscore_status_updatesearch_principlestriage_sync_vs_asyncScored across 11 tools
Most tools target distinct outputs: book retrieval tools (book_outline, get_chapter_summary, search_principles, get_taglines, get_guidance, handle_objection) versus async-work generators (draft_decision_doc, score_status_update, run_async_standup). There is mild overlap between triage_sync_vs_async and convert_meeting_to_async, and between search_principles and get_chapter_summary, but descriptions clarify the boundaries.
The set largely follows a verb_noun pattern (draft_decision_doc, convert_meeting_to_async, score_status_update, run_async_standup, triage_sync_vs_async, search_principles, handle_objection, get_guidance, get_taglines, get_chapter_summary). The only deviation is book_outline, which lacks a verb, but overall the convention is predictable.
Eleven tools sit comfortably in the well-scoped 3-15 range, with each tool mapping to a distinct action (generate a doc, score an update, retrieve a slice of book content). No tool appears redundant or filler.
The surface covers both the generative async-workflows and the book's content access (outline, summaries, search, taglines, objections, role guidance), which is solid lifecycle coverage. A gap is that full-text retrieval is deliberately excluded and there is no tool for exploring chapters beyond summaries, though the provided links mitigate this.
Ask what your team decided in meetings, get your standup, and update Jira/Linear-synced tasks.
Project management for AI agents: tasks, docs, decisions and time in one shared team context.
Your second brain: documents, meetings, decisions, tables, agents and connected apps.
AI-native project management for tasks, docs, collaboration, and agents.
