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 substantive behavior: what is kept (first lines, error/failure/warning/test-total lines, last lines) and that the full text remains queryable via recall this session. It does not discuss side effects on existing memory, permissions, or size limits, so it is strong but not exhaustive.

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

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

Front-loaded with the core action and an explicit breakdown of what is returned, followed by a compact Args section. Every sentence carries information; the Args block mildly duplicates the schema but adds the example and rationale.

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 read-only-style tool with an output schema, the description covers purpose, return composition, and retention semantics. With no annotations, it could say more about session scope and side effects, but nothing critical to 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 coverage is 0% and both properties are bare, but the description compensates: text is identified as the raw output and label as a short recall key with a concrete example ("maven-build"). It adds real meaning beyond the schema, though it doesn't note the default value or label uniqueness.

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 (condense) plus resource (long command output such as build logs/test reports) and immediately clarifies the retention side effect. An agent can distinguish this from siblings like save_memory or recall because the description frames it as summarization-plus-retention rather than storing or fetching.

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 clear context: use it on long command output (build log, test report). It references recall("<label> ...") for later retrieval, letting the agent infer the workflow, but it names no explicit when-not or alternative tool for the same job, so it stops just short of 5.

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 well: it discloses the return shape, the AMBIGUOUS state and how to respond, and that the index resyncs by checksum so code is never stale. It omits permission/error behavior, but the key behavioral traits of this search tool are 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?

Purpose and output format are front-loaded, followed by an Args block that parses cleanly. It is slightly long, but each sentence adds operational value (output shape, ambiguity handling, param meanings) rather than filler.

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

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

For a six-parameter search tool with an output schema already covering return values, the description supplies everything an agent needs to call it correctly: scope defaults, subpath restriction, ambiguity recovery, and token capping.

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 fully and does: every one of the six parameters is explained, including scope's valid values ('main' default skipping tests, 'test', 'all'), subpath's containment, clue's role after an AMBIGUOUS reply, and max_tokens' cap.

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 (find the method or class answering a question) and its scope, and distinguishes itself from siblings by returning only the symbol 'instead of whole files', which implicitly separates it from read_file and project_map.

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 clear context: name the class/method when known, handle AMBIGUOUS by refining the query or passing `clue`. It does not explicitly name sibling alternatives or state when NOT to use it, so it stops short of a full when/when-not routing rule.

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

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

With no annotations present, the description carries the burden and does real work: it discloses that the old memory is not deleted (kept because it was true on its date) and that it carries an OUTDATED notice, plus that searches surface the new memory first. It omits whether the operation is idempotent or requires prior save_memory output, but the destructive/ordering semantics are clearly communicated.

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 behaviour and the tool-flow context are front-loaded in the first two sentences, then the args are documented compactly. Slightly more text than strictly needed for two parameters, but nothing is 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 no explanation, and the description covers purpose, precondition flow, and both params. The only gap is the absence of any note on failure cases (e.g. hub id not found or already outdated).

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 both parameters are bare strings, so the description must supply meaning — which it does by defining old_id as 'the memory that is no longer current' and new_id as 'the memory that replaces it'. It does not specify id format or where to literally find them beyond the tool reference, so not a full 5.

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

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

States a specific verb and resource ('Flag one memory as corrected by another') plus the exact effect on the memory store. It also implicitly distinguishes itself from siblings save_memory and search_memory by naming them as the upstream steps, so an agent can tell it apart without opening schemas.

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

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

Gives a clear when-to-use context ('after save_memory listed candidates') and where the ids come from ('save_memory or a full search printed'). It does not state when NOT to use it or what to do if only one id is known, so it stops short of explicit alternatives.

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

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

With no annotations, the description carries the full burden and does well: it discloses lifecycle semantics that are not derivable from the schema — notes survive context compaction but vanish when the session ends. It also advises including file:line. It stops short of stating whether notes are mutable, deduplicated, or how they surface on recall, which leaves a small gap for a persistence 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?

