Server Quality Checklist

Tool Scores

• kie_statusB
  3.1/5.0
  Behavior2/5

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

  With no annotations present, the description must carry the full burden. It reveals output fields but fails to state that this is a read-only operation, whether it can be polled, or any side effects. The mention of creditsConsumed implies cost-related context but is not clarified.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no unnecessary words. It efficiently conveys the essential information in a compact format.

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

  Completeness3/5

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

  The description lists the expected return fields, but without an output schema, the agent has limited information about data types or how to interpret results. It also lacks usage context relative to sibling tools. For such a simple tool, it is minimally adequate.

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

  Parameters3/5

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

  The schema description covers 100% of the single parameter (taskId), so the description's 'by taskId' adds no new meaning. The baseline of 3 applies because the schema already documents the parameter adequately.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: retrieving task state by taskId, with a list of returned fields. It distinguishes itself from sibling tools that generate, upload, or wait, though it lacks an explicit verb like 'get' or 'retrieve'.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. It does not mention that it is useful after asynchronous operations like kie_generate or kie_upload, nor does it specify scenarios where 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.

• kie_ledgerB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that this is a ledger and a data source, which implies a read-only operation, but it does not confirm whether the tool modifies state, what the return format is, whether pagination is handled, or any other runtime behavior. This is a significant gap for a data-access tool.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences with no filler. The first sentence front-loads the core purpose ('Spend ledger'), and the second sentence adds a practical usage note. Every word contributes value, making it optimally sized.

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

  Completeness2/5

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

  The tool has no output schema and no annotations, and the description provides only minimal context. It lacks explicit information about the return structure, whether entries are listed chronologically, how filters work together, or any side effects. For a tool that the agent will likely use for user-facing reporting, the description is incomplete.

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

  Parameters3/5

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

  The input schema already describes all three parameters (limit, runId, since) with 100% coverage, so the description does not need to explain them. The description adds no extra parameter context, but the schema descriptions are sufficient, warranting the baseline score of 3.

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

  Purpose4/5

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

  The description clearly identifies the tool as a 'spend ledger' and explains it tracks 'what was generated and what it cost,' which indicates the resource and its content. It distinguishes from siblings like 'kie_balance' by implying a detailed transaction log rather than a summary. However, it lacks a direct verb (e.g., 'list', 'retrieve') that would more explicitly state the action.

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

  Usage Guidelines3/5

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

  The phrase 'The source for a report to the user' provides a clear use case—when the agent needs to report on generation and costs—but it does not explicitly mention when NOT to use this tool or any alternatives. The context is implied rather than clearly guiding selection among sibling tools.

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

• kie_catalog_listB
  3.4/5.0
  Behavior4/5

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

  With no annotations, the description effectively discloses key behavioral traits: prices are fetched live and never stored, schemas come from a 30-day cache, and the first call incurs a delay. This gives the agent useful expectations about data freshness and latency, going beyond the basic function.

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

  Conciseness4/5

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

  The description is brief and front-loaded with the core purpose, followed by two clarifying behavioral notes. It is efficient with no redundant wording, though the first phrase is a fragment rather than a complete sentence.

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

  Completeness3/5

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

  The description covers data freshness and latency, but given that no output schema exists and there are 11 sibling tools, it lacks explicit guidance on use cases and return contents. It is sufficient for a simple list tool but leaves the agent to infer when to use it.

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

  Parameters3/5

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

  The input schema already provides 100% coverage with descriptions for mode, type, and query. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description starts with 'Models with prices and limits,' which implies a listing operation but lacks an explicit verb like 'list' or 'retrieve.' The tool name kie_catalog_list clarifies the purpose, and the description distinguishes it by mentioning live prices and cached schemas, but it doesn't explicitly contrast with sibling tools like kie_catalog_show or kie_catalog_refresh.

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

  Usage Guidelines2/5

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

  The description does not state when to use this tool versus alternatives. It provides behavioral details about live fetching and caching but no guidance on when to choose kie_catalog_list over kie_catalog_show or kie_catalog_refresh. No exclusions or alternative tool mentions are present.

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

