Timexxs MCP

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 implies a non-destructive check but says nothing about what the result looks like (flagged terms vs. pass/fail verdict), whether detection is per-segment, or any limits beyond the schema's maxItems. For a no-annotation tool this is a notable gap.

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 the capability stated first and the usage condition second; nothing is redundant. The 快工场 prefix is mild branding overhead but does not impede comprehension.

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?

There is no output schema and no annotations, so the description is the only place a caller could learn what comes back — and it does not say. Given the tool's simplicity and fully documented single parameter it is minimally viable, but the return-value semantics are missing.

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 single required parameter `texts` is documented in the schema itself (要检测的文案, 可多段). The description adds no syntax, format, or batching detail beyond the schema, so the baseline of 3 applies.

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+resource (风险词检测 / risk-word detection) and further scopes it as 发布前合规自检, so an agent knows exactly what the tool produces. It does not explicitly contrast itself with any sibling, but no sibling in the list performs compliance/risk-word checking, so the ambiguity risk is low.

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 two concrete trigger conditions: when the user's copy is about to be published externally, or when the user asks whether something is 违规/敏感词. That is clear when-to-use guidance. It stops short of naming alternatives or stating exclusions, so it is not a full 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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the returned metric set and the platform-filtering capability, which is meaningful without an output schema, but it says nothing about authorization needs, data freshness, or return format for a data-aggregation read endpoint.

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 sentences, front-loaded with tool identity and returned metrics followed by the trigger condition. The metric enumeration is dense but each item earns its place by telling the agent what data comes back; nothing is redundant 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?

For a simple single-optional-parameter tool with no output schema, the description does the necessary work by listing the returned metrics. It is close to complete, though it could note the filtering default or that all platforms are included when the parameter is omitted.

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 single 'platform' parameter is already documented as a 平台码 filter with a douyin example and empty=all. The description ('可按平台过滤') adds only a high-level restatement, so baseline 3 is appropriate.

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+resource (数据中心总览 / data-center overview) and enumerates exactly which metrics are returned (accounts, followers, finished/published videos, plays, likes, comments, shares). No sibling tool produces an aggregated data overview, so an agent can distinguish it immediately.

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 invocation triggers (用户问 '我的数据/涨粉/播放量怎么样' 时调用), which is clear when-to-use context. It does not name when-not to use it or point to any alternative sibling (e.g. get_point_balance, kgc_usage), so it falls short of a full 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?

No annotations are present, so the description carries full burden. It discloses that the balance is scoped to the current user or their team and that it returns synchronously, which is useful. It doesn't mention authentication or failure behavior, but for a simple no-parameter read query that's a minor gap.

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 compact sentences: first states what is returned, second states when to invoke, third states timing. No filler; all content is front-loaded.

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 zero-parameter read-only query with a clear return concept, the description covers what an agent needs to select and call it. Not tied to any output schema, so explaining return format could add a little value, but the core is complete.

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 zero parameters, so baseline 4 applies. The description adds the semantic nuance of a team-scoped balance, which is not expressible through the schema and helps the agent interpret the result.

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 a specific verb and resource: query the current user's (or team's) compute point balance. In a sibling set dominated by generation and task tools, no other tool competes for this exact purpose, so it is clearly distinguishable.

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?

Explicitly names the use cases (user asks remaining points/quota, or wants to confirm balance before generating), which is more than most siblings provide. This leaves little ambiguity about when to call 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 full burden. It does disclose real behavior beyond the schema: the ACCEPTED trigger, the running/polling loop, and the 20-second retry interval. However it never says what other status values mean (succeeded/failed/expired), whether jobs expire, or how long results persist, which matters for a polling tool.

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?

A single dense sentence that front-loads the identity (fast-workshop background result query), then the trigger condition, then the polling rule. 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?

For a one-parameter polling tool with no output schema and no annotations, the description covers the essential loop (ACCEPTED in, job_id, re-poll on running) but stops short of saying what the terminal result looks like or when polling should be abandoned, which the agent would need to avoid infinite polling.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents job_id as the value found in the ACCEPTED result. The description reinforces its origin and ties it to the ACCEPTED condition, adding light contextual meaning over the schema's own wording, hence just above the baseline.

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 a specific verb+resource combination in "查询转入后台的调用结果" (query the result of a background call) and scopes it to results that were deferred with code=ACCEPTED. An agent can distinguish this from siblings like task_status or publish_status because the trigger condition is spelled out.

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?

