vault_get_document_map

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description does add real value beyond that by introducing the 'exact-byte version' token and warning that returned keys must be copied unchanged. It nonetheless omits truncation behavior despite bounds on maxBytes/maxHeadings, which is a material behavioral gap.

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, zero filler, with the payload contents front-loaded and the operational caveat second. Nothing is redundant with the schema or annotations.

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?

An output schema exists, so return-value structure need not be explained, and the description rightly focuses on how to consume the result. Still, with three parameters at 0% schema coverage and no note about what happens when maxBytes or maxHeadings are hit, an agent cannot fully predict the call's behavior.

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 carry the full burden of explaining path, maxBytes and maxHeadings. It explains none of them: maxBytes and maxHeadings in particular are opaque limit parameters whose truncation semantics are left entirely undefined, and even 'path' is not clarified as a vault-relative path or a folder path.

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 resource and enumerates what the map contains (heading paths, block IDs, property names, version), which is far more informative than the name alone. It hints at its role relative to siblings by pointing to 'targeted reads/patches', though it never names vault_read or vault_patch explicitly.

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?

'Copy returned keys unchanged for targeted reads/patches' implies a workflow (map first, then targeted read/patch), which is genuinely useful routing guidance. However, it never states when to choose this tool instead of vault_read or the other read siblings, nor any preconditions, so the guidance remains implied rather than explicit.

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