• kie_waitA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior on its own. It mentions 'polling' and 'returns the final state', but omits critical behaviors such as what happens on timeout, error handling, or whether it blocks the caller. There is no mention of the timeoutSec parameter's effect or potential exceptions. This is a significant transparency gap.

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

  Conciseness5/5

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

  The description is extremely concise: two short sentences that are front-loaded and contain zero filler. Every word contributes to understanding the tool's core function. It is appropriately sized for a simple polling tool.

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

  Completeness2/5

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

  Given the tool has no output schema and no annotations, the description should explain what 'final state' means, how timeouts affect the return, and how to interpret the result. It does none of this. It also does not reference the task lifecycle or relationship to other kie_* tools. This is incomplete for a tool with three parameters and a non-obvious return value.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all three parameters (taskId, pollSec, timeoutSec), so the baseline is 3. The tool description adds no additional semantics about the parameters, but the schema already provides adequate meaning. No extra credit is warranted beyond the baseline.

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

  Purpose5/5

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

  The description clearly states the tool's function: to wait for a task to finish by polling and then return the final state. It uses a specific verb ('wait') and resource ('task'), and distinguishes itself from sibling tools like kie_status by emphasizing the blocking/polling behavior.

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

  Usage Guidelines4/5

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

  The description implies a clear use case: when you need to block until a task completes. It provides context but does not explicitly mention alternatives (e.g., using kie_status for a non-blocking status check) or exclusions. Thus it earns a 4 for clear context without explicit exclusions.

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

• kie_balanceA
  3.9/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Cheap, no side effects,' which informs the agent that this is a low-risk, non-mutating operation. It does not describe the return format or whether real-time data is returned, but for a simple balance tool, the side-effect disclosure adds meaningful transparency beyond the name.

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

  Conciseness5/5

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

  The description is extremely concise: two short sentences. 'Remaining credits on the kie.ai account' conveys the core purpose, and 'Cheap, no side effects' adds valuable behavioral context. Every word earns its place, and the structure is front-loaded with the most important information.

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

  Completeness4/5

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

  Given the tool's simplicity (zero parameters, no output schema, no nested objects), the description is suitably complete. It tells the agent what the tool does and the side-effect profile. It does not explicitly mention that the tool returns a numeric credit value, but that is largely self-evident from the name. The lack of an output schema makes the description's omission slightly noticeable, but overall it covers the essential context.

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

  Parameters4/5

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

  The tool has zero parameters, so the input schema is empty. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4. The description adds no parameter-specific information, but none is required; it correctly focuses on the tool's behavior.

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

  Purpose4/5

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

  The description clearly states the tool's function: reporting remaining credits on the kie.ai account. While it lacks an explicit verb like 'get' or 'check', the noun phrase 'Remaining credits' unambiguously conveys a balance query. It is distinct from sibling tools like kie_ledger or kie_status because it specifically targets credit balance, though it does not name alternatives.

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

  Usage Guidelines3/5

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

  The description implies usage context: it is a cheap, side-effect-free way to check credit balance. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to check credits vs. view ledger or status). The phrase 'no side effects' suggests it is safe for frequent calls, but no exclusions or alternative guidance is provided.

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

• kie_doctorA
  3.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral transparency. It reveals the diagnostic checks performed, but it doesn't state whether the tool is read-only, has side effects, makes network calls, or how it reports failures. This is a significant gap for a diagnostic tool.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the tool's purpose, and each sentence adds essential information: what the tool checks and when to call it. No wasted words.

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

  Completeness3/5

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

  For a tool with zero parameters and no annotations, the description covers the essential checks and usage timing. However, since there is no output schema, the description doesn't explain what the tool returns or how results are presented, leaving some context incomplete.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is 100% as an empty object. The baseline of 4 applies here since there are no parameters to explain, and the description doesn't need to compensate for missing parameter information.

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

  Purpose5/5

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

  The description clearly defines the tool as a readiness check for kie.ai, listing specific checks (API key presence and source, API responsiveness, price list fetchability, credit-to-USD rate status). It distinguishes itself from siblings by framing itself as the first action when something is wrong, even though it doesn't name alternate tools.

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

  Usage Guidelines4/5

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

  Explicit guidance is provided: 'Call this first whenever something is wrong.' This clearly states when to use the tool, but it doesn't mention when not to use it or name alternative tools for specific scenarios, which would make it a 5.

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

