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 well: it discloses data provenance (reads actual tool calls and test output, not agent self-reports), a time window (last 2 hours), and ordering (newest first). It does not cover pagination, limits, or the shape of the session ID 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?

The core capability is front-loaded in the first sentence, followed by the provenance note and the usage hint. The first sentence is long and list-heavy, but every clause adds distinct information about returned fields rather than restating the name.

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 appropriately explains the returned data (fields, statuses, test standing) and the data source. It is nearly complete for a zero-parameter read tool, lacking only edge-case coverage such as what an empty result means or how the session ID should be consumed.

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 takes zero parameters (empty object schema), so there is no parameter meaning to convey. Per the rubric this is the baseline 4 for a parameterless tool.

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

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

The description names a specific resource (what coding agents on this computer are doing) with concrete output fields (project, working/waiting/finished/stopped status, latest step, test standing) and a scope (last 2 hours, newest first). It is clear but does not explicitly differentiate itself from overlapping siblings like recap or today, which likely also summarize agent activity.

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

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

It gives explicit usage triggers ("what are my agents doing?") and points to the downstream use case of finding a session ID for other tools. There is no "when-not-to-use" or direct naming of an alternative sibling, which keeps 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.

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 well by itemizing what the brief surfaces (requests/files/tokens, cut-off or failing work, regressions, suspicious changes). It doesn't explicitly state it's a read-only report or note any limits, but for a read-only aggregation tool the content disclosure is the substantive behavioral trait.

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 core sentence is front-loaded and dense but well-organized via a colon-led list of the four report sections. The trailing two sentences largely duplicate the schema's parameter descriptions, which is minor waste.

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?

No output schema exists, so the description must convey return content — and it enumerates the brief's sections, time windows, and default scope thoroughly. An agent has everything needed to call it and understand what comes back.

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

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

