Skip to main content
Glama

Manage Yunxin app identifiers

yunxin_app_identity
Destructive

Query or update iOS Bundle Identifier, Android/HarmonyOS package names, and identity security validation settings; writes require confirm: true because changes affect client login.

Instructions

查询或修改 iOS Bundle Identifier、Android Package Name、HarmonyOS Package Name,以及标识安全校验开关。修改标识会影响客户端登录,写入需 confirm: true。

Input Schema

NameRequiredDescriptionDefault
appNo
dataNoset 时的字段,例如 {iosbundle, packagename}
actionYes
confirmNo
checkAppBundleNoset_check_bundle 时是否开启校验

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description adds genuinely useful context beyond them: that changes impact client-side login and that writes require confirm: true. It does not clarify that the 'get' action is itself a safe read within an otherwise destructive-annotated tool, which is the notable remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the resource list first and the risk/confirm caveat second. No filler, though the confirm requirement could have been attached more explicitly to the write actions rather than the tool as a whole.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with a nested object, partial schema coverage, and no output schema, the description covers impact and the confirm gate but omits action-enum semantics and what 'get' returns. Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40%, so the description carries weight — and it does explain the confirm gate and the intent of the data object (iosbundle, packagename) and checkAppBundle. But the 'app' parameter and the exact meaning of the three action enum values are left unexplained in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb pair (查询/修改) and concrete resources — iOS Bundle Identifier, Android Package Name, HarmonyOS Package Name, and the identifier security-check switch. It is clearly distinct from sibling tools like yunxin_app_get or yunxin_app_admin, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the consequence of modification (affects client login) and a prerequisite for writes (confirm: true), which implies when caution is needed. However, it does not route the agent away from siblings such as yunxin_app_get for simple reads, nor does it say when set_check_bundle is preferred.

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