Fetch accounting journal entries for a date range; specify start or end date, and filter by account or realization status.
会計仕訳一覧を取得する。start_date または end_date のいずれかを指定する必要がある（同一会計期間内）。
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ページ番号（デフォルト 1） | |
| end_date | No | 対象期間の終了日（取引日基準） | |
| per_page | No | 1ページあたりの件数（デフォルト 10、最大 10000） | |
| account_id | No | 勘定科目ID（借方/貸方のいずれかに含む仕訳を絞り込む） | |
| start_date | No | 対象期間の開始日（取引日基準） | |
| is_realized | No | 未実現仕訳のフラグ。未指定なら全件返却 |
Changes observed during successful MCP inspections.
v0.2.0Does 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 the date-range constraint but says nothing about read-only safety, authentication requirements, pagination behavior (despite page/per_page params), or what the response contains — a large gap for a 6-parameter list tool.
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?
Two short sentences with the core operation front-loaded and the constraint second — no wasted words. It is appropriately sized, though the second sentence could be slightly clearer about the exact rule.
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 no annotations and no output schema, the description covers the operation and the date precondition but omits auth/permission needs, pagination semantics, and return-shape expectations. The rich schema covers parameters, so this is adequate but not fully self-sufficient.
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 coverage is 100%, so the baseline is 3, but the description adds a genuinely useful constraint beyond the schema: it states that at least one of start_date/end_date must be supplied, while the schema marks all 6 parameters as optional (0 required). That resolves an ambiguity the structured data leaves open.
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?
States a specific verb (取得する) and resource (会計仕訳一覧), which clearly identifies the operation. It is distinguishable from the singular sibling mf_accounting_get_journal by the 'list/一覧' framing, but does not explicitly name or contrast with any sibling.
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?
Adds a real precondition ('start_date または end_date のいずれかを指定する必要がある（同一会計期間内）'), which tells the agent when the call is valid. However, it gives no guidance on when to use this list tool versus mf_accounting_get_journal or the create/update/delete siblings, so routing remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.