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

With no annotations provided, the description carries the full burden, and it does disclose the most important safety behavior: default-deny and the confirm=true trigger. Still, it does not describe side effects, persistence of the submission, auth requirements, or what happens once the remote review is triggered.

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 description is short, front-loaded with the tool's origin, and then states the key trigger condition without filler. It is compact and readable, though a dangerous tool could reasonably carry a bit more operational detail.

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?

Given there is no output schema, no annotations, and six parameters, the description is too thin to fully support correct invocation. It explains the confirm gate but omits expected return behavior, side-effect risks, and any setup or preconditions, so an agent is left guessing on several important points.

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 must compensate for six undocumented parameters. It adds real meaning for confirm by explaining the trigger condition, but host, channel, timeoutMs, autoPublish, and even appid are left unexplained beyond their names and schema types.

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 it is a safe wrapper around the official tma audit and explicitly says confirm=true triggers remote submission, which matches the title '提审抖音项目'. It is clear about the core action, though it does not explicitly differentiate this tool from its siblings.

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?

The description provides a critical usage condition: the tool defaults to denial and only acts when confirm=true. However, it gives no guidance on when to choose this tool over sibling tools like douyin_open_project or douyin_tmg_open, and no exclusions or prerequisites are mentioned.

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

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

No annotations are present, so the description carries the full behavioral burden. The word '查询' implies a read-only operation and the phrase '调用官方 tma hosts' gives provenance, but there is no disclosure of return shape, rate limits, timeout behavior, or side effects.

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?

One sentence, front-loaded with the primary action and scope, followed by a compact parenthetical that ties the result to douyin_audit. No unnecessary words.

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 simple two-param query tool, the description clearly states what it queries, for which AppID, and why an agent would call it. It does not give an explicit return format, but 'host列表' sufficiently implies a list, so the remaining gaps are minor.

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%, and the description only adds meaning to 'appid' by indicating it selects the available hosts. The optional 'timeoutMs' is not mentioned, so the description only partially compensates for the schema's lack of parameter documentation.

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 uses a specific verb '查询' (query) and a specific resource: the list of available audit hosts for a given AppID. It also states the result is the reference for the 'host' parameter of douyin_audit, which distinguishes it from sibling tools.

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 explicitly says the output is the reference for choosing the host parameter when calling douyin_audit, telling an agent when the tool is useful. It does not mention alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the routing behavior and the non-upload/audit boundary, but it does not disclose side effects such as project file mutations, build output generation, success/failure behavior, or whether a local environment must be prepared.

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 description is a single sentence that immediately fronts the routing rule and the exclusion boundary. There is no redundant filler or repetition of the tool name/title.

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 core purpose and routing are clear, but the tool has no annotations, no output schema, and three parameter descriptions at 0% coverage. The description does not explain return values, command execution behavior, or the meaning of timeoutMs and projectPath, so an agent still has to infer important invocation details.

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 needs to explain the parameters. It only indirectly clarifies expectedProjectType through the minigame/others routing. timeoutMs and projectPath are left entirely unexplained, including their purpose, defaults, and whether they are optional at runtime.

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 clearly states a specific action (build NPM) and a routing rule based on project type (minigame vs. others). It also explicitly excludes upload and audit, which distinguishes it from sibling tools like douyin_upload and douyin_audit.

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 explicit routing guidance: minigame projects should use tmg build-npm, others should use tma build-npm. It also states what the tool does not do (upload or audit), helping an agent choose a sibling tool when those actions are needed.

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

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

无任何 annotations，描述承担全部行为披露责任。它确实补充了有价值的机制信息：IDE 走 Windows 原生拷贝（隐含平台限制）、模拟器走 CDP 截图、projectPath 用于多实例绑定。但未说明输出行为（返回值是什么、是否通过 outputPath 落盘、timeoutMs 的作用）以及失败情形（IDE 未打开、CDP 连接失败时怎么办），透明性只做了一半。

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?

两句话完成全部信息传递：第一句按目标任务分派机制，第二句补充多开场景的参数技巧。机制差异前置、绑定细节后置，信息密度高且无任何冗余，每一句都有独立价值。

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?