• kie_catalog_showA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the transparency burden. It discloses the content of the model card (input schema, limits, price) which is useful, but it does not state whether the operation is read-only, how it handles invalid model IDs, or any error behavior. Since it's a simple info tool, this is adequate but 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose, and no extraneous detail. The 'Call this BEFORE kie_generate' instruction is placed efficiently at the end. Highly concise and well-structured.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description is largely complete. It conveys what the tool returns (full model card with specific fields) and when to call it. Minor gaps like error handling or how to obtain model IDs are not critical for this low-complexity tool.

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

  Parameters3/5

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

  Schema coverage is 100% because the only parameter 'model' has a description 'model id'. The tool description does not add extra meaning beyond the schema, such as where to find valid model IDs or examples. Baseline of 3 applies since schema covers it.

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

  Purpose5/5

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

  The description clearly states the tool shows a full model card including input schema, limits, and price. It distinguishes from sibling tools like kie_catalog_list by emphasizing the 'full model card' aspect, and explicitly mentions a key usage tie to kie_generate.

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

  Usage Guidelines4/5

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

  Provides explicit guidance to call this tool BEFORE kie_generate, giving a clear when-to-use. However, it does not mention when not to use it or contrast with alternatives like kie_catalog_list, so it falls 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.

• kie_estimateA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It successfully discloses that the tool spends no money, may return an unknown price (known=false), and that certain models resolve exact prices only when passed matching input/refs. It also references missingFields in the response, hinting at conditional behavior. However, it omits details about error handling or what the full response contains, so it is not exhaustive.

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

  Conciseness4/5

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

  The description is three sentences, front-loaded with the core purpose. The second sentence ('Spends no money') is highly informative and concise. The third sentence is long and dense, but every clause carries essential conditional logic. It is efficient and not padded, though a slight structural break would improve readability.

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

  Completeness3/5

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

  Given there is no output schema and no annotations, the description needs to explain the response and edge cases more fully. It mentions missingFields, known=false, and priceBasis, but does not describe the overall response shape, how to interpret cost values, or what to do when missingFields indicates issues. It is adequate for a basic call but leaves operational gaps for an agent needing to make decisions.

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

  Parameters4/5

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

  The schema covers 75% of parameters with basic descriptions, and the description adds significant meaning by instructing that input and refs must match the generation parameters exactly for accurate range-based estimates. This helps the agent understand how to fill the undocumented 'input' object and clarifies the purpose of 'refs'. The description thus goes beyond schema in defining parameter relationships.

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

  Purpose5/5

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

  The description opens with 'Cost estimate before generation,' which is a specific verb+resource statement that clearly distinguishes it from sibling tools like kie_generate (actual generation) and kie_balance (balance check). It also states 'Spends no money,' further differentiating its purpose as a non-mutating pre-flight check.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on how to use the tool: pass the same input and refs that will go into kie_generate, implying this is a pre-generation step. It also gives conditional usage rules ('If known=false ... generation must not start without user confirmation') and a conditional for priceBasis="range". However, it does not explicitly state when NOT to use it or name alternative tools, so it misses the full 'when/alternatives' ideal.

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

• kie_uploadA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the public URL 'lives 3 days', which is critical for the agent to know. It does not cover auth requirements, overwrite behavior, or storage limits, but it adds meaningful context beyond the simple verb 'upload'.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the verb 'Upload' and immediately states the target storage, public URL, lifetime, and purpose. Every phrase contributes value, and there is no repetition or wasted words.

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

  Completeness4/5

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

  For a simple tool with one parameter and no output schema, the description covers the essential aspects: action, result, longevity, and intended use. It lacks details like file size limits or explicit return format, but 'get a public URL' adequately implies the response type.

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

  Parameters3/5

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

  The only parameter 'path' is fully described in the schema as 'Path to the file', giving 100% schema coverage. The description does not add any additional semantic information about the parameter, so it remains at the baseline score for high schema coverage.

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

  Purpose5/5

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

  The description clearly states 'Upload a local file to kie storage and get a public URL', specifying both the action and the outcome. This uniquely distinguishes it from sibling tools like kie_doctor or kie_catalog_list, which serve unrelated purposes.

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

  Usage Guidelines4/5

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

  The phrase 'Needed for references' provides a clear usage context, indicating when the tool should be used. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusion criteria.

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

