memory_get

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

With no annotations, the description carries the full burden and does substantial work: it discloses that neighbors are returned by default, that private-namespace reads require the owner's reader id, and that embedded neighbors are filtered to global plus the caller's project. It does not describe return shape, error modes, or whether missing ids fail loudly, leaving some behavioral gaps for a 4-parameter read 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 core action and default behavior are front-loaded in the first clause, and the parameter notes follow in order. The longer em-dash sentences and the trailing memory_feedback instruction add real information but make the block denser than it needs to be.

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 annotations, the description supplies the permission model, the default neighbor behavior, and the project-scoping rule — enough for an agent to call it correctly in the common case. It stops short of describing the response payload or failure behavior, which a 0%-coverage schema leaves entirely undocumented.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: reader gets meaning plus a required-when condition, project gets meaning plus its filtering effect on neighbors, and include_neighbors is implied by 'included by default'. Only mem_id is left undefined, which is self-evident from the purpose sentence.

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 and resource: 'Fetch a memory by id', and immediately narrows scope by noting that one-hop link neighbors are included by default. It never explicitly contrasts with memory_search or memory_link, so an agent gets the gist but must infer the boundary between this and the search sibling 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?

It states a real conditional rule ('reader: required when the memory lives in a private agent-<name> namespace') and a follow-up workflow ('After adopting it, call memory_feedback'). What is missing is a negative case — there is no statement of when to prefer memory_search or memory_link instead.

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