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

Annotations only supply the generic readOnly/destructive/idempotent/openWorld flags; the description adds real behavioral context on top: who may retract (publisher or owner), who may set instructions (owner), that invite returns a code and may create the teammate's account on the hub's PC, that a git attach reflects the true commit stage and must not overstate it, and what to do on NAME_REQUIRED and UNAVAILABLE. Nothing here contradicts the 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?

The intent is front-loaded, which is good, but the body is a ~500-word wall of dense pseudo-bullets mixing actions, parameters, membership rules and hub topology in one block. There is redundant restatement ('Nothing personal is shared through this' repeats the earlier exclusion), so several sentences do not earn their place.

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

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

For a 15-action, 18-parameter meta-tool this is unusually complete: it covers intent routing, permissions, membership lifecycle, hosting modes and the two named failure modes, and an output schema exists so return values need not be described. An agent has enough to pick the right action and parameters without guessing.

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 only 6%, so the description carries the burden, and it largely does: it explains workspace (bind your cwd), project, path, type, summary (one line, user's language), details (handover-note contents), supersedes (replaces an earlier decision), context payload fields, checkpoint_id, member/role/projects, code, name and hub. The mapping is prose-embedded inside action bullets rather than per-parameter, and source_refs plus some action-specific params are never addressed, so it falls short of a full 5.

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

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

The opening line states the resource precisely (team project brains holding decisions and progress shared with teammates' AIs, per project) and explicitly carves out the sibling it is not: 'Not for the user's own memory or their other PCs: that is brain_folder.' An agent can separate this from brain_folder and the personal-memory siblings without opening a schema.

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

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

It gives an explicit trigger ('Publish only when the user asks' with quoted user phrasings), a prohibition ('Never paste conversation text'), a fallback ('ask only if the project is ambiguous'), and a per-action routing table keyed to user intent (timeline for '누가 어디까지 했어?', invite for adding members). This is exactly the when/when-not/alternative guidance the dimension asks 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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: the return is a size cap-limited text of memories and turns with date and source, and `recent`/`around` change ranking semantics (newest-first vs word overlap; conversations from then rank first, nothing dropped). It does not discuss cost/latency or the interaction of `limit` with ranking, 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?

Front-loaded with the core purpose and the primary exclusion, then organized flag-by-flag. It is long, and the embedded Korean examples plus the measured statistic are dense, but each sentence carries routing or ranking information rather than filler.

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

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

With an output schema present, the description needn't enumerate return fields, and it still names the `context` payload. For an 11-parameter, default-memory tool, the when-to-use rules, flag semantics, and the explicit misleading-case warning give the agent everything needed to invoke 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 coverage is 64%, and the description compensates precisely for the undocumented parameters (recent, since, around, about_assistant), giving format hints ('ISO date or time', 'start..end') and semantic consequences. It leaves knowledge_cutoff and the exact ranking interaction with `limit`/`scopes` unexplained, so not a full 5.

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

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

States a specific verb+resource ('one bounded text packet to read before replying') and explicitly names the sibling it is not for structured rows/ids/history: brain_recall. An agent can distinguish it from brain_recall and brain_remember without opening any schema.

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

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

Gives an explicit default ('use it whenever a request may depend on earlier conversations, facts, preferences, decisions or work'), a routing rule to brain_recall, and per-flag conditions with concrete example queries (including Korean) for recent, since, about_assistant. It even states a when-NOT: do not set `around` for when something happened, with measured evidence (2 of 11 questions helped vs hurt).

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses real side effects: `path="share"` opens Postgres to the LAN/Tailscale, may trigger a one-time firewall prompt, and returns a connection_code containing a password with an explicit warning not to post it publicly. It also flags that export files contain the entire memory (secrets masked) and that share_existing uploads to the sync folder.

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

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

Purpose and the team exclusion are front-loaded, then usage follows mode-by-mode, which is the right order. It is still long and repetitively framed around quoted user utterances, but almost every sentence adds a distinct operational rule rather than restating 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 five-parameter tool with no schema descriptions but a present output schema, the description covers every parameter, the side effects of each mode, the privacy caveats, and the sibling boundary. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: `path` is defined across its value space (a named sync folder, `"local"` for on-PC Postgres, `"share"`, or a pasted gmt1./gm1. code), and reindex, export_to, import_from, and share_existing each get a concrete meaning, trigger, and effect.

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

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

The opening states the resource (the user's personal memory folder and which PCs share it), and the second paragraph explicitly excludes the sibling case: 'Not for teams: project brains shared with teammates are brain_checkpoint.' However, the tool is an omnibus of modes (folder config, share, code redemption, export/import, reindex) that the name 'brain_folder' does not signal, so an agent must read the whole description to learn the full 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?

Nearly every mode is gated on an explicit trigger: call with `path` when the user names a folder, use `path="share"` when the user asks other PCs to connect, use `path=<the code>` when any Graph-MIND code is pasted, and 'Set it only when the user has explicitly agreed' for share_existing. It also names the alternative (brain_checkpoint) and pre-empts a question ('never ask the user which kind it is').

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

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

Annotations already mark this destructive/non-read-only/idempotent, and the description goes well beyond them by specifying deletion scope (this PC, search indexes, shared memory, other PCs), that the deletion exchange itself is not saved, and that app chat history is separate. It does not, however, describe failure behavior or what happens if ids match nothing.

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?

Longer than most definitions, but front-loaded with the purpose and each block (examples, two-call protocol, deletion scope) earns its place. Slightly more verbose than strictly necessary, but no filler sentences.

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

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

An output schema exists, so return-value detail is unnecessary; the description instead supplies everything an agent needs to safely drive a destructive, two-step deletion — trigger conditions, privacy constraints, and blast radius. Nothing material is missing.

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

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

Schema description coverage is 0%, so the description carries the load, and it does: query must use general words and never repeat a secret the user typed; ids must be exactly the user-selected ones from the prior call. The mutual exclusivity/two-phase usage of the two optional params is implied clearly though not spelled out formally.

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 ('Delete what the user wants gone from memory') and grounds it in three concrete example utterances spanning languages. An agent can immediately distinguish this from brain_remember/brain_recall.

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 two-call protocol: first query with general words, then a second call with the selected ids 'and only those.' It also states the required interaction pattern (show masked previews, ask the user which to delete, never quote the original).

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: results are raw rows, `entity` returns oldest-first with replaced entries marked and the current one picked out, and the no-filter default lists busiest-first. It stops short of describing pagination or result-size 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?

Front-loaded with the key differentiator (raw rows vs ready context), then routing, then per-parameter behavior. Four dense paragraphs are on the long side but nearly every sentence carries distinct information; the `entity` versus similarity-search contrast earns its length.

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

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

An output schema exists, so return format needn't be restated, and the description covers routing, ordering, defaults, and the entity mode. The one gap is `query`, whose matching semantics are only obliquely implied by the similarity-search aside.

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 only 40%, so the description must compensate, and it largely does: `entity` is explained in depth and `recent`/`since`/`about_assistant`/`around` are cross-referenced to brain_context's semantics. `query` — arguably the primary selector — is never defined in either schema or description, which keeps this below a 5.

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

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

States a specific verb and resource ('Raw lookup: the matching memories and turns as structured rows') and immediately contrasts the output shape with brain_context's 'ready context'. An agent can distinguish it from siblings without opening a schema.

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

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

Explicit when-to-use routing ('To answer the user's question from their past, use brain_context instead') plus three concrete recall use cases (inspecting ids/fields before brain_forget or supersedes_memory_id, one thing's history, listing store contents). Alternatives and conditions are named, not 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses that a later value with the same `about`/`attribute` REPLACES the earlier one, that recall surfaces both current and prior values, that saving is silent with no user-facing confirmation, and that decisions should be stored with a reason. These are exactly the non-obvious behaviors an agent would otherwise get wrong.

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

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

Front-loaded with the core directive, then logically grouped into identity/supersession, triggering, and silence rules. It is long for a tool description and repeats the 'use the same attribute names' point twice, but nearly every sentence carries operational guidance rather than filler.

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

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

An output schema exists, so return values need no explanation, and the description covers the calling contract, supersession model and the required `content` field. The main gap is the absence of any guidance on `scope` (project vs global) and on when the optional metadata params matter, which for a 20-param tool is a real but secondary omission.

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 only 60%, so the description must carry weight, and it does for the semantically tricky params: it explains `about`/`attribute` pairing, the snake_case naming convention with a failure example ('last_trip', not 'last_trip_paris'), `content` as verbatim user text, plus `entities`, `effective_at`, `supersedes_memory_id` and `memory_type`. It leaves roughly a third of the 20 params (scope, tags, modality, retention, confidence, importance, memory_class, related_memory_ids) undocumented, though the schema marks most of those 'optional; usually left 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?

Opens with a specific verb+resource+scope: 'Save what the user just told you, in their own words,' which immediately separates it from brain_recall, brain_forget and brain_context. The proactive-call directive further pins down its role in the sibling set.

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

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

Explicit when-to-use with concrete trigger examples ('I had kimchi fried rice today', 'my dog is called Kongi'), explicit when-not ('do not wait to be told remember this'), and an explicit anti-pattern ('do not ask whether to save it'). No alternative tool is named, but the routing conditions are unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: results carry diff excerpts, results are silently empty without a watched code folder, and it names the config artifacts (automatic-capture.json, code_workspaces) that control that 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?

Front-loads what the tool returns, then the filter axes, then the caveat about watched folders. Dense but every clause carries information; slightly long for a single paragraph, with the caveat tucked at the end where it is easiest to miss.

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 an output schema present, the description need not explain return fields, and it correctly focuses on filtering, diff excerpting, and the empty-result precondition. Nothing essential for a correct call is missing, though the default limit/max_diff_chars tradeoffs are only 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 coverage is 63%; the description supplies meaning for the undocumented parameters by naming the filter set (project, happened_from/happened_to as ISO, file, symbol, kind) and tying them to example queries. limit and max_diff_chars are left to their schema text, which already documents them.

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: code changes recorded by the capture service, with diff excerpts, plus the filter axes (project, time range, file, symbol, kind). This is clearly distinct from the brain_* sibling tools, so an agent can select it 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?

Gives two concrete example questions ('what did I change in auth.py last week?', 'when did the parser change?') that map directly onto the filters, and states the precondition that results are empty unless a code folder is being watched. It does not name any alternative tool to prefer or avoid, but no sibling overlaps this domain.

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