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

With no annotations provided, the description fully discloses behavioral traits: immediate registration, deferred agent spawn, the codex trusted-directory addition, and the language prepend behavior. It also details workspace behavior, covering mutation side effects and prerequisites without contradiction.

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 well-organized, front-loading the core action and then using bullet-style paragraphs for optional parameters. It is slightly long but every sentence adds relevant context; no filler or 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 7-parameter tool with zero schema coverage, the description covers the most behaviorally significant parameters but leaves 'tags' and 'agent' completely unexplained. The presence of an output schema mitigates the need to describe return values, but parameter coverage is incomplete for an agent to use all options 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 0%, so the description must compensate. It explains the 'language' and 'workspace' parameters in detail, including default behavior and formatting. However, it does not explain 'name', 'path', 'tags', 'agent', or 'description', leaving their semantics to inference or schema defaults.

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 ('Append') and resource ('registry.yaml'), making the core action unambiguous. It also clarifies that this is an addition operation (not update/removal) by describing the registry append and the deferred agent spawn, which separates it from siblings like update_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 states the operation's effect ('Registration is immediate... not spawned until next dispatch'), which tells an agent when it is appropriate to use this tool. It does not explicitly name alternatives or exclusion conditions, but the side-effect explanation implies the timing and scope of use.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the internal mechanism (sets cancel flag, stops before next fallback attempt, terminates the subprocess) and the resulting status ('cancelled'). This goes beyond a bare 'cancels a dispatch' and gives the agent real expectations, though it does not describe the return payload or failure modes.

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 front-loaded sentences with zero filler: the purpose and edge case come first, followed by mechanism details. Every sentence earns its place and there is no 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 one-parameter cancel operation with an output schema present (so return values need not be explained), the description covers purpose, the idempotent edge case, the cancellation mechanism, and the resulting status. The only gap is explicit parameter documentation, which is minor for such a self-evident parameter.

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 0%, so the description must compensate. It does not explicitly define dispatch_id, but the name is self-evident given the tool purpose and it is referenced implicitly throughout. The description does not add format, source, or validation hints beyond what the schema shows, which is an acceptable but not strong level of compensation for a single obvious 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?

States a specific verb+resource ('Abort a running background dispatch') and adds the edge-case behavior 'No-op if already finished'. This clearly distinguishes it from siblings like dispatch (which starts), check_dispatch (which checks status), and dispatch_history (which lists history) 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?

The purpose statement implies when to use it (when you need to stop a running dispatch), and the 'no-op if already finished' gives some boundary context. However, it never explicitly names alternatives or states when NOT to use it (e.g., 'use check_dispatch first to see if it is still running'), leaving routing partially to inference.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses both possible states of the poll (running result with elapsed_sec vs. full result once exited) and references the shape of the final output. It does not address edge cases like unknown dispatch_id, but the core runtime behavior is clearly explained.

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 short blocks with no fluff: the action is front-loaded, and the return behavior is stated precisely. Every sentence adds information needed to call the tool correctly.

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 polling tool with an output schema available, this description is complete. It tells the agent when to use it, what input it needs, what a running response looks like, and what the final response references. No critical decision or invocation information 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 0%, so the description must add meaning to dispatch_id. The context that this is a background dispatch started by dispatch_background gives the parameter implied meaning, but the description does not explicitly say where to obtain the ID or what format to expect. The semantics are inferable, not fully stated.

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 ('Poll') and resource ('a background dispatch started by dispatch_background'), immediately distinguishing this from plain dispatch or dispatch_history tools. It also contrasts its output with dispatch_query's return shape, further clarifying what unique role this tool plays.

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 when to use the tool: after a background dispatch has been started by dispatch_background. It does not explicitly list exclusions or contrast with direct alternatives, but the context is unambiguous enough that an agent can select it appropriately.

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

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

