Server Quality Checklist

Tool Scores

• zaim_create_incomeC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates an income record (implying a write/mutation operation) but provides no information about permissions needed, whether the operation is idempotent, what happens on success/failure, rate limits, or what the response looks like. For a creation 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. There's no wasted language or unnecessary elaboration. 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 creation/mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation, what the response contains, error conditions, or behavioral characteristics. The description should provide more context about this being a write operation with specific implications.

  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 with clear parameter documentation in Japanese. The tool description adds no additional parameter information beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't need to compensate for schema gaps.

  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) and resource ('収入記録' - income record) in Zaim. It distinguishes from siblings like zaim_create_payment (expenses) and zaim_create_transfer (transfers), but 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 like zaim_create_payment or zaim_create_transfer. It doesn't mention prerequisites, authentication requirements, or any context about when income recording is appropriate versus other financial operations.

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

• zaim_create_paymentC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. '作成します' implies a write/mutation operation, but the description doesn't disclose behavioral traits like authentication requirements, whether the operation is idempotent, error handling, or what happens on success/failure. 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.

  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. It's appropriately sized and front-loaded with zero wasted words, making it easy for an agent 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 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address authentication needs, error conditions, return values, or how this tool differs from similar write operations (create_income, create_transfer). The agent lacks crucial context for proper tool invocation.

  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 information beyond what the input schema provides. However, schema description coverage is 100% (all 8 parameters have descriptions in Japanese), so the baseline is 3. The description doesn't compensate with additional context about parameter relationships or usage examples.

  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 'Zaimに支出記録を作成します' clearly states the action ('作成します' - creates) and resource ('支出記録' - payment record) in Japanese. It's specific about creating a payment record in the Zaim system. However, it doesn't explicitly differentiate from sibling tools like 'zaim_create_income' or 'zaim_create_transfer', which would require a 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's no mention of when to choose this over 'zaim_create_income' or 'zaim_create_transfer', nor any prerequisites or context for usage. The agent must 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.

• zaim_update_money_recordC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. '更新します' (updates) implies a mutation operation, but the description doesn't disclose any behavioral traits: no information about authentication requirements, rate limits, error conditions, whether the update is partial or complete, or what happens to unspecified fields. For a mutation tool with 11 parameters and no 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 directly states the tool's purpose: 'Zaimの既存の家計簿記録を更新します' (Updates Zaim's existing household account records). There's zero wasted verbiage or 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 11 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens when the tool is invoked (response format, success indicators, error handling), doesn't mention authentication requirements despite sibling tools including auth-related tools, and provides no behavioral context. The description alone is insufficient for an agent to understand 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 description coverage is 100%, with all 11 parameters having descriptions in Japanese. The tool description doesn't add any parameter-specific information beyond what's already 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, 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 action ('更新します' - updates) and the resource ('Zaimの既存の家計簿記録' - Zaim's existing household account records). It distinguishes from sibling tools like zaim_create_income/payment/transfer by specifying it updates existing records rather than creating new ones. However, it doesn't explicitly mention what fields can be updated beyond the general concept.

  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 for creating records (zaim_create_income/payment/transfer) and deleting records (zaim_delete_money_record), but the description doesn't explain when updating is appropriate versus creating new or deleting existing records. No prerequisites or constraints are mentioned.

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

• zaim_check_auth_statusB
  3.1/5.0
  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 what the tool does but doesn't describe important behavioral aspects: what 'checking' entails (e.g., makes a test API call), what happens if authentication fails, whether this consumes rate limits, or what the response looks like. The description is minimal and lacks operational 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 with zero wasted words. It's appropriately sized for a simple authentication check 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.

  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 the check returns (e.g., token expiry time, user info, success/failure status) or how the agent should interpret results. Given the authentication context and lack of structured output documentation, more completeness is needed.

  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 (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. Baseline score for zero parameters is 4.

  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: checking Zaim API authentication status and verifying access token validity. It specifies the verb ('check'/'verify') and resource ('authentication status'/'access token'), but doesn't explicitly differentiate from sibling tools (though it's the only auth-related tool in the list).

  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 (like needing to authenticate first), error conditions, or typical use cases (e.g., before making other API calls). The agent must 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.