工具中等复杂（4 参数、两种截图路径），而上下文信号很弱（无 annotations、无输出 schema、参数覆盖 0%、无必填参数）。描述却遗漏了调用契约的核心：调用后返回什么、不传 outputPath 时截图如何获取、空参数调用会得到什么结果。代理能正确选择该工具，但无法预测其输出，这是一个关键缺口。

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 描述覆盖率为 0%，描述必须补偿参数语义。它实际做到了对两个参数的补充：target 的两个枚举值对应两种截图机制，projectPath 解释了多 IDE 绑定行为。但 timeoutMs 和 outputPath 在描述中完全没有语义说明，outputPath 的作用只能靠参数名猜测，属于部分补偿而非充分补偿。

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?

描述明确说明这是截图工具，且细分为两种目标：IDE 全窗和模拟器画面，并分别给出具体机制（Windows 原生窗口拷贝 vs. MiniApp Webview CDP 截图）。动词+资源+机制齐全，能与全部 16 个兄弟工具（如 douyin_preview、douyin_read_console_errors）清晰区分，没有任何职责重叠。

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?

描述给出了明确的使用场景：需要截取 IDE 窗口或模拟器画面时使用，并说明了多开 IDE 时传 projectPath 的绑定用法。但没有命名任何替代工具或排除条件，也没有说明与 douyin_preview 等在预览/截图职责上的边界，when-not-to-use 完全缺失。

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

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

No annotations are provided, so the description must carry the behavioral burden. It adds a useful non-goal ('不读取源码内容' – does not read source code), implying a read-only intent, but it does not explicitly state whether the tool has side effects, network calls, or what happens on failure. A 3 reflects partial transparency.

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 description is a single well-structured sentence that front-loads the primary purpose and ends with a clarifying boundary. There is no redundant text, and every clause contributes information.

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 no annotations and no output schema, the description leaves meaningful gaps: it does not explain expected output or return behavior, does not describe optional parameters, and does not state when this check should be run relative to sibling tools. The core function is clear, but the operational context is incomplete.

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%, and the description does not explain timeoutMs or projectPath. The phrase '当前项目' weakly suggests projectPath, and timeoutMs is inferable from its name alone, but the description adds essentially no parameter meaning beyond the schema's bare names and types.

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 clearly states a specific verb ('检查' / check) and a specific resource scope: official tt-ide-cli, Douyin developer tools, current project, and local debug interface status. It distinguishes itself from sibling actions like open/build/preview/upload by being an environment diagnostics tool.

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?

The description tells what is checked but not when to use this tool versus alternatives, nor does it provide conditions or prerequisites. The usage context is only implied as a preflight diagnostic step, with no explicit exclusions or routing to sibling tools.

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

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

The description adds meaningful behavioral context beyond the schema: the action is performed via IDE workbench interaction rather than a simple command, the shortcut path is a fallback, and projectPath binds the operation to a specific IDE instance. However, with no annotations provided, the description still leaves key behaviors unexplained such as side effects of compile/refresh or what response/error conditions to expect.

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 concise sentences with no filler. It front-loads the preferred method, provides a fallback strategy, and includes a key parameter hint about multi-IDE binding. 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 tool with ive parameters, no annotations, and no output schema, the description is incomplete. It omits mode semantics, timeout behavior, prerequisites such as project opening or IDE running state, and what result or error the agent should expect after triggering compile/refresh.

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 must compensate, but it only clarifies projectPath and indirectly hints at shortcut usage. mode, shortcut values, timeoutMs, and useShortcut are left undocumented, leaving the agent to guess their semantics from the schema alone.

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 clearly identifies the action as triggering IDE compile/refresh and specifies the mechanism (workbench debug page click or shortcut). It does not explicitly differentiate among sibling tools such as douyin_build_npm or douyin_preview, but the verb and resource are concrete enough for an agent to understand the core purpose.

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?

The description provides an internal preference order: prefer clicking compile/refresh in the IDE workbench, and use a reliable shortcut as a fallback. It also explains when projectPath is useful (multiple IDE instances), but it does not state when this tool should be selected over sibling tools or when it should not be used.

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

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

With no annotations provided, the description carries the full burden, and it is unusually detailed. It discloses the CDP DOM-based UI automation approach, prohibits screenshot coordinate clicks, states forced project options, describes non-empty directory rejection, and documents the CREATE_PROJECT_UI_UNSUPPORTED error plus a unique manual operation. This exceeds the typical level of behavioral disclosure.

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 description is dense and information-rich; every clause contributes a real constraint or behavior. It could be slightly better organized with separate sentences or bullets, but it is concise relative to the amount of behavioral detail it conveys.

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?

