Locul Cloud Memory

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavior beyond that: duplicate facts are skipped rather than accumulated, and entities are found-or-created and linked into a knowledge graph. It stops short of stating auth requirements or what identifier is returned.

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 dense paragraph, front-loaded with the action and the trigger condition before the selectivity caveats and field guidance. Slightly long, but nearly every clause carries a distinct instruction (selectivity, standalone wording, entity coverage, dedup), so little is wasted.

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 output schema, the description covers purpose, trigger conditions, exclusions, dedup behavior, and key field expectations. It could go one step further and say what a successful save returns, but an agent has what it needs to call this 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 100%, so the baseline is 3, but the description adds genuine semantics: `fact` must be concrete and standalone so it reads correctly months later, and `entities` should enumerate every person/company/product/project/tool/topic so the graph links them. That is more than restating 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?

States a specific verb and resource ('Save a NEW memory') plus the destination ('user's cloud brain') and timing ('immediately'). This cleanly separates it from read-side siblings like recall_memories, search, and get_memory_source.

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 about when to use it (durable reusable facts: decisions and reasoning, preferences, changed facts about people/companies/products/projects/tools, goals, constraints) and when not to (transient chatter, one-off task mechanics, secrets, anything already saved). Nothing is left 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety and scope profile is covered. The description adds that it returns the 'full record' (as opposed to a summary), but says nothing about behavior on an unknown/stale id or the shape of what comes back. With annotations doing the heavy lifting, this is adequate but thin.

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 front-loaded sentence with the action, the resource, and the id's source; nothing is wasted and nothing needs re-reading.

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 one-parameter read tool with full schema coverage and annotations covering safety, the description supplies what an agent needs to call it and hints at the return ('full record') despite no output schema. A note about behavior on a missing or expired id would make it complete.

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?

There is one parameter and schema description coverage is 100%, so the schema already documents the id fully. The description adds only that the id originates from search results, which is useful but not a semantic detail the schema lacks; baseline 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 (Fetch) and resource (full record for one memory id) and ties the id's provenance to search, which implicitly separates it from the list-style search tool. It does not, however, differentiate itself from the other getter siblings like get_memory_source or get_entity_profile, so an agent still has to infer which retrieval tool applies.

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?

'returned by search' gives clear context: use this after a search has produced an id. There is no explicit when-not or named alternative among the sibling getters, 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context about the payload shape (totals plus top entities), but with no output schema it stops short of describing ordering, limits, or how 'most-mentioned' is ranked.

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 that front-loads the metaphor ('top-down map') and immediately grounds it with the concrete return contents. No filler, no restatement of the title.

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 and no parameters, the description is the only source of return-shape information, and it covers the two main pieces (counts, top entities). It leaves open how many entities are returned, what fields they carry, and how this differs from memory_stats, which is a meaningful gap for an overview 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly signals that this is a no-argument overview call.

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 output: a top-down map of the user's cloud brain with total counts plus most-mentioned entities. It is specific about what is returned, though it never explicitly distinguishes itself from the sibling memory_stats, which likely also surfaces counts.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as memory_stats or get_entity_profile. The agent must infer that this is an overview/entry-point tool from the words 'top-down map' alone.

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 establish that this is a safe, read-only, closed-world lookup, so the bar is lower. The description adds genuine value by disclosing what the response contains (top memories, relationships, aliases), which is important given there is no output schema; it stops short of noting behavior when a key resolves to nothing or how many 'top memories' are returned.

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 sentences, front-loaded with the action and resource before the parenthetical detail. The entity-type list is slightly long but earns its place by conveying lookup breadth, and there is no filler or redundancy.

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 one-param, read-only lookup with no output schema, the description supplies the return shape, matching rule, and entity scope, which is enough to call it correctly. Minor gaps remain around not-found behavior and the size/ordering of returned collections, but nothing essential 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?

Only one parameter and schema coverage is 100%, so the schema already documents 'key' as 'the entity's canonical key or name.' The description's 'Match by canonical key or name' largely restates that and adds no new format or resolution semantics, so the baseline 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?

Specific verb ('Return') plus specific resource ('the full profile for one entity') with an enumeration of contents (top memories, relationships, aliases) and entity kinds. The single-entity scope plus the content list implicitly separates it from aggregate/sibling tools like get_brain_index, memory_stats, and search.

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 never says when to reach for this tool versus search, recall_memories, or search_notes, nor any exclusions or prerequisites. 'Match by canonical key or name' is an input hint, not usage guidance, so the agent must infer the use case.

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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond them by naming the returned fields (fact, note title, path), which is the only place that return shape is communicated since no output schema exists. It does not cover error or missing-id 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?

A single tight sentence, front-loaded with the action and resource, with the return contents appended. Every clause earns its 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 one-parameter read-only lookup with no output schema, the description covers purpose and return contents adequately. Minor gaps remain around failure modes (invalid or inaccessible id), but nothing essential for a correct call is missing.

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

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

Schema coverage is 100% and the schema already explains that id is a cloud uuid returned by recall/search. The description only echoes "one memory," adding no syntax, format, or source-of-id detail beyond the schema, so the baseline 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?

States a specific verb ("Open") and a precise resource ("the source provenance behind one memory") and discloses the payload (fact plus note title and path). It implicitly separates itself from the plural retrieval siblings (recall_memories, search, search_notes) by scoping to a single memory, though it never names an alternative.

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 explicit when-to-use statement, no prerequisites, and no named alternatives. The phrase "one memory" weakly implies a single-id lookup, but the agent gets no guidance on when to reach for this instead of recall_memories or search_notes.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safe read-only nature is covered. The description adds the breakdown of what is counted, but discloses nothing about cost, freshness, or scoping; with annotations carrying the safety profile, a 3 is appropriate.

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 front-loaded sentence with the verb first and zero wasted words. Every clause (counts, categories, entities, sources) carries 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?

For a trivial, parameterless, read-only tool with no output schema, the description usefully lists the returned count categories, which is the main thing an agent needs to know before calling. It is nearly complete, missing only any note on scope (e.g., which brain/workspace the counts apply to).

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 tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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 ('Report cloud brain counts') and enumerates the exact categories counted (active/superseded/orphaned memories, entities, sources). This makes it clearly distinct from siblings like get_entity_profile, search, and recall_memories, though it never explicitly names an alternative.

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 is given; usage is only implied by the nature of a stats/count tool. It does not route the agent away from alternatives or state prerequisites such as needing an existing brain.

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 readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context that retrieval is semantic plus keyword and can be scoped by entity, but it does not describe return format, pagination, or other behavioral traits beyond what annotations provide.

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 two concise sentences, front-loads the core purpose, and every sentence contributes without waste. It is appropriately sized for a simple recall tool.

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 read-only tool with full parameter descriptions and safety annotations, the description is largely complete: it states the retrieval method, scoping option, and required query. The main gap is lack of explicit routing guidance versus sibling search tools, but the memory-specific scope and retrieval method still make it callable 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 100%, so the schema already documents all three parameters with descriptions. The description adds no new parameter meaning beyond what is in the schema; it mostly restates the entity parameter's schema 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 states a specific verb ('recall') and resource ('user's distilled cloud memories') and specifies it combines semantic and keyword search. It does not explicitly differentiate from siblings like search or search_notes, 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?

