list_journals

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 explicitly discloses that the operation is asynchronous and outlines the expected sequence: request, status check, then download. This is meaningful behavioral context beyond what the schema provides. However, the description does not clarify what the initial response contains, how the status is checked, or what the actual download artifact looks like, keeping it from a 5.

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

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

The description is two short sentences: the first front-loads the core purpose and the async nature, the second gives the minimal workflow. Every word earns its place and there is no redundancy. The structure is easy to parse and quickly conveys the essential behavior.

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

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

Given the tool is asynchronous, lacks an output schema, and has no annotations, the description is only partially complete. It names the workflow steps but does not explain how the status check is performed, what a success response looks like, or whether this tool returns a job ID. For a tool with such a non-trivial async flow, more detail about the expected intermediate and final responses would be needed for fully autonomous use.

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

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

Schema description coverage is 100%, with each parameter (company_id, start_date, end_date) having a reasonable description with format and purpose. The tool description does not add any parameter-level semantics, so a baseline of 3 is appropriate. The async workflow is not tied to any specific parameter, which is fine because the parameters are simple date filters and an identifier.

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

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

The description clearly states the tool's purpose with a specific verb and resource: '仕訳帳をダウンロード' (download journal). It also adds the key qualifier '非同期' (asynchronous), which distinguishes it from the sibling list_* tools that are presumably synchronous reads. This is more than a tautology and helps an agent understand the operation at a glance.

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

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

The description provides a workflow hint ('まずリクエストを送信し、ステータスを確認してからダウンロード' – first send request, check status, then download), but gives no guidance on when to choose this tool over the many sibling tools (list_deals, list_transfers, get_trial_balance, etc.). There are no exclusion criteria or alternative pointers, so an agent must infer usage context from the resource name alone.

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