With no annotations provided, the description carries the full burden and excels: it reveals side effects (permission_mode resolved value saved to registry), non-blocking return behavior with <100ms latency, subprocess spawning, session continuation side effects, and workspace fan-out behavior. This is far beyond the minimum.

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 front-loaded with the core purpose and non-blocking caveat, then uses clear bolded parameter labels and structured lists. Though long, every sentence adds meaningful detail for a complex async dispatch tool, with 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?

For a 9-parameter tool with no annotations settlement, the description covers the most complex aspects and return behavior thoroughly, including workspace fan-out and registry side effects. The lack of any explanation for `resume` and `timeout` leaves a meaningful gap given the absence of schema descriptions.

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?

Despite 0% schema description coverage, the description adds deep semantics for six parameters (name, agent, fallback, permission_mode, session_id, language) with precise behavior and examples. However, it fails to explain `resume` and `timeout`, leaving two parameters undocumented, so it does not fully compensate for the schema gap.

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: 'Dispatch a prompt to a project or workspace.' It clearly distinguishes this from siblings by emphasizing NON-BLOCKING execution and immediate return of a dispatch_id, which is unique among the listed project tools.

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 conveys when to use the tool: for non-blocking prompt dispatch, with rich context about behavior such as workspace fan-out and one-shot subprocess spawning. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of the top score.

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

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

With no annotations present, the description carries the full burden. It discloses that the tool reads `~/.central-mcp/logs/<project>/dispatch.jsonl`, filters to terminal states, and merges terminal events with their matching `start` so each record includes both prompt and outcome. It stops short of describing error/edge-case behavior, but the core operational behavior is transparent.

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 core action, followed by a useful mechanic and an alternative. 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 two-parameter read tool with an output schema, the description covers the purpose, the file source, the merging behavior, and the main alternative. The only omissions are edge cases like a missing log file or an invalid `n`, which are minor given the tool's simplicity and output schema.

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 property descriptions are absent (0% coverage), so the description is the only semantic source. It maps `n` to 'last N' and `name` to 'one project', and the log path `~/.central-mcp/logs/<project>/...` clarifies what `name` refers to. It doesn't spell out parameter limits or formatting, but it gives enough meaning beyond the bare 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?

Opens with a specific verb and resource: 'Return the last N completed/failed/cancelled dispatches for one project.' It also signals the read-only log source and explicitly distinguishes itself from the cross-project sibling orchestration_history, so an agent can tell it apart from similar dispatch tools in 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?

The first sentence establishes the intended use case (per-project dispatch history), and the final sentence gives an explicit alternative: 'For a cross-project portfolio summary, use orchestration_history instead.' This is clear when-to-use and when-not-to-use guidance, leaving little to inference.

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

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

No annotations are provided, so the description carries the burden. It discloses that the file holds user-authored rules, that empty content means no preferences, and that the response includes available_sections and examples. This is good but doesn't explicitly state the operation is read-only (though 'Return' implies it) or mention any error conditions. Still, it provides solid behavioral context.

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 well-structured: first sentence states the core action, second paragraph explains the file semantics and response fields, third sentence gives the usage context. Every sentence adds value without fluff, and the key info 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?

