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

With no annotations, the description carries the full burden and largely discharges it: it discloses the exact ordered contents of the response and that retrieval is deterministic with no vector search. It omits permission/auth requirements and any note about cost or side effects, but for a read tool this is solid disclosure.

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 urgency directive, then a compact enumerated return list, then the parameter note. Every sentence carries information; only the capitalized domain jargon (QUIET THREADS, CORE) slightly taxes a first-time reader.

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 spelled out, yet the description still summarizes them helpfully. Combined with the strong usage directive and parameter note, it is complete enough for an agent to call correctly, though it lacks any auth or failure-mode context.

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 the single parameter, and it does: 'channel: optional — return only that lane's pin' explains the filter and its opt-in nature. It is terse but sufficient for a one-param tool.

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

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

The description states a specific verb (Returns) and enumerates the exact resources returned in order (hard-rule constraints, one pin per lane, QUIET THREADS, CORE wiki pages, wiki index), and adds a distinctive trait ('Deterministic — no vector search'). An agent can immediately distinguish this bundle-retrieval tool from siblings like load_wiki or read_memory.

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?

'CALL THIS FIRST in every conversation' is an explicit, unambiguous when-to-use directive, reinforced by the deterministic-vs-vector-search contrast that differentiates it from the search_* siblings. No when-not is stated, but the first-call directive is about as strong as guidance gets.

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 load. It does disclose one real behavioral trait: retired rules exist and are excluded from the default listing. It says nothing about permissions, result size, ordering, or pagination, which an agent calling a list tool would want.

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

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

Two short sentences, front-loaded with the action, with no filler. The aphoristic second sentence is memorable and does work, but is slightly obscure in a way that trades precision for style.

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

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

An output schema exists, so return values need not be described. For a single-parameter list tool that is roughly adequate, but the description leaves an agent unsure what a 'constraint' is, how many there are, or how this relates to the surrounding constraint tools.

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 parameter 'include_inactive' is undescribed. The sentence 'Retired rules are history, not truth' implies what 'inactive' means and that it is off by default, partially compensating, though the framing is exhortative rather than a clear definition of the flag's effect.

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+resource ('List standing rules'), but renames the resource as 'rules' rather than 'constraints' and never defines what a constraint actually is. Against siblings like list_entities, list_threads, and list_records it does not make clear why this list is different beyond the active/retired distinction.

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 statement of when to call this tool versus alternatives such as set_constraint, retire_constraint, or read_memory. The second sentence only hints, obliquely, that retired rules exist and are probably not wanted by default, which is guidance about the parameter rather than about selecting the tool.

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 disclosure burden. It implies a read operation but does not state read-only safety, permissions, pagination behavior, or how include_archived changes the result set; the word 'every' may even mislead given the parameter's default false.

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 a single front-loaded sentence with no filler, and it efficiently enumerates the key return fields. It is appropriately sized for the surface-level purpose it communicates.

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?

Because there are no annotations and the only parameter is undocumented, the description is not complete enough for confident invocation. The output schema covers return values, but usage context and include_archived semantics are missing, leaving significant gaps.

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

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

The sole parameter, include_archived, has 0% schema description coverage and is never mentioned in the description. The description adds no meaning about what the flag controls or when it should be used, leaving the agent unable to invoke the tool with the parameter correctly understood.

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

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

The description states a clear verb and resource: 'List every wiki page,' and enumerates the returned fields (folder, name, version, last update, headline). It does not, however, differentiate this listing tool from siblings like load_wiki or clarify whether it is a complete dump versus a filtered view.

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 explicit alternatives, and no conditions for choosing list_entities over load_wiki or any other sibling. The agent is left to infer usage from the tool name and description alone.

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 full behavioral burden. 'Read path' weakly implies a safe read-only operation, but there is no disclosure of pagination, permissions, ordering, or side effects. The description does not contradict anything, but it leaves key behavioral traits unstated.

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 definition is very short and front-loads the purpose before the parameter values. It avoids wasted words, though the terse 'HUMAN's triage read path' phrasing is slightly cryptic rather than perfectly 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?

