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

No annotations exist, so the description carries the full burden; it usefully discloses the return shape (source/chunks) and the two error codes with reasons, which is real behavioral value. However it omits permissions/auth, idempotency, and what happens on re-import or duplicate files.

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 operation and return contract, which is good structure. But the entire content is duplicated in Chinese and English, roughly doubling length without adding information, and the parameter notes trail after the return-value block.

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

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

With no output schema the description correctly supplies the return and error contract, and with no annotations it covers parameter meaning. It is only missing the safety/permission profile and path-format semantics, so it is close to complete for a 3-parameter ingest tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does well for project (sub-store target, empty = global) and client (audit-only), but the required `path` parameter is left unqualified – no indication of whether it is a server-side or client-side path or an absolute vs relative path.

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 (import/split/ingest) and resource (local document) plus the supported formats, so it is distinguishable from the sibling add_webpage via the 'local' qualifier. It stops short of naming the sibling explicitly, but the intent 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?

No explicit when-to-use or when-not-to-use guidance. It never mentions add_webpage (the obvious alternative for remote content) or any prerequisite/precondition, leaving the agent to infer that this tool is only for local files.

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 reasonably well: it discloses both the success return shape ({source, chunks}) and the failure shape including the WEB_FETCH_FAILED error code and a reason message. It also explains the storage scoping rule (project sub-store vs global). It stops short of auth requirements, rate limits, or duplicate-URL behavior.

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

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

The content is front-loaded and each piece of information is useful, but the entire description is duplicated verbatim in Chinese and English, which doubles the token cost without adding information for a reader who understands either language.

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?

There is no output schema, so the description's disclosure of the return and error shapes is exactly what is needed. For a simple 3-parameter ingestion tool with no annotations, the description covers purpose, parameters, and outcomes adequately; only operational details like deduplication or size limits 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?

Schema description coverage is 0%, so the description must compensate, and it does for the non-obvious parameters: 'project' is explained as the destination sub-store with empty meaning global, and 'client' is explicitly flagged as audit-only metadata. 'url' is self-evident. This adds real meaning beyond the echoed titles in the schema.

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

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

The description states a concrete verb chain and resource: fetch a webpage body, split it, and ingest it into the store. That is far more specific than the bare name, but it never differentiates itself from the sibling add_document (file-based ingestion) or write_memory, so an agent must infer which ingestion tool to pick.

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

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

Usage is only implied by the phrase 'fetch a webpage body and ingest it' — an agent can infer this is for pulling web content into the knowledge base. There is no statement of when to prefer add_document over this tool, no prerequisites, and no exclusions (e.g. unsupported schemes or already-ingested URLs).

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 meaningful behavior: the retrieve→context→guarded-generation pipeline, the side effect that an ask access-audit is written, that client is audit-only, and the exact failure contract {"error": "LLM_DISABLED", ...}. It stops short of covering auth requirements, rate limits, or result-size limits.

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 content is front-loaded and dense, but the English block restates the Chinese block nearly verbatim, roughly doubling the length without adding information. A single-language description would carry the same payload.

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

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

No output schema exists, so the description correctly takes on the return contract (answer + sources, plus the error object) and covers the one non-obvious side effect. Missing detail is limited to the shape of sources and any size or rate limits.

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 successfully explains project (sub-store + global, empty = global only) and client (optional, auto-detected from clientInfo, audit-only), which the schema alone gives no meaning for. Only 'question' is left without added detail, but its meaning is self-evident.

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: 'Knowledge-base RAG Q&A (retrieve → build context → guarded generation), returning answer and sources'. It is unambiguous about what the tool produces, but it does not name or contrast with siblings such as search_memory, so an agent must infer the boundary itself.

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

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

Usage is implied by the pipeline and by the project/client explanations, and the LLM-disabled fallback gives situational context. However, there is no explicit when-to-use-this-vs-search_memory guidance, no statement about question phrasing, and no exclusion conditions.

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 burden and does substantial work: it discloses cascade deletion of BM25 and vector indexes, the {"source", "deleted"} return shape, the INVALID_ARGUMENT failure for empty source, and that client is audit-only metadata. It stops short of stating whether deletion is recoverable, what the `deleted` count represents, or whether elevated permissions are required for a destructive operation.

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?