Schema description coverage is 100% and both parameters are fully documented in the schema, including the `period` enum semantics. The description restates the same `period`/`project` defaults rather than adding syntax or edge-case meaning beyond the schema, so the baseline of 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 clear resource (a per-project brief/recap) and enumerates its four content categories (what agents did, what's unfinished, what's failing, what's worth a check), so the agent knows exactly what it returns. However, it does not distinguish itself from close siblings like `recap`, `today`, or `report_card`, which sound like overlapping reports.

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 'morning brief or weekly recap' framing and the `period`/`project` defaults imply when it's useful (daily/weekly review, all projects by default), but there is no explicit when-to-use guidance or reference to the alternative siblings (`recap`, `today`, `test_status`). 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.

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

With no annotations, the description carries the full burden and does reasonably well: it enumerates the checks performed (tests run after last change, pass/fail and causes, test edits used to force passes, lingering failures, risky actions) and the shape of the answer ("Looks done" versus what to fix first). It does not state that the tool is read-only/side-effect free, nor any cost, auth or timing traits, which is the remaining 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?

Front-loads the imperative call-to-action, then explains the checks and the output in three compact sentences. Slightly chatty with phrases like "the way a reviewer would," but every sentence is doing work.

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-optional-param, no-annotation, no-output-schema tool, the description covers what is inspected and what the response means well enough to invoke it correctly. It omits how it relates to the other audit/status tools, which is the only real completeness gap.

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

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

Schema description coverage is 100% and both params are optional with clear "only if dotpals picks the wrong session/project" semantics already in the schema. The description itself adds no parameter 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 and resource: it checks the agent's own session in the current project, described concretely as a reviewer-style audit of tests, failures, test tampering and risky moves. It is clear what the tool does, but it does not distinguish itself from siblings like test_status and risky_steps, whose territory it partly claims.

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 an explicit trigger: "Call this before you tell the user your work is done." That is a clear when-to-use signal. It stops short of naming alternatives (e.g. test_status, ready_to_merge, risky_steps) or saying when not to call it, so the routing guidance is incomplete.

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 the output format ('Markdown, ready to paste'), the exact content sections, and the default behavior ('the newest session in this project'). It stops short of stating whether the operation is read-only or what permissions are needed, but for a note-generation tool the disclosure is strong.

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 dense but front-loads the core purpose and then lists the components of the note in a compact sequence. Every clause contributes information, though the long extended sentence could be structured with clearer delimiters for easier scanning.

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 note-generation tool with no output schema and no annotations, the description is nearly sufficient: it explains the output format, the content, and the default session. It could be more complete by noting how the session ID is obtained or by distinguishing the tool from adjacent recap/status tools, but the essential information is present.

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

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

Schema description coverage is 100%, and the schema already explains both parameters, including the project folder default and the session ID-from-agents_now default. The description repeats the session default ('the newest session in this project') but adds no new syntax, format, or constraint beyond what the schema provides.

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

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

The description states a specific deliverable: a hand-off note that lets another agent or session resume, and enumerates the exact contents (original ask, last request, evidence, files, test failures, plan, risks, last message). It does not, however, differentiate itself from siblings like recap or check_my_work.

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 scenario is implied — 'so another agent (or a new session) can pick up where a session left off' — which gives an agent enough context to understand the intended use case. But there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as recap or check_my_work.

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 well: it discloses the exact review criteria, notable edge cases ("not because the tests were changed"), and expected output form (each check ✓ or ✗). It still does not state that the operation is read-only/side-effect free or what is returned when no session exists, so a gap remains.

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 the core question, then the check list, then parameter guidance — an efficient ordering. Slightly dense with a parenthetical aside ("force pushes, .env changes, recursive deletes…") but 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?

No output schema exists, and the description compensates by describing the ✓/✗ check-by-check return structure, which is what an agent needs to interpret results. No annotations means safety/non-mutation behavior is unaddressed, keeping this just short of fully complete.

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

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

Schema description coverage is 100%, so all three parameters are already documented with defaults and resolution rules. The description restates the `branch` use case and the newest-session default but adds no syntax or precedence detail beyond what the schema provides, matching the 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 question it answers ("Is an agent session's work ready to merge?") and enumerates the concrete checks performed (tests after last change, no leftover failures, no risky operations, tested commit). It is clearly a readiness-verification tool, but it never distinguishes itself from close siblings like check_my_work or test_status, leaving the agent to infer the boundary.

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 clear invocation context: pass `branch` to query a git branch ("is feat/login ready?"), otherwise default to the newest session in the project. It does not, however, say when to prefer this over check_my_work or test_status, so alternative selection is only implicit.

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 disclose meaningful behavior: the default window is the last 24 hours for a project versus the full history for a session, and it flags warnings such as tests that passed only after being edited. It does not explicitly state the operation is read-only, but the nature of a 'recap' makes that 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?

It is a single long sentence densely packed with nested parentheticals and em-dash asides, which makes it hard to parse on first read. Front-loading is decent ('What agents actually did'), and every clause carries content, but the run-on structure undercuts readability.

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 no-output-schema, no-annotation, three-optional-parameter read tool, the description sufficiently covers what content is returned and the scope defaults. It stops short of fully spelling out how warnings or session defaults interact, but nothing critical to calling it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and their defaults, making 3 the baseline. The description only echoes the project/session scoping and adds the 24-hour default window, adding little beyond the schema.

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

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

The description states a specific resource (agent activity) and enumerates exactly what the recap contains: what each agent was asked, one-sentence summaries, warnings, test-failure reasons, and changed files. It is clear what the tool produces, but it never names or contrasts any sibling (today, agents_now, check_my_work), so an agent must infer the distinction itself.

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

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

It gives scoping context: 'For a project (default: this one, the last 24 hours) or one session (all of it).' That implies when each parameter applies, but there is no explicit when-to-use/when-not guidance and no routing to the alternatives among the siblings, so usage is only implied.

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 discloses meaningful behavior: the data source ('Read from what the agents did, not what they said') and the return format ('A Markdown table'). It omits cost/permission/limits detail, but for a reporting tool those are lower-stakes than the output-shape disclosure it does provide.

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

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

The lead sentence front-loads what the tool is, but the middle collapses a long metric list into one winding clause ('how many that changed code were tested after the last change and passed...'), which is dense and partly redundant. The closing `project` tip is worth its space; the enumeration is only borderline.

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 report tool with full schema coverage and no output schema, the description explains both what the report contains and its Markdown return format, which is what an agent needs. Nothing critical is missing, though it could state that it is a safe, non-mutating read.

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 both `since` and `project` are already documented with formats and defaults. The description's 'Pass `project` for one project' and default-period note merely restate schema content, adding no syntax or edge-case meaning beyond it.

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 concrete artifact ('a report card comparing the agents side by side over a period') and enumerates the metrics it contains, so the resource and scope are unmistakable. It does not, however, explicitly distinguish itself from near-neighbors like 'recap', 'today' or 'brief', which a reader must infer from the metric list.

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

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

It states the default window ('last 7 days, every project') and how to narrow scope ('Pass `project` for one project'), which implies typical usage. There is no explicit when-to-use-this-vs-alternatives guidance, so the agent gets context but not routing rules against the sibling reporting tools.

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 behavioral burden and does disclose useful traits beyond the schema: the detection categories and the scoping defaults (project = this one, last 24 hours; session = whole session). It still says nothing about whether it's read-only, result volume, or performance, which keeps it below a 5.

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 long enumeration in the first sentence is dense but each item earns its place by defining the tool's detection scope, and the usage conditions follow immediately. It is slightly run-on but front-loaded and waste-free.

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 compensates by stating what each entry contains ("when, which agent and the command") and by covering scope and time defaults. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a default time window ("the last 24 hours") that the schema's `since` parameter does not state, and clarifies session scope means "all of it." That is genuine added meaning over 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?

It names a specific concept (risky agent actions) and enumerates the concrete verbs/events that qualify: force pushes, recursive deletes, dropped tables, sudo, .env edits, repeated failures. An agent can immediately tell this is a risk-reporting tool and distinguish it from siblings like test_status or ready_to_merge.

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

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

It gives explicit triggering questions: "did my agents do anything dangerous?" or "before trusting their work." That is clear when-to-use guidance, but it names no sibling alternative and gives no when-not-to-use 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?

With no annotations, the description carries the full behavioral burden, and it does meaningful work: it discloses what is measured (only agent-run tests), what the output conveys (pass/fail, counts, last-failure reason, timestamp) and a non-obvious derived trait (stale when code changed after the last run, or never tested). It omits whether the call is read-only, its cost, or error behavior, so it is solid but not exhaustive.

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 front-loads with a rhetorical question ('Is the code really tested?') that delays the actual operation, then packs return-value, scoping, and staleness detail into a single dense run-on sentence. The content mostly earns its place, but the structure is cluttered rather than cleanly segmented.

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 must describe the return payload, and it does: pass/fail, counts, why the last run failed, when it ran, and stale/never-tested state. Combined with complete schema coverage for both parameters, an agent has enough to call the tool and interpret results, with minor gaps only around read-only/error behavior.

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 both 'project' and 'session' are already documented in the schema, including their defaults. The description only restates the project-default scoping and the session default ('newest session in this project'), adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

The description states a specific resource and outcome: the test status of code within an agent session (passed/failed, counts, failure reason, timing, staleness). It is clearly a status-inspection tool distinct from siblings like ready_to_merge or check_my_work, though it never names an alternative to route against. Purpose is clear but not sharply differentiated from 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?

Implicit guidance is present — 'Only tests an agent ran count' and 'Default: the newest session in this project' tell the agent when the tool is meaningful and which session it targets. However, there is no explicit statement of when to use this versus siblings (e.g., agents_now for sessions, check_my_work for review), so usage is only implied.

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 surprisingly well: it discloses the exact contents surfaced, including subtle signals like tests that passed only after being changed and the reasons tests failed. It does not state read-only safety explicitly or any auth/rate behavior, but the output-shape disclosure is strong.

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 lead clause 'What the agents did today' is well front-loaded, and every fragment is informative, but the whole thing is one sprawling sentence with nested parentheticals that is harder to parse than it needs to be.

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 correctly takes on the job of explaining return contents in detail, and it also states the default scope. For a single-optional-param read tool it is close to complete, missing only tool-selection routing against its siblings.

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 single 'project' parameter is already fully documented. The description's 'For a project (default: this one)' merely restates the schema default, adding no syntax or matching nuance beyond it. 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 clearly conveys the resource being produced: a per-agent daily activity digest covering request counts, files changed, test runs, per-request detail, warnings, and test failures. It is specific about content and scope, though it never names the closely related siblings (recap, handoff_note) to help an agent distinguish the right reporting 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?

It offers a use-case hook ('for a standup or an end-of-day note'), which implies when to reach for it. However, there are no explicit when-not conditions and no named alternatives to route against the several other summary/status siblings, leaving selection to inference.

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