Given six parameters, no output schema, and no annotations, important invocation details are missing: there is no description of the success return value, the role of appid, projectName, or timeoutMs, or how the forced language/template values interact with the schema enums. The error code and post-creation identity verification are helpful, but they do not make the tool fully actionable without guesswork.

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 must compensate for six parameters. It gives useful semantics for projectPath via the non-empty directory rejection and effectively constrains language and template to javascript/empty, but it does not explain the required appid, projectName, or timeoutMs. It also leaves unclear whether passing typescript or rich triggers rejection or silent coercion.

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 verb and resource: creating a Douyin minigame project through the IDE startup page's real "minigame" entry. The scope "仅小游戏" and the creation focus clearly distinguish it from sibling tools like douyin_open_project or douyin_tmg_open.

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?

The description provides clear context by stating this tool is for creating minigame projects and by specifying constraints such as '强制 JavaScript + 空白模板 + 小游戏类型' and '目标目录非空默认拒绝'. However, it does not explicitly name alternatives or say when to prefer this tool over siblings, so usage guidance is present but mainly implied.

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

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.

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

With no annotations, the description carries the burden, and it does disclose the routing behavior, the workspace-only output constraint, and the passthrough options. However, it does not describe side effects, prerequisite environment state, failure modes, or what happens after the preview command succeeds.

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 description is two dense sentences with no filler. Each sentence contributes a distinct operational fact: the routing rule, the workspace constraint, and the pass-through options.

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 core routing and output constraint are present, which is sufficient for a basic call. But given 9 parameters, no output schema, and no annotations, the description would be stronger if it explained the expected relationship between projectPath and expectedProjecType, the purpose of timeoutMs, and how to locate the generated QR code.

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 description adds meaning by naming small/copy/query/scene/launchFrom as pass-through official options and by linking --output and --qrcode-output to the routing behavior. But with 0% schema description coverage, it still leaves timeoutMs, qrcodeOutput format, and expectedProjecType/projectPath semantics largely implicit.

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—generating a Douyin preview QR code—and immediately gives the routing rule: minigames use tmg preview, other project types use tma preview. This clearly differentiates the tool from siblings like douyin_upload, douyin_audit, or douyin_compile_refresh.

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 explicit statement about when to use this tool versus its siblings, and no alternatives or exclusions are named. The routing note is internal command selection, not MCP tool selection, so the usage context is only implied by the title.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses the source of truth (IDE state and logged-in app metadata) and gives a concrete structured error taxonomy with conditions for each failure mode. It does not explicitly state side effects, but the diagnostic verb '判断/识别' and evidence-based wording imply a read-only check.

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 description is compact and front-loaded: the core purpose appears first, the evidentiary caveat second, and the error codes are appended as a concise list. Every sentence contributes and there is no redundant prose.

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?

With no annotations and no output schema, the description is the sole contract. It covers the tool's inputs sources and failure modes, but it never specifies the shape of a successful result and leaves timeoutMs and projectPath unexplained. This is adequate for a simple identity check but has clear completeness gaps.

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 must compensate. It indirectly informs expectedAppid and expectedProjectType through the APPID_MISMATCH and PROJECT_TYPE_MISMATCH errors, but timeoutMs and projectPath are completely undocumented anywhere, leaving two of four parameters without usable semantics.

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 names the exact object ('项目身份') and the specific attributes it determines: project type, actual AppID, and permission status. It also states the evidence source (IDE actual state / logged-in app metadata) and clarifies that file structure is only auxiliary, which distinguishes this tool from the related Douyin checking and opening tools.

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?

The description implies the tool is used to verify the real on-device project identity and permission state, and that file-structure evidence alone is not reliable. However, it does not explicitly name alternative tools or state when this tool should be preferred over siblings such as douyin_check_environment or douyin_open_project.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It states the tool invokes an official command and that '--json 输出结构化结果' (--json outputs structured results), which reveals output behavior. However, it does not mention side effects, failure modes, prerequisites, or whether the operation is read-only, leaving some ambiguity.

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 description is a single compact sentence that front-loads the main behavior, then adds the useful --json detail and the intended use case. Every clause earns its place with no repetition of the title or verbosity.

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 low-complexity tool with three optional parameters and no output schema, the description gives the core action and a use case. However, it leaves gaps around how projectPath behaves, what the default (non-JSON) output looks like, and whether prior environment checks or project opening are required.

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%, and the description only adds meaning for the 'json' parameter via '--json 输出结构化结果'. The 'projectPath' and 'timeoutMs' parameters are left unexplained, so the description only partially compensates for the missing schema descriptions.

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 names a specific verb and resource: '调用官方 tma project-size 输出包体积信息' (call the official tma project-size to output package size info). This clearly identifies the tool's function and distinguishes it from siblings like douyin_check_environment and douyin_open_project by referencing the actual command.

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?