• zaim_get_default_categoriesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('取得します' - get), which implies non-destructive behavior, but doesn't mention any behavioral traits like authentication requirements, rate limits, or what the output looks like. For a tool with zero annotation coverage, this is a significant gap, as it doesn't add context beyond the basic purpose.

  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 purpose. It's appropriately sized and front-loaded with the key action and resource. There's no wasted text, but it could be slightly more structured if it included brief usage hints, though it's not necessary 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 complexity (a read operation with one parameter) and no annotations or output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, fields) or any behavioral aspects like error handling. For a tool with no structured data to rely on, the description should provide more context to be fully helpful, making it inadequate.

  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 minimal meaning beyond the input schema. It mentions '支出または収入' (expense or income), which aligns with the 'mode' parameter's enum values ('payment' and 'income'), but the schema already has 100% coverage with a clear description for 'mode.' With high schema coverage, the baseline is 3, and the description doesn't compensate with additional details like parameter constraints or examples, so it meets the minimum viable standard.

  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: 'Zaimのデフォルトカテゴリ一覧を取得します（支出または収入）' translates to 'Get Zaim's default category list (expense or income).' It specifies the verb ('取得します' - get) and resource ('デフォルトカテゴリ一覧' - default category list), and distinguishes it from siblings like 'zaim_get_user_categories' by specifying 'default' categories. However, it doesn't explicitly contrast with all siblings, such as 'zaim_get_default_genres,' which is similar but for genres, so it's not a perfect 5.

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

  Usage Guidelines3/5

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

  The description implies usage by mentioning '支出または収入' (expense or income), which relates to the 'mode' parameter, but it doesn't provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use 'zaim_get_default_categories' versus 'zaim_get_user_categories' or 'zaim_get_default_genres.' The context is clear but lacks explicit when/when-not statements or named alternatives, so it's adequate but with gaps.

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

