打开抖音项目

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

No annotations are provided, so the description must disclose behavior itself. It discloses the polling/readiness wait, the identity check, and failure semantics: IDE_STARTUP_TIMEOUT, structured ok:false/isEror:true errors for permission/type/AppID mismatches, and no false success reporting. This is unusually transparent.

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?

The main point is front-loaded with '按期望类型打开白名单内项目', and the rest is packed into one information-dense clause with semicolons; every phrase carries protocol, readiness, identity, or error semantics. No filler.

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?

The description is quite complete for a complex tool with no annotations or output schema: it covers protocol selection, readiness polling, identity checks, and structured errors. It still leaves the success return shape and the precise role of timeoutMs implicit, but the essentials for correct invocation and expectation-setting are present.

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?

The schema provides only types/enums with no descriptive text, so the description must add meaning. It maps expectedProjectType to the minigame/tmg vs microapp/tma choice and clarifies expectedAppid/expectedProjectType as identity-check inputs, while timeoutMs and projectPath are left to their self-explanatory names. This is solid but not full compensation for all parameters.

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 states a specific action: open a whitelisted project according to expectedProjectType, and names the underlying CLI/protocol branches (tgm for minigame, tma otherwise). It does not explicitly contrast this against siblings such as douyin_tmg_open, so it misses clear sibling differentiation.

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?

It gives clear usage context: opening a whitelisted project with an optional expected type and appid, and it defines when the tmg vs tma branch applies. However, it does not say when to prefer this tool over a sibling like douyin_tmg_open, so alternatives are only implied.

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