The description provides a concrete use context: '上传/提审前核对包体积用' (for checking package size before upload/submission). It does not explicitly contrast with alternative tools, but the timing and purpose are clear enough for an agent to decide when to invoke it.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals the underlying command (official tmg version) and the important supported:false behavior for miniapp, but it does not discuss side effects, authentication needs, or successful response details. The query intent is clear, though not all edge behavior is disclosed.

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 description is compact and front-loaded: the core purpose appears in the first clause, and the tma limitation follows immediately. Every sentence adds unique information with no filler or repetition.

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 tool is relatively simple and all parameters are optional, but there is no output schema and no parameter documentation. The description explains why and when to use the tool and mentions the miniapp unsupported behavior, but leaves out expected return format for successful calls and how parameters affect invocation.

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 must compensate, but it does not mention timeoutMs or projectPath. It does partially help with expectedProjectType by distinguishing '小游戏' from '小程序端 tma', but it never explicitly maps these concepts to the enum values minigame/miniapp.

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 names a specific action and resource: '调用官方 tmg version 查询最新已发布版本号'. It also distinguishes minigame from miniapp by noting that tma has no version command, which helps separate this tool from siblings like douyin_tmg_check and douyin_upload.

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?

The description gives explicit usage context: '上传/提审前核对用', meaning it should be used to verify the latest version before upload or review submission. It also clearly states the miniapp exclusion: '小程序端 tma 无 version 命令', so an agent knows not to use it for miniapp projects.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It uses a read-only verb, communicates best-effort behavior with '尽最大可能', and discloses the unsupported-interface result ('接口不存在时返回明确的不支持原因'). These are meaningful behavioral traits, though timeout behavior and side effects are not covered.

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 description is two short sentences with no filler. The core purpose and fallback behavior are front-loaded, and the projectPath guidance is cleanly separated.

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 simple optional-parameter read tool, this is reasonably complete: it covers what is read, where it is read from, best-effort behavior, unsupported cases, and the projectPath use case. The main gaps are timeoutMs semantics and successful return shape, but these are largely inferable for this 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?

The schema has zero parameter descriptions, so the description must add meaning. It does add value for projectPath by explaining its role in multi-open IDE binding, but timeoutMs is left entirely to naming inference. This is partial compensation, not complete.

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 clearly states the operation ('read errors') and the resource ('IDE 内嵌 DevTools DOM'), and even describes the fallback behavior when the interface is unavailable. No sibling tool targets console-error reading, so it is easy to distinguish.

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?

The intended use case is implied rather than explicitly stated: an agent would use this when IDE/DevTools console errors need to be read. It gives one concrete conditional guideline: pass projectPath when multiple IDE instances are open, but it does not explain when to prefer this tool over siblings.

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

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

No annotations are provided, so the description carries the full disclosure burden. It explicitly states the token goes only into the local tma config ('仅写入本机 tma 配置'), will not be echoed ('不会回显'), and is a local config write to be used carefully ('属于本地配置写入，请谨慎使用'). These are significant behavioral traits beyond just saying 'set token'. It does not mention overwrite behavior or return values, but for a simple local write tool this is reasonably 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 description is two sentences long and front-loaded with the core purpose (official call, target, token). The second sentence adds important behavioral warnings. It is concise with no filler, though it could have ordered the caution before the detailed effect.

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 3 parameters, no output schema, and no annotations, the description covers purpose, main side effects, and a caution. However, it omits what constitutes success/failure, whether an existing token is overwritten, and any environmental prerequisites (e.g., tma installed or environment checked). This leaves some gaps for an agent deciding how to handle the result and error recovery.

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 must compensate. It does explain the purpose of two key parameters: 'AppID' and 'token' (for CI login), but the optional timeoutMs parameter is not mentioned anywhere in the description or schema. The description adds useful semantic context for the required params, but incomplete coverage of all three parameters keeps it at a mid score.

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 verb and resource: '为指定 AppID 设置 token' (set token for the specified AppID) via '官方 tma set-app-config'. It also clearly scopes the context to CI non-interactive login and identifies the local config write nature, making it easy to distinguish from all sibling tools, none of which touch configuration.

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?

