Server Quality Checklist

Tool Scores

• kintone-get-appC
  2.7/5.0
  Behavior2/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 of behavioral disclosure. 'Get' implies a read-only operation, but the description does not mention authentication requirements, error behavior, or what happens when the app does not exist.

  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 a single concise sentence with no filler or redundant content. It is appropriately short for a simple one-parameter read operation, though it sacrifices useful context for brevity.

  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?

  A simple tool with one documented parameter and an output schema is largely callable as-is. However, the description is incomplete for tool selection because it does not clarify the relationship to kintone-get-general-settings or other getter siblings.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the single parameter appId is already well documented in the input schema. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

  Purpose3/5

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

  The description states a clear verb ('Get') and a resource ('app settings'), but 'app settings' is vague in the context of siblings like kintone-get-general-settings. An agent cannot tell whether this returns general settings only or broader app configuration.

  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 given about when to use this tool over kintone-get-general-settings or the other getter siblings. There are no exclusions, alternatives, or contextual triggers provided.

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

• kintone-get-app-deploy-statusC
  2.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 disclosure. It only states the action 'Get' without explaining what status values are returned, whether deployment is asynchronous, or whether the tool requires an active deployment. This is minimal and reveals little beyond the title.

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

  Conciseness3/5

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

  The description is one short sentence with no filler, but it mostly restates the title with 'from kintone' adding little value. It is structurally clean but under-specifying rather than efficiently informative.

  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 tool is simple and has an output schema, but the description does not connect it to the deployment lifecycle or clarify what 'deploy status' means. The parameter is documented and output is presumably covered by the schema, so it is minimally viable but not rich enough for confident selection among siblings.

  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 documents the single 'apps' parameter with a description stating it is an array of app IDs with a maximum of 300. The description adds no additional meaning about the parameter, so it merits 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.

  Purpose4/5

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

  The description uses the verb 'Get' and names the resource 'app deploy status', clearly indicating a read-only status query. It does not explicitly differentiate itself from sibling tools like kintone-deploy-app or kintone-update-statuses, so it is clear but lacks sibling contrast.

  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 provides no guidance on when to call this tool, such as after kintone-deploy-app to check deployment progress. There are no mentions of alternatives, exclusions, or prerequisites, so an agent must infer its place from the name alone.

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

• kintone-get-general-settingsC
  2.9/5.0
  Behavior2/5

  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, yet it only states the bare action. It does not mention permission requirements, read-only guarantees, error behavior for nonexistent apps, or how lang/preview alter the request beyond what the schema already documents. For a tool with zero annotation coverage, this is a significant gap.

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

  Conciseness4/5

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

  The definition is a single front-loaded sentence with the verb first and zero filler. It is appropriately compact, though the brevity partly reflects under-specification rather than deliberate economy.

  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?

  An output schema exists and parameter coverage is complete, so return shape and argument formats are already handled structurally. What is missing is routing guidance among siblings and behavioral disclosure — making this minimally viable for a simple get tool but short of complete.

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

  Parameters3/5

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

  Schema description coverage is 100%: app, lang, and preview each carry inline descriptions, including enum options and a permission caveat for preview. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

  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 states a specific verb ('Get') and resource ('general settings of a kintone app'), which cleanly distinguishes it from sibling getters like kintone-get-form-fields, kintone-get-form-layout, and kintone-get-process-management. It stops short of explicitly naming what it is not (e.g., 'for fields, use kintone-get-form-fields'), so it misses the 5 bar.

  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?

  There is no guidance on when to use this tool versus the many sibling retrieval tools, no exclusions, and no prerequisites. The description merely restates the action; the agent must infer selection context purely from the resource name, with no help differentiating 'general settings' from 'app', 'form fields', 'process management', or 'app deploy status'.

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

• kintone-get-process-managementB
  3.1/5.0
  Behavior2/5

  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 only says 'Get', suggesting a read operation, but it does not disclose whether the operation has side effects, requires special permissions, or how it behaves if the app does not exist or process management is not configured.

  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, front-loaded sentence with no wasted words. It immediately conveys the verb and resource, making it both concise and easy to parse.

  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 output schema and full parameter schema cover the invocation details, and the simple read operation is probably callable as-is. However, the lack of usage guidance and the absence of any behavioral context beyond the terse 'Get' leaves some gaps for an agent trying to decide when this tool is the right choice.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameter properties are fully documented in the schema itself. The description adds no additional semantic detail beyond that, which is acceptable under the baseline for complete schema coverage.

  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 a specific verb ('Get') and resource ('process management settings from a kintone app'), so an agent can tell this is a retrieval operation for a distinct settings domain. It does not, however, describe what process management settings actually contain or explicitly contrast itself with sibling tools like kintone-get-general-settings.

  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?

  There is no guidance on when to use this tool versus alternatives such as kintone-get-general-settings or kintone-update-statuses. The description only states the action and target resource, leaving all selection context to the agent's inference.

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