Gives explicit usage context: call it when some tool returns code=ACCEPTED, and poll again after 20 seconds if status=running. That is strong when-to-use guidance, but it never explicitly excludes or contrasts the sibling task_status/publish_status tools, so an agent facing overlapping status tools still has to infer which to pick.

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 full burden. It usefully discloses return semantics (per-day x per-tool breakdown, estimates, and an included todayPoints field), which is genuine behavioral context. It does not state that this is a read-only/non-mutating call, nor any auth or rate-limit characteristics.

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?

Front-loaded with the tool's identity and scope, followed by payload detail and a trigger clause; every sentence carries information. Slightly dense with parenthetical qualifiers, but no waste and 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?

With no output schema, the description does the work of describing the return shape (daily per-tool counts, points spent, todayPoints) and flags that point figures are estimates. The remaining gap is routing context versus get_point_balance, which an agent hovering between the two would benefit from.

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 single days parameter is fully documented there (default 7, max 90). The description only echoes the window concept, adding no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 (查…用量 / query usage) and pins the scope (最近 N 天) plus the exact payload (按日 x 工具的调用次数与消耗点数). It is clearly distinguishable in content from balance-style siblings, but it never names an alternative such as get_point_balance, so the differentiation is left implicit.

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?

An explicit invocation trigger is given: 用户问"今天用了多少点/最近消耗"时调用, which tells the agent exactly what user phrasing should route here. There is no when-not guidance or pointer to the sibling (get_point_balance) that would handle a plain current-balance question.

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 usefully states what is returned (id/平台/昵称/状态), but omits auth requirements, whether results are paginated or sorted, and what an empty list means (no bound accounts vs. error).

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 compact sentences, front-loaded with the verb and resource, followed by the return fields and the code table. Every element earns its place; 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?

For a one-parameter list tool with no output schema, the description covers purpose, returned fields, and the platform code vocabulary needed to use the filter. Remaining gaps (pagination, empty-result semantics) 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 coverage is 100% and the single parameter is self-documented as an optional filter defaulting to all platforms. The description adds real value beyond the schema by supplying the valid platform codes (douyin, xiaohongshu, weixinshipinhao, kuaishou, guanghe, bilibili, tiktok_desktop), which the schema does not enumerate as an enum.

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 a specific verb (列出/list) and resource (用户已绑定的自媒体矩阵账号) plus the downstream purpose (发布视频用), and enumerates the returned fields. It does not explicitly compare itself to any sibling, but the siblings are largely unrelated operations, so the risk of mis-selection is low.

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 parenthetical '(发布视频用)' implies the context in which this list is needed (before publishing a video), but there is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named. Usage is inferable rather than spelled out.

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 behavioral burden. It usefully discloses the return fields and that keyword searches title/content, but says nothing about ordering, pagination semantics beyond the schema, or permissions. For a low-risk read operation this is adequate, not rich.

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 tight sentences, front-loaded with the tool's purpose followed by parameter behavior, with no filler. The '快工场 ·' prefix is minor branding overhead but harmless.

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?

Despite having no output schema, the description enumerates the returned fields (title, content, source), which compensates well. With params fully covered by the schema and a simple read-only scope, the definition is nearly complete, missing only ordering/pagination 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 coverage is 100% so page_size is already documented. The description adds real meaning beyond the schema by clarifying that keyword performs fuzzy matching against both title and content, while the schema merely says '关键词(可空)'.

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 a specific verb (列出) and resource (文案库) and even enumerates the returned fields (标题+内容+来源), so the agent knows exactly what this tool surfaces. It does not, however, distinguish itself from the sibling save_copywriting or the other list_* tools, so it stops short of a 5.

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?

Usage is implied: retrieve saved copywriting from the library. The keyword behavior is explained, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives like list_my_works or list_materials, leaving the agent to infer context.

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 full burden. It discloses that results are returned synchronously ('同步返回') and enumerates what is returned (value, aspect ratios, prompt/reference limits), but it does not explicitly state read-only nature, permission requirements, or any 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?

The description is three short sentences, front-loading the purpose and usage before return details. Every sentence 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?