The description gives a clear context for when to use this tool: 'CI 无交互登录用' (for CI non-interactive login). It does not explicitly mention when not to use it or name alternatives, but no sibling tool appears to be a direct alternative for token configuration, so the context alone is adequate.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a status/read operation and explains the underlying protocol behavior (tmg invoking IDE via mini-game protocol). However, it does not explicitly state side-effect-free behavior, return format, or behavior when the CLI is missing/logged out, which would add useful behavioral context.

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 short sentences with no wasted words. The primary action and scope are front-loaded, and the protocol distinction is added as a compact clarifier.

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 simple check tool, the description covers the main purpose and protocol context. But with no annotations, no output schema, and an undocumented optional parameter, the agent is left without information on return values, possible states, or how to interpret the check results. It is minimally adequate but has clear gaps.

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 single parameter timeoutMs has no schema description (0% schema description coverage), and the description never mentions it. Since coverage is very low, the description must explain parameter semantics, but it remains silent. Thus no meaning is added beyond the bare parameter name.

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 clearly states a specific verb ('检查' / check), a specific resource ('tt-minigame-ide-cli（tmg 2.x）'), and the exact scope of the check (installation, version, login status). It also distinguishes tmg from tma by protocol, which helps differentiate it from sibling tools without opening their schemas.

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?

The description gives clear context for when to use this tool: checking the dedicated mini-game CLI. The note that tmg uses the mini-game protocol versus tma's mini-program protocol provides a decision criterion, though it does not explicitly name alternative sibling tools or state when not to use this tool.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the whitelist requirement, the protocol difference from `tma`, the full-mode behavior, and the returned CLI output and IDE window status. It does not cover side effects or prerequisites such as login/auth, but the core behavioral traits are 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 description is a single dense sentence that front-loads the core operation and then adds the differentiating protocol detail and return value. Every clause adds value, with no redundancy.

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 captures the operation, output, and an important constraint, but it lacks parameter semantics and explicit usage routing. Given that all 5 parameters are optional and there is no output schema, an agent would benefit from more detail about what each parameter means and when to supply it.

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?

There are 5 parameters with 0% schema description coverage, so the description must compensate, but it does not. It only hints at the `mode` parameter by mentioning 'full mode' and does not explain `projectPath`, `timeoutMs`, `expectedAppid`, or `expectedProjectType`. Parameter names are somewhat self-explanatory, but the agent is left without concrete guidance.

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 verb and resource: it invokes the official minigame CLI `tmg open` to open whitelisted projects in full mode. It also explicitly differentiates this from the `tma` miniapp protocol, making the tool's purpose and scope unmistakable.

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?

The description gives clear context: the IDE should handle the project as a minigame rather than a miniapp, which implies the intended use case. It does not explicitly list when not to use it or name sibling tools like douyin_open_project as alternatives, but the protocol distinction provides meaningful guidance.

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

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

With no annotations at all, the description carries the full burden of disclosing behavior. It explicitly warns of remote side effects ('远程上传'), states the safety gate ('默认拒绝，必须 confirm=true 才会触发'), and clarifies that the version check is informational and non-blocking ('信息性，不阻断'). This goes well beyond what the schema or annotations reveal, though it could still mention rollback or failure-mode consequences.

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 description is two dense sentences with no filler. The routing behavior is front-loaded, followed by the safety gating and the version-check nuance. Every clause contributes meaning.

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 tool has 9 parameters, no output schema, and no annotations, yet the description explains only the confirm gate and a small portion of the routing logic. It does not describe the expected return format, the meaning of projectPath/appChangelog/channel, or what 'versionCheck' contains. For a dangerous remote-upload operation, this is incomplete.

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 must compensate for the 9 parameters. It clarifies confirm and the minigame/regular routing, but it leaves required parameters like appChangelog and important ones like projectPath, channel, appVersion, copy, timeoutMs, and expectedProjectType undefined. This is a significant gap for a complex, dangerously action tool.

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 clearly states a specific verb and resource: '上传抖音项目' (upload Douyin project). It further distinguishes internal behavior by routing '小游戏走 tmg upload，其余走 tma upload', which removes ambiguity about what the tool actually does. No sibling tool appears to overlap with uploading, so the purpose is unambiguous.

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?

The description gives clear operational context: by default uploads are rejected, and only confirm=true triggers the remote upload. It also explains project-type routing, helping the agent understand when the minigame path versus the general path applies. It does not explicitly name an alternative tool for 'not uploading', but no sibling tool competes with this action, so the guidance is sufficient.

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