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

With no annotations provided, the description carries the behavioral disclosure burden. It does this well by explaining the empty case: 'Empty when none yet or the API key is not linked to a human account,' and by adding the context about minting keys from the console while signed in. It also correctly characterizes the data as a 'private soul,' signaling sensitivity. The only omission is an explicit read-only guarantee, but 'Return' reasonably implies no mutation.

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 primary action. Each subsequent sentence earns its place: the definition of a soul, the empty/edge-case behavior, and the useful alternative source via memory_session_ensure. There is no filler or 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 zero-parameter getter with an output schema available, the description is complete. It explains what the returned value means, when it can be empty, and offers a fallback source. Nothing an agent needs to call 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?

The tool has zero parameters, so there is nothing for the description to explain about parameters. The rubric sets a baseline of 4 for zero-parameter tools, and the description wisely spends no space on parameters. The 'current org' scope is implied by the description, which is sufficient.

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: 'Return this person's private soul for the current org.' It further defines exactly what a soul is ('a tiny compressed identity block...'), which removes ambiguity. It is clearly distinguishable from the sibling memory_soul_set by the get/set contrast and the resource it targets.

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 gives clear context for when this tool is appropriate: to retrieve the private soul for the current org. It also notes that the soul is 'Also returned on memory_session_ensure as soul,' which alerts an agent to an alternative source. It does not explicitly state when not to use it, but the purpose is clear enough that an agent can decide.

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