• kintone-add-record-commentA
  3.6/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 full burden of behavioral disclosure. It does add genuine value by revealing the API's one-comment-per-call constraint, which sets correct expectations for repeated invocation. However, it is silent on permissions/auth requirements, idempotency, and any side effects beyond appending the comment, which a write operation with zero annotation coverage should ideally address.

  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 totaling roughly 35 words, with the core operation front-loaded in the first sentence. The second sentence earns its place by adding the one-comment-per-call constraint and the repeated-call pattern. There is zero filler 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?

  The tool is low complexity: four parameters, all documented at 100% coverage, and an output schema exists so return values need not be explained in the description. The description covers the single-call constraint and the schema covers the nuanced mentions behavior, giving an agent sufficient information to call the tool correctly. The only notable gap is the absence of explicit routing to the read sibling for comment retrieval.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline of 3 applies; the tool description itself adds no parameter-level meaning beyond what the schema provides. The schema richly documents all four parameters, notably the text parameter's warning that '@code' tokens become plain-text literals and mentions must be specified separately. The description doesn't need to compensate, but it also doesn't exceed the baseline.

  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 opens with 'Add a single comment to a kintone record,' a specific verb and resource that unambiguously states the operation. The 'one comment per call' qualification distinguishes it from potential batch operations and reinforces the single-item scope. It doesn't explicitly name a sibling such as kintone-get-record-comments, but the write-vs-read distinction is clear from the verb alone.

  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 provides explicit context for batching: 'to add comments to multiple records, call this tool repeatedly.' This tells the agent how to scale the operation. However, it gives no guidance on when not to use the tool or when a sibling like kintone-get-record-comments would be the appropriate choice, leaving alternative routing to inference.

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

• kintone-delete-recordsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates the destructive action and adds the maximum batch size of 100 records, but it does not mention irreversibility, permission requirements, or what happens if some records cannot be deleted.

  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 concise, front-loaded, and every sentence earns its place. It states the action, target, and a key constraint in only two short sentences.

  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 batch-delete tool, the description covers the core operation and batch limit, while the input and output schemas supply parameter details and return structure. A slight gap is the absence of an explicit irreversibility warning, but deletion is strongly implied by the tool name and description.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add new parameter-level meaning beyond confirming the batch nature via the 100-record maximum, which is already present in the ids schema.

  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 states a specific verb (delete), resource (records), and container (a kintone app), making the tool's purpose immediately clear. It also distinguishes itself from siblings like kintone-update-records and kintone-get-records by focusing on deletion of records rather than other operations.

  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 the tool should be used when multiple records need to be deleted from a kintone app, but it does not explicitly state when to prefer this over alternatives like kintone-update-records or kintone-delete-form-fields. No exclusions or alternative routing are provided.

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

• kintone-update-statusesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose a feature prerequisite and the 100-record limit, which are useful. However, it does not mention permissions, whether updates are atomic across the batch, or what happens on partial failure; schema text covers action/revision errors, but the free-text description remains thin for a mutating workflow 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?

  Two sentences, no filler, with the core action first followed by the two most decision-relevant constraints. Every sentence earns its place.

  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 two-parameter tool with a rich input schema and an output schema, the description covers the essential context: what it does, the prerequisite, and the batch ceiling. It is not fully complete because it doesn't name alternatives or side-effect behavior, but the structured fields compensate for most gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds no parameter meaning beyond what the schema already provides ('100 records' repeats maxItems). Baseline 3 is appropriate.

  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 a specific verb and resource: 'Update status of multiple records in a kintone app.' The word 'status' clearly distinguishes this from sibling tools like kintone-update-records, and the process-management requirement reinforces its distinct workflow purpose.

  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 gives an important precondition (process management must be enabled) and a batch limit, but it never explicitly says when to choose this tool over kintone-update-records or when status updates are not appropriate. Usage context is implied by the name and 'status' wording rather than stated.

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