Three short sentences, front-loaded with the core action, then persistence behavior, then the routing rule to save_memory. No filler; every sentence adds a distinct fact.

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. For a one-parameter persistence tool with no annotations, the description covers purpose, lifecycle, content guidance, and the sibling boundary — everything an agent needs to call it correctly.

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

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

The single `text` parameter has 0% schema description coverage, but the description compensates by explaining what the content should be (a learning, with file:line when relevant). That is meaningful guidance beyond the bare string type, though it does not discuss length limits or formatting.

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 action and resource: keeping a learning from the current session, with concrete examples of what counts (where a thing lives, what a method does, a result). It explicitly contrasts itself with save_memory for durable facts, so an agent can separate it from siblings like save_memory and recall without opening any schema.

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

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

Gives explicit when-to-use (session-scoped learnings), when-not (durable facts belong in save_memory), and names the alternative tool. The condition that selects between this and save_memory is stated outright rather than inferred.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious runtime behavior: it indexes the project on first use and resyncs changed files by checksum on every call. It does not discuss cost/latency on large repos, read-only guarantees, or failure modes for an invalid path, so it is strong but not complete.

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

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

Front-loaded purpose sentence, then the behavioral/usage line, then a compact Args block. Every sentence earns its place and nothing is repeated between the prose and the parameter list.

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; the description covers the remaining agent-relevant questions, namely when to reach for it and what each parameter controls, including the cost trade-off between detail levels.

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 compensation is required and the Args block delivers it: path is the absolute project root, detail distinguishes 'files' (cheapest) from 'symbols' (adds methods/classes with first-last line), and subpath is scoped with a concrete example ('src/main'). This adds real meaning the bare schema does not carry.

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 artifact (a compact map of a codebase: files with token sizes, optionally symbols and line ranges) rather than a vague action. The line 'Call it before exploring a project instead of listing directories and opening files' implicitly separates it from siblings like find_code and read_file, so an agent can route correctly without opening a schema.

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

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

Explicitly prescribes the situation to use it ('before exploring a project') and names the alternative behaviors it replaces (listing directories, opening files). It stops short of when-not-to-use guidance (e.g. single-file lookups where read_file suffices), but the intended context is unambiguous.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior beyond the schema: repeat reads return 'UNCHANGED' or a unified diff, and force bypasses that optimization. It does not cover error behavior (missing path, non-text/binary files) or any permission/size constraints, but the caching semantics are unusually well surfaced.

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

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

Front-loads the most decision-relevant fact (session caching and the UNCHANGED/diff behavior) before the parameter block, and every sentence earns its place. The Args list duplicates the schema field names, but with 0% schema description coverage that repetition is functional rather than wasteful.

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

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

An output schema exists, so return values need not be described, yet the description still explains the two non-obvious return forms (UNCHANGED, unified diff). Given no annotations and a four-parameter tool, the only real gap is failure-mode behavior, which is minor for a read operation.

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 supply all parameter meaning, and it does: path is absolute, force returns full content, start_line is 1-based with 0 meaning whole file, end_line is inclusive with 0 meaning end of file. This fully compensates for the empty schema, though it mostly restates the documented defaults rather than adding edge-case guidance (e.g. start_line > end_line).

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 opening sentence states a specific verb and resource (read a text file) and adds a non-obvious scope trait: session-scoped memory of prior reads. It references project_map as a source of line ranges, but it does not explicitly differentiate itself from other retrieval siblings like find_code or recall, which are plausible alternatives for getting code into context.

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 clear when-to-use guidance: prefer this over re-reading a file already read in the session, and use force=true specifically when the earlier copy was lost after a context compaction. It stops short of naming an explicit alternative tool or stating when this tool is the wrong choice.

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

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

