Manage Yunxin app keys

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

Goes beyond the destructiveHint annotation by naming the real-world consequence: clients still using the old secret will fail. It also states the hard requirement of confirm: true for the destructive path. It does not say whether the old secret is recoverable or whether there is a grace period, so it falls short of a 5.

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 short clauses plus a warning sentence; the destructive consequence and confirm requirement are placed last but clearly flagged. There is no filler. Slightly telegraphic ('必须传 confirm: true') 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 5-parameter, no-output-schema tool with destructive semantics, the description covers the action split, the destructive warning, and the confirm gate. It omits what get actually returns (masked vs. full secret) and whether the app parameter is required, but those are covered by the 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 100%, and the description largely repeats what the schema already documents (action enum meanings, confirm requirement). The only marginal addition is restating the confirm gate as a hard rule rather than a field hint.

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 specific verbs and resources: query AppKey/AppSecret or reset AppSecret, and enumerates the three actions with one-clause semantics each. Clear, but does not distinguish this from the sibling yunxin_app_get, which plausibly also returns app details.

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?

Maps each action value to a purpose (get = query, set_secret = set a supplied secret, random = generate a new one) and gives a clear precondition for reset (confirm: true). Lacks any explicit statement of when to prefer this over yunxin_app_get or yunxin_app_admin.

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