• kintone-update-form-layoutA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It usefully discloses preview-only behavior, case-sensitive field codes, subtable structure, and the need for a deploy step. However, it does not mention that updating form layout may replace the entire layout or reposition existing fields, which is a significant side effect for a mutation 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 compact and front-loaded: purpose, environment, prerequisite calls, sensitivity constraint, subtable example, and deployment requirement each earn their place. No redundant or filler sentences are present.

  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 complex layout-update tool, the description covers the preview environment, pre-read steps, exact matching requirements, subtable structure, and deployment workflow. It falls short only by not clarifying whether the update is a full replacement of the layout or an incremental change, and by not explicitly routing to sibling field tools when relevant.

  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 meaningful value beyond the schema by warning that field codes are case-sensitive and must match exactly, and by giving concrete nested syntax for SUBTABLE fields. It does not add revision-parameter guidance, but the schema already documents that parameter well.

  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 verb and resource: 'Update form layout settings in a kintone app'. It also adds the limitation that it only works in the preview environment, which helps distinguish it from other tools. It does not explicitly name a sibling tool for contrast, but the resource is specific enough to avoid major confusion.

  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 actionable guidance: use kintone-get-form-fields and kintone-get-form-layout first, ensure field codes match exactly, and deploy via kintone-deploy-app to apply changes to the live app. It does not explicitly state when not to use this tool versus sibling update tools, but the context is clear.

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

• kintone-update-recordsA
  3.9/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 full burden of behavioral disclosure. It does reveal the mutating nature of the operation and lists useful non-updatable field types, but it omits important behavioral details such as revision/optimistic-locking behavior, partial-failure semantics, and permission/auth requirements.

  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 compact sentences with the primary action front-loaded. Every sentence adds value: the operation, the prerequisite, and a high-value warning about non-updatable fields. There is no filler or redundancy.

  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 complex schema documents field formats and the output schema presumably covers return values, so those do not need repeating. However, for a write tool with no annotations, the description omits context around revision validation, partial failures, and permissions, making it adequate but not fully complete for an agent to use confidently.

  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% parameter coverage with detailed descriptions for app, records, revision, and every field value type. The description adds the non-updatable field list and the prerequisite to discover field codes, but much of this is also reflected in the schema, so it does not significantly elevate parameter understanding 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 action ('Update multiple records') and the resource ('in a kintone app'), which distinguishes it from sibling tools like add-records, delete-records, and get-records. The title alone is generic, but the description adds the object and scope.

  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 explicitly instructs the agent to call kintone-get-form-fields first to discover field codes and formats, which is concrete and actionable. However, it does not provide explicit when-not-to-use guidance or mention alternatives for record creation/deletion, so it is one step below a fully explicit usage guide.

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

• kintone-deploy-appA
  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 full burden of behavioral disclosure. It does disclose the key asynchronous nature of the API and directs users to check progress with a sibling tool. However, it does not describe the effect on the production environment, whether deployment is reversible, or any permissions required, leaving moderate gaps for a mutating operation.

  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 exactly two sentences, with the core purpose front-loaded and the async follow-up immediately stated. Every sentence earns its place, and there is no redundant or filler content.

  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 full parameter schema, presence of an output schema, and the description's disclosure of asynchronous behavior plus the status-checking sibling, the definition is largely complete. It lacks explicit notes on permissions or error conditions, but those are not essential for correct invocation given the available structured data.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema fully documents both parameters (apps array with app and optional revision, plus the revert boolean). The description itself adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

  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 a specific verb ('deploy'), resource ('app settings'), and environment transition ('from pre-live to production environment'). It distinguishes itself from sibling tools, particularly kintone-get-app-deploy-status, which is explicitly named as the follow-up status checker.

  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 gives clear context for when to use the tool (deploying app settings from pre-live to production) and mentions the related status-checking tool as the next step. It does not explicitly state when not to use it or list alternatives, but the deployment scope is specific enough that the agent can determine appropriate usage.

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

