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 split-and-ingest side effect, the two error modes with exact error codes, and the shared-knowledge behavior. It does not mention permissions or idempotency, but it is still substantially transparent.

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 verb, formats, and return contract, and the bilingual duplication is structured rather than rambling. It is longer than necessary because of the translation, but every section carries useful 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?

Given there is no output schema, the description supplies the return shape and error contract. Given there are no annotations, it also discloses the shared-knowledge side effect. A small gap remains around path qualification and prerequisites, but the agent has enough context to call the tool and interpret results.

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

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

Schema description coverage is 0%, and the description does add useful meaning for project/client: audit bucketing only and optional client auto-detection from clientInfo. However, the required path parameter is never explicitly described, and its format is only implied by 'local document' and FILE_NOT_FOUND.

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

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

The description opens with a specific action: import and ingest a local document. It names supported formats, states the exact return shape, and contrasts naturally with the sibling add_webpage by requiring a local path.

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 tells the agent this is for local files, that project/client are audit-only, and that ingested chunks become shared knowledge searchable by all clients. It does not explicitly name alternatives or state when not to use it, but the local-file requirement and the presence of add_webpage imply the boundary.

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 clearly specifies success return shape, failure error code, project/client's audit-only role, and that web chunks are shared knowledge searchable by all clients, while also noting client auto-detection.

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 main action and return behavior are front-loaded and the structure is logical, but the content is duplicated across Chinese and English sections, making it longer than strictly necessary. Each sentence does not fully earn its place because of the near-verbatim repetition.

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

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

For a tool with no annotations and no output schema, the description provides crucial invocation details: success/error returns, parameter roles, and sharing semantics. Minor gaps remain around url parameter documentation and any size/format constraints, but the core usage context is sufficiently complete for an agent 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 schema has 0% description coverage, so the description must compensate. It explains that client is optional and defaults from clientInfo, and that project/client are audit-only, but it does not describe the url format or project individually beyond the grouped 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 states a specific action ('抓取网页正文并切分入库' / 'Fetch a webpage body and ingest it after splitting') with a clear resource: a webpage. This distinguishes it from siblings like add_document and write_memory, which handle documents and memory respectively.

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 the tool is for ingesting web pages into shared knowledge, and clarifies that project/client are only for audit bucketing. However, it does not explicitly compare against alternatives like add_document, nor state when one should choose this tool over them.

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 is notably forthcoming: it discloses the retrieve-to-generation pipeline, retrieval scoping by (client, project) with doc/web memory shared, an emitted ask access-audit, client auto-detection from clientInfo, and the exact shape of the LLM-unavailable error response. These are concrete behavioral traits beyond a basic read, especially the audit side effect and error contract.

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 purpose is front-loaded and the content is logically segmented into pipeline, v2 behavior, client semantics, and error handling. However, the entire description is duplicated in Chinese and English, which roughly doubles the length without adding 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?

Given no output schema and sparse input schema, the description covers the important operational details: return shape (answer and sources), memory scoping, the audit side effect, and LLM-unavailable error handling. It does not specify the exact structure of sources or how the current (client, project) is fully resolved, but these are minor relative to what is disclosed.

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 add parameter meaning, and it does so only partially. It clearly explains client (optional, auto-detected from clientInfo) and indirectly ties project to memory isolation, but it does not define project's role directly nor describe the expected form/content of the required question parameter.

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

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

States a concrete action and resource: 'Knowledge-base RAG Q&A' / '基于知识库的 RAG 问答', with a described pipeline and return values (answer and sources). It is far from a tautology, but it does not explicitly contrast itself with sibling tools such as search_memory 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?

The phrase 'Knowledge-base RAG Q&A' and the memory-isolation note imply use for natural-language questions grounded in the KB rather than for memory CRUD or document ingestion. However, the description offers no explicit when-to-use, when-not-to-use, or alternative-tool guidance, so an agent must infer the decision.

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 of behavioral disclosure. It does well by specifying success and error return shapes, including NOT_FOUND and FORBIDDEN ownership restrictions. It could further disclose that the deletion is permanent and irreversible, but the core behavioral surface is 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?

The description is compact and front-loaded with the core operation and return values. The bilingual repetition adds some length but is acceptable given multilingual context. No filler or irrelevant details are present.

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

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

For a simple delete tool with no output schema and no annotations, the description covers the main operation, the three return states, the ownership restriction, and the optional client parameter. Minor gaps remain around project semantics and explicit irreversibility, but overall an agent has enough 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?

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for client by saying it is the source client and optional, defaulting from clientInfo. It does not explain project beyond its role in ownership, and record_id is only implicitly described as 'by ID'. Partial compensation but not full.

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 clearly states the action: deleting a memory by ID. It uses a specific verb and resource, and the tool name itself distinguishes it from siblings like write_memory and read_memory. However, it does not explicitly contrast itself with sibling tools, 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?

The description implies usage: use this tool to delete a memory by ID. It does not provide explicit when-to-use versus when-not-to-use guidance, nor does it mention alternatives such as update_memory for modifying existing memories. The context is clear but implicit.

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 transparently discloses NOT_FOUND and FORBIDDEN error responses, ownership rules, that shared knowledge is readable, and the default behavior for optional client/project parameters. This gives the agent a strong behavioral model without needing to invoke the 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?

The description is compact and front-loaded with the core action and error semantics. It includes bilingual text that duplicates the same information, adding minor redundancy, but the content remains well-organized and scannable.

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

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