Content is front-loaded with the destructive scope and cascade behavior in the opening sentence, which is correct ordering. But the entire text is duplicated verbatim in Chinese and English, roughly doubling length with zero added information for a single agent, and the parenthetical error/parameter notes are run together in one block.

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 destructive tool with no annotations and no output schema, the description supplies the essential load-bearing facts: what gets removed, that secondary indexes are cascaded, the return shape, and the error condition. Only permission/auth prerequisites and irreversibility are unstated, which is a minor residual gap given the rest of the coverage.

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 explains the role of all three parameters: project selects the sub-store (empty = global), client is audit-only, and source is the deletion key. The remaining gap is that the required `source` parameter's expected format (exact URL, path, or filename) and matching semantics are never specified.

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 with explicit scope: delete *all records* of one RAG document/webpage/table, keyed by source. That scope wording distinguishes it from the sibling delete_memory (which operates on memories, not ingested document records) without needing to open 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?

The description implies when to use it (purge a whole document's records by source) and explains the project sub-store selection and the empty-source error case. However it gives no explicit when-not-to-use guidance, never mentions the delete_memory sibling, and does not say anything about confirming intent before a destructive purge.

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 return payloads ({'ok': true} vs {'error': 'NOT_FOUND'}), the scoped search order for project, and that client is audit-only with auto-detection from clientInfo. It omits whether deletion is permanent/irreversible and any permission requirements.

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?

Content is front-loaded and clear, but it is presented bilingually with the English text duplicating the Chinese nearly verbatim, roughly doubling the length without adding information. That redundancy costs 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?

For a mutating tool with no annotations and no output schema, the description covers the essentials: return values, project scoping order, and audit behavior. It is nearly complete, only missing auth/irreversibility details and guidance on obtaining record_id.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'project' lookup behavior and clarifies 'client' is optional and audit-only, but says nothing about the required 'record_id' (format, where to obtain it), leaving one of three params 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 ('Delete a memory by ID') and the operation is unambiguously distinct from siblings like read_memory, update_memory, and write_memory. An agent can identify the correct tool without inspecting the schema.

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

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

Explains the resolution behavior for the 'project' parameter (project sub-store vs global store, and the lookup order when omitted), which is the main usage-relevant context. It does not state explicit when-not-to-use conditions or name alternative tools, but the delete semantics are self-evident.

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 idempotency semantics (`created=false`), the scope-consistency restriction, self-link rejection, and the failure envelope `{"error": <CODE>, "message": reason}` with sample codes. It omits permission/auth requirements and the full success payload beyond the `created` flag.

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?

Each half is tight and front-loaded with the core action before the constraints, but the entire body is duplicated verbatim in Chinese and English, roughly doubling length without adding information. Efficient content, wasteful packaging.

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 and no output schema, the description covers the mutation's semantics, constraints, idempotency and error shape — enough to invoke correctly. Only the precise success return value and any authorization preconditions are unstated.

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

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

Schema description coverage is 0%, so the description must compensate — and it does for the non-obvious parameters: the five valid `relation` values, `project` (empty = global library) and `client` (audit only). `from_id`/`to_id` are left undefined but are self-evident from the purpose statement.

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

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

The description names a specific verb and resource ("Link two memories") and enumerates the exact relation vocabulary (related/supersedes/depends_on/part_of/contradicts), which also implicitly distinguishes it from the sibling `unlink_memory`. An agent knows precisely what this tool creates without opening the schema.

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

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

It gives concrete preconditions: both records must be in the same scope, self-links are rejected, and duplicate edges are idempotent. It does not explicitly route the agent to `unlink_memory`/`list_links` for the inverse or inspection cases, which keeps it short of a 5.

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

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

No annotations are supplied, so the description carries the full burden, and it does disclose genuinely non-obvious behavior: results are pre-aggregated per source with chunk and character counts, 'client' does not filter but is audit-only, and an empty project means the global store. What is missing is any statement about ordering, result limits, or behavior on an empty store — relevant for a listing call that can return many sources.

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?

Each language block is well front-loaded (purpose first, then parameters, then return shape), but the entire content is duplicated in Chinese and English, effectively doubling length with no added information. It also restates the return fields even though an output schema already exists.

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 0-required-parameter read-only listing tool with only two optional parameters and an output schema, the description covers purpose, both parameters, and aggregation semantics. The residual gap is operational detail (ordering, limits) that an agent might want when the store is large.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that project selects the sub-store with empty meaning global, and that client is audit-only rather than a filter — meaning an agent could not derive from the schema alone. It stops short of stating accepted value formats or whether unknown project names error or return empty.

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 ('List ingested RAG content') plus the aggregation semantics ('grouped by source') and the kind values allowed (doc/web/table). It is clearly an inventory/listing tool, distinguishable in intent from siblings like ask_kb or search_memory, though it never names an alternative explicitly.

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

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

Usage is only implied: the reader can infer this is the browse/inventory step rather than the retrieval step, and the note that project empty = global is a scoping rule. There is no explicit when-to-use/when-not guidance and no mention of ask_kb or search_memory as the alternative for content lookup.

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 describe behavior itself. It does describe the response keys and the error payload ('记录不存在返回 {"error": "NOT_FOUND"}'), which is useful. However, it says nothing about permissions, result-set size limits, pagination, or the cost of traversing a high-degree node.

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 purpose is front-loaded in the first clause, and the error behavior follows compactly. The content is fully duplicated in Chinese and English, which doubles the length without adding information, but each half is efficient and the overall size is manageable.

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 compensates well for the missing output schema by specifying the response keys and the NOT_FOUND payload. With no annotations and 0% parameter coverage, however, an agent still cannot tell what 'client', 'project', or 'relation' do, so the definition is not complete enough for confident invocation.

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 4 parameters, so the description must explain them, but it does not. 'relation' and 'direction' appear only as returned fields, not as input filters, and 'client'/'project' are never mentioned at all, leaving half the schema 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 names a precise verb and resource: 'List one-hop neighbors of a memory'. It also states the return shape, {'record_id','links'}. It never names a sibling such as search_memory or read_memory, so the agent must infer that this is a graph-traversal tool rather than a keyword search, but the purpose itself is unambiguous.

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

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

The phrase 'one-hop neighbors' implies graph exploration, but the description gives no explicit condition for choosing this tool over read_memory or search_memory, and it does not say when not to use it. The only usage behavior it states is the NOT_FOUND case for a nonexistent record.

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: the exact NOT_FOUND error shape, the store-resolution order for project lookups (project sub-store then global, vs global then each project store when omitted), and that client is audit-only and auto-detected. It stops short of stating permissions or the success payload shape.

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 core action is front-loaded and each sentence carries information, but the full Chinese/English duplication roughly doubles the length for a single-language agent, which is redundant rather than additive.

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

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

No output schema exists, and the description covers the failure return and store-resolution behavior, which are the non-obvious parts. The success payload is only gestured at ('full content'), a minor gap for a read-by-ID tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains two of three parameters well: project's lookup-order semantics and client being optional, auto-detected, and audit-only. record_id is left undefined but is self-evident from 'by ID'.

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

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

States a specific verb and resource ('Read the full content of a single memory by ID'), and the singular 'by ID' framing cleanly separates it from the sibling search_memory, which returns multiple matches. An agent can pick correctly without opening the schema.

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

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

The 'by ID' phrasing implies it is a direct-lookup tool that presupposes a known identifier, but the description never states when to prefer it over search_memory or how to obtain a record_id. Usage is inferred from context 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?

No annotations are provided, so the description carries the full burden and largely meets it: it discloses the return shape (id/content/score/type/source per hit), the error contract for top_k < 1, the project-boost behavior, and that client is audit-only. It omits auth/permission requirements and any latency or rate-limit context, 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?

Content is front-loaded and each clause carries information, but the entire description is duplicated verbatim in Chinese and English, roughly doubling the length for the same payload. That redundancy is a real cost against a tight token budget even if it aids bilingual readability.

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 retrieval tool with an output schema present, the description covers the scoping model, error behavior, and audit-only client well enough to call correctly. Since an output schema exists it need not detail return values, though it helpfully does; only query semantics and default top_k are left unaddressed.

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 most parameters: project's scoping effect, top_k's validation boundary, and client's optional/auto-detected/audit-only nature. The query parameter itself is left unexplained and top_k's default (5) and result-count meaning are not spelled out, so it is strong but not complete.

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 — hybrid retrieval over memories and knowledge — and even names the retrieval mechanism (vector semantics + BM25, normalized fusion), so the agent knows exactly what operation this performs. It does not, however, differentiate itself from siblings like read_memory or ask_kb, 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 through conditional scoping rules (with project → project sub-store + global; without project → global only), which tells the agent how the call behaves. But there is no explicit guidance on when to choose this over ask_kb or read_memory, and no exclusions 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 provided, the description carries the full burden and does disclose return values and an error case ({"ok": true, "removed": n} and NOT_FOUND). However, it does not state whether unlinking is reversible, what permissions are required, or any destructive side effects beyond link removal.

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 core behavior is front-loaded, but the description is duplicated in Chinese and English, creating redundancy rather than added clarity. It remains reasonably short and does not bury the key relation-empty rule.

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

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

For a mutation tool with no annotations, no output schema, and five parameters at 0% schema coverage, the description leaves important gaps: parameter meanings for client/project/from_id/to_id, required permissions, and reversibility are absent. Return shape and NOT_FOUND are covered, but the overall definition is not complete enough for confident invocation.

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 all five parameters, but it only clarifies relation semantics and does not explain from_id, to_id, client, or project. An agent must infer the meanings of most parameters from their names 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?

States a specific verb and resource: remove links between two memories, with scope details such as either-direction removal and clearing all relations when relation is empty. This clearly distinguishes it from the sibling link_memory tool.

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 implied usage guidance by explaining that an empty relation removes all relations for the pair, but it does not explicitly compare when to use this tool versus link_memory or list_links, nor does it state 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, the description carries the full burden and does well: it discloses auto re-embedding, that an absent record returns NOT_FOUND (i.e. no upsert), that blank content yields INVALID_ARGUMENT with a reason, and the project/global store lookup order. It omits permission/auth requirements and whether other fields are preserved, keeping it below 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?

Purpose is front-loaded, but the content is fully duplicated in Chinese and English, roughly doubling the length for the same information. Each individual sentence earns its place, yet the bilingual redundancy is a real efficiency cost.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description supplies the safety-relevant behavior (error codes, no-upsert, re-embed) and the resolution semantics. Auth/authorization and field-preservation behavior are the remaining gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it covers all four parameters: content (empty/whitespace validation), record_id (lookup by ID), project (sub-store then global lookup order), and client (audit-only, auto-detected from clientInfo). Values are meaningful beyond the bare schema titles.

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 ('Update a memory's content by ID') plus the key side effect ('auto re-embed on change'), which clearly separates it from read_memory, delete_memory, and search_memory. It never names a sibling explicitly, so it stops short of a 5, but an agent can pick it correctly without opening the schema.

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

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

Usage is implied rather than stated: the ID-based update signals 'edit an existing record', and the project/client resolution rules tell the agent how to target the record. There is no explicit when-to-use vs write_memory alternative and no prerequisite guidance, so it remains minimum viable.

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 well: it states the return shape ({"id": record_id}), the validation failure mode and error payload for empty/blank content, that the primary key is server-generated, and that 'client' is audit-only and auto-detected. It omits concurrency/duplicate-handling behavior, which keeps it from a 5.

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

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

Core action and return value are front-loaded, and each sentence is informative. The full bilingual duplication roughly doubles the length, but the structure remains clean and non-repetitive per language.

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

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

For a 4-param write tool with no annotations and no output schema, the description covers return value, error case, and all parameter roles, which is enough for correct invocation. Remaining gaps (duplicate handling, size limits on content) are minor.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: content is defined as the fact/note/summary text, project selects the sub-store with 'empty = global', client is audit-bucketing only, and tags is optional. Tags get only a bare mention, leaving room for richer semantics.

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

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

The description gives a specific verb+resource ('write a memory short text (fact/note/summary)') and scopes the content type, so an agent understands what the tool does. It does not explicitly differentiate itself from siblings like update_memory or add_document, so it stops short of a 5.

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

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

It hints at content type (fact/note/summary) but provides no explicit when-to-use guidance, no conditions for choosing this over update_memory, add_document, or add_webpage, and no exclusions. Usage must be inferred entirely from the tool name and contents.

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