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

No annotations are supplied, so the description carries the full burden. The phrase 'without rewriting decisions' usefully implies decisions are not mutated, but it is silent on whether anything is written, what 'flag' produces, and whether a session must already exist. That is thin behavioral disclosure for a tool with zero annotation coverage.

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

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

It is a single front-loaded sentence with no filler, which is structurally clean. However, the brevity comes at the cost of under-specification rather than economical communication.

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

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

For a two-parameter tool with no annotations and no output schema, the description should explain what a 'flag' looks like in the response and how the decision/evidence matching works. Neither is present, leaving the agent unable to predict the result of a call.

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 two parameters, and the description only obliquely gestures at changed_files via 'changed ... evidence'. Nothing explains what session_id does, that it defaults to empty, or whether an empty value scopes to a default session.

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 verb 'Flag' and object 'changed or missing evidence' give a rough sense of intent, but the core resource, decisions, is only implied by the tool name rather than the prose. It does not differentiate itself from siblings such as record_decision or get_review_memory, so an agent must infer that this cross-checks recorded decisions against a set of files.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The agent is left to guess whether this should run before a review, after files change, or in place of record_review_outcome.

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 real behavioral trait: retrieved items are not promoted to proof, i.e. the call is non-validating and does not mutate review state. It says nothing about scoping defaults (both params default to empty string) or what the response looks like, so the disclosure is partial.

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

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

A single front-loaded sentence with the retrieval content up front and the non-promotion caveat trailing it; nothing is padded. The phrase 'promoting them to proof' is somewhat domain-jargony and would benefit from a short gloss.

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

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

For a tool with two undocumented, optional parameters, no annotations, and no output schema, the description should at minimum explain what goal/session_id scope and roughly what shape the findings come back in. It explains neither, leaving the agent to guess at default behavior when both params are omitted.

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%: 'goal' and 'session_id' have only titles and empty-string defaults. The description does not mention either parameter, so an agent cannot tell whether 'goal' scopes retrieval, filters by goal text, or is merely a label, nor what session_id defaults to when omitted.

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 ('Retrieve') and enumerates the resource contents (findings, dismissals, fixes, failed approaches), so an agent knows what it will get back. It does not name any sibling (e.g. query_memory, check_decisions) to sharpen the boundary, which keeps it 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. The clause 'without promoting them to proof' hints that this is the raw-retrieval counterpart to a validating/recording tool, but the agent must infer that among ten siblings 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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses only that the returned handle is 'durable' and enables cross-connection resumption. It says nothing about whether calling it mutates or creates server-side state, whether the handle is sensitive/credential-like, whether it expires or is single-use, or what happens if the passed session_id is unknown.

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 sentence with the purpose front-loaded and no filler; nothing is redundant. It is appropriately sized for what it says, though the terseness is a symptom of missing content rather than efficient compression.

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 two undocumented optional parameters, the description is the only explanatory channel and it under-delivers: it does not state what the returned handle looks like or how to use it, nor how the defaults on 'goal' and 'session_id' behave. For a tool whose whole point is producing a token for later reuse, that usage contract should be spelled out.

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 two parameters, and the description provides no compensating meaning for either. It never explains what 'goal' influences (both params are optional with defaults) or how 'session_id' selects a prior session versus establishing a new one, leaving an agent to guess the semantics of both fields.

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 uses a specific verb + resource ('Return the durable session handle') and adds the purpose clause 'needed to resume private memory in a new connection', which tells an agent what the artifact is for. It does not, however, distinguish this from siblings such as session_status or list_recent_sessions, and 'handle' remains an ambiguous noun (token? ID? opaque blob?).

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 'to resume private memory in a new connection' implies the triggering situation, so usage is inferable rather than absent. There is no explicit when-not guidance, no mention of what to do if a session already exists in this connection, and no named alternative among the ten sibling memory tools.

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

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

With no annotations, the description carries the full behavioral burden, and it only partially does so. "Citations, constraints, freshness and explicit budget overflow" hints at returned content and at what happens when the token budget is exceeded, but says nothing about permissions, read-only nature, truncation behavior, or cost — all left to inference.

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 with no filler is commendably compact and the scope hint comes first. The compactness comes at the cost of clarity, though: the sentence is a stack of bare noun phrases rather than a readable statement of behavior.

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-parameter tool with zero schema coverage, no annotations, and no output schema, this fragment is not enough to call it correctly. The agent knows roughly what topic the result covers but not how parameters shape it or 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% across four parameters (goal, session_id, token_budget, changed_files), yet the description explains none of them. The word "budget" faintly gestures at token_budget, but the relationship between changed_files and what context is returned — arguably the core selection logic — is never stated.

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

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

