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

With no annotations, the description carries the full disclosure burden, and it does add real signal: results come back as exact quotes with source citations, and the tool should report missing evidence rather than fabricate. However, it says nothing about scope limits, permissions, or retrieval boundaries.

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, front-loaded with the core action and output form, followed by filters and the missing-evidence rule. Nothing is padded, though the compressed 'app/topic filters' phrasing is slightly terse.

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 or annotations exist, so the description is the sole source of behavioral facts, and it does describe the return shape (quotes + citations) and the empty-result behavior. It is nearly complete for a four-parameter Q&A tool, lacking only scope/limit details.

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: it names the day format (YYYY-MM-DD) and identifies app/topic filters, covering all three optional parameters plus the required question. It stops short of explaining filter interaction or default behavior.

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 (answer) and resource (natural-language question over captured memory) and specifies the output form: exact quotes plus source citations. It does not differentiate itself from the sibling search_screen_memory, which an agent might otherwise confuse this with.

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 implies usage (ask a question about your memory) but gives no explicit when-to-use vs. when-not, and never names or contrasts with alternatives like search_screen_memory or read_observation. The 'say evidence is missing' line is an answer-behavior instruction rather than tool-selection 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, the description carries the full behavioral burden. 'Read' implies a non-mutating operation, and pagination is hinted at, but there is no disclosure of permissions, result volume, rate limits, or what 'summaries and source evidence' actually contain. The pagination hint even references a token (next_offset) that does not appear in the schema.

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

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

Two tight sentences with the core purpose front-loaded and no filler. It loses a point because the second sentence conveys inaccurate information about pagination rather than earning 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?

No annotations, no output schema, and 0% schema coverage, so the description must do all the work for a paginated, day-scoped retrieval tool. It leaves parameter formats, pagination mechanics, and result shape unspecified, which is inadequate for this complexity.

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

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

Schema description coverage is 0% for all three parameters. The description only obliquely implies the required 'day' input and mentions pagination, but never explains the format of 'day', the meaning of limit, or how offset works, and the pagination token it names is not a real 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 and resource: 'Read chronological app/window sessions, with summaries and source evidence.' An agent knows it retrieves session data for a day, but the description never distinguishes this from close siblings like read_app_day, read_day_flow, or recent_activity, so it earns a clear-but-undifferentiated 4.

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 only usage guidance is 'Use next_offset for the next page', which is not even a parameter of this tool (the schema exposes limit/offset). No indication of when to prefer this over read_app_day or read_day_flow, and 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, the description carries the full burden. 'List' implies a safe read-only operation and the description discloses what data is returned, but it omits scope (all vs filtered), pagination, sorting, auth, and rate limits, making it minimally 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?

One front-loaded sentence with the verb first, and each listed attribute earns its place by telling the agent what comes back. No redundant phrasing or 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 zero-parameter list tool with no output schema, the description identifies the returned entities and their key fields. It leaves the shape of 'available date ranges' and pagination behavior unspecified, but it is largely complete for correct invocation and interpretation.

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 no parameters, so the semantic baseline is 4. The description does not need to explain parameters and adds no parameter-level detail, which is appropriate for a zero-argument list call.

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 verb 'List' and resource 'captured applications', and enumerates returned attributes (bundle IDs, observation counts, date ranges). It does not name a sibling or clarify when to use it over tools like list_topics or read_app_day, so it falls 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?

No when-to-use guidance, prerequisites, or alternatives are given. Siblings such as read_app_day and search_screen_memory are not mentioned, leaving the agent to infer when list_apps is the right choice.

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 behavioral burden, yet it only hints at output contents ('counts and grouping notice'). It says nothing about what 'suggested' implies (heuristic grouping? freshness?), whether the listing is scoped or permission-bound, or how the optional day influences results.

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

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

One front-loaded sentence with no filler, and the key scope phrase ('across apps') comes early. It could have spent a few of its remaining words on the day parameter or exclusion guidance.

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 annotations, no output schema, and an undocumented parameter, the description is too thin for an agent to invoke this confidently. The overview of the return shape is a start, but the day semantics and the distinction from sibling topic tools are 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% and the single 'day' parameter is never mentioned in the description. The agent cannot tell whether day filters, defaults to today, or accepts a format like ISO date versus a relative label, despite the empty-string 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?