An output schema exists, so return values need not be explained. The tool is simple with one optional parameter, and the description supplies the filter values. Still, the purpose and usage context are thin enough that an agent must infer some details from the name and siblings.

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

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

Schema description coverage is 0%, so the description must explain the single parameter. It lists the valid status values ('open | triaged | fixed | dismissed') and clarifies that an empty string means all, which is exactly the missing enum/semantic detail the schema lacks.

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 calls this 'The HUMAN's triage read path,' which implies a read/list operation but never explicitly states that it lists friction items. Combined with the tool name, an agent can infer the purpose, but the description alone is vague about the resource and verb.

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

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

The phrase 'The HUMAN's triage read path' gives an implicit context for when to use this tool, and the status values suggest filtering. However, there is no explicit guidance on when to choose this over siblings like triage_friction, log_friction, or list_records.

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 disclosure burden. It reveals ordering ('newest first'), which is genuinely useful, but says nothing about read-only safety, side effects, permissions, pagination, or what the returned set's bounds are – thin coverage for a no-annotation tool.

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 core action and ordering, then the optional filters. Zero waste; 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?

An output schema exists, so return values need not be explained. However, with no annotations and a 50-default limit that is never referenced, the definition leaves an agent guessing about result-set size and pagination behavior.

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

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

Schema description coverage is 0% and the schema only carries titles. The description gives meaning to kind and an ISO format hint for the date range, but 'limit' is entirely undocumented in both schema and description, and valid 'kind' values remain 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 (List) and resource (records), plus two behavioral facts: default ordering (newest first) and the optional filters. It does not distinguish itself from siblings like list_entities, list_constraints, or list_friction, but the purpose 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?

Usage is implied by 'optionally by kind and ISO date range' – an agent can infer that calling with no arguments lists everything. There is no explicit statement of when to use this versus log_record or the other list_* siblings, 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?

No annotations are provided, so the description carries the burden, and it does disclose the returned attribute set (lane, status, age, cadence). However, it says nothing about the read-only nature, pagination, ordering, or how the default closed-thread filtering behaves.

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

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

One front-loaded sentence that states the operation and the returned fields with no filler. It is efficient, though arguably too sparse given the undisclosed parameter.

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

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

An output schema exists, so return values need not be explained, and for a simple list tool the bare description is minimally viable. The gaps are the default filtering behavior of include_closed and any guidance on choosing this tool over the other list_* siblings.

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

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

Schema coverage is 0% and the single parameter include_closed is never mentioned in the description. The phrase 'tracked threads' gives no clue that closed threads are excluded by default, so the agent must infer the parameter's meaning from the schema name alone.

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 (List) + resource (tracked threads) plus the fields surfaced (lane, status, last-touched age, cadence). It clearly reads as a read operation and is distinguishable from the write siblings (track_thread, touch_thread), though it never names them explicitly.

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

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

No statement of when to use this versus alternatives such as list_entities, list_constraints or walk_trail, and no conditions or prerequisites. Usage is only inferable from the tool name.

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 burden and does disclose meaningful behavior: exact-match-only semantics, determinism, and near-match suggestions on a miss. It does not cover permissions or listing/ordering behavior, but the failure-mode disclosure is valuable beyond 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?

Two short clauses, front-loaded with the action and its defining constraint, then the failure behavior. No wasted 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?

An output schema exists, so return values need not be described. For a single-parameter lookup tool, the description covers input semantics and miss handling adequately; only edge details like multi-entity partial-miss behavior are 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?

One parameter ('entities', an array of strings) with 0% schema coverage. The phrase 'by exact name' clarifies that the items are exact page names, which adds meaning, but the array semantics (one vs many, batching, ordering) are left unstated.

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 (Load) and resource (compiled wiki pages) with a key constraint (by exact name). It implicitly contrasts with write_wiki in the sibling set, though it doesn't name 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?