Given the tool has no parameters and an output schema exists (though not shown), the description covers the essential semantics: file location, content interpretation, response fields, and the relationship to update_user_preferences. It's complete for a simple getter, though it doesn't elaborate on all output schema details, which is acceptable.

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 covered. The baseline for 0 params is 4, and the description doesn't need to add parameter details. It does implicitly describe the output fields, but that's separate.

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 returns the content of a specific file (~/.central-mcp/user.md) and lists the available preference sections. It also names the sibling it complements (update_user_preferences), making its purpose unambiguous and distinguishing it from other tools.

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 instructs to call this tool before update_user_preferences to merge new rules with existing ones, and mentions when it's useful (when the user asks what's configurable). This gives clear when-to-use guidance and implies a workflow.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses shared-state storage location, strict-greater-than semantics for since, the behavior for still-running rows, the meaning of the failed alias, and the exclusion of cancelled dispatches. It omits potential operational details like pagination or rate limits, but for a listing tool this is adequate.

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 uses bolded parameter names and a purposeful example. Every sentence contributes either parameter semantics or an operational workflow, with 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 two-parameter tool with no annotations and an output schema present, the description covers purpose, state sharing, filter semantics, and a complete polling recipe. Nothing needed to invoke the tool correctly appears to be 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 provides zero description coverage and only bare string/null fields, but the description fully compensates. It enumerates the allowed status values, defines the failed alias semantically, and specifies the ISO 8601 format plus strict-greater-than behavior for since.

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: 'List active and recently completed background dispatches,' and adds a distinguishing scoping fact about shared state across central-mcp processes. However, it does not explicitly differentiate itself from sibling tools like dispatch_history or check_dispatch.

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 a clear, concrete usage pattern for the resident-agent failure watch: call list_dispatches(status='failed', since=<watermark>) and advance the watermark based on finished_at. It does not state when not to use the tool or point to alternatives, so it stops short of a full when/when-not guide.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'list' by thoroughly explaining the workspace selection logic, including fallback precedence and special values. This is significant behavioral nuance. It does not explicitly state that the operation is read-only, but the nature of 'listing' and the absence of any side-effect language imply safety. The description is transparent about the parameter behavior, which is the main variable in this 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 efficiently structured: a one-line purpose statement followed by a bulleted list for the parameter. Each bullet is necessary and adds value, particularly the default resolution order. It avoids redundancy and front-loads the core action. The length is justified by the complexity of the parameter semantics. No unnecessary words are present.

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 that an output schema exists, return values are already covered. The description fully addresses the only parameter and its behaviors, leaving no ambiguity for an agent. It also accounts for the orchestrator's expectation by explaining the default workspace resolution, which is critical context for this tool. There are no missing pieces for an agent to correctly invoke it.

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 provides minimal information: a nullable string parameter named 'workspace' with a default of null and no descriptions. The description compensates fully by explaining three distinct cases: null (current workspace with detailed fallback order), '__all__'/'*' (all workspaces), and any other string (specific workspace). This transforms a generic parameter into a well-documented, actionable one. Schema description coverage is 0%, so this high-quality compensation is essential and well-executed.

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 clear, specific statement: 'List registered projects.' This identifies the verb (list) and resource (registered projects), which unambiguously distinguishes it from sibling tools like list_project_sessions. The additional explanation of workspace behavior reinforces the tool's scope without muddling its core purpose.

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 detailed guidance on the workspace parameter, including default resolution order and special values like '__all__'. However, it does not explicitly address when to use this tool versus alternatives such as list_project_sessions or portfolio_digest. The context implies usage through the purpose, but there is no explicit 'use this when...' or 'instead of...' guidance, leaving selection partly to inference.

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

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

With no annotations, the description carries full responsibility and delivers richly. It discloses the storage retrieval mechanism (filesystem scan vs subprocess), sorting order, limit behavior, the shape of returned session dicts (including preview as a best-effort snippet), and the pinned field behavior. This goes well beyond what an input schema could 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 appropriately sized, with the core purpose stated first, then mechanism, then return fields and usage guidance. Each sentence adds value, though some detail (e.g., the exact backend names) could be trimmed without losing essential meaning. It is well-structured and 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 listing tool with an output schema, the description covers everything needed to call it correctly: purpose, scoping, limit, return field semantics, and how to use the result with dispatch. It does not mention error cases or permissions, but these are not critical for a read-only list operation and are absent from annotations as well. The description is 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?

