Pryzm Memory

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the full-content return and the 20-id cap. It does not say what happens with unknown ids, which keeps it from 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?

Two sentences, zero filler, with the retrieval semantics front-loaded and the usage trigger following. Everything 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 with no output schema, the description covers what is returned and when to call it. Only edge cases (invalid/duplicate ids, result ordering) are left unstated.

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 undocumented in the schema, so the description must compensate. It does add the key constraint ('up to 20 ids'), but says nothing about id format, ordering of results, or behavior for missing ids.

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 (returns full content) and resource (saved memories by id), plus the scope limit of 20 ids. This clearly distinguishes it from memory_search, which returns excerpts.

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 names the trigger ('after memory_search when an excerpt is truncated') and the intent ('read only the memories that are relevant'). The routing from discovery to retrieval is unambiguous.

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?

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description still adds real behavior beyond them: results are sorted by importance and the limit is capped at 30, a constraint absent from 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?

Three sentences, each earning its place: what it returns, the limit constraint, and the usage trigger. Front-loaded with the return semantics before the constraint and the when-to-use hint.

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, idempotent retrieval tool with annotations covering its safety profile and no output schema, the description tells the agent what comes back and how much. The only gap is the expected form of the `project` argument.

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 carries the burden. It explains `limit` well (caps results, max 30) but says nothing about the format or expectations of the required `project` identifier, leaving half the parameters 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?

Specific verb+resource with scope ('for one project') and an enumeration of what is returned (decisions, preferences, to-dos, context). An agent can distinguish it from memory_search or memory_list by the project scoping, though the description 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?

'Useful before working on a project the user has mentioned' gives a clear triggering context. It stops short of advising when NOT to use it or naming the alternative tools for other retrieval modes, so it is strong context without 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered by structured data. The description adds the ordering guarantee ('newest first') and a result cap ('max 50'), which is genuine behavioral context, but it says nothing about pagination, whether the cap truncates silently, or what an empty result means.

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

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

Two sentences, front-loaded with the primary action and then the two parameter behaviors. No filler, nothing repeated from the schema, and every clause carries information an agent needs.

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

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

