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 discloses bucket granularity, that empty buckets are legitimate data points indicating gaps, and the defaulting behavior of end. It omits auth requirements, ordering, and rate limits, but the output schema covers the return shape.

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 short, front-loaded sentences with no filler; the core semantics and required-parameter note come first. The phrasing 'so capture gaps are honest' is slightly slack but not wasteful.

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?

An output schema exists, so return values need not be restated, and the description adds useful interpretation of empty buckets. However, for a tool with no annotations, no sibling differentiation, and one unexplained parameter, the definition is only minimally sufficient for correct selection and 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 description coverage is 0%, so the description must compensate. It documents start's accepted formats (epoch or YYYY-MM-DD), its required status, and that end defaults to now. bucket_hours is only hinted at via '(or custom)' and never explained, leaving one of three parameters effectively undocumented.

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 concrete output: hourly (or custom) event-count buckets for spotting capture gaps. An agent can tell this is a coverage/aggregation tool rather than a raw event search. It stops short of naming how it differs from siblings like search_events_tool or app_time_summary_tool, which also deal with activity over time.

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

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

It explains how to interpret results (empty bucket = no events that hour, often capture off), but never says when to reach for this tool instead of search_events_tool, list_sessions_tool, or app_time_summary_tool. No prerequisites or exclusions are given.

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, but it does disclose meaningful behavioral traits: the values are approximate and gaps are capped at 5 minutes. It omits any auth/permission requirements or how the capped gaps affect interpretation, keeping it at a minimum-viable 3.

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

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

Two short sentences, front-loaded with the purpose followed by parameter format notes; no filler. Slightly terse on the parameter side, but appropriately sized.

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?

An output schema exists, so return values need no explanation, and the approximation caveat is covered. Still missing is guidance on when to use it versus siblings and any permission/scope context for a 2-param analytic tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does document the accepted formats (epoch or YYYY-MM-DD) for both params. However, it doesn't clarify that end is optional/empty by default or how the window boundaries are treated, leaving a partial 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 a specific computation (per-app foreground time) and the method (event gaps in a window), which is enough for an agent to distinguish it from search_events or activity_coverage_tool. It does not explicitly name or contrast a sibling, so it stops short of a 5.

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

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

The description never says when to prefer this over alternatives like activity_coverage_tool or search_events, nor does it state any prerequisite conditions. Usage is only implied by the resource computed.

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 behavioral burden for a destructive operation. It never states that deletion is irreversible, whether confirmation is expected, whether multiple substring matches are all deleted or just one, or what happens if nothing matches — all critical for an agent deciding to invoke a delete.

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 short lines with zero filler: what it does, when to use it, and how the argument is interpreted. Information is front-loaded and each 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?

The output schema covers return values and the trigger/matching guidance is solid. The main remaining gap is the absence of any disclosure about irreversibility or multi-match behavior, which matters for a delete tool with no annotations.

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% and the single parameter has no description, so the description must compensate — and it does, explaining the matching mode ('Matches by substring') and what to pass ('the key phrase or exact text'). This meaningfully exceeds the bare 'note_text' string in the schema.

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

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