Schema coverage is 0%, so the description must explain parameters. It explicitly explains limit's effect ('at most limit sessions') but does not directly define the required 'name' parameter beyond the implicit 'for one project'. Since name is required and not self-explanatory (could be a project ID or path), the description could be clearer. It partially compensates but leaves a gap.

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 lists resumable agent conversation sessions for a project, with a specific verb (list) and resource (sessions). It differentiates from siblings by focusing on resumable sessions scoped to a project's cwd, distinguishing it from dispatch (which resumes sessions) and list_projects. The purpose is unmistakable and non-tautological.

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 explains when to use the returned id with dispatch, and mentions the resume-latest mechanism, giving context on how this tool fits into the workflow. However, it does not explicitly name alternatives or state conditions for when to use this tool instead of others like dispatch_history or project_status. It provides usage context but not explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses data sources (memory, timeline, rotated files), that live timeline.jsonl is always included, and that include_archives delivers compact aggregates, making the read-only scope and behavior 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?

Starts with a one-sentence summary, then uses compact bullets for output fields and explicit optional-parameter explanations. It is detailed but 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 annotations and a schema with no descriptions, the tool description covers all major output sections, the nuanced optional parameters, archive behavior, and default contexts. An output schema exists, so return-value details don't need to be repeated here.

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 0% parameter descriptions, so the description compensates well: it explains workspace filtering, window_minutes semantics and the all-time default, and include_archives behavior. It only implies rather than explicitly defines n as the milestone count, which is a small gap.

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 it is a portfolio-wide snapshot containing in-flight dispatches, recent milestones, and per-project stats, and explicitly frames it as answering 'how is everything going?' without per-project polling. This is clear, but it doesn't distinguish itself from similarly named siblings like portfolio_digest.

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?

Gives a clear when-to-use signal: the tool answers broad status questions without per-project polling. It doesn't name alternatives or say when not to use it, so the guidance is strong but not exhaustive.

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

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

With no annotations provided, the description carries the full behavioral burden and delivers: 'Nothing is stored; every call recomputes from source', rendering is fixed server-side, and warnings must report stuck dispatches 'as unfinished, never as live'. It even warns against the likely agent mistake of re-summarizing the output. This is rich behavioral disclosure well beyond the bare 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?

The description is well-structured and front-loaded: the critical paste-verbatim instruction leads, followed by usage context, section breakdown, parameter semantics, and behavioral notes. It is on the longer side and contains some explanatory flourish (the token_usage comparison clause), but for a tool with four parameters and four output sections, nearly 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 the tool's complexity — 4 params, structured multi-section output, cron integration, no annotations — the description is complete. It covers purpose, output handling, data source, section semantics, parameter meanings, and delegation boundaries, and even anticipates the likely misuse of re-summarizing. The presence of an output schema means it needn't enumerate return fields, and it still sketches the sections.

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 0%, so the description must compensate — and it does for all four parameters. `workspace` is given full semantics (None/name/"__all__" with a pointer to `list_projects`), `since_hours` maps to concrete values (24 daily, 168 weekly), `quiet_days` is defined as the idle threshold for the uncommitted-work warning, and `include_quota` is linked to the quota section. Every parameter gains meaning beyond its type/default.

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 line states a specific verb+resource: 'Pre-rendered portfolio summary for push delivery' with the critical instruction to paste `digest_markdown` verbatim. It differentiates from siblings explicitly ('unlike `orchestration_history` — work that never went through central-mcp ... is counted') and names the analogous `token_usage.summary_markdown`. An agent can immediately tell what this is and how it differs from the dispatch/project-management 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 gives explicit when-to-use context: the resident-agent digest loop (cron forwarding portfolio state each morning) or a terminal orchestrator handling daily/weekly recap requests. It also states what belongs elsewhere: 'Scheduling and alert watermarks belong to the caller (`list_dispatches` with `status="failed"` + `since` covers the alert half)'. This is clear routing with a named alternative and a condition.

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

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

