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

With no annotations, the description carries the full burden for a mutation tool. It does not disclose required permissions, whether the grant is idempotent or revocable, what happens to existing grants, or the effect of the 'access' field. Worse, it says '读取' (read) while the schema permits write, leaving the actual behavioral scope of the grant unclear.

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

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

A single compact sentence front-loads the action and the resource/direction, with no wasted text. It is efficient, though its brevity is as much under-specification as concision.

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 0% parameter coverage, the description should explain the access parameter, permission requirements, and reversibility. It omits all of these and its read-only phrasing conflicts with the write option, so it is not complete enough to invoke confidently.

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

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

Schema coverage is 0%, so the description should compensate for all three parameters. It clarifies that owner_agent supplies the memory and principal is the receiving agent or team:id, but leaves 'access' (read vs write enum) entirely undefined and omits format details for the identifiers.

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 (grant/authorize) and resource (an agent's private memory) plus the direction of access. It is clearly a permissions-granting tool, distinguishable from the memory_* and event_* siblings by its authorization framing. It stops short of naming which sibling it complements (agent_recall/agent_remember), but the core purpose is unambiguous.

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

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

There is no guidance on when to use this versus memory_search, memory_add, or agent_recall, nor any prerequisites, exclusions, or the conditions under which a grant is appropriate. The agent must infer the entire usage context from the one-line purpose.

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 the access model (private + permissioned team + granted) and that results carry source snippets. It says nothing about permission failure behavior, rate limits, or how token_budget constrains output, which matters for a retrieval tool with a budget parameter.

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

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

A single compact sentence with the core scope front-loaded and no filler. It is efficient, though it spends its length on scope enumeration rather than on the parameters that need explanation.

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 five-parameter retrieval tool with no annotations, no output schema, and zero schema description coverage, the description is thin. It partially covers the return shape ('带来源段落的上下文') but leaves the budget and count parameters, and any auth requirements, unexplained.

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

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

Schema coverage is 0%, so the description must compensate for five undocumented parameters, and it largely fails: only the scope concepts loosely map to agent_id and teams. top_k and token_budget — the two parameters that control result size and cost — are never mentioned.

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

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

States a specific verb (检索/retrieve) and resource (记忆/memory), and enumerates the three scopes searched: private, permissioned team shared, and granted others'. This distinguishes it from generic memory_search by scope, though it never names the sibling explicitly.

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

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

The description implies the tool is used when acting as a specific agent_id, but gives no explicit when-to-use guidance and never contrasts it with memory_search or the other memory siblings. The choice between agent_recall and memory_search is left entirely to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose two important traits: it returns a profile record and re-registering updates role/metadata instead of erroring. However, it does not say whether metadata is merged or replaced, who may register, or whether a name is globally unique.

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

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

A single compact sentence with the core purpose front-loaded and the upsert caveat appended after a semicolon. No filler, though the parenthetical precondition could be folded in more cleanly.

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 annotations and no output schema mean the description should do more, and it does cover the mutation semantics and that a profile is returned. It still falls short on the nested metadata payload and on the identity/uniqueness model, which matter for a 3-parameter registration 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 only mentions role and metadata obliquely in the update clause. The required 'name' key, the default role of "member", and especially the nested metadata object's expected keys are left entirely unexplained.

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

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

The description gives a specific verb (注册) and resource (agent), plus the payoff (returns a profile) and the upsert behavior. It is clearly distinguishable from the siblings (memory_*, agent_remember/recall/grant), though it never names them.

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?

"多 agent 协作的前提" implies when to call it (before any multi-agent work) and the duplicate-registration case is spelled out, but there is no explicit when-not guidance or pointer to an alternative for reading existing agents (e.g. agent_recall).

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

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

With no annotations, the description carries the full behavioral burden, and it only discloses one trait: that supplying team_id also writes into a team shared space. It says nothing about idempotency, overwrite/dedup behavior, permission or auth requirements, failure modes, or what the 'share' default of true actually implies.

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 single sentence is front-loaded and free of filler, so it reads efficiently. But given six parameters, nested objects, and zero schema documentation, this level of brevity is under-specification rather than disciplined conciseness.

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 6-parameter mutation tool with nested objects, no annotations, and no output schema, the description covers only the team-sharing branch. An agent still lacks the information needed to call it correctly and predict its effects.

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 6 parameters, and the description only explains team_id's side effect. Required fields (agent_id, messages), the share default, metadata, and event_time receive no semantic clarification anywhere, leaving the agent to guess formats such as event_time encoding or the accepted message shapes.

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 ('以 agent 身份写入记忆' – write memory as an agent), which tells the agent this is an agent-scoped write rather than a generic one. It does not, however, distinguish itself from the sibling memory_add, so an agent cannot tell which write tool to pick from the description alone.

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

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

There is no statement of when to use this tool versus memory_add, memory_search, or memory_consolidate, and no prerequisites or exclusions. The team_id clause describes a behavioral effect rather than a selection rule, so usage must be 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?

No annotations exist, so the description carries the full burden. It does disclose that as_memory=true has a synchronous side effect of writing to shared memory, but it never says whether the event is broadcast to all team members, whether it is persisted/replayable, what permissions sender needs, or what failure modes exist.

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

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

One compact sentence with the core action front-loaded and no filler. However, brevity here is under-specification rather than economy, given four required undocumented parameters.

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 mutation/publish tool with no annotations, no output schema, and 0% schema coverage needs the description to do far more work. It covers one flag out of five parameters and omits delivery semantics and return shape entirely.

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

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

Schema description coverage is 0% for 5 parameters. The description explains only as_memory (the flag and its effect); team_id, sender, event_type, and text carry no format, constraint, or accepted-value information anywhere. event_type in particular is an unconstrained string with no examples, which leaves the agent guessing.

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: publish an event to a team, characterized as an inter-agent message. The publish/pull split against sibling event_pull is inferable from the verb, but the sibling is never named, so differentiation is implicit rather than explicit.

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 only conditional given is that as_memory=true also writes to shared memory, which is a parameter behavior, not guidance on when to use this tool. Nothing says when to prefer event_post over event_pull or memory_add, nor what a team_id must already exist for.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only that results are incremental from a cursor; it says nothing about ordering, whether limit truncates results, how to detect end-of-stream, or what the response contains, all of which matter for a polling tool with no annotations.

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

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

A single short sentence with the incremental/cursor constraint front-loaded and no filler. It is efficient, though the brevity contributes to the missing behavioral detail.

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 four parameters at 0% schema coverage, no annotations, and no output schema, the description leaves too much unexplained: cursor semantics for paging, limit behavior, response shape, and scope of agent_id vs team_id are all absent.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It only explains since_id as a cursor (events after it) and says nothing about agent_id, team_id, or the meaning/limits of the limit 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?

The description states a specific verb (增量拉取 / incrementally pull) and resource (团队事件流 / team event stream), and the parenthetical clarifies the cursor-based scope (events after since_id). This distinguishes it from event_post, though it never names that sibling explicitly.

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

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

Incremental/cursor semantics imply the polling use case, so an agent can infer when to call it. However, there is no explicit statement of when to use this versus event_post or how it relates to the memory/recall siblings, and no preconditions (e.g., required agent/team membership) are given.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose genuinely non-obvious behavior – automatic fact extraction, deduplication, and conflict handling – which is valuable for a write tool, but it omits scope/isolation requirements, idempotency, whether the call is synchronous, and how conflicts are surfaced to the caller.

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

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

A single sentence with the write action and its automatic side effects front-loaded, and no filler. Nothing in it is redundant.

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 a nested scope object and no output schema, the description covers what goes in and what the system does with it. The gap is that with no output schema and no annotations, nothing is said about what the caller gets back or how to recover the extracted/conflicting facts.

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 75%: scope (with its isolation meaning), messages, and event_time are documented in the schema, but metadata is undocumented in both places. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 (长期记忆), and lists the input types (对话、事件、文档), so an agent immediately knows it is a write/ingest tool. It does not differentiate from the near-sibling agent_remember or memory_consolidate, which are also write-ish operations.

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 accepted content types (conversation, event, document); there is no explicit statement of when to choose memory_add over agent_remember or memory_consolidate, and no prerequisites or exclusions are given. An agent can guess the context but is not routed.

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. It does disclose that the tool merges/removes memories (dedupe, conflict resolution), which hints at mutation of existing data, but says nothing about reversibility, permissions, expected duration, or whether it runs synchronously — all material for a consolidation job.

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

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

Two short sentences, operations front-loaded, timing recommendation second. No filler and nothing repeated from the schema.

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 no-annotation, no-output-schema, mutation-style tool, the description should at least address scope defaults and the nature of the result. It covers what and when but leaves the agent guessing about the effect of omitting scope and what a successful run returns.

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 100% and the single 'scope' object already documents its four sub-fields (user_id, agent_id, tenant_id, session_id) and their multi-tenant isolation purpose. The description adds nothing about scope semantics, and notably does not say what happens when the optional scope is omitted (all users? current session?). Baseline 3 applies since the schema does the work.

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 the resource (memory) and enumerates four concrete operations: dedupe, conflict resolution, session summarization, and profile refresh. This distinguishes it from siblings like memory_search, memory_add, and memory_forget, which cover retrieval, insertion, and deletion rather than batch consolidation. It stops short of a single crisp verb+object statement, but the operation list is specific enough to act on.

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

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

'建议在会话结束后调用' gives an explicit trigger condition — call it at the end of a session — which is the main decision an agent needs to make. There is no guidance on when NOT to call it, no mention of cost or idempotency, and no reference to an alternative sibling if the agent only needs one of the four operations.

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

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

No annotations exist, so the description carries the full burden; it does add real behavioral value by disclosing that deletes are soft by default with audit records retained, and that hard=true is a physical deletion. It omits permissions/authorization, whether hard delete is reversible, and critically what happens when neither ids nor query is supplied given zero required parameters.

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

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

A single tight sentence, front-loaded with the verb and the two selection modes, with the destructive-flag detail placed last where it matters. Nothing redundant, though the density means the parameter interaction stays unexplained.

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 destructive 4-parameter tool with zero required params, a nested scope object, no annotations and no output schema, the description covers the safety-critical soft/hard distinction but leaves open the risk of an unscoped mass delete, permission requirements, and return/confirmation behavior.

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

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

Schema description coverage is 25%, with only the nested scope object documented. The description rescues the meaning of `hard` (default false, physical vs audit-preserving) and loosely maps ids/query as the two selection paths, but says nothing about how ids and query interact, how scope narrows the deletion, or which nested scope fields matter.

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 plus resource (delete memories) and names both selection modes (by id or by query), along with the soft/hard delete distinction. None of the sibling tools (memory_search, memory_add, memory_profile, memory_consolidate...) covers deletion, so an agent can route here without sibling ambiguity, though the description never states that 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 implied by the 'soft-delete by default, hard=true physically deletes' framing, which gives a usable default-vs-escalation rule. There is no explicit when-not or caution about irreversible hard deletes, and no named alternative for non-destructive cleanup.

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 at all, the description has to carry the behavioral load, and it does imply read-only semantics via 读取 and states the two classes of content returned. However, it is silent on what happens when scope is omitted (global vs. default user), whether anything is mutated or cached, and how large or paginated the response is.

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

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

One sentence that leads with what is read and follows with when to use it; no filler, no repetition of the name.

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 zero-required-parameter read tool this covers the essentials, but with no output schema and no annotations, the agent still cannot tell what a call without scope returns or what the statistics payload looks like. A brief note on default scoping behavior would close the remaining gap.

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 100%, including a description on the nested scope object, so the schema already does the parameter work and baseline 3 applies. The description never mentions the scope parameter or its user/agent/tenant/session dimensions, adding no meaning beyond 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 pairs a specific verb (读取/read) with two named resources (用户画像块 / user profile blocks and 记忆库统计 / memory store statistics), which clearly separates it from siblings like memory_search or agent_recall that query individual memories. It stops short of explicitly naming an alternative, but the scope of what it returns 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?

It gives a concrete usage context — '适合在会话开始时加载' (best loaded at session start) — which tells the agent this is a bootstrap/priming call rather than an on-demand query. It does not name exclusions or point to a sibling for the non-session-start case, so it falls 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 exist, so the description carries the full disclosure burden, yet it only notes that results carry source and confidence. It says nothing about ranking behavior, whether expired facts are merged, tenancy isolation effects, or cost/latency tradeoffs from token_budget — all of which matter for a retrieval tool with history semantics.

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

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

A single compact sentence with no filler, and the key behavior (source- and confidence-tagged snippets) is front-loaded. It is arguably too terse rather than bloated, so conciseness itself is not the problem.

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 5 parameters, a nested scope object, no annotations, and no output schema, the description should explain scope isolation, budget controls, and the include_history auto-detection behavior. It covers none of these, leaving the agent to infer how retrieval limits and history inclusion actually work.

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 60% and the description adds zero parameter meaning. top_k and token_budget have no descriptions anywhere, and the nested scope object's isolation semantics are only hinted at in the schema's own text, not clarified by the description.

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

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

The description gives a specific verb+resource (检索/长期记忆) and states what comes back (带来源与置信度的上下文片段). However, it does not differentiate itself from sibling retrieval tools such as agent_recall or memory_profile, 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?

There is no statement of when to use this versus agent_recall, memory_profile, or memory_add, and no prerequisites or exclusions. The phrase '与当前任务相关' implies a usage context but gives no routing criteria.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the access-control semantics of open vs closed (who can read), which is real behavioral context, but omits permissions required, behavior when team_id already exists, and whether creation is idempotent.

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

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

Two short sentences, zero waste, and the core action is front-loaded ahead of the policy clarification.

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 creation/mutation tool with no annotations, no output schema, and zero schema coverage, the description is only partially complete: access semantics are covered, but required identifier formats and creation edge cases are not.

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% across three parameters, so the description must compensate. It does explain the policy enum values clearly, but leaves members (presumably user/agent identifiers?) and team_id completely unexplained.

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

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

States a specific verb and resource: creating a team shared memory space. The word 'team' differentiates it from memory_add/memory_search siblings, 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 implied by the name and the policy explanation, but there is no explicit guidance on when to call this versus memory_add or agent_remember, nor any stated prerequisites (does the team need to exist first?).

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