• kie_catalog_setA
  4.4/5.0
  Behavior3/5

  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 a key behavioral trait: 'Stored separately from live data and applied on top of it,' which clarifies override semantics. However, it does not mention whether re-recording an existing model overwrites it, persistence details, or any side effects beyond the separate storage. It adds some context but is not fully transparent.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the action ('Record a model by hand') and immediately followed by essential context. Every sentence earns its place; there is no fluff or redundancy.

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

  Completeness4/5

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

  For a 10-parameter tool with nested objects and no output schema, the description provides key context: the manual override role, separate storage behavior, and pricing rule. It does not elaborate on all parameters, but the full schema covers them. It misses potential details like interaction with catalog_refresh or what the response looks like, but overall for the complexity, it is reasonably complete.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explicitly ties 'price' to documentation sourcing ('take it from the documentation') and mentions 'limits' as a general concept, grouping parameters like maxRefs/maxDurationSec. This provides helpful intent for several parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Record a model by hand' with specific fields (id, type, price, limits). It distinguishes this tool from siblings by explaining its role as a manual override for models missed by automatic matching, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  Explicit usage guidance is provided: 'use this only for models the automatic price matching misses.' It also provides a critical rule: 'Do NOT invent a price; take it from the documentation.' This clearly delineates when to use the tool versus relying on automatic processes.

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

• kie_catalog_refreshA
  4.6/5.0
  Behavior4/5

  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 it ignores the cache and forces a re-read, and clarifies that prices are otherwise fetched live. However, it doesn't mention any potential side effects or return behavior, though for a non-destructive refresh this is likely acceptable.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the core action, then the rarity and usage condition. Every sentence adds unique value without redundancy.

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

  Completeness4/5

  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 is sufficiently complete: it explains what it does, when to use it, and why it's rarely needed. It doesn't clarify the return value, but that's likely low-stakes for a refresh action.

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

  Parameters4/5

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

  The tool has zero parameters, with an empty schema, so there are no parameter details needed. The description provides context about what is refreshed, covering the only relevant semantics.

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

  Purpose5/5

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

  The description clearly states the tool forces a full re-read of prices and model schemas, ignoring the 30-day schema cache. This uses a specific verb and resource, and distinguishes it from siblings like kie_catalog_list and kie_catalog_show.

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

  Usage Guidelines5/5

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

  Explicitly says 'Rarely needed' and 'Use it when a model is missing or its parameters look wrong', providing clear conditions for use and when not to use it, contrasting with the default live-fetch behavior.

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

• kie_generateA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and excels. It leads with 'SPENDS MONEY,' warns that downloading is ON by default, explains the 14-day retention, and details default output paths. It also explains the noDownload behavior. This is rich behavioral disclosure that goes well beyond basic safety hints.

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

  Conciseness4/5

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

  The description is dense but every sentence contributes critical information: the spending warning, core function, prerequisites, safety limit, download default, and skip option. It is front-loaded with the most important warning ('SPENDS MONEY'). Slightly long, but appropriately so for the complexity.

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

  Completeness4/5

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

  Covers the main flow, prerequisites, download behavior, and safety. With 11 parameters and no output schema, it addresses the key invocation concerns. Could mention what the function returns (e.g., task ID or link) explicitly, but this is a minor gap given the rich context and sibling tools handling status/wait.

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

  Parameters4/5

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

  Although schema coverage is 100%, the description adds meaningful context: it explains the default download path when 'out' is unset, the effect of 'noDownload' (leaves only the link), and the purpose of 'maxCostCredits' as a safety limit. This enriches parameter understanding beyond the raw schema definitions.

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

  Purpose5/5

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

  The description clearly states the tool 'Creates a generation task and, with wait=true, waits for the result and downloads the files.' This specifies the verb (creates), the resource (generation task), and additional behavior (waiting, downloading). It also distinguishes itself from siblings by mandating prerequisites like kie_catalog_show and kie_estimate, implying this is the actual generation action.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'Before calling: kie_catalog_show (limits) and kie_estimate (price), plus the user's explicit consent to the amount.' It also advises using 'maxCostCredits as a safety limit,' giving clear operational guidance. This goes beyond simple context to include required preconditions and safety measures.

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