save_build

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds useful context: the build is persisted for later loading and is consumed by sell_advice when mods get sold. It does not explain what happens on a name collision (idempotentHint=true implies overwrite but this is never stated) or what persistence/retrieval looks like.

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?

One sentence with the action front-loaded and no filler. The trailing clause ('so it can be loaded later and sell_advice can warn before its mods are sold') is grammatically tangled and packs two ideas, but no sentence is wasted.

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 mutation tool with a nested object parameter and no output schema, it covers purpose and the cross-tool lifecycle reasonably well. It leaves gaps an agent would want filled: what 'checking it works' concretely requires, overwrite behavior on duplicate names, and the expected shape of `arguments`.

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 50% — `notes` is documented, but `name`, `tool`, and the nested `arguments` object are not. The description adds no meaning to any of them: it never says whether `name` must be unique, nor that `arguments` should be the argument payload from a prior weapon_build/warframe_build call. It fails to compensate for the coverage gap.

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 a specific verb and resource: 'Save a build the player likes', plus the downstream purpose ('can be loaded later', 'sell_advice can warn'). It does not explicitly contrast itself with the generation siblings (weapon_build, suggest_warframe_build, build_guide), so the agent must infer that those *create* a build while this one *persists* it.

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?

'after checking it works' implies a sequencing rule (verify a build before saving it) and the sell_advice clause hints at the post-save workflow. But no sibling is named as the prerequisite or alternative, and 'checking it works' is never tied to a concrete tool, so the when-to-use guidance is only implied.

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