• zaim_get_default_genresB
  3.1/5.0
  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 mention any constraints like rate limits, authentication requirements, or response format details that would help the agent understand how to properly invoke it.

  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 communicates the core 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.

  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 100% schema coverage but no annotations or output schema, the description provides adequate basic information about what the tool does. However, it lacks details about authentication requirements, response format, or error conditions that would be helpful for the 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 fully documents the single 'mode' parameter with its enum values and description. The description adds no additional parameter information beyond what's in the schema, meeting 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.

  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 resource ('Zaimのデフォルトジャンル一覧' - Zaim's default genre list) with scope qualification ('支出または収入' - expense or income). It doesn't explicitly differentiate from sibling tools like zaim_get_user_genres, but the 'default' distinction is implied.

  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 zaim_get_user_genres or zaim_get_default_categories. The description only states what the tool does, not when it should be selected over other available options.

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

• zaim_get_user_genresB
  3.1/5.0
  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 what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, or describes the return format. 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 any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  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. It doesn't explain what the returned data looks like (e.g., list format, fields), authentication requirements, or error conditions. For a data retrieval tool, this leaves the agent with insufficient context to use it effectively.

  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 fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters. Baseline 4 is appropriate for zero-parameter tools.

  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 ('Zaimユーザーのカスタムジャンル一覧' - Zaim user's custom genre list). It distinguishes from siblings like 'zaim_get_default_genres' by specifying 'user' and 'custom' genres. However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 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 like 'zaim_get_default_genres' or 'zaim_get_user_categories'. It lacks context about prerequisites (e.g., authentication status) or typical use cases, offering only a basic functional statement.

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

• zaim_get_user_infoB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves user information but doesn't mention any behavioral traits such as authentication requirements, rate limits, response format, or whether it's a read-only operation. 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: 'Zaimユーザーの詳細情報（プロフィール、統計情報等）を取得します'. It is front-loaded with the core purpose and uses parentheses to clarify scope without unnecessary elaboration. Every word earns its place, making it highly concise and well-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?

  Given the tool's complexity (simple retrieval with no parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned user information includes (e.g., profile vs. statistics details), authentication needs, or error handling. For a tool with no structured data to supplement it, the description should provide more context to be fully 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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, as there are no parameters to explain. This meets the baseline for tools with no parameters, as it doesn't mislead or omit necessary information about inputs.

  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: 'Zaimユーザーの詳細情報（プロフィール、統計情報等）を取得します' (Get detailed Zaim user information such as profile, statistics, etc.). It specifies the verb '取得します' (get/retrieve) and resource 'Zaimユーザーの詳細情報' (Zaim user details), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'zaim_get_user_accounts' or 'zaim_get_money_records', which also retrieve user-related data but 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 doesn't mention any prerequisites (e.g., authentication status), context for usage, or exclusions. Given sibling tools like 'zaim_get_user_accounts' and 'zaim_get_user_categories', the lack of differentiation leaves the agent without clear usage instructions.

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

• zaim_create_transferB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states it creates records without disclosing behavioral traits. It doesn't mention whether this is a write operation requiring specific permissions, if it's idempotent, what happens on failure, or any rate limits. 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.

  Conciseness5/5

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

  The description is a single, efficient sentence in Japanese that clearly communicates the tool's purpose. It's appropriately sized with zero wasted words and front-loads the essential information about creating transfer records.

  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 happens after creation (success response format, error conditions), doesn't mention authentication requirements despite zaim_check_auth_status being a sibling, and provides minimal behavioral context for a write 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?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics 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 ('作成します' - creates) and resource ('振替記録' - transfer record) with the context of being between accounts. It distinguishes from siblings like zaim_create_income and zaim_create_payment by specifying it's for transfers between accounts rather than income or payments.

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

  Usage Guidelines3/5

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

  The description implies usage context by specifying '口座間の資金移動' (fund transfers between accounts), which helps differentiate from income/payment creation tools. However, it doesn't explicitly state when to use this versus alternatives or mention any prerequisites like authentication status.

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

• zaim_get_currenciesB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('get currency list') without adding context like authentication needs, rate limits, or what the return 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 any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse 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's low complexity (0 parameters, no output schema), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral aspects like return values or error handling. It meets the basic requirement but leaves gaps that could hinder agent performance.

  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%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate as it avoids misalignment with 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 verb '取得します' (get/retrieve) and the resource '通貨一覧' (currency list), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'zaim_get_user_accounts' or 'zaim_get_user_info', which are also retrieval operations but for different resources, 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. It doesn't mention context, prerequisites, or exclusions, such as whether it requires authentication or how it relates to other 'get' tools in the sibling list. This leaves the agent with minimal usage context.

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

• zaim_get_money_recordsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the tool retrieves records with filtering but doesn't disclose behavioral traits like whether this requires authentication (implied by sibling tools with auth), rate limits, pagination behavior (though schema hints at it), or what happens when no records match. The description is minimal and lacks critical operational 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 two concise sentences in Japanese, front-loaded with the core purpose and followed by filtering capabilities. Every sentence earns its place with no wasted words, making it efficient and well-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?

  Given no annotations, no output schema, and a tool with 6 parameters for retrieving financial records, the description is incomplete. It lacks information on authentication requirements, error handling, response format, and how filtering interacts (e.g., AND/OR logic). For a data retrieval tool in a household accounting context, this leaves significant gaps for 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 all parameters thoroughly. The description adds minimal value by mentioning filtering by date range, category, and mode, but doesn't provide additional semantics beyond what's in the schema (e.g., explaining relationships between parameters). Baseline 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: 'Zaim家計簿の支出・収入・振替記録を取得します' (retrieves expenditure, income, and transfer records from Zaim household accounting). It specifies the verb '取得します' (retrieves) and resource '記録' (records), but doesn't explicitly differentiate from sibling tools like zaim_get_user_categories or zaim_get_user_info that also retrieve data.

  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 mentions filtering capabilities ('日付範囲、カテゴリ、モードでフィルタリング可能です'), which implies usage context for retrieving filtered records. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like zaim_get_user_categories for category data or zaim_get_user_info for user information.

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

• zaim_get_user_accountsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While '取得します' (get/retrieve) implies a read-only operation, the description doesn't specify authentication requirements, rate limits, error conditions, or what the return format looks like (e.g., list structure, pagination). 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, efficient sentence in Japanese that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information 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 simplicity (0 parameters, no output schema), the description is adequate as a basic statement of purpose. However, without annotations or output schema, it lacks details on authentication, response format, or error handling that would be helpful for an agent. It meets minimum viability but has clear gaps in contextual 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, and schema description coverage is 100% (though empty). With no parameters to document, the description doesn't need to compensate for any gaps. A baseline of 4 is appropriate since there's nothing to explain beyond what's already covered by the schema (which indicates no inputs).

  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 ('Zaimユーザーの口座一覧' - Zaim user account list), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'zaim_get_user_info' or 'zaim_get_money_records' which also retrieve user-related data, 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. With sibling tools like 'zaim_get_user_info' (which might include account info) and 'zaim_get_money_records' (which involves financial data), there's no indication of when this specific account-listing tool is appropriate or what distinguishes it from other retrieval operations.

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

• zaim_get_user_categoriesB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description 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 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, efficient sentence in Japanese that directly states the tool's purpose without any wasted 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-only tool with no parameters and no output schema, the description adequately states what it does. However, without annotations or output schema, it should ideally mention what the return data looks like (e.g., list format, category structure) or authentication requirements to be more complete for agent 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?

  The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. The baseline for 0 parameters with full schema coverage is 4.

  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 ('Zaimユーザーのカスタムカテゴリ一覧' - Zaim user's custom category list), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'zaim_get_default_categories', which might cause confusion about when to use each.

  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 'zaim_get_default_categories' or 'zaim_get_user_genres'. It lacks context about prerequisites (e.g., authentication status) 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.

• zaim_delete_money_recordA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and adds valuable behavioral context: it explicitly states deletion is permanent ('永続的') and irreversible ('復元できません'). However, it doesn't mention authentication requirements, rate limits, or error conditions.

  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 immediately states the tool's purpose and critical behavioral warning. Every word earns its place with no redundancy or unnecessary elaboration.

  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 destructive operation with no annotations and no output schema, the description provides essential context about permanence. However, it lacks information about authentication requirements, error responses, or what happens after deletion that would make it fully 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 both parameters (id and mode with enum values). The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score.

  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 ('削除します' - delete) and resource ('Zaimの家計簿記録' - Zaim household accounting records). It distinguishes from sibling tools like zaim_get_money_records (read) and zaim_update_money_record (update) by specifying deletion.

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

  Usage Guidelines3/5

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

  The description implies usage when permanent deletion of a money record is needed, but doesn't explicitly state when to use this vs alternatives like zaim_update_money_record for modifications or when not to use it. No prerequisites or comparison to siblings is provided.

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