No annotations, so the description carries the burden. It usefully discloses scope (session-only, not long-term) and a cost/benefit trait (cheaper than re-reading/re-running), but says nothing about permissions, rate limits, or mutation behavior. Adequate but not rich for an annotation-free 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?

Two tight sentences with zero filler, and the essential scope constraint is front-loaded ahead of the cost rationale.

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

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

The output schema covers return values and the description covers scope well, but the unexplained 'clue' parameter and the absence of any annotations leave real gaps. Complete enough to attempt a call, not complete enough to call 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% with two parameters ('query' required, 'clue' optional), neither documented in the schema. The description implies a search query but gives no meaning for 'clue' and no syntax/format guidance, so it fails to compensate for the coverage gap.

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

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

States a specific verb (Search) and a precise resource (things kept earlier in this session via note or digest_output), and explicitly distinguishes it from long-term memory. An agent can separate it from sibling search_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?

Gives clear context (recall session-stored notes rather than long-term memory) and a when-to-use rationale (cheaper than re-reading files or re-running commands). It implicitly routes long-term lookups to search_memory but never names that sibling as the alternative, so the exclusion is stated but the target tool is not.

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 so: it discloses the side effect that 'replaces' flags the earlier memory OUTDATED and that searches then answer with the new one first, and the failure path where nothing is flagged and candidates are listed. It also states the tool reports filing location and contradictions that should be relayed.

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

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

Front-loads purpose and scope in the first sentence, then the inclusion/exclusion rule, then a compact per-argument block. Given zero schema coverage, the args section is necessary rather than redundant, and no sentence is 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?

A four-parameter write tool with no annotations and no output schema explanation needed; the description still notes the return signal to relay. Everything an agent needs to invoke it correctly, including the cross-memory side effect, is present.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for all four parameters: content (self-contained, date-prefixed), domain (default 'general' with a concrete example 'software.java'), content_type (enumerates values with 'auto' recommended), and replaces (meaning plus example 'RainDesktop version 1.3' and multi-match behavior).

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

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

States a specific verb and resource ('Store durable knowledge in the user's long-term memory (IHMT)') and immediately scopes it with what belongs and what does not. The 'IHMT' naming and the 'replaces' semantics clearly separate it from search_memory/recall/mark_outdated.

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

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

Explicit when-to-use ('decisions and why, setup, preferences, people and projects, procedures'), when-not ('not transient chat, not secrets'), plus formatting rules (self-contained, date prefix) and a named fallback to mark_outdated when several memories match. Routing is fully specified.

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 largely meets it: it discloses the return shape (best memory plus its date, one line per other match), the meaning of an AMBIGUOUS result and the recovery path, the obligation to relay OUTDATED notices, and the two `detail` modes. It never states whether the call has side effects, permission requirements, or result limits, which keeps 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?

The opening sentence front-loads the scope, the ambiguity/outdated handling follows, and the Args block is compact and scannable. It is slightly longer than necessary given an output schema already exists, since part of the return-format sentence restates what the schema exposes.

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

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

For a 3-parameter retrieval tool with no annotations and a documented output schema, the description covers the essentials: scope, query phrasing, ambiguity workflow, and outdated handling. Missing only edge-case behavior such as empty results, permission assumptions, or result caps.

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 does: each of the three parameters is explained with meaning beyond its title, including the conditional trigger for `clue` ('only after an AMBIGUOUS reply') and the actual difference between `detail` values ('compact' default vs 'full' adding ids, tree paths and excerpts).

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 ('Search the user's long-term memory (IHMT)') and enumerates the content it covers: decisions, setup, preferences, people, earlier sessions. That is far more than a tautology. It stops short of a 5 because it never distinguishes itself from the closest sibling, `recall`, which an agent must disambiguate on its own.

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

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

It gives concrete procedural guidance: use several distinctive words rather than a bare name, and pass `clue` only after an AMBIGUOUS reply. That is clear context for how and when to call it. It does not name any alternative tool or state when NOT to use this one, so it misses the 5 bar.

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