"Get whole-record context" gives a verb and an object, but "whole-record" is undefined jargon — the agent cannot tell whether this returns a file, a session, a decision log, or an assembled bundle. Nothing in the sentence distinguishes it from siblings like get_session_handoff or query_memory, which also sound like context retrieval.

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 at all: no conditions, no exclusions, and no named alternative among the ten sibling tools. The agent must guess whether this replaces or complements query_memory and get_session_handoff.

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

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

No annotations, so the description carries the full burden. It says results are limited to what the caller can see, which is a genuine visibility constraint, but it doesn't state ordering (why 'recent'), pagination, permissions, or what 'legacy' implies about freshness. A read tool is low risk, but the description leaves core behavior unexplained.

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 the action and scope. It is compact with no padding, though the wording is slightly confusing ('legacy notes and summaries' vs the tool name) rather than maximally clear.

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

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

The tool has three parameters at 0% schema description, no annotations, and an output schema. Even allowing that the output schema covers returns, the description fails to explain the parameters, the meaning of 'recent', or how it differs from sibling session tools, which is too little for a three-parameter listing tool.

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

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

Schema coverage is 0%, so the description must compensate and it says nothing about count, session_id, or project_name. An agent cannot tell whether session_id filters to one session, whether project_name scopes the listing, or what count defaults to (the schema shows 3 but gives no meaning). This is the biggest 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 verb+resource is 'List legacy notes and summaries', which is specific, but the tool is named list_recent_sessions and the name promises 'recent sessions' while the description talks about 'legacy notes and summaries'. That mismatch leaves the agent guessing which artifact it actually gets. The scope qualifier 'visible to this caller' is useful but the core object is muddled.

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 guidance on when to use this versus siblings such as get_session_handoff, session_status, or query_memory, which all touch session data. The 'never other private sessions' clause is an exclusion but about data visibility, not about when to pick this tool. The agent gets no routing signal.

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 of behavioral disclosure. It adds that explicit session IDs enable "durable scoped continuity," but it does not state whether the operation is read-only, how query matching works, what happens if session_id is omitted, or whether there are permission or rate-limit concerns.

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

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

The description is two short sentences and front-loads the core purpose before the session-ID detail. There is no repetition or wasted wording, though "durable scoped continuity" is somewhat jargon-heavy and could be clearer.

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 the description need not explain return values. But with no annotations, 0% schema description coverage, and several sibling memory/session tools, the definition is too sparse: it does not clarify query semantics, project_name usage, or how to choose this tool over alternatives.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only implies the role of session_id through "durable scoped continuity"; the required project_name and query parameters are not explained at all.

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: "Load saved memory," and adds a timing cue, "before work." It is clear enough to understand the tool's basic purpose, but it does not differentiate it from siblings such as get_review_memory or get_session_handoff.

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 "before work" gives a clear usage context, telling the agent when this tool is appropriate. However, it provides no exclusions, prerequisites, or guidance about when to use an alternative memory/session tool instead.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a save operation and mentions explicit sharing and supersession, but does not disclose persistence scope, permission requirements, duplicate handling, or what happens when source/evidence_files are missing.

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, with the primary action front-loaded. The wording is efficient and avoids filler, though it is arguably too sparse given the tool's parameter count.

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?

This is a complex 9-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage. The description does not explain the required evidence_files or source semantics, nor the many optional fields, leaving an agent unable to invoke it reliably.

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 9 parameters and 0% schema description coverage, the description must compensate heavily, but it adds little. It implies kind values (decision/constraint/blocker) and the presence of a supersedes field, yet leaves scope, session_id, status, topic, source, and evidence_files essentially 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?

The description gives a specific verb ('Save') and resource ('decision/constraint/blocker'), making the core action clear. It does not distinguish this tool from siblings like check_decisions or share_memory_record, so it is clear but lacks sibling 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?

The phrase 'Sharing and supersession are explicit' hints that sharing/supersession require deliberate fields, but there is no guidance on when to use this tool versus check_decisions, share_memory_record, or record_review_outcome. It also gives no when-not conditions 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?

With no annotations supplied, the description carries the full burden, and the second sentence does disclose one genuinely useful trait: command strings are persisted as inert data rather than executed, and verification status is caller-asserted rather than server-validated. That is real value beyond structured fields. However, nothing is said about persistence scope, what happens on duplicate records, whether entries are mutable or reopenable (the `reopens` parameter hints at state changes), or what the caller gets back.

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 with no filler and the core action front-loaded, so nothing is wasted. The problem is under-specification rather than verbosity: at this size for a 14-parameter mutation tool, the terseness costs more than it saves.

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?