States a specific verb and resource: 'List suggested project/topic groups across apps,' plus the payload shape (counts, grouping notice). It is distinguishable from read_topic (singular detail fetch) and list_apps, though it never names those siblings 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 at all. Nothing tells the agent whether to call this before read_topic, how it relates to list_apps, or what 'suggested' means in contrast to a raw topic list.

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 burden. It does disclose the return shape as a 'complete' (i.e., non-truncated) Markdown journal, which hints there is no pagination, but says nothing about missing days, permissions, or error behavior for an invalid app_id.

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 zero filler, and the resource description is front-loaded ahead of the parameter note. Slightly terse given the gaps elsewhere, but nothing is wasted.

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

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

With an output schema present, return values need not be explained, but with no annotations and 0% parameter coverage the description still leaves app_id semantics and sibling routing unaddressed. It is thin for a tool in a crowded read-only namespace.

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 usefully specifies the day format (YYYY-MM-DD), but leaves app_id entirely undefined beyond its self-evident name.

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 ('Read') and a well-scoped resource ('app-specific daily Markdown journal'), which separates it from read_day_flow and day_sessions by its app dimension. It does not, however, name or contrast with any sibling explicitly, so differentiation is inferred rather than stated.

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 and no alternatives mentioned, despite several overlapping read siblings (read_observation, read_review, read_day_flow, day_sessions). Usage is only implied by the word 'app-specific'.

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 usefully discloses the output shape (a Markdown journal grouped into chronological sessions), which is real behavioral context. However, it says nothing about permissions, pagination, or limits for what could be a large multi-app aggregate read.

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

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

Two sentences, zero filler, and the scoping/grouping behavior is front-loaded ahead of the parameter note. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained. Scope, grouping, and parameter format are covered, making the definition sufficient to call the tool. Minor gaps remain around access requirements and any size limits for an all-app aggregate.

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 by specifying the required format 'day is YYYY-MM-DD' — the single most important semantic for the one required parameter. It does not address timezone or invalid-date handling, keeping it just short of a 5.

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: reading a continuous daily Markdown journal, with the distinguishing scope 'across all apps, grouped into chronological sessions'. This implicitly sets it apart from read_app_day (single app) and day_sessions, but it never names a sibling, so differentiation is left to inference.

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

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

Usage is only implied: 'across all apps' signals this is the whole-day, cross-app view rather than a per-app one. There is no explicit when-to-use statement, no when-not-to-use, and no sibling named as the alternative, so the agent must infer the routing decision.

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 load. It does disclose the key behavioral trait relevant here — read-only, no link opening, no side effects — which is genuinely useful. It is silent on permissions, error behavior when the observation_id is missing, and any rate limits, so it is adequate but not rich.

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

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

Two short sentences, front-loaded with what is read and the returned payload, followed by the boundary clause. Zero filler, 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?

For a one-parameter read tool this is nearly complete: the return content (OCR/accessibility text plus source URL) is described even without an output schema, and the no-side-effects behavior is stated. The remaining gap is that the agent gets no guidance on sourcing a valid observation_id.

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 in the schema. The description partially compensates by framing the id as belonging to a 'cited observation,' hinting at its origin, but gives no format, source, or lookup guidance. Marginal added value over 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?

States a specific verb+resource ('Read a cited observation') and even names the payload ('original Accessibility/OCR text and source URL'), so the agent knows exactly what comes back. It does not visibly differentiate itself from sibling read tools like read_review or read_topic, but the resource scope 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?