• kintone-get-form-layoutA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden, but it uses 'Get' and 'retrieval' to signal a non-mutating operation and explicitly states support for both live and pre-live settings. It doesn't cover permissions or error behavior, though the preview parameter schema already contains the relevant permission notes.

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

  Conciseness3/5

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

  The description is reasonably sized and front-loaded, but 'Use to understand current form arrangement before layout updates' and 'Essential when adding new fields... or rearranging existing fields' are redundant restatements of the same usage guidance. It could be condensed without losing value.

  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?

  There is an output schema covering the return structure, and the description covers rationale, use cases, and the live/preview retrieval distinction. Permission caveats are already present in the preview parameter description, so the missing details are minor for a simple read-only retrieval 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 description coverage is 100%, so the schema already documents both parameters and their meanings. The description adds the live/pre-live vocabulary, but that maps directly to the preview parameter and does not introduce new constraints or syntax.

  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 first sentence names the exact action and resource ('Get form layout from a kintone app'), and the second specifies the return payload ('rows, subtables, groups, and field positioning'). This clearly distinguishes it from sibling tools like kintone-get-form-fields and kintone-update-form-layout.

  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 gives concrete use triggers: before layout updates, when adding fields needing positioning, and when rearranging existing fields. It does not explicitly say when not to use it or route to alternatives, but the context is clear enough for an agent.

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

• kintone-download-fileA
  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 behavioral disclosure burden. It explicitly discloses the local filesystem side effect, the return value, and the required permissions and environment setup. It does not mention overwrite behavior or failure modes, but the most important behavioral traits are covered.

  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 compact sentences with no filler. The first sentence states the action and return value, and the second lists prerequisites; it does not repeat schema details or add unnecessary context.

  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 two-parameter tool with an output schema and fully documented parameters, this description is largely complete: behavior, return value, and prerequisites are all included. Minor omissions such as overwrite policy and error behavior prevent a perfect score, but the agent has enough to select and call the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters are already well documented: fileKey explains its source and fileName explains naming plus automatic extension detection. The description adds the download-directory context but no additional parameter-level meaning, so the schema does the heavy lifting.

  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 names the specific action (download), the resource (a file identified by fileKey), and the destination (the configured download directory). This clearly distinguishes it from sibling tools, which concern app settings, form layouts, and record operations rather than file retrieval.

  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 states the prerequisite environment variable and required permissions, giving clear conditions for successful use. It implies the appropriate context—after obtaining a fileKey from record retrieval or upload—and no sibling tool provides file download, so an explicit 'use this instead of X' exclusion is not necessary.

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

• kintone-get-form-fieldsA
  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 behavioral burden. It discloses the read-only nature through 'Get' and 'before add/update/delete operations', and describes the response shape including the properties object and revision. It also mentions live and pre-live retrieval support.

  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 front-loaded with the main purpose and then gives useful detail about return contents and use cases. It is slightly long but each sentence adds relevant context, such as response structure and when to use the tool.

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

  Completeness5/5

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

  For a simple read tool with an output schema, the description covers the primary purpose, the return payload, the use cases, and environment support. Nothing essential for an agent to call the tool correctly is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that field configuration settings are included and mentions pre-live/live support, but it does not materially expand on parameter-level semantics beyond the schema.

  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?

  Clearly states a specific verb and resource: get form field settings from a kintone app. It also lists what is returned, differentiating it from sibling tools like get-form-layout and update-form-fields.

  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 gives clear context: use it to understand current field structure before add/update/delete operations and to verify lookup configurations. It does not explicitly exclude any sibling alternatives, but the usage intent is unambiguous.

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

• kintone-get-recordsA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the disclosure burden. It transparently states the key behavioral constraint that all filter conditions are AND-combined and that OR conditions are unsupported, and the 'Get' wording makes the read-only nature evident. It omits peripheral details such as permissions or rate limits, but nothing about the core call behavior is hidden.

  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 with no filler. It front-loads the core purpose, then states the critical filter limitation, then gives an actionable prerequisite. Every sentence carries distinct 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?

  For a six-parameter tool with nested filter objects, the description plus the fully documented schema and output schema are largely sufficient for correct invocation. The only non-critical gap is that default pagination behavior when limit is omitted is not addressed, but this does not undermine selection or basic usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents every parameter, including nested filter types and supported field types. The description reinforces the AND/no-OR rule and the need to discover field codes, but adds no significant parameter semantics beyond what the schema provides.

  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 states a concrete action and resource ('Get multiple records from a kintone app') and adds the distinguishing feature of 'structured filtering.' This clearly separates it from sibling metadata tools like get-form-fields and mutation tools like add-records or update-records.

  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 gives explicit guidance to call kintone-get-form-fields first to discover available fields and types, which directly supports correct filter usage. It does not enumerate exclusions like 'use add-records for writes,' but the verb and sibling names make that distinction clear.

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

