get_skill_memory

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

Annotations already declare this a safe, closed, non-destructive read, so the burden here is lighter, and the description does add real value: newest-first ordering, a size cap, a `truncated` signal for omitted older entries, and the per-user memory scope for Built-in and Unilytics skills. It still omits what an empty memory returns, whether the cap is configurable, and how the `as_of` value should be interpreted by a caller — so it earns credit but not a top score.

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 purpose is front-loaded in the first sentence and the remaining lines are short, factual, and mostly load-bearing. The docstring-style "Args:" block is slightly awkward, and the sentence about `as_of` only makes sense if the reader infers it is a returned field rather than a parameter, which is unnecessary friction.

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, describing return characteristics (`truncated`, `as_of`, ordering) is the right call and is done well. However, the description imports concepts about the return payload without labeling them as returns, and leaves the size cap magnitude and empty-memory behavior undefined, so an agent can call it correctly but not fully predict the response.

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% for the single parameter, so the description must carry it, and it does provide a concrete format example for skill_id ("built-in like \"seo/keyword_research\", or user/project"). The user/project form is left underspecified with no example, but the parameter is meaningfully clarified beyond the bare `string` 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 gives a specific verb and resource — "Return a skill's memory" — and then enumerates what that memory contains ("learnings, workarounds and preferences saved from earlier runs"), which is far more informative than the bare name. It implicitly separates this read from the write siblings (append_skill_memory, compact_skill_memory) by framing the tool as a retrieval, but it never states directly which sibling to prefer, leaving a bit of differentiation to inference.

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: the phrase "saved from earlier runs" suggests reading accumulated knowledge before doing work, and compact_skill_memory is mentioned purely to explain the `as_of` field, not as an alternative to choose under some condition. There is no explicit when-to-use / when-not-to-use statement, no note about what happens when no memory exists, and no guidance versus the get_skill / get_skill_proposal siblings.

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