Kintone MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v8.1.0
Disambiguation3/5
Most tools are clearly distinct by resource and action, but there is some overlap in documentation tools (e.g., get_documentation_tool_description, get_field_creation_tool_description, get_field_type_documentation) and between create_choice_field, create_lookup_field, create_reference_table_field which all generate field settings, potentially causing confusion. The large number of tools also increases the risk of misselection.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern with snake_case throughout (e.g., create_app, get_form_fields, update_record). There are no deviations in naming conventions, making the set predictable and readable.
Tool Count2/5
With 79 tools, the count is excessive for an MCP server, making it overwhelming and difficult for agents to navigate. While Kintone is a comprehensive platform, this many tools suggests poor scoping and could be streamlined into fewer, more general-purpose tools.
Completeness5/5
The tool set provides extensive coverage of Kintone's domain, including app management (create, deploy, update), record operations (CRUD, search, comments), field and layout management, permissions, notifications, spaces, threads, and documentation. There are no obvious gaps, and it supports full lifecycle workflows.
Average 3.1/5 across 79 of 79 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on November 28, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 but offers none. It doesn't indicate whether this is a destructive mutation, what permissions are required, how conflicts are handled, what happens to existing members not included in the update, or what the response looks like. For a tool that modifies membership data, this lack of behavioral context is critical.
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 extremely concise—a single Japanese sentence—and front-loaded with the core action. There's no wasted verbiage, though this brevity comes at the cost of completeness. It's structured appropriately for its length but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (modifying space members with nested parameters), lack of annotations, no output schema, and low schema description coverage, the description is completely inadequate. It doesn't address behavioral risks, parameter meanings, usage context, or expected outcomes, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 50% (only 'space_id' has a description in Japanese, while 'members' and its nested properties lack descriptions). The tool description adds no parameter semantics beyond what's minimally in the schema—it doesn't explain what 'members' array should contain, how entity types differ, what 'isAdmin' or 'includeSubs' mean, or the expected format. With low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'スペースメンバーを更新します' (Updates space members) is a tautology that essentially restates the tool name 'update_space_members' in Japanese. It doesn't specify what aspect of space members is being updated (e.g., adding/removing members, changing permissions), nor does it distinguish this tool from sibling tools like 'update_space_guests' or 'get_space_members'. The purpose is vague beyond the basic verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus sibling tools like 'update_space_guests' or 'get_space_members', or any context for its application. The agent receives no usage direction beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't indicate whether this is a read-only or destructive operation, what permissions might be required, whether it creates something permanent or temporary, what happens on failure, or any behavioral characteristics. The single sentence provides no behavioral context beyond the basic action implied by 'creates'.
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 extremely concise - a single Japanese sentence. While this represents under-specification rather than true conciseness, from a structural perspective it's front-loaded with the core action. There's no wasted verbiage, though the extreme brevity creates significant information gaps.
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 complexity implied by nested objects in the schema, the lack of annotations, and no output schema, the description is severely incomplete. A tool that creates table layouts with complex row structures and options needs more context about what it actually produces, how it integrates with the system, and what behavioral characteristics it has. The current description leaves the agent guessing about critical aspects of tool behavior.
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?
With 100% schema description coverage, the schema already documents both parameters ('rows' and 'options') adequately. The description adds no additional semantic information about parameters - it doesn't explain what constitutes valid rows data, what options are available, or provide examples. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'テーブルレイアウトを作成します' (Creates a table layout) is a tautology that essentially restates the tool name 'create_table_layout' in Japanese. While it does specify the verb 'creates' and resource 'table layout', it doesn't distinguish this tool from its many siblings (like create_form_layout, create_group_layout, etc.) or provide any specific details about what kind of table layout is being created or in what context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools including other layout creation tools (create_form_layout, create_group_layout) and related tools (add_layout_element, update_form_layout), the agent receives no indication of the specific use case, prerequisites, or differentiation from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool 'gets' something, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or what the return format looks like. For a tool with zero annotation coverage, this minimal description leaves critical behavioral aspects undocumented.
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 a single Japanese sentence that's technically concise, but it's under-specified rather than efficiently informative. While it doesn't waste words, it also doesn't provide enough meaningful information. The structure is simple but lacks the front-loaded clarity needed for optimal agent understanding.
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 parameters (simplifying context) but also has no annotations and no output schema, the description is incomplete. It doesn't explain what 'documentation tool description' means, what format the information returns in, or how this differs from similar documentation-related sibling tools. For a tool that presumably returns structured information, more context about the output would be helpful.
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 schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain any parameters, and it doesn't contradict the empty schema. With no parameters to document, a baseline score of 4 is appropriate as there's nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ドキュメントツールの説明を取得します' (Gets documentation tool description) is a tautology that essentially restates the tool name 'get_documentation_tool_description' in Japanese. While it indicates the tool retrieves something about documentation tools, it doesn't specify what kind of documentation, what format it returns, or what 'tool description' entails. It fails to distinguish this from similar sibling tools like 'get_field_creation_tool_description' or 'get_query_language_documentation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like 'get_field_creation_tool_description' or 'get_query_language_documentation'. The agent receives zero usage instructions beyond the tautological purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '自動生成します' (automatically generates) implies a write/mutation operation, the description doesn't specify whether this requires specific permissions, what happens to existing layouts, whether the operation is reversible, or any rate limits or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral transparency.
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, efficient Japanese sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. However, it could be slightly more front-loaded by explicitly mentioning it's for kintone forms (implied by the schema but not stated in the description).
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?
For a mutation tool that creates form layouts with 3 parameters (including nested objects) and no annotations or output schema, the description is insufficient. It doesn't explain what a successful operation returns, what error conditions might occur, how the generated layout integrates with the existing app, or any dependencies on other tools. The description alone leaves significant gaps in understanding the tool's complete behavior and outcomes.
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 coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'フィールド情報' (field information) which corresponds to the 'fields' parameter, but provides no additional context about format, constraints, or relationships between parameters. This meets the baseline expectation when schema coverage is high.
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 'フィールド情報からフォームレイアウトを自動生成します' (Automatically generates form layout from field information) clearly states the tool's function with a specific verb ('自動生成します' - automatically generates) and resource ('フォームレイアウト' - form layout). However, it doesn't distinguish this tool from sibling tools like 'create_table_layout' or 'create_group_layout', which appear to be related layout creation tools. The purpose is understandable but lacks sibling differentiation.
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 use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other layout creation tools like 'create_table_layout' or 'create_group_layout', or any contextual constraints. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but only states the basic action. It doesn't mention whether this is a write operation (implied by 'create'), what permissions might be required, whether the creation is reversible, what happens on failure, or any rate limits. For a creation tool with zero annotation coverage, this represents significant gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one short sentence. While this represents efficient communication, it borders on under-specification rather than optimal conciseness. The single sentence is front-loaded with the core action but lacks supporting context that would be helpful for tool selection.
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?
For a creation tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'group element' is, what system it creates it in, what the expected outcome looks like, or how this differs from other layout tools. The agent would need to infer too much from the minimal 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?
The description provides no parameter information, but the schema has 100% description coverage with clear Japanese descriptions for all 5 parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting of documenting parameters, though the description adds no additional semantic context beyond what's already in the structured schema.
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 the tool 'creates a group element' which provides a basic verb+resource combination, but it's vague about what exactly a 'group element' is in this context. It doesn't distinguish this tool from similar sibling tools like 'create_form_layout' or 'create_table_layout', leaving ambiguity about what type of layout element is being created.
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 use this tool versus alternatives. With multiple layout-related sibling tools (create_form_layout, create_table_layout, add_layout_element), there's no indication of what distinguishes this group layout creation from other layout operations or when it would be the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions 'deploy' which implies a mutation operation, but doesn't disclose behavioral traits such as required permissions, whether it's destructive (e.g., overwrites existing settings), rate limits, or what happens post-deployment (e.g., app downtime, confirmation). This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence in Japanese that directly states the tool's action. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be slightly more informative without losing conciseness, such as by hinting at the deployment scope or outcome.
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 complexity of a deployment tool (likely involving mutations and system changes), the description is insufficient. With no annotations, no output schema, and minimal behavioral details, it fails to provide a complete picture. For example, it doesn't cover error handling, success indicators, or how it integrates with sibling tools like 'get_deploy_status'. This leaves the agent with inadequate context for safe and effective use.
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%, with the 'apps' parameter fully documented in the schema as an array of app IDs for deployment targets. The description doesn't add any meaning beyond this, such as explaining valid ID ranges or deployment order. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 the action ('deploy') and target ('kintone app settings'), which provides a basic purpose. However, it's vague about what 'deploy' entails (e.g., publishing changes, activating configurations) and doesn't differentiate from siblings like 'create_app' or 'update_app_settings', which could involve similar concepts. It avoids tautology but lacks specificity.
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 versus alternatives. For example, it doesn't clarify if this is for pushing development changes to production, activating settings after updates, or how it relates to siblings like 'get_deploy_status' or 'update_app_settings'. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool 'evaluates' access permissions but doesn't disclose behavioral traits such as whether it's a read-only operation, what the output format might be, if it requires specific permissions, or how errors are handled. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence in Japanese that conveys the core action. It's front-loaded with the main purpose and avoids unnecessary words. However, it could be more structured by explicitly stating the tool's output or context, but it's appropriately concise for its content.
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's complexity (evaluating permissions with conditions), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'evaluate' entails, what results to expect, or how conditions are applied. For a tool that likely returns detailed access control information, this leaves too much unspecified for effective use.
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 coverage is 100%, with clear descriptions for both parameters (app_id and record_ids). The description adds no additional meaning beyond the schema, as it doesn't explain how these parameters relate to the 'specified conditions' mentioned. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 the tool evaluates access permissions for records based on specified conditions, which provides a basic purpose. However, it doesn't specify what 'evaluate' means operationally (e.g., returns permission levels, checks access) or how it differs from sibling tools like 'get_record_acl' or 'get_app_acl'. The purpose is clear but lacks specificity and sibling differentiation.
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 versus alternatives. The description mentions 'specified conditions' but doesn't explain what those are or how they relate to parameters. With sibling tools like 'get_record_acl' and 'get_app_acl' available, there's no indication of when this evaluation tool is preferred, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. The description only states what the tool does ('retrieves user information') without any information about permissions needed, rate limits, pagination behavior, error conditions, or what format the returned data takes. For a data retrieval tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. However, the extreme brevity comes at the cost of completeness, as noted in other dimensions. The structure is front-loaded with the core purpose but lacks supporting details.
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 that this is a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what user information is returned, in what format, whether there are permission requirements, or how to handle the optional parameter effectively. The description provides only the most basic purpose statement without the context needed for effective tool use.
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, with the 'codes' parameter clearly documented as optional with its behavior explained. The description doesn't add any parameter information beyond what's already in the schema, but with complete schema coverage, a baseline score of 3 is appropriate. The description doesn't compensate for any gaps because there are none in the schema documentation.
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 the tool's purpose ('ユーザー情報を取得します' - 'retrieves user information') which is clear but generic. It specifies the resource (kintone users) but doesn't differentiate from sibling tools like 'get_groups' or 'get_group_users' that also retrieve user-related information. The description is accurate but lacks specificity about what makes this tool unique.
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 use this tool versus alternatives. There are multiple sibling tools that retrieve user-related data (get_groups, get_group_users, get_space_members), but the description doesn't help the agent understand when this specific user retrieval tool is appropriate versus those alternatives. No usage context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'update' but doesn't clarify if this is a destructive overwrite, additive operation, or requires specific permissions. No information on rate limits, error handling, or response format is included, making it inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence in Japanese with no wasted words, making it appropriately concise. However, it lacks front-loading of critical details (e.g., the nature of 'update'), which slightly reduces its effectiveness despite the brevity.
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's complexity (a mutation operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, error cases, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly in context.
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 50%, with 'space_id' and 'guests' documented in the schema but no additional details. The description doesn't add meaning beyond the schema—it doesn't explain parameter interactions, constraints (e.g., email format validation), or usage examples. With two parameters and partial schema coverage, the baseline is 3 as the schema does some work, but the description fails to compensate for gaps.
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 'スペースのゲストメンバーを更新します' (Updates guest members of a space) clearly states the action (update) and resource (space guest members), but it's vague about what 'update' entails—whether it adds, removes, replaces, or modifies guests. It distinguishes from some siblings like 'add_guests' by implying a different operation, but the distinction isn't explicit, leaving ambiguity in purpose.
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 use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing space access), exclusions, or comparisons to sibling tools like 'add_guests' or 'update_space_members', leaving the agent to infer usage context 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.
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 states this is a 'get' operation, implying read-only behavior, but doesn't provide any additional context about what exactly is returned, format considerations, or any limitations. The description doesn't contradict annotations (since there are none), but provides only basic behavioral information without details about the nature of the description being retrieved.
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, efficient sentence in Japanese that directly states the tool's function. It's appropriately sized for a simple tool with no parameters. While it could be more informative, it doesn't contain unnecessary verbiage or structural issues. The sentence earns its place by at least stating the basic operation.
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's simplicity (0 parameters, no annotations, no output schema), the description is incomplete. While it states what the tool does at a basic level, it doesn't explain what kind of description is returned, in what format, or how this differs from other documentation tools on the server. For a tool that presumably returns metadata/documentation, more context about the return value would be helpful since there's no output schema to provide that information.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of parameters. The description doesn't need to compensate for any parameter gaps. The baseline for 0 parameters with high schema coverage is 4, as the description appropriately doesn't waste space discussing non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'フィールド作成ツールの説明を取得します' (Gets the description of the field creation tool) is a tautology that essentially restates the tool name 'get_field_creation_tool_description' in Japanese. It specifies the verb '取得します' (gets) and resource 'フィールド作成ツールの説明' (field creation tool description), but doesn't provide meaningful differentiation from what the name already conveys. This is a minimal restatement rather than a clear purpose explanation.
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 use this tool versus alternatives. It doesn't mention any context, prerequisites, or relationships to sibling tools like 'get_field_type_documentation' or 'get_documentation_tool_description' that might serve similar documentation purposes. There's no indication of when this specific tool should be selected over other documentation-related tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description only states what the tool does ('get documentation') without revealing any behavioral traits such as whether it's a read-only operation, what permissions are required, whether it has rate limits, what format the documentation is returned in, or if there are any side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part of the sentence contributing to understanding the tool's function. There's no wasted language or structural issues.
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's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or output format, which are crucial for an agent to use it correctly. While the purpose is clear, the lack of context about how the tool behaves or what it returns makes it inadequate for confident use.
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, with the single parameter 'field_type' documented as 'ドキュメントを取得するフィールドタイプ' (field type to get documentation for). The description doesn't add any meaning beyond what the schema already provides—it doesn't explain what constitutes a valid field type, provide examples, or clarify the parameter's role. With high schema coverage, 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 'フィールドタイプに関するドキュメントを取得します' (Get documentation about field types) states a clear purpose with a verb ('取得します' - get) and resource ('フィールドタイプに関するドキュメント' - documentation about field types). However, it doesn't differentiate from sibling tools like 'get_documentation_tool_description' or 'get_query_language_documentation', which also retrieve documentation but for different resources. The purpose is clear but lacks sibling distinction.
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 use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from other documentation-retrieval tools like 'get_documentation_tool_description' or 'get_query_language_documentation'. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states '更新します' (updates), implying a mutation operation, but doesn't disclose any behavioral traits such as required permissions, whether changes are reversible, rate limits, or what happens to unspecified settings. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence in Japanese with no wasted words. It's appropriately sized and front-loaded, stating the core action immediately, making it easy to parse quickly.
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's complexity (a mutation operation with 5 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or response format, which are critical for safe and effective use. The high schema coverage helps, but overall context is insufficient.
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 coverage is 100%, with all parameters documented in the input schema (e.g., space_id, name, isPrivate). The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions, defaults, or constraints. With high schema coverage, 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 'スペースの設定を更新します' (Updates space settings) states the basic purpose with a verb and resource, but it's vague about which specific settings can be updated. It doesn't distinguish this tool from sibling tools like 'update_space_body', 'update_space_guests', or 'update_space_members', which also update space-related aspects.
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 use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing space_id), exclusions, or comparisons to sibling tools like 'update_space_body' or 'update_space_members', leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states 'updates' but doesn't clarify if this is a partial or full update, what permissions are required, whether changes are reversible, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese with zero waste. It's front-loaded with the core action, though brevity here reflects under-specification rather than optimal clarity. Structurally, it's concise but lacks depth.
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 this is a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address behavioral traits, error conditions, or return values, leaving significant gaps for an agent to understand how to use it effectively. The context signals indicate complexity (3 parameters), but the description doesn't compensate.
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%, with all parameters (thread_id, name, body) documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is provided.
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 'スレッドを更新します' (Updates a thread) states the basic action and resource but lacks specificity. It doesn't clarify what aspects of a thread can be updated or differentiate from sibling tools like 'update_record' or 'add_thread_comment'. The purpose is clear at a high level but vague about scope.
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 versus alternatives. With many sibling tools for updating various resources (e.g., 'update_record', 'update_space'), the description offers no context about prerequisites, typical use cases, or exclusions. It's a generic statement without practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'adds' implies a write operation, the description doesn't specify required permissions, whether guests are added to a specific context (space/app), what happens on duplicate entries, or what the response contains. This leaves significant behavioral gaps 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 a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately front-loaded with the core action, though this conciseness comes at the cost of missing important contextual information.
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?
For a mutation tool with no annotations, no output schema, and complex nested parameters (array of objects with 5 properties), the description is severely incomplete. It doesn't address permissions, response format, error conditions, or parameter semantics. The single-sentence description is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter (an array of guest objects with 5 sub-properties), the description provides no parameter information. It doesn't explain what 'guests' array contains, what the sub-properties represent, or provide examples of valid values. The description fails to compensate for the complete lack of schema documentation.
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 'ゲストユーザーを追加します' (Adds guest users) clearly states the verb ('adds') and resource ('guest users'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_space_guests' or 'get_users', which could handle similar user management functions.
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 use this tool versus alternatives. With sibling tools like 'update_space_guests' and 'get_users' available, there's no indication whether this tool is for initial guest creation versus modification, or whether it applies to specific contexts like spaces or apps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'adds' implies a mutation operation, the description doesn't address important behavioral aspects: what permissions are required, whether this affects existing data, what happens on failure, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient sentence in Japanese that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool that adds elements to form layouts with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after the addition, what types of elements are supported, whether there are constraints on element addition, or what the tool returns. The context signals show this is a complex operation with nested objects, requiring more comprehensive documentation.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain what types of elements can be added, provide examples of valid element objects, or clarify position parameter usage. The baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('adds an element') and the target resource ('to an existing form layout'), which provides a specific verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'add_fields', 'create_form_layout', or 'update_form_layout', which all relate to form layout manipulation.
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 use this tool versus alternatives. There are multiple sibling tools dealing with form layouts (create_form_layout, update_form_layout, get_form_layout), but the description doesn't indicate when this specific 'add' operation is appropriate versus creating a new layout or updating an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'adds a comment' implies a write/mutation operation, it doesn't specify permissions required, whether comments are editable/deletable, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence in Japanese that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral constraints. The 100% schema coverage helps with parameters, but overall context about the operation's behavior is lacking.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, which is acceptable given the comprehensive 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 the action ('adds a comment') and target resource ('kintone record') in Japanese, making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_thread_comment' or 'get_record_comments', which would require more specificity about what type of comment this adds.
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 use this tool versus alternatives. With siblings like 'add_thread_comment' and 'get_record_comments', there's no indication whether this is for record-level comments versus thread comments, or whether it's for creation versus retrieval operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation ('adds') but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error conditions, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence in Japanese with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, side effects) and doesn't explain return values or error handling, leaving significant gaps for an AI agent to use it 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%, so the schema already documents both parameters (space_id and name) with descriptions. The description doesn't add any meaning beyond this, such as format examples or constraints, but meets the baseline since the schema does the heavy lifting.
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 'スペースにスレッドを追加します' (Adds a thread to a space) clearly states the action (adds) and resource (thread to space), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_thread_comment' or 'update_thread', which would require more specificity for a perfect score.
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 use this tool versus alternatives. With many sibling tools (e.g., 'add_thread_comment', 'update_thread', 'create_record'), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('adds a comment') but doesn't cover critical aspects like required permissions, whether this is a write operation (implied but not explicit), rate limits, error conditions, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
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, clear sentence in Japanese with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), response format, and usage context, leaving significant gaps that could hinder an agent's ability to invoke it 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 75% (three of four parameters have descriptions in Japanese), so the schema does most of the work. The description doesn't add any parameter-specific context beyond what's in the schema (e.g., format of 'mentions' array or how 'text' is processed), resulting in a baseline score appropriate 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 'スレッドにコメントを追加します' (Adds a comment to a thread) clearly states the verb ('adds') and resource ('comment to a thread'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_record_comment' or 'add_thread', which would require specifying the target context more distinctly.
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 use this tool versus alternatives. There's no mention of prerequisites (e.g., needing space/thread IDs), exclusions, or comparisons to similar tools like 'add_record_comment', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'creates' a new app, implying a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on failure, or the response format. This leaves significant gaps 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 a single, clear sentence in Japanese with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or return values, which are critical for an agent to use it correctly. The 100% schema coverage helps with parameters but doesn't compensate for the lack of operational context.
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 parameters (name, space, thread). The description adds no additional meaning beyond what's in the schema, such as explaining the relationship between space and thread or typical values. Baseline 3 is appropriate when schema does the heavy lifting.
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 '新しいkintoneアプリを作成します' (creates a new kintone app) clearly states the verb ('creates') and resource ('kintone app'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'deploy_app' or 'update_app_settings', but it's unambiguous about its core function.
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 use this tool versus alternatives like 'deploy_app' or 'update_app_settings', nor does it mention prerequisites or context for app creation. It's a standalone statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'generates settings' but doesn't clarify whether this creates a new field in a system, returns configuration data, or has side effects. It doesn't mention permissions required, rate limits, or what happens after generation. The example shows input format but not behavioral consequences.
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 appropriately sized with two sentences and an example. The first sentence states the purpose clearly, and the second provides character constraints. The example is helpful but could be more concise. No wasted words, though the example takes significant space.
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 6 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and provides an example, but doesn't address behavioral aspects, usage context, or what the tool actually does with the generated settings. Given the complexity and lack of annotations/output schema, more context would be helpful.
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 parameters thoroughly. The description adds minimal value beyond the schema: it provides an example showing how parameters fit together and mentions allowed characters for the 'code' field. However, it doesn't explain parameter interactions or edge cases beyond what the schema provides.
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: '選択肢フィールド（ラジオボタン、チェックボックス、ドロップダウン、複数選択）の設定を生成します' (generates settings for choice fields). This specifies the verb ('生成します' - generates) and resource ('選択肢フィールドの設定' - choice field settings). However, it doesn't explicitly differentiate from sibling tools like 'create_lookup_field' or 'create_reference_table_field', which appear to create other field types in the same system.
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 use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might be needed, or how it relates to sibling tools like 'create_lookup_field' or 'update_field'. The example shows usage but doesn't provide contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '生成します' (generates) implies a creation/write operation, the description doesn't disclose important behavioral traits: whether this requires specific permissions, what happens on conflict (e.g., duplicate field codes), whether the creation is reversible, or any rate limits. The example shows a JSON structure but doesn't explain behavioral aspects beyond the basic operation.
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 concise with two sentences and an example, but it's not optimally structured. The first sentence states the purpose, while the second provides character constraints. The example JSON is helpful but takes significant space. The description could be more front-loaded with clearer usage context before diving into implementation details.
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 10-parameter creation tool with no annotations and no output schema, the description is moderately complete. It covers the basic operation and provides an example, but lacks important context: no output information, no error handling details, no permission requirements, and no differentiation from similar tools. The 100% schema coverage helps, but the description itself doesn't provide enough standalone guidance for this complex 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 all 10 parameters thoroughly. The description adds minimal value beyond the schema: it provides allowed characters for field codes and shows a JSON example that illustrates some parameter usage. However, it doesn't add significant semantic meaning beyond what's already in the comprehensive schema descriptions.
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: 'ルックアップフィールドの設定を生成します' (generates lookup field settings). It specifies the verb ('生成します' - generates) and resource ('ルックアップフィールドの設定' - lookup field settings). However, it doesn't explicitly differentiate from sibling tools like 'create_choice_field' or 'create_reference_table_field', which appear to be related field creation tools.
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 use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites exist, or how it differs from other field creation tools like 'create_choice_field' or 'create_reference_table_field' in the sibling list. The example shows usage but doesn't provide contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the batch limit (100 records) but doesn't cover critical aspects like error handling (e.g., partial failures), permissions required, rate limits, or what happens if the app_id is invalid. For a write operation with no annotation coverage, this leaves significant gaps.
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, efficient sentence in Japanese that conveys the core purpose and key constraint (max 100 records) without any wasted words. It's front-loaded and appropriately sized for the tool's complexity.
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?
For a write operation with no annotations and no output schema, the description is incomplete. It lacks information on error conditions, response format, authentication requirements, and how it differs from similar tools (e.g., create_record, upsert_records). Given the complexity of bulk creation and the absence of structured metadata, more context is needed.
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 fully documents both parameters (app_id and records). The description adds no additional parameter semantics beyond what's in the schema, such as format examples for records or constraints on app_id values. Baseline 3 is appropriate when the schema does all the work.
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 action ('creates multiple records in bulk') and the resource ('kintone app'), which is specific and informative. However, it doesn't explicitly differentiate from sibling tools like 'create_record' (singular) or 'upsert_records', leaving some ambiguity about when to choose this over alternatives.
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 use this tool versus alternatives like 'create_record' (for single records) or 'upsert_records' (for create-or-update operations). It mentions the maximum batch size (100 records) but doesn't explain trade-offs or prerequisites for bulk creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description states it 'generates' settings, implying a creation/write operation, but doesn't clarify permissions needed, whether this is a preview or actual deployment, side effects, or response format. The example shows a JSON structure but doesn't explain what happens after generation.
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 reasonably concise with two sentences and an example. The first sentence states the purpose, the second provides character set guidance, and the example illustrates usage. However, the example only shows 5 of 11 parameters, which could be misleading about required vs optional parameters.
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?
For a tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'generates settings' means operationally, doesn't clarify the tool's place in a workflow (e.g., whether this creates a field immediately or just generates configuration), and provides minimal guidance despite the complexity. The example helps but doesn't compensate for missing behavioral context.
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 11 parameters thoroughly. The description adds minimal value beyond the schema: it provides character set guidance for 'code' field and shows a partial example with 5 parameters. However, it doesn't explain relationships between parameters (like relatedAppId vs relatedAppCode priority) or provide context beyond what's in the schema descriptions.
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: '関連テーブルフィールドの設定を生成します' (generates related table field settings). It specifies the verb ('生成します' - generates) and resource ('関連テーブルフィールドの設定' - related table field settings). However, it doesn't explicitly differentiate from sibling tools like 'create_lookup_field' or 'create_choice_field', which appear to be similar field creation tools.
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 use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or comparison with sibling tools like 'create_lookup_field' or 'create_choice_field'. The example shows parameter usage but doesn't explain the tool's context within the broader system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it retrieves a list but doesn't disclose behavioral traits like whether it's read-only (implied by 'get'), authentication requirements, rate limits, pagination, error conditions, or what format the list returns. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 annotations and no output schema, the description is incomplete. It doesn't explain what the returned list contains (e.g., plugin names, IDs, versions), how results are structured, or any behavioral context needed for effective use. For a retrieval tool with these gaps, more detail would be helpful.
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 description doesn't mention any parameters. However, the input schema has 100% description coverage with a clear parameter 'app_id' documented as 'kintoneアプリのID'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description adds no value beyond what's in the schema.
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 action ('取得します' - retrieves/get) and resource ('kintoneアプリに追加されているプラグインの一覧' - list of plugins added to kintone app). It's specific about what it retrieves, though it doesn't explicitly differentiate from sibling tools like 'update_plugins' or 'get_app_customize' which might relate to similar app components.
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 use this tool versus alternatives. There's no mention of prerequisites, related tools like 'update_plugins' for modifying plugins, or context about when plugin information is needed versus other app metadata tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does ('確認します') without describing whether this is a read-only operation, what permissions are required, whether it affects system state, rate limits, or what the output format might be. For a status-checking tool with zero annotation coverage, this is insufficient.
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, efficient Japanese sentence that states the core purpose without any wasted words. It's appropriately sized for a simple tool and gets straight to the point with no unnecessary elaboration.
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 that this is a read operation (implied by 'get' name) with no annotations and no output schema, the description should provide more context about what 'deploy status' means, what values might be returned, and whether this checks production or preview environments. The current description is too minimal for the agent to understand the full context of use.
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, with the 'apps' parameter clearly documented as '確認対象のアプリID配列' (array of app IDs to check). The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline score when schema coverage is high.
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: '確認します' (check/confirm) for 'kintoneアプリのデプロイ状態' (kintone app deployment status). It uses a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'deploy_app' or other status-checking tools, which prevents a perfect score.
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 use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or differentiate from similar tools like 'get_apps_info' or 'get_preview_app_settings' that might provide related information. The agent must infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('取得します'), which implies read-only behavior, but doesn't explicitly confirm it's non-destructive. No information about authentication requirements, rate limits, error conditions, or response format is provided. The description doesn't mention that this tool requires an app_id parameter or that preview mode is optional.
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, efficient Japanese sentence that directly states the tool's purpose. There's no unnecessary verbiage or repetition. However, it could be more front-loaded with key distinguishing information (e.g., 'field-level' permissions specifically).
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the ACL information is returned in, what permissions are included, or how to interpret the results. The description doesn't mention that this is a read-only operation (though implied) or any behavioral constraints. Given the complexity of ACL systems and lack of structured documentation, more context is needed.
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 fully documents both parameters (app_id and preview). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain the relationship between parameters or provide usage examples. Since schema coverage is complete, baseline 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 clearly states the action ('取得します' - get/retrieve) and target resource ('kintoneアプリのフィールドのアクセス権限' - Kintone app field access permissions). It specifies what is being retrieved (field ACLs) rather than just restating the tool name. However, it doesn't explicitly differentiate from sibling tools like 'get_app_acl' or 'get_record_acl' which retrieve different types of permissions.
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 use this tool versus alternatives. There are multiple ACL-related tools in the sibling list (get_app_acl, get_record_acl, evaluate_records_acl), but the description doesn't explain that this tool specifically retrieves field-level permissions rather than app-level or record-level permissions. No context about prerequisites or when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does ('get form layout') without disclosing behavioral traits like authentication requirements, rate limits, error conditions, or what format the layout information is returned in. For a read operation with zero annotation coverage, this is insufficient.
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, efficient sentence in Japanese that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple retrieval tool with one parameter.
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?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'form layout' means in practical terms, what data structure is returned, or any behavioral aspects. While the parameter is well-documented in the schema, the overall context for using this tool is insufficient.
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% with the single parameter 'app_id' well-documented in the schema as 'kintoneアプリのID'. The description doesn't add any additional parameter context beyond what's in the schema, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
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 action ('取得します' - get/retrieve) and the resource ('kintoneアプリのフォームレイアウト' - kintone app form layout). It's specific about what is being retrieved, though it doesn't explicitly differentiate from sibling tools like 'get_preview_form_layout' which appears to serve a similar purpose for preview versions.
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 use this tool versus alternatives. There's no mention of prerequisites, context for usage, or comparison with sibling tools like 'get_preview_form_layout' or 'get_form_fields' that might retrieve related information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action ('retrieves') without detailing behavioral traits such as whether it's read-only (implied but not explicit), pagination behavior, rate limits, authentication requirements, or error handling. For a tool with no annotation coverage, this is a significant gap in transparency.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more structured (e.g., by front-loading key details like scope). There's no wasted verbiage, earning a high score for conciseness.
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's simplicity (one optional parameter, no output schema, no annotations), the description is incomplete. It lacks context about the return format (e.g., what group information is included), error cases, or how it fits into the broader kintone ecosystem with many sibling tools. For a retrieval tool in a complex server, more completeness is needed to guide effective use.
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, with the 'codes' parameter fully documented in the schema itself ('取得するグループコードの配列（指定しない場合はすべてのグループを取得）'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
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: 'kintoneのグループ情報を取得します' (retrieves kintone group information). It specifies the verb '取得します' (retrieves/get) and resource 'グループ情報' (group information). However, it doesn't explicitly differentiate from sibling tools like 'get_group_users' or 'get_users', which also retrieve user/group-related data, leaving some ambiguity about scope.
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 use this tool versus alternatives. It doesn't mention sibling tools like 'get_group_users' (which retrieves users within groups) or 'get_users' (which retrieves user information), nor does it specify prerequisites, exclusions, or contextual triggers for usage. This lack of comparative context leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '取得します' (retrieves) implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what format the notification settings are returned in. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for what it communicates and is front-loaded with the core functionality.
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'notification condition settings' include, what format they're returned in, whether there are authentication requirements, or how this differs from other notification-related tools. The agent would have significant gaps in understanding how to properly use this 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?
The schema has 100% description coverage, so both parameters (app_id and preview) are already documented in the schema. The description doesn't add any additional parameter context beyond what the schema provides, such as explaining what 'notification condition settings' specifically include or how the preview parameter affects the retrieval.
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 action ('取得します' - retrieves/get) and resource ('kintoneアプリの通知条件設定' - Kintone app notification condition settings). It's specific about what is being retrieved, though it doesn't explicitly differentiate from sibling tools like 'get_per_record_notifications' or 'get_reminder_notifications' which also retrieve notification-related data.
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 use this tool versus alternatives. There are several sibling tools that retrieve notification-related data (get_per_record_notifications, get_reminder_notifications), but the description doesn't help an agent understand when this specific notification settings retrieval is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '取得します' (retrieves) implies a read operation, there's no information about authentication requirements, rate limits, error conditions, or what specific 'app settings' are returned. The description doesn't mention whether this affects the preview environment or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and gets straight to the point.
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'app settings' actually includes, what format the response takes, or any behavioral constraints. Given the complexity of kintone app configuration and the lack of structured metadata, more context is needed.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly ('app_id' and optional 'lang' with enum values). The description doesn't add any additional parameter context beyond what's in the schema, so it meets the baseline 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 clearly states the action ('取得します' - retrieves/get) and the resource ('プレビュー環境のkintoneアプリ設定' - preview environment kintone app settings), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_app_settings' or 'get_preview_form_fields', which would be needed for a perfect score.
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 use this tool versus alternatives. With many sibling tools in the kintone ecosystem (like 'get_app_settings', 'get_preview_form_fields', 'get_preview_form_layout'), there's no indication of what distinguishes this tool from those similar-sounding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states it retrieves information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what the output format might be. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding the tool's function.
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 complexity of retrieving form field information in a preview environment, no annotations, and no output schema, the description is incomplete. It lacks details on what information is returned, how it differs from production data, or any behavioral context. This makes it inadequate for an agent to fully understand the tool's operation.
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, with clear documentation for both parameters (app_id and lang). The description doesn't add any parameter semantics beyond what the schema provides, such as explaining the purpose of 'preview' in relation to app_id or lang options. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('取得します' - retrieves) and the resource ('プレビュー環境のkintoneアプリのフォームフィールド情報' - preview environment kintone app form field information). It distinguishes from the sibling 'get_form_fields' by specifying 'preview environment', making the scope clear. However, it doesn't explicitly contrast with all sibling tools, which prevents a perfect score.
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 use this tool versus alternatives like 'get_form_fields' (for production) or other field-related tools. It doesn't mention prerequisites, such as needing a preview environment setup, or exclusions. The only contextual clue is 'preview environment', but no explicit usage instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '取得します' (get/retrieve) implies a read operation, the description doesn't disclose important behavioral aspects: whether this requires specific permissions, if it returns structured layout data or raw configuration, potential rate limits, or what happens if the app doesn't exist. For a read operation with zero annotation coverage, this is insufficient disclosure.
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, efficient Japanese sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool. However, it could be slightly more front-loaded by specifying it's for 'retrieving' rather than just 'getting' to be more precise.
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 single-parameter read operation with no output schema, the description provides the basic purpose but lacks important context. It doesn't explain what 'form layout information' includes, the format of the returned data, or how this differs from the production version. With no annotations and no output schema, the description should provide more behavioral and output context to be 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%, so the schema already documents the single 'app_id' parameter completely. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage and only one parameter, the baseline score of 3 is appropriate - the description doesn't compensate but doesn't need to given the comprehensive schema documentation.
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 action ('取得します' - get/retrieve) and the resource ('プレビュー環境のkintoneアプリのフォームレイアウト情報' - preview environment kintone app form layout information). It specifies the 'preview environment' context, which distinguishes it from the sibling tool 'get_form_layout' that presumably retrieves production layout. However, it doesn't explicitly mention this distinction in the description text itself.
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 use this tool versus alternatives. It doesn't mention the sibling 'get_form_layout' tool or explain when preview vs production layout retrieval is appropriate. There are no prerequisites, exclusions, or contextual usage instructions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states this is a read operation ('取得します'), but does not cover other behavioral aspects such as authentication requirements, error handling, rate limits, or what the output looks like (e.g., format, structure). For a tool with no annotations, this leaves significant gaps in understanding its 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 a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand quickly. There is no wasted language or redundancy.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves access control information. It does not explain what the output includes (e.g., permissions list, user/group details) or behavioral context like error cases (e.g., invalid IDs). For a tool with no structured output documentation, the description should provide more context about the return values and usage scenarios.
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, with clear documentation for both parameters (app_id and record_id). The description does not add any additional meaning beyond what the schema provides, such as explaining parameter relationships or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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: '指定したレコードのアクセス権限を取得します' (Get the access permissions for a specified record). It specifies the verb '取得します' (get) and the resource 'アクセス権限' (access permissions) with the scope '指定したレコード' (specified record). However, it does not explicitly differentiate from sibling tools like 'get_app_acl' or 'get_field_acl', which handle permissions for different resources.
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 use this tool versus alternatives. It does not mention sibling tools like 'get_app_acl' (for app-level permissions) or 'get_field_acl' (for field-level permissions), nor does it specify prerequisites, such as requiring a valid app_id and record_id. Usage is implied by the description but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action without mentioning any behavioral traits like whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what the output format looks like. For a tool with no annotations, this is insufficient to inform the agent adequately.
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, clear sentence in Japanese: 'スペースメンバーのリストを取得します'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by directly stating the action.
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 complexity of a tool that retrieves member data, the description is incomplete. There are no annotations, no output schema, and the description lacks details on behavioral aspects like permissions, return format, or error handling. While the purpose is clear, the overall context is insufficient for an agent to use the tool effectively without additional assumptions.
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, with the single parameter 'space_id' documented as 'スペースID' (space ID). The description doesn't add any additional meaning beyond this, such as explaining the format of the space ID or providing examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation 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: 'スペースメンバーのリストを取得します' (Get a list of space members). It specifies the verb '取得します' (get) and the resource 'スペースメンバーのリスト' (list of space members), making the action explicit. However, it doesn't distinguish this tool from sibling tools like 'get_users' or 'get_group_users', which might have overlapping functionality, so it doesn't reach a score of 5.
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 use this tool versus alternatives. There are sibling tools such as 'get_users' and 'get_group_users' that might retrieve user-related data, but the description doesn't clarify if this tool is for space-specific members, how it differs, or any prerequisites. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It states the action is a move but doesn't disclose whether this requires specific permissions, if it's reversible, what happens to app data/configuration during the move, or any rate limits. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence in Japanese that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple 2-parameter tool and front-loads the core action.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'moving' entails operationally, what permissions are required, what the response contains, or potential side effects. For a tool that modifies system state, this leaves significant gaps in understanding.
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 parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying 'app_id' identifies the app to move and 'space_id' is the destination. This meets the baseline of 3 when the schema does the heavy lifting.
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 action ('移動します' - moves) and the resource ('kintoneアプリ' - kintone app) with a specific destination ('指定したスペースに' - to a specified space). It distinguishes from sibling 'move_app_from_space' by indicating direction (to vs from). However, it doesn't explicitly mention what 'moving' entails operationally beyond the basic verb.
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 versus alternatives. The description doesn't mention prerequisites (e.g., needing admin permissions), what happens to the app's current location, or how this differs from other app management tools like 'create_app' or 'update_app_settings'. The agent must infer usage 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.
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. While '更新します' (updates) implies a mutation operation, the description doesn't disclose any behavioral traits like required permissions, whether this is a destructive operation, rate limits, or what happens when ACLs are modified. For a permission-modifying 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that states exactly what the tool does without any wasted words. It's appropriately sized and front-loaded with the core functionality.
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?
For a permission-modifying tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what permissions are required to use it, whether changes are reversible, or how ACL updates affect existing users. Given the complexity of ACL management and the complete lack of structured behavioral information, the description should provide more context.
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 coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('更新します' - updates) and resource ('kintoneアプリのアクセス権限' - kintone app access permissions), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'update_field_acl' or 'update_record_acl', but the focus on app-level permissions is clear from the description itself.
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 use this tool versus alternatives. There are multiple ACL-related tools in the sibling list (get_app_acl, evaluate_records_acl, get_field_acl, update_field_acl, get_record_acl), but the description doesn't help the agent understand when app-level ACL updates are appropriate versus field or record-level updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('更新します' - updates) and gives a parameter example. It doesn't cover critical behaviors: whether this is a destructive mutation (likely yes, but unstated), permission requirements, error handling, or what happens on success/failure. For a mutation 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 description is appropriately concise: one sentence stating the purpose followed by an illustrative example. It's front-loaded with the core function. The example is somewhat lengthy but serves to clarify the complex 'actions' parameter structure. No wasted words, though it could be slightly more structured.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'updates' entails behaviorally (e.g., overwrites existing actions?), what the return value is (success confirmation? error details?), or any side effects. The example helps with parameter format but doesn't compensate for the lack of behavioral and output context.
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 fully documents all parameters. The description adds minimal value: it mentions the 'filterCond' property for setting execution conditions and provides an example JSON structure. This doesn't add meaningful semantics beyond what's in the schema descriptions, but meets the baseline since the schema does the heavy lifting.
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: 'kintoneアプリのアクション設定を更新します' (updates action settings for a Kintone app). It specifies the verb ('更新します' - updates) and resource ('アクション設定' - action settings), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_app_settings' or 'update_app_customize', which reduces it from a perfect score.
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 use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing app admin permissions), compare it to similar tools like 'get_app_actions' or 'update_app_settings', or specify scenarios where it's appropriate. The example is purely illustrative of parameter structure, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'updates' without disclosing behavioral traits. It doesn't mention whether this is a destructive operation, what permissions are required, whether changes are reversible, rate limits, or what happens to existing settings not mentioned. For a mutation tool with complex nested parameters, this is inadequate.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized for what it communicates, though it could benefit from additional context.
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?
For a complex mutation tool with 5 parameters (including nested objects), no annotations, no output schema, and only 60% schema description coverage, the description is insufficient. It doesn't explain what the tool returns, error conditions, or how to interpret the scope parameter's enum values in practical terms. The agent would struggle to use this tool effectively.
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 60%, so the description should compensate but doesn't add any parameter information beyond what's in the schema. The description mentions 'JavaScript/CSS customization settings' which aligns with the 'desktop' and 'mobile' parameters in the schema, but provides no additional context about parameter relationships, constraints, or usage patterns.
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 ('update') and resource ('JavaScript/CSS customization settings for kintone app') in Japanese. It's specific about what gets updated but doesn't differentiate from sibling tools like 'update_app_settings' or 'update_app_acl' that also modify app configurations.
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 on when to use this tool versus alternatives like 'get_app_customize' (for reading) or other update_* tools for different app aspects. The description implies it's for modifying customization settings but provides no context about prerequisites, permissions needed, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '変更します' (changes/updates) implies a mutation operation, it doesn't describe permissions required, whether changes are reversible, rate limits, or what happens when only some parameters are provided. For a complex mutation tool with 13 parameters, this is inadequate.
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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded with the essential information.
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?
For a complex mutation tool with 13 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, side effects, or response format. The agent would struggle to use this tool correctly without additional context about what 'general settings' encompasses and how changes affect the app.
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 coverage is 77%, which is relatively high, so the baseline is 3. The description adds no specific parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify which settings are most commonly changed.
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 'kintoneアプリの一般設定を変更します' clearly states the action (変更/update) and target (kintoneアプリの一般設定/kintone app general settings). It's specific about what gets updated, though it doesn't explicitly differentiate from sibling tools like update_app_acl or update_app_customize.
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 use this tool versus alternatives. There are many update_* sibling tools (update_app_acl, update_app_customize, update_field, etc.), but the description doesn't help the agent choose between them or indicate prerequisites like needing an existing app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't mention that this is a destructive/mutative operation, potential side effects (e.g., affecting existing permissions), error conditions, or authentication requirements. This leaves critical gaps for safe tool invocation.
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, efficient sentence in Japanese that directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., permissions needed, idempotency), error handling, and what the tool returns. Given the complexity of ACL updates, more context is needed for safe and effective use.
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 parameters are well-documented in the schema itself. The description adds no additional parameter context beyond implying 'field' relates to the 'code' parameter, but this is already covered. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 action ('update') and target ('field access permissions for a Kintone app'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'update_app_acl' or 'update_record_acl', but the focus on 'field' is specific enough for basic identification.
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 versus alternatives like 'update_app_acl' or 'get_field_acl'. The description lacks context about prerequisites, such as needing admin permissions or when field-level ACLs are appropriate compared to app-level controls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '更新します' (updates) implies a mutation operation, the description doesn't disclose any behavioral traits - no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to existing settings. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient Japanese sentence that gets straight to the point. There's no wasted verbiage or unnecessary elaboration. It could potentially be more front-loaded with critical information, but it's appropriately concise for what it does convey.
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?
For a mutation tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, prerequisites, or how it differs from similar notification update tools. The description should provide more context about the operation's scope and behavior.
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 thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('更新します' - updates) and the resource ('kintoneアプリのレコード単位の通知設定' - per-record notification settings for Kintone apps). It's specific about what gets updated, though it doesn't explicitly differentiate from sibling tools like 'update_notifications' or 'update_reminder_notifications'.
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 use this tool versus alternatives. With sibling tools like 'update_notifications' and 'update_reminder_notifications' available, there's no indication of what distinguishes this per-record notification update from other notification-related updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'update' implies a mutation operation, the description doesn't mention permission requirements, whether changes are reversible, potential side effects, or error conditions. It provides minimal behavioral context beyond the basic action.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary elaboration. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens during plugin updates, whether there are validation requirements, what the response looks like, or potential impacts on app functionality. Given the complexity of plugin configuration and the lack of structured metadata, more descriptive context is needed.
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 description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). The schema already documents app_id, plugins, and revision parameters thoroughly. The description doesn't provide additional context about parameter relationships, constraints, or usage patterns.
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 action ('update') and target ('plugin settings for kintone apps'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling update tools like update_app_settings or update_app_customize, which also modify app configurations.
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 use this tool versus alternatives. There are multiple sibling tools that update various aspects of kintone apps (update_app_settings, update_app_customize, update_field, etc.), but the description offers no context about when plugin updates are appropriate versus other configuration changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '更新します' (updates) implies a mutation operation, the description doesn't mention permission requirements, whether changes are reversible, potential side effects, or what happens when the operation fails. For a complex mutation tool with 5 parameters, this is inadequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information about what the tool does.
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?
For a complex mutation tool with 5 parameters, nested objects, and no output schema, the description is insufficient. It doesn't explain what 'process management settings' entail, what the expected behavior is, or what constitutes success/failure. Without annotations and with no output schema, the description should provide more context about the operation's scope and outcomes.
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 coverage is 100%, meaning all parameters are documented in the input schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 action ('更新します' - updates) and the target ('kintoneアプリのプロセス管理設定' - kintone app process management settings), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'update_app_settings' or 'update_record_status', which also perform updates on different aspects of kintone apps.
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 use this tool versus alternatives. There are multiple update-related sibling tools (update_app_settings, update_record_status, update_app_actions, etc.), but the description doesn't indicate that this tool specifically handles process management settings rather than other app configurations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It indicates this is a mutation operation ('更新します') but doesn't disclose permission requirements, whether changes are reversible, rate limits, or what happens to existing assignees not in the new array. For a write operation with zero annotation coverage, this is insufficient.
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, efficient Japanese sentence with zero wasted words. It's appropriately sized for a straightforward update operation and front-loads the core purpose immediately.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important behavioral aspects like whether the assignees array replaces or merges with existing assignees. The process management context hint is useful but insufficient for full understanding.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. The baseline score of 3 reflects adequate coverage through the schema alone.
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 action ('更新します' - updates) and target resource ('kintoneレコードの作業者' - kintone record assignees) with specific context ('プロセス管理' - process management). It distinguishes from generic update_record by focusing on assignees, but doesn't explicitly differentiate from sibling tools like update_record_status that also modify records.
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 about when to use this tool versus alternatives like update_record or update_record_status. The description mentions process management context but doesn't specify prerequisites, constraints, or when this specific assignee update is appropriate versus other record modification methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation for record status in process management, implying mutation, but doesn't disclose important behavioral aspects like required permissions, whether changes are reversible, what happens to other record fields, or any rate limits. The description adds minimal value beyond the basic operation.
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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for what it communicates, though it could potentially benefit from slightly more detail given the lack of annotations and output schema.
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?
For a mutation tool with no annotations, no output schema, and multiple similar sibling tools, the description is insufficiently complete. It doesn't explain what the tool returns, what happens on success/failure, how it differs from other update tools, or any prerequisites for using process management features. The description leaves significant gaps for an AI agent to understand this tool's full context.
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 four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain the relationship between parameters, provide examples of valid 'action' values, or clarify when 'assignee' is required. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('update') and resource ('kintone record status') with the context of process management. It distinguishes itself from generic 'update_record' by focusing specifically on status updates, but doesn't explicitly differentiate from sibling tools like 'update_process_management' or 'update_record_assignees' which might have overlapping functionality.
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 use this tool versus alternatives. There are multiple sibling tools that handle record updates (update_record, update_record_assignees, upsert_record) and process management (update_process_management), but the description offers no comparison or context for choosing this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention required permissions, whether it's destructive, what happens to existing settings not included in the update, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format. While the schema covers parameters well, the overall context for safe and effective use is lacking.
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 3 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 action ('更新します' - updates) and the resource ('kintoneアプリのリマインダー通知設定' - kintone app reminder notification settings). It's specific about what gets updated but doesn't differentiate from sibling tools like 'update_notifications' or 'update_per_record_notifications' which handle different notification types.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, when this tool is appropriate, or what distinguishes it from similar tools like 'update_notifications' or 'update_per_record_notifications' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '更新します' (updates) implies a mutation operation, the description doesn't address important behavioral aspects like required permissions, whether the operation is idempotent, what happens to existing reports not mentioned in the update, error conditions, or response format. This leaves significant gaps 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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words or structural complexity. It's appropriately sized for what it communicates.
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?
For a mutation tool with complex nested parameters (3 parameters with deep nesting) and no annotations or output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error handling, or response format that would help an agent understand how to use this tool effectively in context.
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 has 100% description coverage, so all parameters are well-documented in the structured schema. The description doesn't add any additional parameter semantics beyond what's already in the schema, which meets the baseline expectation when schema coverage is complete.
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 ('更新します' - updates) and resource ('kintoneアプリのグラフ設定' - Kintone app graph settings), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'update_views' or 'update_app_settings' that also modify Kintone app configurations, which prevents a perfect score.
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 use this tool versus alternatives. With sibling tools like 'update_views' and 'update_app_settings' that modify different aspects of Kintone apps, there's no indication of what makes this tool distinct or when it should be chosen over other update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'updates' (implying a mutation), but doesn't mention permissions required, whether changes are reversible, rate limits, or what happens to existing content. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence in Japanese that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly, though it could benefit from more detail given the lack of annotations.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the update entails (e.g., overwriting vs. appending), potential side effects, error conditions, or return values. Given the complexity of updating content and the lack of structured data, more context is needed for safe and effective use.
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 coverage is 100%, with both parameters ('space_id' and 'body') clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema already provides, such as format constraints or examples. Given the high schema coverage, a baseline score 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 'スペースの本文を更新します' (Updates the body of a space) clearly states the verb ('updates') and resource ('space body'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'update_space', which might also handle space updates, so it doesn't reach the highest score.
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 use this tool versus alternatives like 'update_space' or other space-related tools in the sibling list. It lacks explicit instructions on prerequisites, exclusions, or recommended contexts, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'update' implies mutation, it doesn't disclose behavioral aspects like required permissions, whether changes are reversible, rate limits, or what happens to existing view configurations not mentioned. For a mutation tool with zero annotation coverage, this is insufficient.
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?
Single sentence in Japanese that efficiently conveys the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool that modifies app views with complex nested parameters and no annotations or output schema, the description is inadequate. It doesn't explain what happens after the update, potential side effects, or error conditions. The agent would need to guess about the tool's behavior and response format.
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 fully documents all 3 parameters and their nested properties. The description doesn't add any parameter-specific information beyond what's already in the schema, meeting the baseline 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 clearly states the action ('update') and resource ('views settings of a kintone app') in Japanese. It's specific about what gets updated but doesn't differentiate from sibling tools like 'update_app_settings' or 'update_field' that also modify app configurations.
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 on when to use this tool versus alternatives like 'update_app_settings' or 'get_views'. The description only states what it does, not when it's appropriate or what prerequisites exist for updating views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the upload action but doesn't disclose behavioral traits like authentication requirements, file size limits, supported file types, whether it overwrites existing files, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is insufficient.
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?
Single sentence, zero waste. The description is front-loaded with the core action and target. No unnecessary words or redundant information. Perfectly concise for a straightforward 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or important behavioral constraints. While concise, it lacks necessary context for safe and effective use by an AI agent.
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 (file_name and file_data with Base64 encoding). The description doesn't add any parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when schema does the documentation work.
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 action ('アップロードします' - uploads) and target resource ('kintoneアプリにファイル' - file to kintone app). It distinguishes from siblings like 'download_file' by specifying upload direction, but doesn't explicitly differentiate from other file-related operations that might exist.
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 on when to use this tool versus alternatives. While the name implies file operations, there's no mention of prerequisites, constraints, or comparison with sibling tools like 'create_record' that might also handle file attachments. The description provides only the basic function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '取得します' (get/retrieve) implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what format the access permissions are returned in. For a tool with zero annotation coverage, this is insufficient.
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 that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple retrieval operation and front-loads the core functionality.
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 read-only tool with 100% schema coverage but no output schema and no annotations, the description adequately covers the basic purpose. However, it lacks information about return format, error handling, or authentication requirements that would be helpful given the absence of structured metadata.
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 (app_id and preview) completely. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.
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 ('取得します' - get/retrieve) and resource ('kintoneアプリのアクセス権限' - kintone app access permissions), making the purpose unambiguous. It doesn't explicitly differentiate from siblings like 'get_field_acl' or 'get_record_acl', but the resource specificity (app vs field vs record) provides implicit distinction.
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 use this tool versus alternatives like 'get_field_acl' or 'get_record_acl', nor does it mention prerequisites or context for usage. It's a standalone statement without comparative or contextual information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '取得します' (get/retrieve) implies a read-only operation, the description doesn't explicitly state this or provide any other behavioral context such as authentication requirements, rate limits, error conditions, or what format the customization settings are returned in. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point without unnecessary elaboration.
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 the tool's relative simplicity (2 parameters, 100% schema coverage, no output schema), the description is minimally adequate but leaves gaps. While it clearly states what the tool retrieves, it doesn't provide behavioral context that would be helpful for an agent (especially with no annotations), nor does it help differentiate this tool from similar sibling tools. For a read operation with good schema coverage, it meets basic requirements but could be more 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?
The schema description coverage is 100%, meaning both parameters are well-documented in the schema itself. The description doesn't add any additional semantic context about the parameters beyond what's already in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting of parameter documentation.
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 action ('取得します' - get/retrieve) and the resource ('kintoneアプリのJavaScript/CSSカスタマイズ設定' - kintone app's JavaScript/CSS customization settings). It's specific about what is being retrieved, though it doesn't explicitly differentiate from sibling tools like 'get_app_settings' or 'get_preview_app_settings' which might retrieve different aspects of 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?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools that retrieve app-related information (e.g., 'get_app_acl', 'get_app_actions', 'get_app_plugins', 'get_apps_info'), but the description doesn't help the agent understand when this specific customization retrieval tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the action ('取得します' - get/retrieve) but doesn't describe return format (e.g., list structure, pagination), permissions required, rate limits, or error conditions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool 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 a single, clear sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes essential information.
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 the tool's simplicity (single parameter, read-only operation), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on return values, permissions, or error handling. For a basic retrieval tool, it meets the minimum but doesn't provide rich context for reliable agent use.
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%, with the single parameter 'group_code' documented in the schema as 'グループコード' (group code). The description adds no additional parameter semantics beyond what's in the schema (it doesn't explain format, examples, or constraints). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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: '指定したグループに所属するユーザーの一覧を取得します' translates to 'Get a list of users belonging to the specified group.' This provides a specific verb ('取得します' - get/retrieve) and resource (users in a group). However, it doesn't explicitly differentiate from sibling tools like 'get_users' or 'get_groups', which could retrieve similar data.
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 use this tool versus alternatives. It doesn't mention sibling tools like 'get_users' (which might retrieve all users) or 'get_groups' (which might retrieve group metadata), nor does it specify prerequisites or exclusions. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('取得します'), implying it's read-only, but doesn't mention authentication requirements, rate limits, error conditions, or what the return format looks like. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality.
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 simple read operation with 2 parameters and 100% schema coverage, the description is minimally adequate but lacks important context. With no output schema and no annotations, it should ideally mention the return format or data structure. The description covers the basic 'what' but misses the 'what you get back' aspect that would help an agent understand the tool's output.
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 both parameters (app_id and preview) are already documented in the schema. The description doesn't add any additional parameter context beyond what's in the schema, such as example app_id values or when preview mode would be useful. Baseline 3 is appropriate when schema does the documentation work.
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 action ('取得します' - get/retrieve) and the resource ('kintoneアプリのレコード単位の通知設定' - per-record notification settings for a Kintone app). It distinguishes itself from the sibling tool 'get_notifications' by specifying 'per-record' scope, but doesn't explicitly contrast with 'get_reminder_notifications' or 'update_per_record_notifications'.
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 use this tool versus alternatives like 'get_notifications' or 'get_reminder_notifications'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (retrieves settings) without mentioning any behavioral traits: no information about permissions required, rate limits, whether this is a read-only operation (implied but not stated), response format, error conditions, or whether it works on live vs. preview environments (though the 'preview' parameter hints at this). The description adds minimal value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality. Every word earns its place.
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 the tool's moderate complexity (retrieving process management settings), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It states what the tool does but lacks important context about the return format, error handling, authentication requirements, and differentiation from sibling tools. The description meets the bare minimum but leaves significant gaps for an AI agent to understand the full context of use.
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, with both parameters ('app_id' and 'preview') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'kintoneアプリのプロセス管理設定を取得します' (retrieves process management settings for a kintone app). It specifies the verb '取得します' (retrieves/get) and resource 'プロセス管理設定' (process management settings). However, it doesn't explicitly differentiate from sibling tools like 'get_preview_app_settings' or 'get_app_settings' that might retrieve other types of settings, leaving some ambiguity about scope.
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 use this tool versus alternatives. There are multiple 'get_' sibling tools for retrieving different aspects of kintone apps (e.g., 'get_app_settings', 'get_form_layout', 'get_views'), but no indication of when this specific process management settings retrieval is appropriate versus other settings retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '取得します' (retrieves) implies a read-only operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what format the reminder notification settings are returned in. For a tool with zero annotation coverage, this is insufficient.
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, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
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 simple 2-parameter retrieval tool with good schema coverage but no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks important context about authentication, return format, and differentiation from similar tools. The absence of an output schema means the description should ideally mention what kind of data is returned.
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 both parameters (app_id and preview) are documented in the schema. The description doesn't add any additional parameter context beyond what's already in the schema descriptions, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieves/gets) and resource ('kintoneアプリのリマインダー通知設定' - kintone app reminder notification settings). It's specific about what is being retrieved, though it doesn't explicitly differentiate from sibling tools like 'get_notifications' or 'get_per_record_notifications'.
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 use this tool versus alternatives. There are several sibling tools with 'get_' prefixes that retrieve different types of notification or app settings, but no context is given about when this specific reminder notification tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool retrieves graph settings, implying a read-only operation, but doesn't specify whether it requires authentication, returns paginated results, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic action.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential information.
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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It clarifies the action and resource but lacks details on behavioral aspects like authentication or error handling. Without an output schema, it doesn't explain what the retrieved graph settings include, leaving gaps in completeness for effective tool use.
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 coverage is 100%, with clear descriptions for both parameters ('app_id' and 'preview'). The description doesn't add any additional meaning beyond what the schema provides, such as explaining the format of graph settings or how 'preview' affects the retrieval. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation 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: 'kintoneアプリのグラフ設定を取得します' (retrieves graph settings for a Kintone app). It specifies the verb '取得します' (retrieves) and the resource 'グラフ設定' (graph settings), making the action explicit. However, it doesn't differentiate from sibling tools like 'get_views' or 'get_app_settings', which might retrieve other app configurations.
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 use this tool versus alternatives. It doesn't mention any prerequisites, such as needing an app ID, or suggest other tools for related tasks like updating reports (e.g., 'update_reports' is a sibling tool). Usage is implied only by the action described, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '取得します' (retrieve) implies a read operation, the description doesn't mention any behavioral traits like authentication requirements, rate limits, error conditions, or what '一般情報' (general information) specifically includes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
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 simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it doesn't provide enough context about what information is returned or any behavioral constraints. The description meets basic requirements but leaves important questions unanswered.
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, with the single parameter 'space_id' clearly documented as 'スペースID' (space ID). The description doesn't add any additional meaning beyond what the schema already provides about this parameter. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'スペースの一般情報を取得します' (Get general information about a space) clearly states the verb (取得/retrieve) and resource (スペース/space). It distinguishes this from sibling tools like 'update_space' or 'get_space_members' by focusing on general information retrieval. However, it doesn't explicitly differentiate from other 'get_' tools that might also retrieve space-related data.
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 use this tool versus alternatives. There are several sibling tools like 'get_space_members', 'update_space', and 'search_records' that might be relevant for space-related operations, but the description doesn't indicate when this specific tool is appropriate versus those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool retrieves view settings, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or the format/scope of the returned data (e.g., whether it includes all view types or metadata). For a tool with no annotations, this leaves significant gaps in understanding its 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 a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information.
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 the tool's moderate complexity (retrieving view settings with 2 parameters), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format. For a read operation without annotations, more context would be helpful to ensure proper use.
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 ('app_id' and 'preview') thoroughly. The description doesn't add any additional meaning beyond what the schema provides, such as explaining the relationship between parameters or usage examples. With high schema coverage, 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.
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: 'kintoneアプリの一覧（ビュー）の設定を取得します' (retrieves the settings/list of views for a Kintone app). It specifies the verb '取得します' (retrieve/get) and the resource 'kintoneアプリの一覧（ビュー）の設定' (Kintone app views/settings). However, it doesn't explicitly distinguish itself from sibling tools like 'get_form_fields' or 'get_form_layout', which also retrieve app configurations but for different components.
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 use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an app ID), exclusions, or compare it to sibling tools like 'get_reports' or 'update_views'. Usage is implied only through the parameter 'app_id', but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '更新します' (updates) implies a mutation operation, the description doesn't mention required permissions, whether changes are reversible, what happens to existing notifications not included in the update, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient Japanese sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded with the core functionality.
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 mutation tool with no annotations and no output schema, the description is minimally adequate. It identifies the resource being updated but doesn't address behavioral aspects like permissions, side effects, or response format. The 100% schema coverage helps, but the description itself doesn't provide enough context for safe and effective use.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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 action ('更新します' - updates) and the resource ('kintoneアプリの通知条件設定' - kintone app notification condition settings). It's specific about what gets updated, though it doesn't explicitly differentiate from sibling tools like 'update_per_record_notifications' or 'update_reminder_notifications' which also handle notification updates.
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 use this tool versus alternatives. With sibling tools like 'update_per_record_notifications' and 'update_reminder_notifications' that also update notification-related settings, there's no indication of which scenarios call for this tool versus those others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the response includes execution conditions ('filterCond') in Kintone query syntax, which adds useful behavioral context beyond a basic 'get' operation. However, it doesn't cover other traits like authentication requirements, rate limits, error handling, or response format details (e.g., pagination). The description adds some value but leaves gaps for a read operation.
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 two concise sentences that efficiently state the purpose and a key behavioral detail (inclusion of filterCond). It's front-loaded with the main action and avoids unnecessary elaboration. However, it could be slightly more structured by explicitly separating purpose from response details.
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 the tool's moderate complexity (retrieving app action settings), no annotations, and no output schema, the description is partially complete. It covers the core purpose and a response detail (filterCond), but lacks information on authentication, error cases, or full response structure. It's adequate as a minimum viable description but has clear gaps for effective agent use.
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, with clear documentation for both parameters (app_id and optional lang with enum values). The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param details in the description.
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: 'kintoneアプリのアクション設定を取得します' (gets action settings for a Kintone app). It specifies the verb '取得します' (get/retrieve) and the resource 'アクション設定' (action settings). However, it doesn't explicitly differentiate from sibling tools like 'get_app_acl' or 'get_app_customize', which also retrieve app-related configurations but for different aspects.
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 use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing app permissions), exclusions, or compare it to related tools like 'update_app_actions' (which modifies actions) or other 'get_app_*' tools. Usage is implied only by the action-focused context, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does ('get domain') without disclosing behavioral traits like whether this requires authentication, returns cached vs live data, format of the returned domain, error conditions, or rate limits. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence in Japanese that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple, parameter-less tool and is front-loaded with the essential information.
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 simple tool with no parameters, no output schema, and no annotations, the description provides the basic purpose but lacks important context. It doesn't explain what format the domain information is returned in, whether this is a configuration lookup or runtime discovery, or how this integrates with other connection-related tools. The description is minimally adequate but has clear gaps in behavioral 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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema fully documents this. No additional parameter information is needed or provided.
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 action ('取得します' - get/retrieve) and the resource ('kintoneの接続先ドメイン' - kintone connection destination domain), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'get_kintone_username' which retrieves a different piece of connection information.
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 use this tool versus alternatives. It doesn't mention prerequisites, context for retrieving domain information, or how this differs from other 'get_' tools in the sibling list that retrieve different configuration data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool retrieves a username for kintone connection but doesn't specify whether this is a read-only operation, if it requires authentication, what format the username is in, or any error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, clear sentence in Japanese that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and has zero waste, making it highly efficient for an AI agent 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It explains what the tool does but lacks details on behavioral aspects like authentication needs or return format. For a basic retrieval tool, it's functional but could be more informative to compensate for the absence of annotations.
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 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional information is required beyond what the schema provides.
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: 'kintoneへの接続に使用されるユーザー名を取得します' (Get the username used for connecting to kintone). It specifies the verb '取得します' (get) and the resource 'ユーザー名' (username) with context about kintone connection. However, it doesn't explicitly differentiate from sibling tools like 'get_users' or 'get_group_users', which also retrieve user-related information.
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 use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools such as 'get_users' or 'get_group_users', which might retrieve broader user information. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes what content will be retrieved (query language documentation covering operators, conditions, sorting, paging) but doesn't mention format (HTML, markdown, JSON), size limitations, authentication requirements, rate limits, or whether this is a read-only operation. The description adds some value but leaves significant behavioral aspects unspecified.
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, efficient sentence that clearly states the tool's purpose and scope. It's appropriately sized for a zero-parameter documentation retrieval tool, with no redundant information. However, it could be slightly more structured by separating the core purpose from the content details.
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 zero-parameter documentation retrieval tool with no annotations and no output schema, the description provides adequate but minimal information. It specifies what documentation will be retrieved and the topics covered, but doesn't describe the return format, structure, or any limitations. Given the lack of structured fields, the description should ideally provide more complete context about the output.
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 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it appropriately focuses on what the tool returns rather than what it accepts as input.
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: '取得します' (get/retrieve) 'kintoneクエリ言語（検索クエリ）に関する詳細なドキュメント' (detailed documentation about kintone query language/search queries). It specifies the resource (query language documentation) and scope (operators, conditional expressions, sorting, paging). However, it doesn't explicitly differentiate from sibling tools like 'get_documentation_tool_description' or 'get_field_type_documentation'.
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 use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or relationships with other documentation tools in the sibling list. The agent must infer usage from the tool name and description alone without explicit contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('取得します' - get), which suggests non-destructive behavior, but doesn't disclose details like authentication needs, rate limits, or response format. The description adds minimal behavioral context beyond the basic action, leaving gaps for an agent to infer usage.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it easy to parse. There's no wasted text, and it fits well within the context of a simple lookup tool.
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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on usage context, behavioral traits, or output expectations. For a tool that might return a list of field types, more context on format or application could enhance completeness, though it's not critical here.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully covers the parameters (or lack thereof), and the description doesn't need to compensate.
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: '利用可能なフィールドタイプの一覧を取得します' (Get a list of available field types). It specifies the verb '取得します' (get) and resource 'フィールドタイプの一覧' (list of field types), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_field_type_documentation' or 'create_choice_field', which slightly reduces clarity.
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 use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as whether it's for reference during field creation or for general documentation. With many sibling tools related to fields and documentation, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses a critical behavioral trait: the system setting requirement, which is essential for successful invocation. However, it doesn't cover other aspects like permissions needed, whether the operation is reversible, error conditions, or what happens to the app after removal. It adds some value but leaves gaps.
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 two sentences: one states the purpose, and the other provides a prerequisite note. It's front-loaded with the main action and avoids unnecessary fluff. However, it could be slightly more structured (e.g., separating usage notes).
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 the tool has no annotations, no output schema, and a simple single parameter, the description is moderately complete. It covers the purpose and a key prerequisite, but for a mutation tool (implied by 'move'), it lacks details on behavioral outcomes, error handling, or post-operation state. More context would improve completeness.
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%, with the single parameter 'app_id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., format constraints or examples). Baseline 3 is appropriate since the schema handles parameter documentation 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 action ('move app from space' or 'disassociate app from space') and specifies the resource (kintone app). It distinguishes from the sibling tool 'move_app_to_space' by implying the opposite operation, though not explicitly named. The purpose is specific but could be more precise about what 'move from space' entails.
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 includes a prerequisite note about system settings ('スペースに所属しないアプリの作成を許可する' must be enabled), which provides implicit guidance on when this tool can be used. However, it lacks explicit alternatives (e.g., when to use vs. other space-related tools) or clear exclusions. The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses a size limitation ('1MB以上のファイルは正常にダウンロードできない場合があります' - files over 1MB may not download properly). This is important operational information not captured elsewhere. No contradictions exist since annotations are empty.
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 with zero waste: first states the core purpose, second provides critical behavioral constraint. Both sentences earn their place by adding distinct value. The description is appropriately sized and front-loaded with the main functionality.
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 single-parameter tool with no output schema and no annotations, the description provides good coverage: clear purpose, important behavioral constraint about file size limitations. While it doesn't explain return values or error conditions, the size warning addresses a key operational consideration for this type of 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% with the single parameter 'file_key' already documented as 'ダウンロードするファイルのキー' (key of file to download). The description doesn't add any additional parameter information beyond what the schema provides, so baseline 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 clearly states the action ('ダウンロードします' - downloads) and resource ('kintoneアプリからファイル' - file from kintone app). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'upload_file' beyond the obvious directionality.
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 about when to use this tool versus alternatives. While 'upload_file' is clearly the opposite operation, there's no explicit comparison or context about when download versus other file-related operations would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the filtering behavior (search by name substring, filter by ID, optional additional filters) which is useful context. However, it doesn't mention important behavioral aspects like whether this is a read-only operation, what format the returned information takes, or any rate limits or authentication requirements. The description adds some value but leaves significant gaps.
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 and well-structured in a single sentence that efficiently communicates the tool's purpose, required parameters, and optional parameters. Every word serves a purpose with no wasted text, making it easy to parse and understand quickly.
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 the tool has no annotations and no output schema, the description provides adequate basic information about what the tool does and parameter requirements. However, for a tool that retrieves application information with multiple filtering options, more context about the return format, error conditions, or typical use cases would be helpful. The description is minimally complete but could be more comprehensive.
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 coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds some semantic context by explaining the relationships between parameters (either/or requirements for app_name/app_id, optional combinability of app_code/space_id), but doesn't provide additional meaning beyond what's already in the schema descriptions. This meets the baseline 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 clearly states the tool's purpose: 'get kintone app information' with filtering capabilities. It specifies the verb ('get') and resource ('kintone app information'), making the purpose unambiguous. However, it doesn't explicitly differentiate this from other app-related tools like 'get_app_acl' or 'get_app_settings' among the siblings, which prevents a perfect score.
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 usage context by specifying that either 'app_name' or 'app_id' must be provided, and that 'app_code' and 'space_id' are optional combinable filters. This gives practical guidance on parameter requirements. However, it doesn't explain when to use this tool versus alternatives like 'get_app_acl' or 'get_app_settings' from the sibling list, which would be needed for a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the tool's purpose and a prerequisite step, but lacks details on authentication needs, rate limits, error conditions, or return format. The description doesn't contradict annotations (none exist), but provides only basic operational context without deeper behavioral traits.
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 perfectly concise and well-structured with two sentences: one stating the core purpose and another providing usage guidance. Every sentence earns its place with no wasted words, and the information is front-loaded with the primary function stated first.
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 simple read operation with 2 parameters and no output schema, the description provides adequate context about what the tool does and a helpful prerequisite. However, without annotations or output schema, it lacks details on authentication, error handling, or return format. The description is complete enough for basic use but leaves gaps in operational understanding.
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 coverage is 100%, with both parameters (app_id, record_id) clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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: 'kintoneアプリの1レコードを取得します' (retrieves one record from a Kintone app). It specifies the verb (取得/retrieve) and resource (レコード/record), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_records' or 'get_record_acl', which would be needed for a perfect score.
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 usage guidance by recommending to use 'get_form_fields' first to understand field structures before calling this tool. This establishes a helpful prerequisite context. However, it doesn't specify when to use this tool versus alternatives like 'search_records' for multiple records or 'get_record_acl' for permissions, missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 key behavioral traits: it fetches comments, performs internal pagination when limit is unspecified to get all items, and recommends using limit for large datasets to manage performance. This covers important operational aspects like data handling and performance considerations, though it doesn't detail error conditions or response format.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second provides crucial behavioral guidance. Every sentence earns its place with no wasted words, making it efficient 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?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers purpose and key behavior (pagination, limit usage), but lacks details on output format, error handling, or authentication needs. Without annotations or output schema, more context would be helpful for a read operation, though it's minimally viable.
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 coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds value by explaining the default behavior for 'limit' (internal pagination for all items when unspecified) and providing an example ('例: 10'), but doesn't add significant meaning beyond what the schema provides. This meets the baseline 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 clearly states the tool's purpose: 'kintoneレコードのコメントを取得します' (get comments for a kintone record). It specifies the verb (取得/get) and resource (コメント/comments), but doesn't explicitly differentiate from sibling tools like 'get_record' or 'add_record_comment'. The purpose is clear but lacks sibling differentiation for a perfect score.
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 some usage guidance by recommending to use 'limit' for large datasets to avoid fetching all comments, which implies when to use this parameter. However, it doesn't specify when to use this tool versus alternatives like 'get_record' (which might include comments) or 'add_record_comment', nor does it mention prerequisites or exclusions. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: the tool mutates form layouts (implied by '変更します'), specifies layout constraints (top-level elements, SUBTABLE/GROUP placement rules), and mentions technical requirements (lookup field width). However, it lacks details on permissions, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: layout element types, placement rules, SUBTABLE field specification, and lookup field width. No redundant information, though it could be slightly more structured.
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 the complexity (3 parameters, nested layout structure, no output schema, and no annotations), the description is adequate but has gaps. It covers layout constraints and technical details but lacks information on permissions, error cases, or response format. For a mutation tool with no annotations, more behavioral context would improve completeness.
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 parameters (app_id, layout, revision). The description adds some context about layout structure (ROW, SUBTABLE, GROUP) and field requirements, but does not provide additional syntax or format details beyond what the schema specifies. Baseline 3 is appropriate when 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 clearly states the tool's purpose: 'kintoneアプリのフォームレイアウトを変更します' (changes the form layout of a kintone app). It specifies the verb ('変更します' - changes/updates) and resource ('フォームレイアウト' - form layout), and distinguishes it from sibling tools like 'create_form_layout' (creates) and 'get_form_layout' (reads).
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 implied usage guidance through technical constraints (e.g., SUBTABLE/GROUP must be top-level, cannot be in ROW; lookup fields need width ≥250). However, it does not explicitly state when to use this tool versus alternatives like 'create_form_layout' or 'update_app_settings', nor does it mention prerequisites (e.g., needing app_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds useful context about the system field constraint, but doesn't mention permission requirements, whether the update is reversible, rate limits, or what happens to existing data in the field. The example helps but doesn't fully compensate for missing behavioral details.
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 efficiently structured with a clear purpose statement, important constraint note, and illustrative example. Every sentence earns its place, and the information is front-loaded with the most critical constraint immediately following the main purpose.
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 mutation tool with 4 parameters, no annotations, and no output schema, the description is adequate but has clear gaps. The system field constraint is valuable, but missing details about permissions, side effects, and response format leave the agent with incomplete understanding of the tool's behavior.
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 parameters. The description provides an example that illustrates parameter usage but doesn't add significant semantic meaning beyond what the schema provides. The baseline of 3 is appropriate when 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 clearly states the specific action ('更新します' - updates) and resource ('既存のkintoneフィールドの設定' - existing kintone field settings). It distinguishes from sibling tools like 'create_choice_field' or 'create_lookup_field' by focusing on updating existing fields rather than creating new ones.
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 context about when NOT to use this tool (system field types cannot be updated), which helps the agent avoid incorrect invocations. However, it doesn't explicitly mention when to use this versus alternatives like 'update_field_acl' or provide prerequisites beyond the constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the conditional update/create logic based on duplicate prevention fields and the 100-record limit. However, it doesn't mention authentication requirements, error handling, rate limits, or what happens when duplicate prevention fields conflict, which are important 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 perfectly concise with just two sentences that front-load the core functionality. Every word earns its place by explaining the upsert logic, duplicate prevention mechanism, and record limit without any redundancy or unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description provides adequate coverage of the core functionality but lacks important contextual details. It explains what the tool does but doesn't cover response format, error conditions, permissions needed, or system constraints beyond the 100-record limit, leaving gaps for an AI agent to operate safely.
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?
With 100% schema description coverage, the baseline is 3. The description adds some value by explaining the purpose of 'updateKey' (duplicate prevention field) and the conditional logic, but doesn't provide additional semantic context beyond what's already well-documented in the schema properties and their descriptions.
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 specific action ('upsert multiple records in bulk'), the resource ('records'), and distinguishes it from siblings by specifying batch processing with up to 100 items. It explicitly mentions the conditional logic (update existing, create new) based on duplicate prevention 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 provides clear context for when to use this tool (bulk upsert operations with duplicate prevention fields) and mentions the 100-record limit. However, it doesn't explicitly contrast with alternatives like 'create_records', 'update_record', or 'upsert_record' (singular), leaving some ambiguity about when to choose this specific bulk version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains what gets created (fields with specific constraints), provides detailed format requirements for default values, describes priority rules when conflicting defaults are specified, and includes important constraints about system field types and lookup field width requirements.
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 appropriately front-loaded with core functionality, but contains some redundancy (repeating system field type warnings) and includes an extensive example that could be streamlined. While most content is valuable, the section about alternative field naming approaches could be more concise.
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 tool with no annotations and no output schema, the description provides comprehensive coverage of what the tool does, how to use it, parameter details, constraints, and examples. The only minor gap is the lack of information about what the tool returns (success/failure indicators, field IDs, etc.), which would be helpful given the absence of an output schema.
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?
Despite 100% schema description coverage, the description adds significant value beyond the schema. It elaborates on the structure of the 'properties' object, specifies required sub-fields (code, type, label), provides detailed format requirements for default values, and includes a comprehensive example showing exactly how parameters should be structured.
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 specific action ('adds fields') and resource ('kintone app'), distinguishing it from siblings like 'create_app' (creates entire app) or 'update_field' (modifies existing fields). It precisely defines what the tool does without being tautological.
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 context about when to use this tool (adding fields to an app) and includes important exclusions (system field types cannot be added). However, it doesn't explicitly compare against alternatives like 'create_choice_field' or 'create_lookup_field' which appear to be more specialized sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it explains query syntax with examples, notes constraints (e.g., is empty/is not empty only works for specific field types), and mentions pagination and sorting options. However, it lacks details on error handling, rate limits, or authentication needs, which are common for such tools.
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 well-structured with clear sections: purpose, recommendation, query examples, and notes. It is appropriately sized for a complex tool, though some examples could be condensed. Every sentence adds value, such as clarifying field type constraints and referencing other tools for details.
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 complexity (search tool with query language), no annotations, and no output schema, the description is quite complete. It covers purpose, usage guidelines, behavioral aspects (query syntax, constraints), and parameter context. However, it lacks details on output format (e.g., structure of returned records) and error cases, which would be helpful for full completeness.
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 parameters (app_id, query, fields). The description adds value by providing extensive query examples and usage notes that clarify the semantics of the query parameter beyond the schema's basic examples, but it doesn't add significant meaning for app_id or fields parameters. Baseline 3 is appropriate as the schema does 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 clearly states the tool's purpose: 'kintoneアプリのレコードを検索します' (searches records in a kintone app). It specifies the verb (search) and resource (records in a kintone app), and distinguishes itself from siblings like get_record (which retrieves a single record) or get_records (not listed, but implied as different).
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 provides explicit guidance on when to use this tool: it recommends using get_form_fields first to understand field codes and types before creating queries, and directs users to get_query_language_documentation for detailed syntax and specifications. It also distinguishes from siblings by not overlapping with tools like get_record or create_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the upsert behavior (update if exists, create if not), specifying the key mechanism (duplicate prevention field or record ID), and mentioning the field value format requirement. It doesn't cover error conditions or rate limits, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each serve distinct purposes: first explains the tool's core functionality, second provides usage guidance. It's front-loaded with the main purpose and avoids unnecessary repetition. Could be slightly more concise but efficiently conveys essential 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 mutation tool with no annotations and no output schema, the description does well by explaining the upsert behavior, providing usage prerequisites, and clarifying field format. It covers the essential context needed to understand when and how to use this tool versus alternatives like create_record or update_record. Minor gaps exist regarding error handling and response format.
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 is 3. The description adds some value by explaining that fields should be specified as { 'value': ... } format, which clarifies the structure beyond the schema's generic description. However, it doesn't provide additional semantic context about parameter relationships or usage nuances.
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 purpose: 'upsert 機能を使用します' (use upsert functionality) with specific details about using a duplicate prevention field or record ID as a key to update if exists or create if not. It distinguishes from sibling tools like 'create_record' and 'update_record' by specifying this hybrid behavior.
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 provides explicit usage guidelines: '実行前に `get_form_fields` や `get_form_layout` でフィールド構造を確認し、利用するフィールドコードが最新であることをチェックしてから実行してください' (Before execution, check field structure with get_form_fields or get_form_layout and verify field codes are up-to-date). It mentions specific sibling tools to use first and provides clear prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies this only works for production environments (not preview), mentions error conditions when apps don't exist in production, and implies this is a read operation through context. It doesn't mention rate limits, authentication needs, or response format details.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides critical usage guidance and alternative tool reference. No wasted words, front-loaded with essential 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 single-parameter read tool with no output schema, the description provides excellent context about environment constraints and sibling alternatives. It doesn't describe the return format or structure of the form field information, which would be helpful but isn't critical given the tool's relative simplicity.
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?
With 100% schema description coverage (the single parameter 'app_id' is fully documented in the schema as 'kintoneアプリのID'), the description adds no additional parameter information beyond what the schema already provides. The baseline score of 3 is appropriate when 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 clearly states the specific action ('取得します' - retrieves) and resource ('kintoneアプリのフォームフィールド情報' - kintone app form field information). It explicitly distinguishes from its sibling tool 'get_preview_form_fields' by specifying this works only for production environments.
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 provides explicit guidance on when to use this tool ('対象アプリが本番環境に存在しない場合はエラーとなります' - errors if target app doesn't exist in production) and when to use an alternative ('プレビュー環境の情報を取得したい場合は get_preview_form_fields を使用してください' - use get_preview_form_fields for preview environment information).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's behavior: it's a mutation operation (updates records), explains the two identification methods (record_id or updateKey), specifies field value format requirements ('各フィールドは { "value": ... } の形式で指定します'), and provides concrete examples. It doesn't mention authentication requirements or rate limits, but covers the core behavioral aspects well 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose and usage guidance, but includes two lengthy JSON examples that could be condensed. While the examples are helpful, they make the description quite long. Every sentence earns its place, but the structure could be more concise by summarizing the examples or moving them to a separate section.
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 mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, usage guidelines, parameter explanations, and behavioral details. It covers the essential aspects of how to use the tool effectively. The main gap is the lack of information about return values or error conditions, but given the complexity of the tool and the absence of output schema, it's 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 description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining the relationship between record_id and updateKey ('レコードIDまたはupdateKeyのいずれかを指定して更新できます'), providing detailed examples of the fields parameter structure, and clarifying that updateKey requires duplicate-prohibited fields. This goes well beyond what the schema descriptions provide.
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 purpose: 'kintoneアプリの既存レコードを更新します' (updates existing records in a kintone app). It specifies the exact resource (existing records) and operation (update), distinguishing it from sibling tools like create_record, upsert_record, and update_record_status which have different purposes.
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 provides explicit guidance on when to use this tool: '更新前に`get_form_fields` や`get_form_layout` でフィールド構造とレイアウトを確認し、利用するフィールドコードが最新であることをチェックしてから操作してください' (check field structure and layout before updating). It also distinguishes between two usage patterns (record_id vs updateKey) and specifies prerequisites for using updateKey (must be a duplicate-prohibited field).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively communicates this is a write operation ('作成します' - creates), provides formatting requirements ('各フィールドは { "value": ... } の形式で指定します' - each field must be specified in { "value": ... } format), and gives a comprehensive example showing various field types and their expected structures. However, it doesn't mention potential side effects, error conditions, or authentication requirements.
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 appropriately sized and front-loaded with the core purpose first, followed by usage guidance, then parameter formatting rules, and finally a comprehensive example. Every sentence serves a clear purpose, though the lengthy example (while valuable) makes it less concise than ideal.
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 write operation with no annotations and no output schema, the description does an excellent job covering the essential context: purpose, prerequisites, parameter formatting, and examples. It could be more complete by mentioning what happens on success/failure or the response format, but given the comprehensive example and guidance, it's quite complete for practical use.
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?
With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the 'fields' parameter structure in detail ('各フィールドは { "value": ... } の形式で指定します' - each field must be specified in { "value": ... } format) and providing an extensive example showing how different field types should be formatted. This goes well beyond what the schema's minimal description 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 clearly states the specific action ('新しいレコードを作成します' - creates a new record) and resource ('kintoneアプリ' - Kintone app), distinguishing it from sibling tools like 'create_records' (plural) and 'update_record'. It provides a complete operational definition beyond just restating the name.
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 explicitly recommends when to use this tool ('事前に対象アプリのフィールド構造を把握するため' - to understand the target app's field structure beforehand) and names specific alternative tools to use first ('get_form_fields' and 'get_form_layout'). It provides clear prerequisites and sequencing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kintone-mcp-server MCP server](https://glama.ai/mcp/servers/r3-yamauchi/kintone-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/r3-yamauchi/kintone-mcp-server)

Score Badge

Copy to your README.md:

[![kintone-mcp-server MCP server](https://glama.ai/mcp/servers/r3-yamauchi/kintone-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/r3-yamauchi/kintone-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/r3-yamauchi/kintone-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server