• kintone-update-general-settingsA
  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 behavioral disclosure burden. It clearly states that the update modifies a temporary pre-live area, not the live production environment, and that deployment is required for production impact. This is a key side-effect. It does not mention permissions or partial-update behavior, but the schema's revision parameter hints at optimistic locking.

  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 with no wasted words. It front-loads the primary purpose, then explains the critical pre-live environment detail and the required follow-up deploy action. Every sentence earns its place.

  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 14-parameter tool, the description covers the most important contextual nuance: the pre-live staging behavior and the need for a subsequent deploy. The schema handles all parameter documentation, and an output schema is indicated, so return-value details are not needed. A minor improvement would be noting that unspecified settings remain unchanged, but this is not essential.

  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?

  All parameters have descriptive text in the input schema, giving 100% schema coverage. The description adds no extra parameter-level meaning, 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.

  Purpose5/5

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

  The description states a specific verb and resource: 'Update the general settings of a kintone app.' It clearly distinguishes this tool from sibling tools like kintone-update-form-fields, kintone-update-form-layout, and kintone-update-records by focusing on general settings, and the pre-live environment detail further sharpens the scope.

  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 gives explicit sequential guidance: changes go to the pre-live environment, and to affect production you must then execute kintone-deploy-app. This tells the agent when to use this tool and what to do after, but it does not explicitly compare against alternative update tools for non-general settings.

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

• kintone-get-record-commentsA
  4.3/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 and does well: it discloses that the API returns comments for one record at a time, caps results at 10 per call, and requires offset for pagination. It also implies read-only behavior through 'Get' and 'returns'. It does not cover error handling, but the key operational behaviors are disclosed.

  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 with no filler, each carrying a distinct piece of information: the resource and scope, the multi-record usage pattern, and pagination limits. There is slight redundancy between 'single' and 'one record at a time,' but the overall structure is tight and front-loaded.

  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 100% schema coverage, an output schema, and no annotations, the description covers the non-obvious operational context an agent needs: the single-record limitation and pagination behavior. It does not mention ordering behavior or error cases, but these are minor given the schema and output schema. The tool is sufficiently complete for correct invocation.

  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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the relationship between limit and offset: up to 10 comments are returned per call and offset is used to paginate. This complements the schema's numeric bounds and makes parameter usage clearer.

  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 the verb 'Get' and identifies the exact resource: comments on a single kintone record. It clearly states the one-record-at-a-time constraint, which separates this tool from bulk record tools like kintone-get-records and from write tools like kintone-add-record-comment. The scope is unambiguous.

  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 gives clear operational context: this tool fetches comments for one record only, and for multiple records the agent must call the tool repeatedly. It does not explicitly name alternative sibling tools, but the use case is distinct enough that this is not a serious gap. No misleading usage guidance is present.

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

• kintone-add-recordsA
  4.4/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 disclosure burden and does meaningful work: it warns that certain field types cannot be registered (LOOKUP copies, STATUS, CATEGORY, CALC, ASSIGNEE, auto-calculated), which is exactly the kind of trap that causes failed invocations, and it signals batching behavior with 'multiple records'. It omits authorization requirements and partial-failure semantics, but the output schema covers return values.

  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?

  Three sentences with zero filler: the core action is front-loaded, the prerequisite workflow is second, and the exclusion warning closes. Every sentence earns its place and no information is repeated from the schema.

  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 highly complex tool (12+ field-type variants, nested records array), the combination of a 100%-covered schema, an output schema, and a description that flags non-registrable fields is nearly complete. The batch limit (max 100) and FILE-field unsupported status live in the schema. Minor gaps: no explicit guidance on choosing this over kintone-update-records and no authorization 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?

  Schema description coverage is 100%, so the schema already documents every field-type variant in detail (text, number, date/time, selects, user/org/group, subtable, lookup, created/updated time). The description adds complementary value the schema cannot express: the get-form-fields-first discovery workflow and the list of non-registrable field types, which are valid schema types that simply cannot be written.

  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 states a specific action — 'Add multiple records to a kintone app' — with a clear verb, resource, and batching scope. It naturally distinguishes from sibling record tools (kintone-get-records, kintone-update-records, kintone-delete-records) via the 'add' verb and 'multiple records' scope, going beyond the title 'Add Records'.

  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?

  It explicitly establishes a prerequisite workflow — 'Use kintone-get-form-fields tool first to discover available field codes and their required formats' — and enumerates field types that will fail registration (LOOKUP copies, STATUS, CATEGORY, CALC, ASSIGNEE, auto-calculated fields). It does not explicitly contrast with kintone-update-records or kintone-delete-records, but the creation context makes the intended usage clear.

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