There is no guidance on when to use this tool versus alternatives such as search or fetch. The only usage instruction is about passing an entity to scope results, which is parameter semantics rather than tool selection.

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 readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are returned as records and may not be the full text, requiring a fetch by id. It omits result-count limits or pagination 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?

Two sentences, no filler, with the core action stated first and the follow-up workflow second. Every sentence carries information the agent needs.

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 must say what comes back, and it does (matching memories as result records, full text via fetch). For a one-parameter search tool this is nearly complete; only result limits or ordering behavior 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?

With a single parameter at 100% schema coverage, the schema already fully documents "query," so the baseline is 3. The description adds no query syntax, matching behavior, or scoping hints beyond what the schema states.

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 ("Search the user's cloud brain") and even characterizes the return as "result records," so the agent knows what it gets back. It does not, however, distinguish itself from close siblings like recall_memories or search_notes, which is what would be needed for 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 gives clear next-step guidance ("Use fetch to retrieve the full text of any result by its id"), which tells the agent how to follow up. It says nothing about when to choose this tool over recall_memories or search_notes, so the alternative-selection question is left 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the scoping fact that the corpus is cloud memory facts; it says nothing about ranking, result shape, or how the limit interacts with total matches.

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 with zero filler, and the scope of the search is front-loaded ahead of the query tip. Every sentence carries 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?

For a two-parameter read tool with full annotation coverage, this is close to sufficient, but with no output schema the description could reasonably say what a match looks like or how results are ordered. The corpus-vs-name mismatch (search_notes returning 'memory facts') is left unresolved for the agent.

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 100% and the two parameters are already documented ('Search terms.', 'Max results (default 10)'). The description adds a modest hint about query style with 'Plain words work best', but nothing about matching semantics (exact vs fuzzy, stemming) to supplement 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?

States a specific verb and method ('Full-text keyword search') plus the corpus ('the user's cloud memory facts'), so the agent knows exactly what operation this is. It does not, however, distinguish itself from siblings like 'search' or 'recall_memories', leaving the agent to guess which search surface to use.

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?

'Plain words work best' is query-formatting advice rather than when-to-use guidance. There is no statement of when this tool should be chosen over 'search' or 'recall_memories', so usage is only implied by the verb 'search'.

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