Given zero parameters and no output schema, the description compensates by listing the returned fields and noting synchronous return. It is nearly complete for a simple list tool, though it omits auth or pagination details (likely unnecessary).

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 tool takes zero parameters, so the baseline score of 4 applies. The description does not need to add input parameter semantics, and it correctly focuses on output details.

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 '列出' (list) and resource 'AI 生图模型' (AI image generation models), scoped to '当前机构可用' (available to current organization). It also names the sibling consumer 'ai_generate_image' for model selection, which helps distinguish it from other list 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 states the tool is for 'ai_generate_image 选 model' (ai_generate_image to select model), providing clear usage context. However, it does not state when not to use it or list alternative tools, so it lacks exclusions.

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 usefully discloses the return payload (id/名称/类型/链接/封面), which compensates for the absent output schema, but says nothing about permissions, pagination limits, or read-only nature beyond the verb 'list'.

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 compact sentences with the purpose front-loaded before the return shape. The '快工场 ·' branding prefix is minor noise but the rest of the text 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 simple, fully-optional read-only listing tool with 100% schema coverage, the description gives scope plus the returned fields, which substitutes adequately for the missing output schema. Nothing essential for a correct call is missing.

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%, so keyword, page_size and material_type are already fully documented in the schema, including the default of 'image' and the 20-item default. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 a specific verb (列出/list) and resource (素材中心的图片/视频素材), and clarifies scope by naming what lives there (生成的参考图、混剪素材). An agent can distinguish it from list_my_works or list_image_models, though the description never names a sibling explicitly.

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?

Usage is implied by the scope note that generated reference images and clip-mix materials are all here, which suggests this is the browsing entry point. However, there is no explicit when-to-use, when-not-to-use, or comparison against alternatives such as list_my_works.

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 exist, so the description carries the full behavioral burden. It helpfully discloses the return fields (id/名称/时长/封面/链接) and the fuzzy-search nature of keyword, but says nothing about auth requirements, pagination limits beyond page_size, or freshness/sorting of results.

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?

A tight, front-loaded passage: library and resource first, return fields next, parameter hint last. No wasted text, though the middle bar-dot concatenation is slightly list-like rather than 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 output schema, the description compensates by enumerating the returned fields, so an agent knows what it will get. For a simple zero-required-parameter listing tool this is close to complete; only sorting/pagination-behavior detail is missing.

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%, so both parameters are already documented in the schema. The description restates that keyword does fuzzy name matching, adding only marginal value over the schema's own '成片名称关键词' description. Baseline 3 is appropriate.

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 a specific verb (列出) and resource (成片库「我的作品」里的视频成片), and even names the returned artifact type. This clearly distinguishes it from sibling list tools like list_materials, list_copywriting, and list_accounts, which target different resource libraries.

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 parenthetical '(可用于发布)' gives an implied usage context (results are publishable), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling list/status tools. Usage must be inferred.

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 full behavioral burden. It discloses the return fields (task name, platform, status counts) but omits important traits like pagination behavior, default page size, or that it is a read-only query. It adds some value but falls short of rich 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, front-loaded sentence that efficiently conveys the tool's purpose and return content. It has no wasted words, though the dense listing of fields is slightly less scannable.

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 the tool's low complexity (one optional parameter, no output schema), the description adequately explains what is returned (task names, platforms, status counts). It omits pagination or ordering details, but those are minor for a simple query tool.

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% (page_size has a clear description and default), so the schema already fully documents the single parameter. The description adds no extra meaning about page_size or pagination, making the baseline of 3 appropriate.

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 specifies a clear verb (查询) and resource (最近的发布任务记录) with detailed return fields (任务名/平台/各状态数量), making the tool's function immediately understandable. However, it does not differentiate from similar siblings like task_status or kgc_job_status.

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 offers no guidance on when to use this tool versus alternatives such as task_status, nor does it mention any prerequisites or exclusions. It simply states what the tool does, leaving the agent to infer usage context.

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 full transparency burden. It implies a read-only status lookup, but says nothing about behavior for pending vs failed vs expired task_ids, whether results are returned only on completion, polling expectations, or authentication requirements. Only the return content ('进度与成片结果') is hinted at.

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?

A single dense sentence with the platform and purpose front-loaded, followed by the parenthetical detail. Nothing is redundant, though the parenthetical prefix enumeration makes it slightly heavier than strictly necessary.

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 one-parameter, no-output-schema tool, the description at least names what comes back (progress and final result) and which ID families are valid. It is still thin on the states a task can be in and what a failure response looks like, which an agent polling a status endpoint genuinely needs.

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 there is one parameter, so the description must compensate. It does add real value by defining the task_id namespace (rm_ / ss_ / tf_ / img_ prefixes), which tells the agent what kind of identifier is valid. It still omits format details such as whether the prefix is included, but this meaningfully beats the empty schema.

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 a specific verb+resource ('查询异步任务...的进度与成片结果') and enumerates the concrete task families it covers via ID prefixes (rm_ / ss_ / tf_ / img_). That is far more specific than the bare name. It does not, however, distinguish itself from the similarly-purposed sibling kgc_job_status, so an agent cannot route between them on this text alone.

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?

Usage is only implied: the prefix list tells the agent which task_ids this tool accepts, which is genuine context for 'when this applies'. But there is no explicit when-to-use, no exclusion, and no pointer to alternatives such as kgc_job_status or publish_status for other job types.

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