No annotations are provided, so the description carries the full burden. It does the job well: it reveals the side effect (appends to a durable ledger that gets skimmed if over-filled), explains the persistence value (why abandoning an approach matters because it leaves no git trace), and clarifies how next_step is consumed by a briefing. It doesn't claim to be read-only or destructive explicitly, but its behavioral character is clearly communicated. Minor gap: it doesn't disclose whether the note can be edited or deleted later, but that's not critical given no annotations to contradict.

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 well-structured with clear sections, bolded lead-ins, and front-loaded purpose. It is longer than the average tool description, but every section earns its place given the tool's unusual depth of meaning (the is-true vs. was-meant distinction, the abandonment case). The 'Arguments' section is compact. One slight deduction: the 'When to call it' paragraph could be tightened, and the parenthetical examples in the abandonment guidance add a small amount of 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 5 parameters, 0% schema coverage, and an output schema present, the description is nearly complete. It explains every parameter's semantics, the when/when-not usage, and the return-value expectation (next_step is offered back for confirmation). It doesn't describe the exact return format beyond that, but an output schema exists to capture that. The only minor gap is the absence of explicit mention of the result of calling this tool (e.g., does it return the saved note?), which the output schema presumably handles.

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 0%, so the description must carry the full weight of parameter documentation — and it does. Every parameter gets meaningful explanation beyond its type: note is what it contains, name vs. cwd are contrasted with a decision rule ('Use this when you know where you are but not what it is registered as'), next_step is specified as an instruction to a future reader (not a note to yourself), and source explains the honesty requirement of the agent/user distinction. The 0% coverage makes a 5 fully justified — the description compensates completely.

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 ('Record what was done / what was left / what comes next for a project') and immediately establishes its role as the durable memory for return briefings. It distinguishes itself sharply from sibling project_pulse by drawing the is-true vs. was-meant distinction, which is precisely what separates it from every other project-related tool in the 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?

The 'When to call it' section is exemplary: it specifies when to call (end of real work, when the plan changes, especially on abandoning an approach), covers the most-common-but-easily-forgotten case (a session opened directly in the repo), and gives explicit negative guidance (do not call for trivia, because an over-full ledger gets skimmed). This is the strongest usage guidance possible — it names the conditions, not just the context.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses that the tool performs no storage ('Nothing is stored: every call recomputes from source'), identifies the only network call (PRs via gh), and explains the `stale` field for crashed servers. It also instructs on handling missing sections with `reason`, preventing misinterpretation. This is comprehensive behavioral disclosure.

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 well-structured with a clear opening, usage guidance, and a section-by-section breakdown. It uses bullet points for readability and includes practical tips (e.g., include_pr=False for sweeps). While lengthy, it is information-dense and front-loaded with the core purpose, so every sentence 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 the tool's complexity (multiple data sections, network call, degradation behavior), the description covers all critical aspects: what data each section provides, how to interpret stale entries, and the note about synthesizing output. Since an output schema exists, the return structure is likely covered there, so the description needn't repeat it. The description is complete for an agent to use 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 description coverage is 0%, so the description must explain parameters, and it does. It clarifies `commits` and `history` as counts for the last N items, explains `include_pr` with a performance tip, and the `name` parameter is self-evident. This adds value beyond the schema's bare types.

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 opening line 'What actually happened in a project, where it stands, what's live' clearly defines the tool's function. It distinguishes itself from sibling tools like dispatch_history and orchestration_history by explicitly stating it reads the repository directly, covering direct commits and manual edits. This specificity ensures an agent understands its unique value.

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 explicit triggers: 'when the user returns to a project after time away, asks "what's the state of X?", or before dispatching into a project you haven't touched this session.' It also contrasts with alternative tools, clarifying when this tool is preferable because it captures work outside central-mcp. This is exemplary usage guidance.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly says 'metadata only,' enumerates the returned fields (working directory, adapter, description, tags), and states that it does not execute the agent. It does not mention not-found behavior or side effects, but as a read-only registry lookup this is a minor gap.

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 only two sentences, with the primary action front-loaded and the clarifying metadata-only warning placed immediately after. Every sentence adds useful 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 simple one-parameter tool with an output schema, the description covers the essential call semantics and the critical caveat that no agent dispatch occurs. The only notable gap is referencing 'dispatch_query' while the sibling list contains 'dispatch,' a minor naming inconsistency that could briefly confuse an agent.

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 0%, and the description only implicitly defines the name parameter as the project identifier by saying 'one project.' It does not state whether name must be an exact registered key or describe valid formats. Still, with a single required string parameter and clear context, an agent can infer the basic meaning.

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: 'Return the registry entry for one project.' It further clarifies that this is metadata only, distinguishing it from dispatch tools and removing ambiguity about what the 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?