For a simple read-only list tool with two optional parameters and no output schema, the description covers ordering, filtering, and the limit cap. The remaining gaps (default limit value, pagination behavior, what a memory record contains) are minor and partly inferable, but not all are addressed.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does: it explains that limit caps results and adds the non-obvious maximum of 50, and that project scopes to a single project. It omits the default limit of 15 and the empty-string default for project, so it doesn't fully compensate.

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 ('Lists the user's most recently saved memories') plus the ordering scope ('newest first'). It doesn't name or position itself against siblings like memory_search or memory_timeline, so an agent must infer the distinction, but the purpose itself 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 phrase 'optionally for one project' implies the filtering use case, but there is no explicit when-to-use guidance, no statement of when memory_search or memory_timeline would be preferable, and no exclusion criteria. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's own additions are modest: 'deterministic' largely restates idempotentHint, and the only genuinely new disclosure is that it returns both a structured object and a short text version. No auth, rate-limit, or scope caveats beyond what annotations supply.

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 what it returns and scoped by what is included; the usage hint comes last. Every sentence adds something except the minor 'read-only' restatement of annotations, which is not enough to penalize.

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 parameters and no output schema, the description adequately covers the return shape (structured object plus short text) and the safety profile is handled by annotations. Complete enough to invoke correctly, though it does not say how large the summary is or whether it can be empty for new users.

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, so the schema carries no semantic burden and there is nothing for the description to disambiguate. Baseline is 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?

States a specific verb and resource ('Returns a compact summary of what the user has saved about themselves') and enumerates the contents (preferences, facts, working style, projects, to-dos). It is clearly distinguishable from raw-retrieval siblings like memory_get or memory_search, though it never names an alternative to route against.

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

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

Gives a concrete when-to-use context: 'Useful before writing something for the user, to follow their stated style.' That is a real trigger rather than implied usage, but it offers no exclusions and does not point to any of the ~20 sibling memory/plan tools when this one is the wrong 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?

Annotations already declare a safe read-only, idempotent, closed-world profile, so the bar is lower, yet the description still adds rich behavior: the returned fields (id, project, type, date, excerpt), a hard cap of 20 on `limit`, the `etat`/`faits` versioning semantics, and explicit handling for `non_decide`/`rien_de_fiable` results. This is far more than the annotations convey.

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

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

It is longer than a typical description, but dense with actionable content and front-loaded with purpose and trigger before the result-handling rules. The versioning guidance is the most verbose section but each clause maps to a real response state an agent must handle.

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 compensates by listing the returned fields and by prescribing how to answer under each `etat`/`couverture` state. For a three-parameter read tool, everything needed to call it and interpret results 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 coverage is 0%, so the description must carry the burden, and it explains `project` as a narrowing filter and `limit` as a result cap with a stated maximum of 20. `query` is self-evident, but the matching semantics of `project` (exact name vs. substring) are 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?

The description states a specific verb and resource: 'Semantic and keyword search over the user's saved memories.' It routes to memory_get for full text, which helps disambiguate a closely related sibling. However, it never distinguishes itself from the sibling memory_search_advanced, leaving one obvious alternative unexplained.

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 triggers with concrete examples ('use when the answer may depend on the user's past decisions... when they ask where something stands or what they decided'). That is clear when-to-use context, but there are no when-not conditions and no comparison against memory_search_advanced or memory_surface.

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?

Annotations already establish read-only, idempotent, non-destructive semantics, so the safety bar is covered. The description still adds genuine behavioral facts: an empty query returns the filtered set sorted by importance, and limit is capped at 30 — both useful and not derivable from 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 tightly written sentences with no filler, and the core capability is front-loaded before the edge-case behavior. Minor density of parenthetical detail but nothing that wastes space.

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

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

For a 7-param, all-optional filtered search with annotations covering the safety profile and no output schema, the definition gives enough to call it correctly — filters, default-empty-query behavior, and a result cap. Only the ranking/tie-break beyond "sorted by importance" 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 description coverage is 0%, so the description must carry the load, and it does: it names projects, types, importance_min, date_from/date_to, query, and limit. It adds format detail (ISO dates) and a hard cap (max 30) that the bare schema lacks, though it doesn't clarify the semantics of projecting types/projects values.

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 ("searches saved memories") plus the differentiator — multiple filters at once. It distinguishes itself functionally from the plain sibling memory_search, 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?

Usage is implied by "several filters at once", which signals the tool is for multi-filter retrieval, but there is no explicit statement of when to prefer it over memory_search or memory_list, and no exclusions or prerequisites.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantive context beyond them by spelling out what the aggregate payload contains (per-project and per-type breakdowns, last activity per project), which is the meaningful behavior an agent needs to know.

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 that leads with the verb and result, then lists the returned dimensions. No filler, no restatement of the title.

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

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

With no output schema and no parameters, the description carries the burden of describing the return shape, and it does so credibly by naming the count categories and breakdown axes. It stops short of specifying value formats or whether results are scoped to a workspace, which are minor residual gaps for a stats endpoint.

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, so per the rubric the baseline is 4. Nothing in the description conflicts with the empty schema, and there is no argument semantics left to explain.

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 ('Returns counts about the user's memory') and enumerates the exact dimensions returned: totals, active/archived, breakdowns by project and type, last activity date. This is plainly distinguishable from sibling read tools like memory_list or memory_search, which return records rather than aggregates.

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 reach for this tool versus memory_list, memory_search, or memory_whats_up, nor does it state any preconditions. Usage is only implied by the word 'statistics'; there are no exclusions or named alternatives.

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?

Annotations only give the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond: it discloses the additive/idempotent-ish semantics (exact repeat reinforced, anything else creates new), that close matches surface in `similar` and are never overwritten, that `supersedes` only marks rather than deletes, and two concrete refusal conditions. This is exactly the extra context annotations cannot carry.

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

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

Front-loaded with purpose and the trigger condition, then a compact scannable parameter list, then the additive/refusal notes. Dense but nearly every sentence carries signal; the trailing refusal sentence is slightly list-like but justified given the security implications.

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

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

For a 9-parameter, no-output-schema write tool, the description covers the important behavioral surface and even names relevant return keys (`similar`, `warnings`). The only real gap is the unexplained `force` parameter and any detail on the shape of confirmation returned, which is minor.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does for 8 of 9 params (content, type with full enum, project, tags, importance, on_similar, status, supersedes) including non-obvious semantics like status=proposal vs decision. The one omission is `force`, which is undocumented anywhere, keeping this just short of full coverage.

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 ("Saves a memory") and enumerates the content kinds it handles (note, decision, preference, to-do), so an agent immediately knows this is the write path. It never names a sibling to contrast against, but no sibling in the list also writes, so disambiguation is effectively implicit.

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 prescribes when to call it: "Call it on your own, without asking first, whenever the user mentions something about themselves or their work worth keeping, even in passing." It also states when NOT to expect success (private mode `##` prefix, secrets/card numbers/passwords) and how to handle near-duplicates via `on_similar`. That is real when/when-not guidance, not 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?

Annotations already declare read-only, idempotent, non-destructive, non-open-world behavior, and the description still adds high-value context the agent cannot infer: memory content is transmitted to a third-party model (Anthropic, United States), the feature is gated behind a user setting and a paid plan, and there is a 20/day rate limit. Data egress and quota information go well beyond what annotations convey.

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

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

Two sentences, with purpose and scope front-loaded and no filler. The second sentence is a dense run-on of colon-separated conditions (model, region, setting, plan, quota), which is information-rich but slightly 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?

For a two-parameter tool with no output schema and no parameter descriptions, the definition covers purpose, alternatives, prerequisites, and limits. The one residual gap is that it never clarifies whether the summary is persisted/stored or only returned to the caller.

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 carries the burden, and it does: 'project' selects a project while its absence (empty default) means the whole memory, and 'focus' is explicitly optional and steers the summary. It stops just short of describing format or length expectations for 'focus'.

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 ('writes a short summary of the memories saved for a project') and immediately delimits scope: a single project versus the whole memory, with an optional focus. It also names the sibling tools it is not (memory_search, memory_get_project_context), 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?

Provides explicit prerequisites (user must have enabled 'AI tagging and grouping' in Pryzm Settings, paid plans only), a hard quota (up to 20 summaries/day), and a named fallback ('Otherwise use memory_search or memory_get_project_context'). This is exactly the when/when-not/alternative pattern.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is fully covered without the text. The description adds that results are the user's saved facts/preferences and that limit is capped at 10, but says nothing about ordering, relevance ranking, or what happens when topic/project are empty.

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 the core behavior front-loaded and no redundant restatement of the name. The final sentence is slightly advisory but earns its place as usage direction.

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 and no parameter descriptions, the text should do more: it does not describe result structure, ordering, or the default/empty-filter behavior of a zero-required-parameter tool. It is adequate for a simple read but leaves real gaps for an agent calling it with only partial filters.

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% across three parameters, so the description must carry the meaning. It explains only `limit` (caps results, max 10, beyond the schema's default of 5), while `topic` and `project` are left unclarified — notably whether they can be combined, whether either is required, or what an empty value does.

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

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

The description gives a specific verb and resource: it returns saved 'key facts and preferences' tied to a topic or project, which is more precise than the title alone. However, it never distinguishes itself from the heavily overlapping siblings memory_search, memory_search_advanced, or memory_whats_up, so an agent cannot tell from the text why it should pick this one.

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 supplies a clear use context — check stated preferences before making a suggestion or writing on a topic — which is genuine when-to-use guidance. But it names no alternatives and gives no exclusions, so the agent must infer this versus memory_search or memory_get on its own.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real behavioral detail beyond that: chronological ordering of results and a hard result cap ('limit caps the results (max 100)'), which an agent needs to reason about truncation.

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 action, then the period vocabulary and the limit cap in two tight sentences. No filler, no restatement of the title, and the highest-value detail (the enum list) is surfaced inline.

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 list tool with annotations covering the safety profile and no output schema to explain, the description supplies everything needed to invoke it correctly: scope, ordering, period vocabulary, project filter and result cap. Nothing material is missing.

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

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

Schema description coverage is 0% and the schema defines no enums, so the description carries the full burden. It enumerates all valid `period` values (today | yesterday | this_week | last_week | 7d | 30d | month | year), states the limit ceiling, and explains project as an optional single-project filter — only the project identifier format (name vs. id) 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 and resource ('Lists the memories saved during a period') plus the ordering ('in date order') and an optional scope ('for one project'). This distinguishes it implicitly from relevance-based siblings like memory_search, but it never names memory_list or memory_search to draw the boundary explicitly.

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

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

Usage is implied by the date-period framing and the 'optionally for one project' filter, so an agent can infer this is the browse-by-time tool. However, there is no explicit when-to-use/when-not statement and no pointer to alternatives such as memory_search or memory_list for other access patterns.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without the text. The description adds only that this is an aggregated snapshot spanning several memory categories, which is mildly useful but omits scoping (per-user vs workspace), limits, or freshness of the snapshot.

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, content listed first and usage condition second, with no filler or restatement of the title. Every clause carries 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 no output schema, the description carries the burden of explaining what comes back, and it does list the returned categories. It falls short on return shape (structured vs prose), ordering, or how complete the snapshot is, but it is adequate for a zero-param read tool whose annotations already cover safety.

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, so there is nothing for the description to clarify beyond what the empty schema shows. Baseline 4 applies for a no-argument 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?

Gives a specific verb ("Returns") and enumerates the resource contents: active projects, open to-dos, recent decisions/intentions, and preferences. An agent can tell what it fetches, but the description never distinguishes it from nearby siblings like memory_get, memory_stats, or memory_surface, so it's clear-but-undifferentiated.

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

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

Provides a concrete trigger: "when the first message of a conversation is about the user's work, clients or projects." That is a usable when-to-use signal, but it names no alternatives and no when-not conditions, so an agent still has to guess against memory_get or memory_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?

Goes well beyond the annotations by disclosing refusal conditions with informative error behavior (empty deliverable, criterion with no proof, non-current step, returned list of what is missing), immutability after closure, the memory side effect ('each closure is also saved as a memory in the plan's project'), and sensitive-content filtering (card numbers, API keys, passwords). These are exactly the traits annotations cannot convey.

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

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

Front-loaded with the core action and payload contract, then validation, then side effects and restrictions. Dense but every sentence carries a distinct constraint; the separate closing sentence on sensitive-content refusal is slightly redundant with the earlier refusal sentence.

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 four-required-parameter mutating tool with no output schema and no parameter documentation, the description covers the call contract, failure modes, post-closure behavior, side effects, and downstream workflow. An agent has everything needed to invoke it and handle its results.

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 carry the load, and it does for the two non-obvious parameters: proofs is one entry per checklist item in checklist order, and deliverable is required and must be non-empty. plan_id and step_id are left implicit, but their meaning is self-evident from the tool's domain.

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 (closes the current plan step) plus the exact payload contract: a deliverable and one proof per checklist item, in checklist order. It distinguishes itself from siblings by naming plan_current_step as the way to discover the step and plan_propose_amendment as the way to fix a closed one.

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?

Explicit routing: use plan_current_step to get the step and its checklist, use this tool only for the current step (any other step is refused), and use plan_propose_amendment to correct an already-closed step. It also states the workflow trigger to stop and ask the user for phase validation.

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?

Beyond the annotations (non-read-only, non-destructive, non-idempotent, closed-world), the description discloses the draft lifecycle, the requirement of explicit user approval before validation, the 200-step ceiling, the free-tier limit of one open plan, and the server-side refusal conditions (card numbers, API/private keys, passwords). That is substantial behavioral context an agent cannot derive from the structured fields.

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?

Purpose and usage are front-loaded, parameters follow as scannable bullets, and behavioral constraints close the block. Despite its length, every sentence adds a constraint or a routing instruction, so nothing is padding.

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

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

For a write tool with no output schema and only safety-oriented annotations, the description covers creation semantics, the draft/approval workflow, hard limits, and failure modes. The only minor omission is the shape of the returned plan identifier, which is implied by the instruction to pass it to plan_validate.

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 carries the full burden, and it does: project (with a pointer to project_list), goal, and phases are all defined, plus the nested shape of phases (ordered titles/steps) and steps (title, instruction, checklist of 1-6 verifiable criteria, deliverable). This meaningfully compensates for the undocumented schema.

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

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

The description opens with a specific verb and resource ('Creates a step-by-step plan as a draft, attached to one of the user's projects') and frames the artifact's lifecycle, which cleanly separates it from siblings like plan_list, plan_status, and plan_validate. An agent can identify the tool without opening the 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?

It states when to use it ('when the user wants to reach a goal through ordered phases and steps, and to follow it from one conversation or assistant to another') and routes the agent to the sibling plan_validate only after explicit user approval. There is no explicit when-not guidance against alternatives such as plan_propose_amendment, so it falls just short of the top band.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the invariant that only one step is current, and the blocking rule that no step is returned until the user validates a completed phase. It stops short of stating what happens with an invalid or inactive plan_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 dense sentences, front-loaded with the return payload before the state rules. Nothing is redundant, though the long field enumeration makes it slightly heavy for a one-parameter read tool.

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 carries the return-value burden by listing the fields of the working frame, and it explains the not-returned case. It is complete for invocation and interpretation, missing only error/empty-input behavior for plan_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?

One parameter with 0% schema description coverage, so the description carries the burden. It implies plan_id must reference an 'active plan,' which is useful scoping, but it gives no format, ID source, or failure behavior for the single required 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?

The description opens with a specific verb and resource: 'Returns the working frame of the current step of an active plan,' then enumerates exactly which fields come back (goal, phase/step numbers, instruction, checklist, deliverable, closed-step deliverables, rule). It is unmistakably distinct from plan_status or plan_close_step by content, though it never names a sibling explicitly.

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

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

It gives the state-machine condition that determines output ('the first step not closed in the open phase') and the edge case ('when a phase is complete, no step is returned until the user validates the phase'). That is implied usage context, but it offers no explicit guidance on when to pick this over plan_status or plan_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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds value beyond that by disclosing sort order ('newest first') and the exact payload contents (status, current version, progress, pending amendments), which orientations the agent correctly.

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 well-formed sentence that front-loads the action and scope, then enumerates return fields. Dense and mostly waste-free, though the parenthetical explaining progress calculation is slightly verbose for a description that could push that into the schema.

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

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

With no output schema, the description carries the burden of describing returns and does so thoroughly, including the status vocabulary. Missing only secondary operational details such as result limits or pagination for a list tool.

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

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

Schema description coverage is 0% and the single 'project' parameter has only a default of empty string, so the description must compensate. It does establish that the parameter is an optional single-project filter, but never says whether the value is a project name, ID, or slug, leaving ambiguity.

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 ('Lists the user's plans') and goes further by enumerating the returned attributes, including the status enum values. It does not explicitly distinguish itself from near-siblings like plan_status or plan_current_step, so an agent may need to compare schemas to be sure.

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

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

'optionally for one project' hints at the filter use case and the default behavior (all plans), which is useful implied guidance. However, there is no statement of when to reach for this versus plan_status, plan_current_step, or plan_list alternatives, and no 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?

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is partly given. The description adds material context the annotations cannot carry: the amendment changes nothing until explicit user acceptance, and closed steps/validated phases are immutable. It stops short of describing atomicity of multi-operation batches or what a rejected amendment 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?

Front-loads the core purpose in the first clause, then uses a tight bulleted enumeration of operations, then closes with the critical staging/immutability caveat. No sentence is filler; the structure matches how an agent would scan for the applicable op.

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 mutation tool with three required params, no output schema and 0% schema description coverage, the definition covers operations, constraints, and the handoff to plan_validate. Remaining gaps are minor: batch semantics when multiple operations are passed, and the behavior when the user declines the amendment.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does by mapping each op (add/remove/modify/move) to the fields it consumes: phase, position, step, step_id. It does not explain plan_id or justification, and the nested PlanStepIn fields (title, instruction, checklist, deliverable) are never mentioned.

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?

Names a specific verb and resource ('Proposes a change to an active plan') and immediately enumerates the four operation kinds with the exact fields each requires. An agent can distinguish this from plan_create (new plan) and plan_validate (accepting the amendment) 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?

States the implicit boundary conditions explicitly: 'Closed steps and validated phases cannot change' and routes corrections to the alternate path ('add a correction step'). It also tells the agent the amendment is inert until the user accepts it in the dashboard or via plan_validate, which is exactly the when-to-use context an agent needs.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Because there is no output schema, the description carries extra weight by enumerating the returned fields, including pending amendments awaiting user decision. It says nothing about error behavior for an invalid plan_id, 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?

Two sentences, front-loaded with the return contents before the usage triggers, and the long enumeration earns its place given no output schema. The second clause 'where a plan stands' slightly echoes the first sentence's opening, a minor redundancy.

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

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

With no output schema, the description properly compensates by detailing what comes back, and annotations cover the safety semantics. Only the plan_id semantics and failure behavior are left unstated for an otherwise simple single-parameter read tool.

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

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

Schema description coverage is 0% and the description never characterizes plan_id — no format, source, or how to obtain it (e.g., from plan_create or plan_list). The parameter name is largely self-explanatory, so this is not catastrophic, but the description does not compensate for the coverage gap.

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

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

The description names a specific verb ('Returns') and resource ('a plan') and then enumerates the payload: status, version, progress, phases/steps, current step, pending amendments, next action. That enumeration distinguishes it in practice from siblings like plan_current_step and plan_list. It never names those siblings explicitly, so it stops short of full differentiation.

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 triggers: 'when the user asks where a plan stands' and 'to find a step id before proposing an amendment', the latter implicitly routing to plan_propose_amendment. There is no when-not guidance or stated prerequisites (e.g., what if plan_id is unknown), so it is clear but not complete.

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?

Discloses the state consequence of every branch: accepting activates the plan at version 1, rejecting abandons it, accepting a phase opens the next, rejecting keeps it open for correction, accepting an amendment creates the next plan version. It also notes decisions may originate from the dashboard and that history records the source — real context beyond the readOnly/destructive/idempotent hints.

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 critical gating rule is front-loaded in the first sentence, and the bulleted parameter/effect notes are scannable. Slightly long, and the parameter bullets partially restate the enum schema, but each line carries decision-relevant meaning.

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

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

For a stateful, 7-parameter mutation with no output schema and no schema descriptions, this is nearly complete: precondition, confirmation flag, conditional parameters, and post-condition per branch are all covered. Missing are the failure modes (invalid target/parameter combination) and what the call returns.

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

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

With 0% schema description coverage, the description carries the load and does so for most fields: target enum values, decision enum values, conditional role of phase ("for target phase"), amendment_id ("for target amendment"), and comment ("optional note from the user"). It leaves plan_id and the conditional-requiredness rules (e.g., phase required when target=phase) 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?

Opens with a precise verb+resource: "Records the user's decision on a draft plan, a completed phase or a proposed amendment." This is clearly distinguishable from siblings like plan_create and plan_propose_amendment, which produce plans/amendments rather than record decisions on them.

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

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

Gives an explicit precondition ("only after the user has explicitly agreed or refused in this conversation"), an explicit prohibition ("do not call it on your own initiative"), and the required flag (confirmed_by_user=true). It also notes the user may decide in the Pryzm dashboard instead, which explains an absence-of-call scenario.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful payload detail (each project's description and memory count) but says nothing about ordering, pagination, or empty-state behavior.

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: the return contents come first, then the usage trigger. Every clause earns its place.

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

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

With no output schema, the description carries the burden of describing returns and does so adequately for a zero-parameter listing tool. Missing only minor operational details like result ordering or how many projects are returned.

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 baseline is 4. There is nothing for the description to disambiguate and it makes no misleading claims about inputs.

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

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

States a specific verb and resource ('Lists the projects the user's memories are organised into') and even names the returned fields. The projects framing separates it from memory_list, though it never explicitly contrasts itself with the similarly named plan_list sibling.

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 to pick the right project name before searching or saving' gives a concrete trigger tied to two downstream operations. No explicit when-not-use or named alternative, so it stops 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.