yapi_save_mock_case

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

With no annotations provided, the description carries the full disclosure burden. It does reveal the key behavioral trait — the same call creates or updates depending on whether caseId is present — which goes beyond what the schema shows. It does not, however, disclose update overwrite semantics, the effect of the dryRun flag, or any return behavior, so the mutation's side effects remain opaque.

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 terse sentences with the verb-resource pair front-loaded and the branching instruction ('更新时传 caseId') placed second. There is zero filler — every clause 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 tool with 11 parameters, 0% schema coverage, no annotations, and no output schema, this description is far from complete. An agent cannot know what dryRun does, how params affect matching, what result to expect on create versus update, or what side effects an update has on an existing mock case.

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 needed to compensate across 11 parameters, yet it only addresses caseId's role as the update discriminator. The three required parameters (interfaceId, name, resBody) and behavior-affecting fields (dryRun, params, ipEnable, delay, code, ip) are never explained, leaving the agent guessing at nearly every parameter's meaning.

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 pairs a specific verb ('新增或更新' — create or update) with a specific resource ('Mock 期望' — Mock expectation), clearly conveying an upsert of mock cases. However, it does not differentiate this tool from siblings such as yapi_update_interface_mock or yapi_update_advanced_mock, so an agent still must infer which mock domain it operates on.

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?

'更新时传 caseId' is actionable guidance: it tells the agent how to select the update path versus the create path. But there is no guidance on prerequisites, what must be supplied for creation, or when to prefer this tool over its sibling mock tools — the agent must infer all of that.

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