For a simple read-by-ID tool with no output schema, the description adequately covers error scenarios, ownership, and optional parameter defaults. It doesn't detail the success response shape, but 'full content of memory' conveys the expected return. Overall, enough for an agent 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?

Schema description coverage is 0%, so the description must compensate. It explains that client is optional and auto-detected from clientInfo, and project defaults to the client's default bucket. record_id is self-explanatory as the ID. This adds meaningful semantics beyond the bare 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?

Description states a specific action: read the full content of a single memory by ID. It distinguishes itself from search_memory (which searches rather than reads a single record) and other sibling write/update/delete tools. The error cases further clarify the scope.

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 clearly implies when to use: when you have a memory ID and want its full content. It explains optional client/project defaults and ownership constraints. However, it doesn't explicitly name alternatives or state when not to use this tool versus 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 zero annotations, the description carries the full burden and delivers substantially: hybrid retrieval mechanism, RRF fusion, response item fields, ownership scoping, the INVALID_ARGUMENT error contract for top_k < 1, and client auto-detection from clientInfo. It does not cover every possible trait (auth, rate limits), but the core behavioral contract an agent needs before calling is well disclosed.

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 function and every sentence conveys a distinct fact, but the full bilingual duplication doubles the length for any single-language reader. The top_k error contract and client parameter note are appended after the main body rather than integrated with a parameter section, making the structure slightly scattered.

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 hybrid-retrieval tool with a bare schema and no annotations, the description covers nearly everything an agent needs: retrieval method, return fields, scope behavior, error contract, and the client shortcut. The remaining gaps — a semantic definition of top_k and a dedicated project explanation — are minor because the parameter names are reasonably self-descriptive and the default of 5 is present in the schema.

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 client (optional, auto-detected from clientInfo), partially for top_k (only the error condition is stated; no explicit 'maximum number of results' definition), and not at all for project, which appears only inside the ownership scoping rule rather than as a parameter definition. This is meaningful but incomplete compensation for a fully undocumented schema.

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

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

The description opens with a specific verb+resource pair — '混合检索记忆与知识' / 'Hybrid retrieval over memories and knowledge' — and specifies the mechanism (vector + BM25 keywords, RRF-fused) and result shape (hits with id/content/score/type/source). This clearly distinguishes it from the CRUD memory siblings (write/read/update/delete_memory) by positioning it as cross-source retrieval, and the v2 scope rule further differentiates personal memory from shared knowledge.

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 usage through the v2 scoping rule (personal memory only for current client/project, shared knowledge visible to all) and the error contract, but it never explicitly states when to choose search_memory over read_memory or ask_kb. There are no 'use X instead' statements or exclusions. An agent can infer this is the retrieval/search tool among its siblings, but the guidance remains implicit rather than explicit.

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 present, so the description carries the burden of behavioral disclosure. It usefully reveals that content is auto-re-embedded on change, and it documents the main error responses (NOT_FOUND, FORBIDDEN, INVALID_ARGUMENT) and the optional client defaulting from clientInfo. Some detail around ownership determination and success return is missing, but the core 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?

The description is front-loaded with the primary purpose and includes important error behavior. However, it duplicates the same content in Chinese and English, which adds length without adding new information; the English section is mostly a redundant translation.

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 that there is no output schema, the description does not specify what a successful response looks like, and the project parameter remains ambiguous. It covers primary errors and behavior well, but for a mutation tool with no structured annotations or output schema, a bit more detail would be needed for full completeness.

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 adds meaningful semantics for the client parameter by explaining it is optional and auto-detected from clientInfo, and content/record_id are reasonably inferable from the main action. However, the project parameter is essentially unexplained beyond the ownership error mention.

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 clearly states the tool updates a memory's content by ID, which is a specific verb+resource action. It inherently distinguishes itself from siblings like write_memory, read_memory, and delete_memory by referencing an existing record via ID.

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 update-by-ID behavior implies when to use it, and the error conditions provide some context for expected failures. However, there is no explicit statement about when to prefer this tool over write_memory or other alternatives, so usage guidance is only implied.

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 it well: it discloses the success return format ({"id": ...}), the error case for empty/blank content, how identity is derived from the MCP handshake, that the primary key is server-generated, and that shared knowledge is separately namespaced. This is far more transparent than typical tool descriptions.

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 key purpose and return format are front-loaded, and the v2 notes are useful. However, the description duplicates nearly all information in Chinese and English, roughly doubling the length. The structure is organized but not optimally concise.

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

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

For a write tool with no output schema and no annotations, the description is quite complete: it covers return values, validation errors, identity/resolution, key generation, and boundary with shared knowledge tools. Minor missing pieces are explicit guidance on when to prefer read/update/delete siblings and any permission requirements.

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 content as the memory text, tags as optional, project as the project/task bucket with empty meaning default, and client as auto-detected from MCP clientInfo. This adds real meaning beyond the bare schema, though it does not specify tag element constraints or content length limits.

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

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

The description opens with a clear verb and resource: '写入一条记忆短文本' (write a memory short text) with optional tags and project, and specifies the return shape. It also distinguishes itself from add_document/add_webpage by noting that shared knowledge is visible to all clients, which implies this tool is for non-shared 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?

The description provides context on when the tool is appropriate by explaining the client/project identity model and contrasting shared knowledge tools (add_document/add_webpage) as visible to all clients. It does not explicitly state 'when not to use' or name alternatives for read/update/delete, but the context is clear enough for an agent to choose correctly.

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