'By exact name — deterministic' implies the appropriate usage context and 'Misses suggest near matches' tells the agent what happens on failure, but no alternative tool or precondition is named. 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?

With no annotations, the description carries the full burden and does meaningful work: it states the evidence precondition, warns the lane is not for behavioral self-modification ('Never read this lane to change your behavior'), and implies write-only semantics. It omits permissions, immutability, dedup behavior, and what logging triggers downstream.

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?

Tight and front-loaded: the core trigger and the hard precondition land in the first two sentences, followed by the normal-case note, the warning, and the category values. Slightly telegraphic phrasing ('this lane') costs a little clarity but 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?

An output schema exists, so return values need not be explained, and the description covers the behavioral essentials of what/when/when-not. Given a 4-parameter, 0%-coverage schema, more parameter-level detail would round it out, but nothing critical for correct invocation 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%, so the description must compensate. It usefully enumerates the allowed category values (stale_protocol, wrong_tool, bad_retrieval, user_correction, missing_context, tooling_error, other), which the schema does not, but leaves summary, evidence, and proposed_fix semantics (length, format, what counts as artifact) undocumented.

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

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

States a specific verb+resource: logging the agent's own failure in the moment with a concrete artifact as evidence. It implicitly contrasts with the read side of the lane ('Never read this lane'), which helps separate it from list_friction/triage_friction, but it never names those siblings or explicitly distinguishes itself from log_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?

Gives an explicit trigger (a failure in the moment, with artifact) and an explicit exclusion ('No artifact = do not call'), plus a normal-case note ('Zero friction is a normal session'). It stops short of naming alternative tools for the read/triage side, so it is clear context rather than full when/when-not/alternatives guidance.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses the upsert key (kind, title, date), which tells the agent existing records with that key will be overwritten. However, it says nothing about permissions, conflict resolution details, or what happens to non-key fields on upsert.

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 purpose front-loaded and examples inline. The value proposition sentence earns its place by clarifying precedence over memory, though it could be trimmed slightly.

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

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

An output schema exists, so return values need no explanation. But for a 5-parameter mutation tool with zero annotation and schema-description coverage, the description covers only three parameters and omits amount/payload_json semantics and error behavior, leaving real gaps.

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

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

Schema description coverage is 0%, so the description must compensate for all five parameters. It only references kind, title, and the date via the upsert key, leaving amount and payload_json completely unexplained, which is a significant gap for a 5-param 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 (store/log) and resource (hard data records) with concrete examples like invoice, deadline, and measurement. It is distinguishable from memory-oriented siblings such as write_memory and log_friction, though it never names them 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?

The line 'Records beat recall: when one disagrees with a remembered fact, the record wins' implies when this tool should take precedence over memory tools, but it gives no explicit when-to-use or when-not-to-use guidance relative to siblings like write_memory or log_friction.

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

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

With no annotations, the description carries the behavioral burden and discloses meaningful traits: hybrid search mechanics, rank fusion, importance/recency re-ranking, and the honesty-floor message when nothing relevant is found. It does not explicitly state read-only behavior or permission requirements, but the core search behavior is well covered.

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 front-load the search mechanics and scope before moving to usage guidance and the honesty-floor behavior. Every sentence carries useful information with no wasted wording.

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 description covers purpose, usage, and behavior well, and an output schema exists so return values need not be described. However, with 0% schema description coverage for three parameters, it remains incomplete regarding how to use query, limit, and domain correctly.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It barely implies that the query should be topic-specific but says nothing about limit or domain, leaving most parameter semantics 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 states a specific operation — hybrid search over the trail — and clarifies it is for topic-specific history rather than current state. It distinguishes itself from pins/wiki, but it does not differentiate from the sibling search_memory, which is likely the closest alternative.

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

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