The description gives clear context that project_status is for metadata lookup, not execution, and explicitly directs work to dispatch_query for actually hitting the agent. It does not enumerate all sibling alternatives like list_projects, but the single-project lookup scope is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the operation is destructive by using 'Remove', but it doesn't state whether the removal is permanent, what happens to associated projects/sessions, or whether confirmation is needed. This is minimal disclosure for a mutation 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 a single, front-loaded sentence with no filler or repetition. It earns its place by stating exactly what the tool does, though it could have added a bit more useful context without becoming bloated.

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 operation, the description is minimally viable: an agent can infer to call remove_project(name='some-project') and an output schema is present to describe return values. However, it lacks critical context about side effects, irreversibility, and validation behavior, which an agent would benefit from when deciding to invoke a destructive 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 0%, and the description does not explain the meaning or format of the required 'name' parameter beyond the obvious implication that it identifies the project. Since there is only one parameter and the schema provides no description, the description should have compensated by stating how 'name' maps to registry.yaml entries.

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 ('Remove') and a specific resource ('a project from registry.yaml'), which clearly distinguishes this from siblings like add_project, update_project, and reorder_projects. It stops short of a 5 because it doesn't explicitly contrast with closely related sibling operations, but the action is 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?

There is no guidance about when to use remove_project versus alternatives, no mention of prerequisites, and no note about effects on related data such as sessions or dispatch history. For a destructive operation, an agent is left to infer when this tool should be selected.

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

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

With no annotations provided, the description carries full responsibility and delivers richly: it discloses error conditions (unknown names, duplicates, missing in strict mode), persistence to `registry.yaml`, and the limitation that running tmux/zellij panes do not live-reorder. This goes well beyond a generic mutation warning.

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 front-loaded with the core purpose and every subsequent sentence adds crucial operational detail: partial reorder safety, strict mode, error conditions, persistence, and session behavior. No redundant or filler content is present.

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 in parameters but behaviorally nuanced; the description covers ordering semantics, validation failures, persistence, and live-session caveats. An output schema exists, so return-value documentation is unnecessary, and nothing needed for correct invocation or expectation-setting 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 0%, so the description must compensate for both parameters. It does: `order` is explained as a sequence of project names that move to the front, and `strict` is described as requiring every project exactly once. This adds meaning far beyond the raw schema types.

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 plus resource: 'Reorder the registry's `projects` list.' It uniquely identifies this tool among siblings, none of which offer reorder functionality. The scope is immediately clear and not a restatement of the name.

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 explains the default partial-reorder behavior and when to use `strict=True`, which gives an agent actionable decision criteria. It does not explicitly name alternatives or say when not to use the tool, but no sibling is a direct alternative, so the context is sufficient.

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

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

No annotations are provided, so the description carries the full burden — and it delivers. It discloses the 60s in-process caching, the timezone-windowed reads, the ORCHESTRATOR special bucketing key for untied tokens, the mutual-exclusion precedence (project wins over workspace), and the quota cache behavior. For a read/aggregation tool this is exceptionally transparent.

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?