Fourteen parameters, zero schema descriptions, no annotations, and no output schema mean the description is the sole carrier of context, and two sentences cannot cover it. Key facts an agent needs — accepted `kind` values, whether `scope: session` versus other scopes changes behavior, what `reopens` does, and whether evidence_files must exist on disk — are all absent.

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 14 parameters, including four required ones (kind, text, source, evidence_files), so the description is the only possible source of meaning — and it explains none of them. "Commands" loosely gestures at the `command` field and "verification is caller-reported" at `status`/`result`, but `kind`, `scope`, `reopens`, `related_id`, `external_id`, and `conditions` remain entirely opaque.

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 verb ("Record") and a loosely named resource ("review/failure evidence"), but the resource doesn't map cleanly to the tool name's "review outcome" and the 14-parameter surface suggests a much broader record type than "evidence." An agent cannot tell from this text whether the tool logs a review verdict, a test failure, or both, nor how it differs from siblings like record_decision or check_decisions.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obviously related siblings (get_review_memory, record_decision, check_decisions) that an agent would need to choose between. The only implicit cue is that this is a write path versus the read-oriented get_review_memory, which the agent must infer entirely 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?

With no annotations provided, the description carries the full behavioral burden. 'Check' implies a read-only probe, but it never confirms side-effect-free behavior, permissions/auth needs, or cost, and gives no hint about what 'loaded' versus 'not loaded' states mean in practice.

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 short sentence with the scope qualifier front-loaded at the end of the clause; nothing is wasted. It is perhaps too terse rather than verbose, but structurally clean.

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, but for a tool whose only argument is ambiguous against its own 'this session only' framing, the description does not resolve the tension. The semantics of the loaded/unloaded state and the role of session_id are both left for the agent to infer.

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 nothing documents the single session_id parameter, which has a default of '' and is not required. The description's 'this session only' actively muddies this: it is unclear whether session_id selects another session or whether an empty value means the current one.

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 concrete verb ('Check') and a concrete target ('the memory-loaded state of this session'), which is more specific than a restatement of the name. The phrase 'this session only' begins to differentiate it from siblings such as get_session_handoff or list_recent_sessions, though what 'memory-loaded state' actually means is left 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?

The word 'only' hints at a scope restriction, but no sibling is named as the alternative for checking other sessions, and no when-to-use/when-not-to-use conditions are stated. An agent must guess whether get_session_handoff, list_recent_sessions, or query_memory is the right call for a non-current session.

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 supplied, so the description carries the full disclosure burden for a mutation tool. It adds one useful behavioral fact (promotion is never automatic), but does not say what sharing means in practice: the resulting visibility scope, whether the change is reversible, required permissions, or side effects for other sessions. For an irreversible-looking visibility change, this is a substantial 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?

A single front-loaded sentence with the action first and the anti-pattern (automatic promotion) second; nothing is redundant. It is arguably over-compressed given how much behavior remains unstated, but structurally it is clean and wastes no words.

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?

This is a mutating visibility-change tool with no annotations, no output schema, and 0% schema description coverage, so the description must supply far more than it does. It omits what happens to the record after sharing, how errors surface, and what session_id does, leaving an agent unable to call it confidently beyond the happy path.

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 both parameters depend on the description, which mentions neither record_id nor session_id. The word "record" faintly implies record_id identifies the target, but the meaning of the optional session_id (default "") and the expected ID format are entirely undocumented in both schema and description.

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

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

The description names an action ("promote") and an object ("a visible private record"), so an agent can tell this changes a record's visibility rather than reading or listing it. However, "promote" and "visible private record" are unexplained internal vocabulary, and nothing distinguishes this from siblings like record_decision or query_memory beyond the word "share". The core intent is inferable but not crisply 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?

"Explicitly" and "no automatic promotion of agent claims" imply the agent should invoke this only when a record genuinely needs to be shared rather than assuming claims become visible on their own. That is real when-to-use signaling, but no alternative tool or condition for choosing among siblings is named, and there is no guidance on when to omit sharing.

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

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

With no annotations provided, the description carries the full behavioral burden and does not meet it. "Durable" signals persistence and the second sentence flags that session type changes storage behavior, but overwrite semantics, permissions, and the meaning of "keep Markdown behavior" are all left undefined.

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?

At two sentences it is appropriately short and the core action is front-loaded. The second sentence, however, is compressed into unexplained internal jargon, so the brevity comes at the cost of comprehension rather than from efficiency.

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

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

The presence of an output schema means return values need not be described. Still, for a write/persist tool with zero annotations, no parameter documentation, and an opaque statement about session isolation, the description leaves out too much for an agent to call it confidently.

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 compensate and does not. It never explains project_name's role as a target or destination key, nor the semantics of session_id (including its empty-string default), even though session scoping is the one behavioral distinction it raises.

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 phrase "Save a durable summary" gives a verb and resource, so the basic action is legible. But it never says what is being summarized, where the summary lands (Obsidian is only implied by the tool name), or how it differs from siblings such as record_decision or share_memory_record.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the ten sibling tools. The clause about MCP/explicit sessions vs. legacy calls hints at a branching condition, but an agent cannot determine from it when this tool is the correct choice.

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