• kintone-delete-form-fieldsA
  4.4/5.0
  Behavior4/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 of behavioral disclosure. It discloses preview-environment-only behavior, the 100-field limit, forbidden field types, and the requirement to deploy for live-app impact. This is strong for a destructive mutation tool, though it stops short of discussing irreversibility or exact error behavior.

  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?

  Four concise sentences, each delivering distinct value: action/scope, field-count limit, field-type restrictions, and the necessary companion operations. No filler or repetition; the most important information is front-loaded in the first sentence.

  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 fully described schema and presence of an output schema, the description covers the key operational caveats: preview-only, limits, restrictions, verification step, and deploy requirement. It may not enumerate all undeletable built-in field types, but it provides enough context for an agent to invoke the tool correctly.

  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 meaningful constraints beyond the schema: 'Maximum 100 fields can be deleted at once' and 'Cannot delete status, assignee, or category fields', which inform the fields parameter. This extra context justifies a 4.

  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 a specific verb and resource: 'Delete form fields from a kintone app'. It also adds scoping details (preview environment only) and restrictions (cannot delete status, assignee, or category fields), which clearly distinguishes it from sibling tools like kintone-add-form-fields and kintone-update-form-fields.

  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 gives actionable workflow guidance: use kintone-get-form-fields first to verify field codes, and use kintone-deploy-app to apply changes to the live app. It also mentions a specific use case ('recreating lookup fields when updates fail'). It does not explicitly contrast with add/update alternatives, but the guidance is clear enough for tool selection.

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

• kintone-add-form-fieldsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses the preview-only scope, permission requirements, field-code constraints, option key-label matching requirement, and deployment requirement. This is substantial behavioral context beyond the schema.

  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 a tight paragraph of about 80 words covering scope, permissions, constraints, option rules, lookup guidance, and workflow. It is not front-loaded with excessive introductory text; everything earns its place.

  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 extreme complexity (nested objects, many field-type variants), the description cannot fully document everything, but it covers the pitfalls that would cause errors: uniqueness, naming rules, option key-label matching, preview-only deployment, and the pre-check with kintone-get-form-fields. The output schema exists, so return values are covered there. Minor gaps: no mention of how many fields can be added at once or default behaviors (e.g., 'label' vs 'code'), but none are essential for a competent call.

  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, but the description adds critical meaning not obvious from schema: field code uniqueness and format rules, the exact-match requirement for selection options, and guidance on which field type to use for lookup fields. This meaningfully helps an agent construct correct property objects.

  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 states a specific verb ('Add'), resource ('new fields to a kintone app'), and a clear scope ('preview environment only'). It clearly distinguishes from sibling tools like kintone-get-form-fields and kintone-update-form-fields.

  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 instructs to use kintone-get-form-fields first to check existing fields, and states that changes require kintone-deploy-app to apply to the live app. This gives clear 'when to use' context and alternatives.

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

• kintone-update-form-fieldsA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It does this well by warning that unspecified selection-field options will be deleted, that option keys must exactly match current option names, and that lookup-field updates may not work correctly. It also clarifies that omitting code or label preserves current values, which is important non-obvious behavior.

  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 dense but every sentence earns its place. It front-loads the main action and environment, then covers permissions, partial-update semantics, destructive option behavior, caveats, and the required deployment follow-up without unnecessary repetition or filler.

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

  Completeness5/5

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

  For a high-complexity tool with a rich schema and an output schema, the description is complete: it covers permissions, environment, partial updates, destructive side effects, known lookup-field issues, and post-update deployment. Nothing critical appears missing for an agent to call this tool correctly.

  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 input schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantic value beyond the schema with practical rules: only 'type' is required per field, omitting 'code' or 'label' keeps existing values, and selection option keys must match current names exactly. These comments directly affect how an agent should construct the 'properties' object.

  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 starts with a specific verb and resource: 'Update form field settings in a kintone app'. It also adds the preview-environment constraint and specifies what can be updated, which makes the tool's purpose clear and distinguishes it from related tools like kintone-get-form-fields or kintone-add-form-fields.

  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?

  The description gives explicit guidance: use kintone-get-form-fields first to check current settings, require App Management permissions, and deploy with kintone-deploy-app to apply changes. It also provides an alternative workflow for lookup fields ('consider deleting and recreating the field instead') and lists field types whose codes cannot be updated, so an agent knows 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.