Front-loaded with purpose and sibling differentiation, then a clean param-by-param section, then the return shape. It is long, but the length is earned — 6 parameters and a rich nested return format warrant it. The only cost is the verbose inline-commented return dict, which could arguably be trimmed without losing meaning.

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 output schema in the description documents every return field including the conditional quota variants per provider (claude/codex/gemini), the ORCHESTRATOR key behavior, and the summary_markdown format. All parameters, defaults, cache semantics, and the windowing behavior are covered. Only error cases are unmentioned, which is minor for a read 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 0%, and the description fully compensates. It supplies the valid values for period (today|week|month|all) that the schema omits, defines group_by keys (project|agent|source), states the project/workspace mutual-exclusion rule, and explains defaults and behavioral effects of include_quota and include_summary. Every one of the 6 params gains meaning beyond the bare 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?

Opens with a specific verb+resource: 'Portfolio-wide token-usage aggregation (SQL over tokens.db) plus a normalized per-agent subscription quota snapshot.' It also explicitly separates itself from the sibling orchestration_history, explaining this tool covers token monitoring while that covers event/dispatch history. An agent can immediately distinguish it from all 18 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?

Clearly justifies separation from orchestration_history ('so token monitoring can evolve independently of event/dispatch history') and gives usage direction per parameter: disable include_summary 'to save tokens when you only need the raw structured data' and opt out of include_quota 'for fast bulk polling'. It stops short of a formal when-to-use/when-not-to-use contrast with siblings, but the context is strong.

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

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

Despite no annotations, the description discloses key side effects: permanent modification, omitted-args-stays-unchanged, atomic validation (registry untouched on invalid input), and detailed future-dispatch behavior for language and session_id. It also states permission_mode allowed values and agent name validation.

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 long but well organized: purpose first, then parameter-specific behaviors in structured sections. Every sentence adds information; 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?

Given no annotations, 8 parameters, and 0% schema coverage, this description is remarkably complete. It covers complex semantics, validation, atomicity, and side effects, and an output schema exists for return values.

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 0% schema coverage, the description compensates admirably: it explains the semantics of language and session_id including empty-string vs null, defines permission_mode values, and clarifies that agent/fallback are validated. Some parameters like tags and description are only implied by 'edit its description/tags', but their schema types cover the basics.

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?

Description opens with 'Update an existing project's fields' – a specific verb and resource – and enumerates the mutable fields. This clearly distinguishes it from add_project, remove_project, and update_user_preferences.

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 lists specific use cases (changing primary agent, editing description/tags, setting fallback chain, etc.). However, it never explicitly says when not to use it or which sibling to prefer for new projects vs. reads.

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

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

With no annotations provided, the description carries the full disclosure burden. It does well by stating the target file, that changes persist across sessions, and crucially that content 'replaces its existing content; other sections are untouched.' It does not mention permissions, failure behavior, or response format, but the output schema covers return values and the destructive semantics are clearly disclosed.

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 long but organized into purpose, usage, parameter blocks, and a merge tip. Every sentence carries information, examples are compact, and the key persistence/replacement semantics are 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 two-parameter mutation tool with an output schema and no annotations, this is complete: it covers when to call, what each parameter means, the replacement behavior, and the merge workflow. The only minor omission is authorization/error handling, which is not essential 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 0%, so the description must fully document both parameters. It does: section is enumerated with exact allowed headings and meaning, and content is explained as full replacement text with formatting recommendations and two concrete examples. This adds far more meaning than the bare string 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 opens with a specific verb and resource: 'Persist a user preference to ~/.central-mcp/user.md.' It goes on to list concrete categories (reporting style, language, routing hints, process rules) and explicitly contrasts itself with one-off instructions, distinguishing it from sibling tools like get_user_preferences.

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 exact trigger conditions ('Call this when the user expresses a PERSISTENT preference') and an explicit exclusion ('NOT for one-off turn instructions; those need no persistence'). It also tells the agent to call get_user_preferences() first for merging, which is precise operational guidance.

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