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

No annotations are present, so the description carries the transparency burden. It discloses retrieval behavior, the quality consequence of long queries, the precedence of explicit collections over inference, and the empty-result handling. It does not explicitly state that the operation is read-only, though 'returns' and 'load' strongly imply it.

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 dense but not padded; every sentence carries an actionable instruction. The key imperative 'Call this BEFORE writing any code' is front-loaded, and the rest of the guidance 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?

Despite having no output schema, the description explains the high-level return payload: rules/conventions plus a list of deeper references. It also covers the no-results edge case with explicit instructions on how to behave. This is sufficient for an agent to invoke and interpret the tool 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%, setting a baseline of 3. The description adds meaningful semantics: task should be one short sentence, full prompts retrieve badly, collection should be used when the user names it with @, and an explicit name always wins over inference. This goes beyond the schema's field descriptions.

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 action and resource: it loads the user's own coding rules and conventions for the current area, plus a list of deeper reference material. This clearly separates it from the sibling search/write/list/save tools by focusing on loading personal coding context.

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 explicit when-to-use guidance: call before writing any code, and call again whenever the work area changes. It also gives clear constraints: pass a one-sentence task, do not paste the full prompt, and pass an explicitly named collection. It does not name an alternative sibling such as devvault_search, so the 'vs alternatives' part is not fully explicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly signals a read-only fetch of complete content, but it does not describe side effects, error behavior, or what 'complete content' means with respect to the depth parameter. This is acceptable for a simple retrieval tool, but some operational nuance is left implicit.

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 purpose stated first and usage guidance second. Every clause contributes information needed to decide when and how to call the 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 simple read tool with two parameters and no output schema, the description covers the essential invocation path: when to use it and where the id comes from. It could be more complete by explaining the output or the effect of depth in prose, but the schema covers depth and the title covers what is returned.

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 description adds meaningful context for container_id by explaining that it comes from a search result or the manifest, which is not in the schema. The depth parameter's behavior is already documented in the schema, and the description does not need to repeat it, though it could have briefly mentioned the inline-versus-link distinction.

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 action ('Fetch a container's complete content') and a clear resource, distinguishing it from sibling tools by focusing on full container retrieval rather than context, search, or research saving. The title reinforces the read operation, and the reference to using an id from a search result or manifest makes the tool's role distinct.

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?

'When the rules you were given are not enough' gives a clear trigger for using this tool, and 'Use the id from a search result or the manifest' explains how to obtain the required identifier. It does not explicitly name alternative tools or state when not to use it, but the conditional framing provides useful guidance.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that this is a read-only listing operation via 'Show which collections exist,' and it specifies that returned data includes descriptions. However, it does not explicitly state that no changes are made, nor does it describe any output structure or edge cases.

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 short sentences with no wasted words. The primary purpose is front-loaded, and the usage guidance is presented succinctly in the second sentence.

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 listing tool, the description covers what the tool does, what the output includes (collections and descriptions), and when it is useful. It does not elaborate on output formatting or pagination, but the absence of a schema and the simple nature of the tool make this acceptable.

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 are no parameter semantics to clarify. The description appropriately adds no parameter-related detail because none is needed.

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 clearly states the tool's function: showing which collections exist and their descriptions. This is distinct from sibling tools like devvault_search or devvault_save_research, which involve searching or writing rather than listing collections.

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 explicitly provides when to use the tool: when the user refers to an unresolvable collection or when deciding where to save research. It lacks explicit when-not-to-use guidance or alternative tool routing, but the stated use cases are sufficiently clear for a simple listing tool.

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?

With no annotations provided, the description bears full responsibility and excels: it discloses server-side constraint enforcement, automatic repair behavior (paragraph splitting, spillover, flattening), and that the response reports what was adjusted and should be relayed. It also exposes the idempotent update behavior tied to external_key. This goes well beyond a generic save description.

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 dense but every sentence earns its place: purpose, structural guidance, repair behavior, idempotency, and agent_rules are all front-loaded with no filler. The only minor nit is its long em-dash sentence, but the information density justifies it.

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 complex, 5-parameter tool with no output schema, the description covers the important behaviors agents need: how to structure containers, what constraints will be auto-repaired, what to report back, and how to make updates idempotent. Nothing critical 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?

Even though the schema already documents every parameter, the description adds valuable guidance beyond it: always set external_key, prefer grouping by topic with nested children, use agent_rules to save future reading, and make collection_description match against future task descriptions. This materially improves how an agent would populate the parameters.

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 action—file the current conversation's findings into the vault as structured containers—and elaborates a clear structure model: topic-based containers with nested sub-topics. This clearly distinguishes the save/import operation from retrieval-oriented siblings like devvault_search and devvault_get_container.

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 the context: after research has happened, when findings should be persisted for future reuse, and advises on agent_rules and external_key to avoid duplicate/re-derived work. It does not explicitly name when to avoid this tool or point to an alternative, so it misses the top tier.

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?

With no annotations, the description must carry behavioral disclosure. It adds useful behavior: items already delivered this session are reported rather than sent twice, and it clarifies the manifest-based selection. However, it does not state whether the operation is read-only, what happens on no match, or the return format—gaps that matter without annotations or an output schema.

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?

Three concise sentences each earn their place: the source of the selection, the query strategy with examples, and the duplicate-delivery behavior. No filler or repetition of schema details.

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 simple search tool with no output schema, the description covers how to choose targets, how to phrase the query, and a key behavioral quirk. It does not explain the exact response shape or error behavior, but these are relatively minor given the tool's simplicity and the absence of an output 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 description coverage is only 33%, so the description must compensate. It does meaningfully for the required query parameter by advising agents to search with the vocabulary of the thing being built and giving concrete examples. The collection parameter is already described in the schema, and limit is self-explanatory with its min/max/default, so the description need not repeat 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?

The description states a specific verb and resource: pull in a specific piece of the user's saved research, with the selection source (manifest from devvault_context) explicitly named. It also orients the agent with search examples, and the title reinforces the purpose. Its reference to devvault_context distinguishes it from sibling tools.

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: use this after devvault_context has returned a manifest, and search using the vocabulary of the thing being built. It does not explicitly list alternatives or say when not to use this tool, so it misses the full exclusionary guidance needed for 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: it overwrites cached rules? Actually it says 'Rules a user wrote by hand are never overwritten,' which implies it may overwrite machine-generated rules. It also warns that a narrow extraction is worse than none, and specifies the format (one imperative rule per line, drop background/explanation, keep code examples and links). This is rich behavioral context beyond the schema.

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 a single dense paragraph, front-loaded with the trigger condition and the core action. It packs a lot of important guidance (completeness, format, preservation of hand-written rules) without excessive verbosity. Slightly long but every sentence 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 write tool with no annotations and no output schema, the description covers the key context: when to use, what to extract, how to format, and what not to overwrite. It doesn't describe the return value or error cases, but those are less critical for an agent deciding to call it. The main gap is not stating whether the tool overwrites existing machine-generated rules, though the hand-written rule caveat implies it.

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 50%: the 'rules' parameter is described as 'One imperative rule per line, task-agnostic,' and the description reinforces that with format and content guidance. The 'container_id' parameter has no description in the schema, but the description implies it identifies the container to write back to. The description adds meaningful semantics for the rules parameter and enough context for container_id.

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 clearly states the action: after reading a container with no cached rules, distil it and save the result. It names the resource (a container) and the specific operation (caching extracted rules), and it distinguishes itself from siblings by describing a write-back workflow that follows reading.

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 explicitly says when to use this tool: after reading a container whose result said it has no cached rules. It also gives a strong exclusion: do not use it for narrow, task-specific extraction; extract every actionable rule. This is clear guidance for an agent deciding between this and sibling read/search tools.

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