'A cited observation's' implies the usage context: follow a citation/observation_id to its source. The closing clause 'Does not open links or take actions' sets a useful boundary against browsers/action tools. However, there is no explicit when-to-use-vs-alternative routing against the many sibling read_* 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 present, the description carries the full burden, and it delivers unusually valuable interpretive warnings: counts are observations not time worked, projects are suggested groups, and no completed actions are inferred. These prevent the agent from over-reading the output, though permission needs and return structure are not addressed.

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 constraint, and every sentence carries distinct information (scope, range limit, two interpretation caveats). Slightly dense phrasing, but 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 a two-parameter read tool with no annotations and no output schema, the description covers the range constraint and output interpretation but says nothing about the shape of the returned review/draft or how it relates to sibling read tools. Adequate but with clear gaps.

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% (only bare 'Start'/'End' titles), so the description must compensate, and it does: it defines an inclusive YYYY-MM-DD format and an upper bound of 31 days. That said, all the added meaning sits on the pair jointly rather than distinguishing start from end semantics.

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 and resource ('Read an evidence-linked review and editable status draft') and clarifies what the payload is, which separates it from pure-data siblings like read_observation and read_day_flow. It stops short of explicitly naming an alternative sibling or stating when this review view is preferred over raw reads.

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 range constraint ('inclusive YYYY-MM-DD range, up to 31 days') gives usable invocation bounds, so usage is reasonably implied. However, nothing says when to choose this review tool versus read_observation, read_app_day, or read_day_flow, and 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, the description carries the full burden. It usefully discloses ordering (chronological), cross-app scope, and the pagination mechanism via next_offset in the response, but says nothing about permissions, result size, or behavior of the day filter.

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

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

One sentence, front-loaded with purpose and scope, with the prerequisite and pagination note appended compactly. 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 4-parameter tool with no annotations, no output schema, and 0% schema description coverage, one sentence is thin. Purpose and pagination are covered, but the day parameter and any return-shape detail beyond next_offset are 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 compensate. It clarifies that key must be an exact value obtained from list_topics and implies pagination covers offset/limit, but leaves the day parameter entirely unexplained.

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 ('Read chronological evidence across apps') plus the narrow scope (an exact topic key), and ties the input source to the list_topics sibling. It is clear what the tool returns, though it does not contrast itself against other read tools like read_observation or read_app_day.

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?

'for an exact topic key returned by list_topics' gives a clear precondition and prerequisite step, telling the agent to call list_topics first. It stops short of stating when another sibling read tool would be preferred 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?

With no annotations, the description carries the full burden, and it does disclose the pagination mechanism (cursor-style backward paging via before_id), which is real behavioral information. However it omits the default limit behavior, what the day/app_id filters do to results, ordering guarantees, and any auth or rate-limit 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?

Two short sentences, zero waste, with the core action front-loaded and the paging hint immediately after. Nothing is padded or 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?

No annotations, no output schema, and four parameters at 0% schema coverage, three of which are unexplained anywhere. For a paged read tool this leaves major gaps (filter semantics, default result size, ordering) that the description should have closed.

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 document all four parameters, yet it only explains before_id. The meaning and format of day, limit (default 20), and app_id are left entirely to inference, so the majority of parameters remain 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?

States a specific verb ('Read') and resource ('latest observations with source text'), and implies a reverse-chronological feed distinct from the single-item siblings like read_observation and read_day_flow. It does not explicitly name a sibling alternative, 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?

Usage is only implied (get a recent-activity feed) and the description never says when to prefer this over read_observation, day_sessions, or search_screen_memory. It does give actionable paging guidance ('pass the last id as before_id to page backward'), which is a genuine usage instruction, preventing a 2.

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 one genuinely useful behavioral trait: matching is conjunctive ('All query words must match'). It omits other behavior an agent needs, such as result ordering, the default limit of 20, or whether matching is case-sensitive.

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, zero filler, and the core action plus the matching rule are front-loaded before the optional filters. Nothing would be lost by trimming it.

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 4-parameter search tool with no annotations and no output schema, the definition is serviceable but thin: it never explains the result shape or ordering, and 'limit' is undocumented. An agent can call it, but cannot predict 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 0%, so the description must compensate. It covers three of four params – query (all words must match), app_id (bundle ID filter), and day (YYYY-MM-DD format) – but leaves 'limit' completely unexplained, so the 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 ('Search') and resource ('captured text and summaries') and adds a discriminating scope note ('All query words must match') that separates it from the semantic sibling ask_memory. It is clear what it does, though the resource label 'captured text and summaries' is slightly abstract.

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 use this tool versus alternatives such as ask_memory or read_observation, nor when-not to use it. It only notes that filters are optional, which is parameter guidance rather than usage guidance.

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