save_form

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

No annotations exist, so the description carries the full burden. It does disclose one non-obvious behavior: human-authored content must be carried through unchanged ('人写过的内容要原样带上'), and that drafted=false encodes human authorship. It says nothing about whether an existing save is overwritten, permission requirements, or what happens to drafted=true entries.

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?

It is a single dense sentence with an inline nested JSON skeleton, front-loading the purpose correctly and containing no filler. However, the embedded structure is hard to parse as prose and a formatted example would communicate the same content far more effectively.

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 two-parameter mutation tool with a nested object, no annotations, and no output schema, the definition documents the payload shape but omits overwrite semantics, failure modes, and any confirmation of what a successful save returns. That leaves real gaps for a write operation.

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%, so baseline would be 3, but the schema itself defers the nested form structure to the description ('形状见上面'), making the description the only documentation of the inner types/fields/label/display_field layout. The drafted flag's meaning is also explained here rather than in the 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 first clause '保存对象表单' gives a clear verb plus resource, so an agent knows this persists an object form. It does not distinguish itself from the sibling draft_form or export_forms, leaving the boundary between drafting and saving for the agent to infer.

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?

There is no statement of when to use this versus draft_form, when not to call it, or what preconditions exist. The only usage-adjacent help is that saved_as 'comes from list_runs or build_ontology', which is provenance for one value rather than selection guidance.

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