It gives explicit usage guidance: use for topic-specific HISTORY, not for current state (pins/wiki). This is clear context and an exclusion, but it omits the direct alternative for historical memory search, such as search_memory.

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 two real traits: retirement is a soft operation ('never delete'), and only active rules are eligible. It omits what happens on zero or multiple matches, whether the change is reversible, and any permission requirements, 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 no filler; the parenthetical 'never delete' is placed exactly where it matters and the emphasis on 'ONE' flags the uniqueness constraint efficiently.

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

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

An output schema exists so return values need not be described, and one parameter keeps the surface small. Still, for a mutation tool with no annotations, the description leaves failure modes (no match, multiple matches) and reversibility undefined.

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 sole parameter is just typed as a string, so the description is the only source of meaning — and it does add that the value is a 'fragment' matched against rules rather than an exact identifier. It does not explain matching rules, case sensitivity, or ambiguity handling, so it only partially compensates.

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 (retire) and its object (the one active rule matching the fragment), which is enough to separate it from set_constraint and list_constraints. It stops short of explicitly naming a sibling or contrasting behavior, so it is clear but not fully differentiated.

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 explicit statement of when to use this versus set_constraint or list_constraints, and no prerequisites or preconditions are given. The 'ONE active rule' phrasing implies a match must be unique, but the agent is left to infer this rather than being told.

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 delivers little: it discloses that ranking matches read_memory and returns more results, but says nothing about pagination, result caps, ordering guarantees, or whether the memory store is read-only. The one comparative fact is genuinely useful, but the behavioral picture is thin.

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 no filler, and the differentiating comparison is front-loaded. It is efficient; the brevity is partly a virtue and partly the source of the gaps scored elsewhere.

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 three-parameter search tool with zero schema descriptions and no annotations the definition leaves the agent guessing about parameters and scope. It is not complete enough to invoke 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 (query, limit, domain), so the description must compensate and largely does not. 'More results' weakly gestures at the limit parameter, but query and domain—including what a domain scopes to—are completely unexplained anywhere.

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 positions the tool relative to a sibling ('broader sweep... same ranking as read_memory') and hints at result volume, but never states the verb+resource plainly (e.g., 'search stored memories by query'). An agent must infer the purpose from the name and the read_memory comparison rather than reading it.

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 'broader sweep ... (more results)' implies this is the wider-coverage alternative to read_memory, which is a usable selection hint. However, it never states an explicit when-to-use/when-not condition, prerequisites, or how broad the sweep actually is.

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

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

No annotations are provided, so the description carries the full burden. It implies persistence via "standing rule" but says nothing about precedence, conflict handling, whether existing rules are superseded, or whether confirmation is needed. For a state-mutating tool this is a significant disclosure 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 tight sentence with the action front-loaded and the trigger condition immediately after. Nothing is wasted or buried.

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

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

The output schema covers return values, so that need not be explained. However, with no annotations and 0% parameter coverage, the description leaves the category argument and the mutation's behavioral consequences undocumented.

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, so the description must compensate and does not. The required "rule" string is only loosely implied ("the user states one"), and the "category" parameter with its "general" default is 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?

"Add a standing rule" names a specific verb and resource, so the agent knows this creates a persistent constraint. It is not explicit about how it differs from family siblings like retire_constraint and list_constraints, but the create/read/delete split is inferable.

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 a concrete trigger condition with example phrasings the user might use ("from now on…", "never…"). It stops short of naming alternatives — e.g. that retire_constraint removes a rule — so it is clear context without explicit 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?

With no annotations, the description carries the burden and largely does: it discloses that the write is a full in-place rewrite of one lane rather than a delta or append, which is the key destructive-behavior fact. It stops short of permission requirements or what happens to sibling lanes / an absent pin, so not 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?

Three dense sentences, front-loaded with the trigger and the object, each carrying distinct information (trigger, scope, semantics, sibling routing). No filler.

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

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