States a specific verb and resource ('Delete a note or memory fact') and clarifies scope with the qualifier 'the user wants forgotten'. This implicitly separates it from save_note_tool and recall_memory_tool, though it never names a sibling to make the contrast explicit.

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 concrete trigger phrases ('forget', 'delete', 'remove', 'don't remember that') that map directly to when this tool should fire. It gives clear usage context but no explicit when-not conditions or named alternatives for ambiguous cases (e.g., recall vs delete).

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 disclosure burden. It reveals that results come with freshness annotations and that the operation is a read ('Get'), but says nothing about behavior on an unknown/invalid label, permission requirements, or result size limits. Adequate but with visible gaps.

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 short sentences, front-loaded with the core action and each subsequent sentence adding a distinct, non-redundant instruction (sequencing, parameter sourcing). 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?

An output schema exists, so return values need not be described. For a simple single-parameter read tool, the description covers purpose, when-to-use, sequencing, and parameter provenance — everything an agent needs 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 description coverage is 0% for the single 'label' parameter, so the description must compensate — and it does by telling the agent exactly where the value comes from ('exactly as returned by recall_memory_tool'). It stops short of format/case rules, but adds real meaning beyond 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?

States a specific verb (get/fetch) and resource (all facts stored in a named memory cluster), and implicitly contrasts with recall_memory_tool by positioning itself as the 'full content' retrieval step. An agent can distinguish it from the many search/list siblings without opening any schema.

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

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

Explicitly says to use it after recall_memory_tool to expand a specific topic, naming the sibling and the sequencing condition. It lacks an explicit 'when-not' (e.g., what to do if you don't have a label), but the usage context is clear rather than 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?

No annotations are provided, so the description carries the full burden. It does disclose a meaningful constraint (searches only 'trusted' roots), but says nothing about whether results are capped by default, how they are ordered, or that this is a read-only operation.

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

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

A single tight sentence with the key scoping constraint front-loaded and no wasted words. Brevity here costs clarity elsewhere, but the sentence itself is well-formed.

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?

An output schema exists so return values need no explanation, but the two optional parameters that control result volume and search scope are left entirely undefined, and there is no guidance on tool selection among many search_* 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 0% for three parameters. The description explains 'name' as a filename or substring, but 'limit' (default 15) and 'under' (path scope, presumably) are completely undocumented in both schema and description.

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

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

States a specific verb (Search) and resource (files by filename or substring) and scopes it to 'trusted workspace roots'. Clear enough to act on, but it does not distinguish itself from sibling tools like list_workspace_roots_tool or search_bounded_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?

No indication of when to prefer this over list_workspace_roots_tool (which presumably enumerates roots) or the other search_* siblings. The agent must infer that this is a filename lookup rather than a content search.

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 meaningfully disclose behavior: the return is redacted screen text, the image file path is deliberately omitted, and screenshots follow an adaptive TTL with a cap. It does not cover auth requirements or what happens when neither identifier resolves.

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?

Four short sentences, front-loaded with the identifier mechanism followed by return-content caveats and the TTL note. No filler, though the TTL sentence is somewhat tangential to the core invocation decision.

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?

An output schema exists, so return-shape explanation is not required, and the description adds useful return-content and TTL context. It remains incomplete for a 2-param, no-annotation, no-required-param tool because it never addresses the ambiguous empty-default case or failure 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 0%, so the description must compensate; it does name both parameters and their meaning (filename string, unix timestamp). However it omits that both are optional with empty/zero defaults and says nothing about precedence or format expectations for the timestamp.

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 (Fetch), resource (one screenshot) and the identifier options (filename or unix timestamp). The word 'one' implicitly distinguishes it from the sibling list_screenshots_tool, but no sibling is named explicitly.

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

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

No when-to-use guidance, no when-not-to-use, and no alternative tools named. The only implied usage is 'you have a filename or timestamp', with no indication of which identifier takes precedence when both are supplied.

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. It does disclose a genuinely useful behavior beyond the schema: results may be OCR-backed stubs, and image_available=false means the JPEG expired while an OCR preview may survive. It says nothing about permissions, pagination, ordering, or what the default limit=30 implies.

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

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

Two tight sentences, with the core action front-loaded and the data-quality caveat second. Nothing is wasted, though the second sentence partly restates return-value semantics that the output schema presumably already encodes.

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?

An output schema exists, so return values need not be explained in the description, yet the image_available note duplicates that role. The real gap is parameters: 0% schema coverage with no start/end format or limit behavior described, and no annotations to lean on. Adequate for a simple list tool, but incomplete 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 description coverage is 0% and the description only partially compensates: 'in a time window' implies start/end are time bounds but gives no format (ISO timestamp, epoch, date?). The limit parameter and its default of 30 are never mentioned. Two of three parameters gain meaning, one gains none, and the format ambiguity remains.

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 screenshots') with an explicit scope modifier ('in a time window'), and the parenthetical '(or OCR-backed stubs)' clarifies what the results actually are. It is clearly distinct from the singular get_screenshot_tool, though it never names that sibling explicitly.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as get_screenshot_tool or search_events_tool. The time-window phrasing hints at the use case but the agent must infer everything else.

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. It usefully discloses that results are chronological and deduplicated, which the schema cannot convey. However it is silent on pagination behavior despite having limit/offset parameters, and says nothing about permissions or result size.

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 short lines with zero filler, and the most decision-relevant information (what it returns, when to prefer it) is front-loaded ahead of the parameter format note.

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?

An output schema exists, so return values need not be explained. The remaining gap is pagination semantics for limit/offset in a list tool that will plausibly truncate results, which the description never addresses.

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 does add real value for start/end by giving accepted formats (epoch or YYYY-MM-DD), which the bare string schema lacks. But limit and offset are entirely undocumented in both places, leaving half the parameters ambiguous.

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 ('session list') plus distinguishing characteristics (chronological, deduped, time-windowed) in a single clause. It explicitly names search_sessions_tool as the sibling it differs from, so an agent can route without opening either schema.

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

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

Explicitly says to prefer this over search_sessions_tool 'for day/week timelines,' naming both the alternative and the condition that selects this tool. Nothing about tool selection is left 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. It usefully discloses that results are deduplicated and returned with counts, and that scope is a time window, which is genuine behavioral context. It omits any mention of pagination behavior, result ordering, or failure/empty conditions.

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

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

Two tight sentences with the core purpose and the count/dedup behavior front-loaded; the pattern example earns its place. Slightly telegraphic phrasing ('active_url / OCR') costs a little clarity.

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?

An output schema exists, so return-format explanation is not required, and the description still adds dedup/count info. However, with zero annotation and zero schema-description coverage, the omission of limit semantics and start/end formatting leaves a real gap for a 4-parameter tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains 'pattern' as a substring filter with an example and implies start/end bound the time window, but 'limit' is never addressed and start/end format is left unspecified.

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 ('Distinct URLs seen in active_url / OCR') and scopes it to a time window, which is clear and concrete. It does not name or contrast itself with any sibling tool (e.g. search_events, list_screenshots), so an agent must infer the boundary on its own.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named. The window/dedup framing implies a discovery use case but nothing routes the agent between this and the many search/list siblings.

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 implicitly communicates a read-only listing, but never states that it has no side effects, whether results are permission-scoped, or what the roots represent. For a trivial zero-parameter read, the output schema absorbs the return-value burden, so the gap is modest.

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

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

A single front-loaded sentence with no filler; every word contributes to identifying the tool's scope.

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

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

With zero parameters and an output schema present, the description does not need to explain return values. It is nearly sufficient for such a simple tool, lacking only an explicit statement of when to invoke it relative to find_files_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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies.

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

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

States a specific verb ('List') and resource ('folders Clippy may search'), and ties the resource to the sibling find_files_tool, so an agent can tell it apart from other list_* tools. Slightly informal phrasing ('folders Clippy may search') keeps it from being maximally precise, but the intent 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?

The mention of find_files_tool implies this is the discovery step for that tool's search scope, but it never says when to call this versus other listing tools or that it should precede find_files_tool. Usage is inferable rather than stated.

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 exist, so the description carries the burden, and it delivers non-obvious behavior: default freshness filtering ('clusters below min_freshness are hidden') and the include_stale override. It does not address auth, rate limits, or what a 'cluster' is, but the output schema covers returns.

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 short sentences, front-loaded with the primary behavior and each carrying distinct information. 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 3-param, dual-mode retrieval tool with an output schema handling return values, the description covers modes, filtering, and overrides adequately. The main gap is no differentiation from sibling retrieval tools like fetch_cluster_tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does: query triggers semantic recall, min_freshness sets the hiding threshold, and include_stale overrides the filter. All three parameters gain meaning beyond the bare schema titles.

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 long-term memory clusters') with scope ('ranked by freshness score') and a second mode ('semantic recall'). Clear enough to distinguish from search_* siblings, but never names or contrasts a sibling such as fetch_cluster_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?

Explicitly tells the agent when to switch modes: 'Pass query to run semantic recall instead of listing.' This gives a real decision rule. It stops short of when-not guidance or routing to sibling retrieval 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?

No annotations, so the description carries full behavioral burden. It usefully discloses that secrets/passwords/API keys are not stored and that only the user's message (not the reply) is captured, which are non-obvious filtering behaviors. However, it says nothing about persistence scope, deduplication, or how the stored fact is surfaced later.

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?

Five short lines, each front-loaded with the actionable point: purpose, trigger, argument rule, exclusions, and safety filter. No filler and nothing redundant.

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

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

An output schema exists so return values need no explanation, and the description covers the call trigger, the argument, and the exclusions. It is complete enough to invoke correctly; only post-store behavior (dedupe, retrieval path) is left implicit.

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% and the single parameter is only titled 'User Message'. The description compensates by clarifying 'Pass only the user's message, not your reply', which resolves the main ambiguity about what belongs in that field.

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: 'Store durable facts from the user's own words.' It also narrows scope via the skip list (activity questions, file search, one-off tasks), which implicitly separates it from the search_* siblings. It stops short of naming a specific sibling tool the way the strongest definitions do.

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 after the user tells you something about themselves, their preferences, relationships, plans...') and explicit exclusions ('Skip for activity questions, file search, and one-off tasks'). It even specifies what to pass, leaving nothing 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 full burden. It does disclose the semantics and caution level of each operation, including the restricted 'override', which implies mutation/overwrite behavior. However, it omits persistence guarantees, permissions, and what happens to existing values on overwrite.

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 purpose, then one tightly scoped line per operation with zero filler. Every sentence earns its place by mapping an op value to its intended use.

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?

An output schema exists, so return-format details are appropriately omitted, and the tricky op-selection logic that drives correct invocation is well covered. The remaining gap is the semantics of the 'field' and 'value' parameters, which are left to the caller's guess.

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 no enums are defined in the schema, so the description must compensate. It effectively documents the four valid 'op' values and the role of 'items', but leaves 'field' (what fields are valid?) and 'value' entirely unexplained, so coverage of the 4 params is only partial.

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 ('Save a personal fact about the user'), which clearly identifies its domain as identity/personal facts. It does not explicitly contrast itself with near siblings such as save_note_tool or remember_turn_tool, so an agent must infer the distinction from the word 'personal fact'.

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

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

Provides explicit conditional guidance per operation: 'set' for scalars, 'add_items' for lists, 'remove_items' to remove, and notably 'override' only when the user explicitly corrects a fact. That conditional restriction is a genuine when-to-use rule. It stops short of naming alternative tools or stating when NOT to use this tool at all.

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 disclosure burden. It adds that the note is 'free-form' (arbitrary text accepted) and persists for later recall via the 'remembered' framing, but says nothing about durability, scope, or permissions. For a simple single-field write, this is minimal but not misleading.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though its brevity is part of the reason sibling differentiation is absent.

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?

An output schema exists, so return values need not be explained, and there is only one required param. Still, the description omits any differentiation from the four sibling save/remember tools and any privacy or scope context for stored notes.

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% — the single 'note' parameter has no description in the schema. The description partially compensates by indicating the value is a free-form note or reminder, but adds no format, length, or content constraints. With only one simple param, baseline is not fully met but the gap is small.

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

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

The description states a clear verb ('Save') and resource ('note or reminder') and clarifies the content is free-form. It does not, however, differentiate itself from closely related siblings like save_identity_tool or remember_turn_tool, so an agent must infer the boundary on its own.

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 phrase 'the user wants remembered' implies a trigger condition (explicit user intent to persist something), which is useful. But there is no explicit when-to-use guidance, no conditions for choosing this over remember_turn_tool or save_identity_tool, and no stated 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, so the description carries the burden. It usefully discloses deterministic date interpretation (no LLM guessing) and that start/end accept multiple formats, but says nothing about permissions, result volume caps, or ordering behavior beyond pagination. An output schema exists, so return shape is covered elsewhere.

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 tight sentences with no filler, and the core purpose plus the differentiator are front-loaded in the first line. Dense but readable; each sentence carries distinct information.

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

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

With an output schema present, return values need not be described, and five of six parameters are meaningfully covered. The only real gap is what 'question' should contain and whether start/end defaults (empty strings) mean unbounded search.

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 mostly does: start/end formats (epoch or YYYY-MM-DD, local), allowed table values ('events'/'sessions'), and the role of limit/offset for pagination. It leaves the required 'question' parameter unexplained, assuming it is the keyword query.

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 ('keyword search') with a distinguishing scope qualifier ('explicit time bounds, no LLM date guessing') and names the two searchable tables. It implicitly separates itself from search_sessions_tool/search_events_tool via the table parameter, though it never names those siblings directly.

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

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

'Use when you know the calendar window and need pagination via limit/offset' gives a clear positive trigger, and the 'no LLM date guessing' clause implies the alternative for fuzzy-date cases. It stops short of an explicit when-not or naming the sibling tool to use instead.

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 exist, so the description carries the full load. It does disclose return shape ('raw event rows with screen/OCR data') and the empty-result behavior that triggers the fallback, which is genuinely useful. However it says nothing about auth requirements, pagination, result limits, or cost of a broad query for what is likely an expensive scan.

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 purpose sentence followed by a targeted enumeration and two routing rules; no filler. The content-type list is long but each item maps to a distinct search target, so it earns its space, though it could be tightened into fewer lines.

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?

An output schema exists, so return values need no explanation, and the description still adds the useful fact that rows contain raw screen/OCR data. Routing, fallback, and scope are all covered; the only real omission is parameter-level query guidance.

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

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

The single 'question' parameter has 0% schema description coverage, so the description must compensate. The content-type list and natural-language framing ('If the result says...') imply the parameter is a free-text question rather than a keyword or timestamp filter, which is real guidance, but it never states the query format, timestamp syntax, or expected phrasing explicitly.

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 (search) and resource (individual events in the activity database), then enumerates the concrete content types it covers (messages, OCR text, URLs, clipboard, app usage). It actively distinguishes itself from siblings by naming search_sessions_tool and search_bounded_tool, so an agent can route without opening any schema.

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 explicit when-to-use content, a named fallback ('If the result says the info isn't there, call search_sessions_tool next'), and a named preference case ('For exact date ranges prefer search_bounded_tool'). This is the full when/when-not/alternatives triad.

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 key behavior: results are paragraph-level summaries rather than granular events, and an empty result should trigger a follow-up call to search_events_tool. It does not mention auth, rate limits, or result limits/pagination, so a small 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-loads what the tool does, then lists use cases and exclusions in compact lines with no filler. Every sentence adds routing or expectation-setting value.

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?

An output schema exists, so return values need not be explained, yet the description still conveys the semantic nature of results. Combined with explicit sibling routing and fallback behavior, an agent has everything needed to invoke this correctly.

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

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

The single 'question' parameter has 0% schema description coverage, so the description must compensate. The examples of question types ('what-did-I-work-on', project topics, task recaps) give indirect guidance on how to phrase the input, but no explicit statement about the expected format or length, so compensation is partial.

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 ('Search session summaries in the activity database') and immediately distinguishes the scope from siblings by noting it returns paragraph summaries, not granular event detail. An agent can tell it apart from search_events_tool without opening either schema.

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

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

Explicitly enumerates when to use it (broad time windows, daily/weekly overviews, recap questions), when not to (exact date ranges → list_sessions_tool or search_bounded_tool), and gives a concrete fallback path if results are empty (search_events_tool). Nothing is left to inference.

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