An output schema exists, so return values need not be explained, and the description covers trigger, scope, write semantics, and the memory-vs-state boundary. Minor gaps remain around overwrite edge cases (missing lane, other lanes' fate) that a mutation tool with no annotations could generously include.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it reveals that 'channel' is one of work|personal|school (an enum the schema omits entirely) and that 'content' must be full state, not a delta. It adds real meaning beyond the bare 'string' schema, though it doesn't define channel format for content syntax.

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 ('set the pin for ONE lane') with scope made explicit (single lane, enumerated values). It also distinguishes itself from write_memory, so an agent can route between a state pin and durable memory without opening either schema.

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

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

States the trigger ('Session close') and the exclusion ('Durable facts belong in write_memory'), naming the alternative and the condition that selects it. This is exactly the when/when-not guidance that makes a writer tool selectable.

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 burden. It discloses the semantic of touching a thread as 'NOW' and the inferential rule for status, but says nothing about what happens to the note field, idempotency, or whether prior timestamps are overwritten.

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

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

Two tight sentences, front-loaded with the action and followed by the constraint. The emphasized status rule is verbose but earns its place as the tool's key behavioral guardrail.

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. Still, for a mutation tool with zero annotations and 0% parameter coverage, the description leaves name/note behavior and mutation side effects unspecified.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies status semantics ('records what they said, never what silence suggested'); name and note are completely undocumented in both schema and description.

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

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

States a specific verb and resource ('Mark a thread discussed NOW'), which is clear intent, but does not distinguish itself from the sibling track_thread, so an agent can't tell the two apart from the description alone.

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 real usage rule for the status parameter ('Set status ONLY if the user ruled on it'), which is genuinely useful guidance. However, there is no when-to-use-this-vs-alternatives guidance, notably nothing distinguishing it from track_thread.

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 usefully explains that cadence_days controls surfacing after quiet days and lists status values, but it never clarifies create-vs-update (upsert) semantics, reversibility, or what happens to existing fields on update.

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 terse per-parameter notes. Slightly telegraphic ('0 = never surfaces on silence') but every line earns its place with no filler.

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

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

An output schema exists so return values need not be described. Still, for a mutation tool with no annotations and 0% schema coverage, the description leaves half the parameters and the create/update distinction unexplained.

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

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

Schema description coverage is 0%, so the description must compensate. It defines cadence_days range/semantics, status enum values, and wake_date, covering three of six parameters, but leaves lane, name, and note entirely undefined.

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 pair (create/update) and resource (thread), plus a trigger condition distinguishing it from list_threads/touch_thread. It does not explicitly name how it differs from the sibling touch_thread, but a reader can infer it.

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 trigger is stated ('when the user names an ongoing project or open loop'), which is clear usage context. However, no alternatives are named and no when-not-to-use guidance is given, so the agent must infer when touch_thread or list_threads is preferable.

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

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

With no annotations, the description carries the full burden and does disclose the most important behavioral trait: the verdict must originate from a human, and the model cannot self-apply 'fixed'. It omits permissions, idempotency/overwrite behavior, and what happens to an existing triage record, keeping it out of 5 territory.

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, both front-loaded with the operative information (what is recorded, then the hard constraint). No filler.

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

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

An output schema exists so return values need not be described, and the key human-only constraint is stated. The gap is the two undocumented parameters (friction_id, triage_note) and no indication of the triage workflow relative to log_friction/list_friction.

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

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

Schema description coverage is 0% and no enums are declared in the schema, so the description's enumeration 'triaged | fixed | dismissed' adds genuinely new meaning for the status parameter. However friction_id and triage_note are left entirely undocumented, so it only partially compensates 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?

States a specific verb ('Record') and resource ('the HUMAN's spoken verdict'), and even enumerates the accepted status values. It is distinguishable from log_friction/list_friction by its triage-verdict framing, though it never names those siblings explicitly.

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

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

The second sentence gives a sharp usage constraint: a model may never mark its own failure fixed, which tells the agent exactly when it must NOT call this tool unilaterally. It stops short of naming an alternative or describing the human-handoff flow, so it is clear context rather than full when/when-not routing.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful traits: chronological ordering, oldest-first, and explicitly 'no scoring'. However, it says nothing about pagination/limit behavior, permissions, or the read-only nature an agent would want to assume for a mutation-capable API family.

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. The core behavior (order, no scoring) is front-loaded and the use-case cue follows immediately; 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?

An output schema exists, so return values need not be described. But with zero annotations and 0% schema description coverage across 4 parameters, the description should do more about limit/domain semantics and the tool's safety profile than it does.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the two date parameters usefully ('ISO dates, inclusive') and implies chronological ordering, but leaves 'limit' and 'domain' entirely unexplained, so half the parameters remain opaque in both schema and description.

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

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

States a specific verb and resource ('walk the trail') and adds distinguishing behavioral detail ('in date order, oldest first, no scoring'). The term 'trail' is domain jargon and no sibling is named, so an agent must infer how this differs from list_records or search_memory, but the operation is otherwise clear.

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

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

Provides concrete triggering questions ('what happened in March' / 'when did X change') that map the tool to a clear use case. It stops short of naming alternatives or saying when NOT to use it (e.g., vs. list_records or search_memory), so it is 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?

With no annotations, the description carries the full burden and discloses meaningful traits: idempotency_key makes a repeated call a safe no-op, content is limited to 300 words, and entities power a topic-to-page push. It does not cover permissions or overwrite semantics, but the key behavioral details are present.

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 front-loaded with the core purpose, then uses compact labeled lines to explain each parameter's semantics. Every sentence earns its place with no repetition or filler.

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

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

Given no annotations, 5 parameters, 0% schema coverage, and an existing output schema, the description provides enough to invoke the tool correctly: it defines most parameter semantics and important behaviors like idempotency and word limit. It stops short of explicitly naming the content parameter and lacks sibling routing guidance, but is largely complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for four of five parameters: domain gets examples, importance gets a numeric interpretation, idempotency_key explains safe duplication, and entities explains linkage. The content parameter is only implicitly defined via 'one specific fact per call, under 300 words', which keeps it from a 5.

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

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

The description states a specific verb and resource: 'Persist one durable fact or decision' and scopes it to one fact per call under 300 words. It does not explicitly differentiate from sibling tools like write_wiki or log_record, so it falls short of a 5.

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

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

Usage is implied by 'Persist one durable fact or decision' and the importance scale, but there is no explicit when-to-use guidance or comparison to alternatives such as write_wiki or log_record. The domain examples and importance mapping are helpful parameter guidance rather than selection criteria.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses that writes are in-place rewrites (implying prior content is replaced) and that folder=CORE injects a page into every session, which is non-obvious behavior. It omits permissions, reversibility, and the consequence for existing page content.

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

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

Two short sentences, front-loaded with the core create/rewrite semantics before the folder special case. Dense and free of filler, though the capitalized 'IN PLACE' and parenthetical add mild visual noise.

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

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

An output schema exists, so return values need not be described. For a mutation tool with no annotations and 0% schema coverage, the description covers overwrite semantics and the CORE folder behavior but leaves key gaps: what happens to overwritten content, and how entity/content are expected to be formed.

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 all three parameters. It explains the special value 'CORE' for folder, adding real meaning, but leaves entity and content entirely undefined — no format, naming convention, or size expectations.

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 pair (create/rewrite) and resource (wiki page), and the parenthetical 'synthesized current truth, never an appended log' sharply defines the write mode, distinguishing it from log-style siblings like log_record and write_memory. It does not explicitly name those siblings, so it stops short of 5.

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

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

The 'never an appended log' clause implies when this tool is appropriate versus append-style tools, and the folder=CORE note signals a special use case. However, no alternative tool is named and no conditions or prerequisites are given for choosing write_wiki over write_memory or set_constraint.

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