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 only states that it exchanges a code for a token and omits what happens on invalid/expired codes, token lifetime, or error behavior — significant gaps for an OAuth callback step.

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?

A single front-loaded sentence with no wasted words. Compact and clear, though the parenthetical could be integrated more cleanly.

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?

For a single-parameter OAuth callback with no annotations and no output schema, the description covers the core action but lacks flow positioning (which sibling precedes/follows) and any error/token context an agent would need to call it confidently.

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% and the single 'code' parameter is already documented as the authorization code. The description restates this concept but adds no format, source, or validation detail beyond the schema, which matches the baseline.

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 (取得する / obtain) and resource (アクセストークン / access token) driven by the authorization code. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like mf_accounting_auth_start or mf_accounting_refresh_token by name.

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 parenthetical '(OOBモードで認証後に使用)' signals when to use it — after authentication in OOB mode — which is useful implied sequencing. However, it names no explicit alternative or exclusion condition to distinguish it from the other auth-step siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the default flow is OOB mode with the auth code shown on screen, which is non-obvious context. However, it says nothing about what the tool returns (an authorization URL), what happens if the user never authorizes, or how the flow is completed.

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 zero filler, front-loaded with the action and followed immediately by the mode detail. Nothing is wasted.

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?

For a simple zero-required-param auth starter with no output schema and no annotations, the description covers the action and the default mode, which is the minimum viable. It still omits what the caller receives (the auth URL) and how the flow proceeds, leaving the agent to guess at the return contract.

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% and the sole parameter 'wait' is fully documented in the schema, including the note that it is ignored for backward compatibility. The description adds no parameter information, so the baseline 3 applies.

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 states a specific verb and resource: '会計API OAuth認証を開始する' (start OAuth authentication for the accounting API). The '会計' qualifier distinguishes it from the parallel mf_expense_auth_start and the generic mf_auth_start, though it never names those siblings explicitly.

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?

It implies this is the entry point of an auth flow but gives no when-to-use guidance, no prerequisites, and no pointer to the obvious next step (mf_accounting_auth_callback) or to mf_accounting_auth_status for polling. The agent must infer the sequencing 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.

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not state that this is a read-only probe, whether it requires an existing token, whether it triggers any network call to the accounting provider, or what the returned status means (authenticated vs. token expired vs. not configured).

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

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

A single short sentence with the purpose front-loaded and no filler. It is efficiently sized, though its brevity borders on under-specification rather than true conciseness.

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?

For a zero-parameter tool in a crowded auth toolset with no annotations and no output schema, the description should at minimum explain what the status result tells the caller and how it fits the auth flow. None of that is present, so an agent cannot act on the result confidently.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter semantics to add, and the description correctly does not invent any.

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 names a specific verb and resource ('認証状態を確認する' / check auth status) and the mf_accounting_ prefix scopes it to the accounting API, which distinguishes it from the sibling mf_auth_status. It stops short of clarifying its relationship to mf_accounting_auth_start, mf_accounting_auth_callback, and mf_accounting_refresh_token, so sibling differentiation is only implicit.

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?

There is no guidance on when to call this versus the other auth-family tools. An agent facing mf_accounting_auth_start, mf_accounting_auth_callback, mf_accounting_refresh_token, and this tool gets no stated ordering, prerequisites, or exclusion conditions.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses that dry_run=true skips the API call and returns the assembled request body, that idempotency keys must be built caller-side, and that debit/credit totals per branch are validated beforehand. It does not cover authentication requirements, error behavior, or rate limits.

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?

Four tight sentences, front-loaded with the main action and endpoint, then dry_run behavior, then the idempotency convention, then the validation note. No wasted text, though the density makes it slightly terse.

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?

For a complex mutation tool with no annotations and no output schema, the description covers the key behavioral facts: API endpoint, dry_run semantics, idempotency responsibility, and pre-validation. It stops short of describing auth/token requirements or what a successful response looks like, which would be needed for full completeness.

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%, so the schema already documents every parameter thoroughly; baseline is 3. The description adds genuine value by explaining the intended use of memo and tags for idempotency keys, which is semantic guidance beyond the schema's field descriptions.

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 states a specific verb and resource (会計仕訳を新規作成する = create a new accounting journal) and even names the underlying endpoint (POST /api/v3/journals). This distinguishes it clearly from siblings like mf_accounting_update_journal and mf_accounting_list_journals.

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?

Usage context is implied through the dry_run behavior and the instruction to construct idempotency keys caller-side, but it does not explicitly say when to use this tool versus mf_accounting_update_journal or how it fits into a workflow. No explicit when-not guidance is provided.

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

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

With no annotations, the description carries the full burden and does disclose the single most important trait: the deletion is irreversible ('不可逆操作') and is gated behind a mandatory confirmation flag. It omits secondary behavior such as auth/scope requirements or what happens if the journal_id is not found, which keeps it short of 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?

Three compact sentences, front-loaded with the action and endpoint, then the risk, then the required safeguard. No filler and nothing is buried.

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?

For an irreversible, two-parameter mutation with no output schema and no annotations, the description covers action, endpoint, reversibility, and the confirmation gate. It would be complete at 5 with a note on required permissions or post-delete effects, but nothing essential for correct invocation is missing.

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%, so both journal_id and confirm are already documented in the schema, including the 'must be true' constraint. The description restates the confirm requirement without adding format or edge-case meaning, so the baseline 3 applies.

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 ('会計仕訳を削除する') and pins the exact endpoint DELETE /api/v3/journals/{id}. This clearly distinguishes it from the sibling set's create/update/get journal tools, which an agent can pick apart 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?

Gives a clear condition and guardrail: irreversible, so confirm=true must always be supplied to avoid accidental deletion. It does not name an alternative (e.g. update_journal for reversible corrections), but for a delete tool the usage context is effectively unambiguous.

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

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, and it discloses almost nothing. '取得する' implies a read with no side effects, but there is no statement about authentication requirements, what happens for a nonexistent ID, or the shape of the response.

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?

A single, front-loaded sentence with zero padding or redundancy. It is efficient, though arguably under-specified rather than optimally concise.

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?

For a one-parameter read operation with no output schema, the definition is minimally viable: an agent can call it correctly from the name and schema alone. It nonetheless omits return-shape expectations and sibling routing 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.

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

Schema description coverage is 100% and the single parameter journal_id is already documented in the schema as '仕訳ID'. The description adds no format, source, or constraint detail beyond that, so the baseline 3 applies for schema doing the heavy lifting.

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 states a specific verb (取得する = retrieve) and resource (会計仕訳 = accounting journal), so the agent knows it fetches journal entry details. However, it does not differentiate itself from its obvious sibling mf_accounting_list_journals, nor does it make explicit that it returns a single record keyed by ID.

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?

There is no when-to-use guidance at all: no mention of using this over mf_accounting_list_journals for enumeration, no prerequisites, and no error/not-found conditions. The agent must infer usage purely from the name.

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

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

No annotations are provided, so the description must carry the full burden. It states what is retrieved but doesn't mention permissions, caching, or side effects. For a read-only operation with no parameters, this is acceptable but not rich; some tools might require auth, which isn't mentioned.

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 a single, clear sentence with no wasted words. It is front-loaded and directly states the purpose. Perfectly concise.

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?

There is no output schema, so the description should ideally explain what is returned (e.g., structure of business operator info and accounting period). It only names the entities without detailing the return format. For a no-param getter, it is minimally complete but leaves gaps about the output.

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?

The tool has zero parameters, so parameter semantics is not applicable. The schema is empty and fully described. The description correctly reflects that no parameters are needed. Baseline is 4 for 0 params.

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 states a specific verb and resource: retrieving current business operator information and accounting period. It distinguishes itself from siblings like mf_accounting_list_accounts and mf_accounting_list_journals by focusing on a singular current context rather than lists. However, it doesn't explicitly differentiate from every relevant sibling, and the scope of '事業者情報' (business operator information) could overlap with other accounting tools.

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 implies usage as a retrieval tool for current context, but provides no explicit when-to-use guidance, no prerequisites, and no alternatives. With many sibling tools, clearer routing would be expected. It's minimal but adequate for a simple getter.

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

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 says a list is retrieved; it does not state that this is a read-only operation, whether authentication is required, how results are paginated, or what the return shape looks like. 'List' implies a read, but nothing more is disclosed.

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 a single short sentence with zero wasted words and the core action is front-loaded. For a simple list tool this is appropriately sized, though it is arguably too terse to be maximally useful.

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?

The tool is simple (one optional parameter, no output schema, no nested objects), so a brief description is defensible. Still, given the dense cluster of similar 'list' siblings, it should say at least enough to distinguish account retrieval from sub-account, tax, and department retrieval, which it does not.

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% – the single 'available' parameter is already documented in the schema as filtering to valid accounts only. The description adds no meaning beyond that, so the baseline of 3 applies.

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 states a clear verb and resource (取得する + 勘定科目一覧), so the basic operation is understandable. However, it does nothing to distinguish itself from close siblings such as mf_accounting_list_sub_accounts, mf_accounting_list_taxes, and mf_accounting_list_departments, which are all list tools in the same accounting namespace. Without that differentiation a vague purpose score of 3 is warranted.

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?

There is no indication of when to use this tool versus the many sibling list tools (sub-accounts, taxes, departments) or when not to use it. No prerequisites, no context, no alternatives are named. The description offers no routing guidance at all.

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

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

With no annotations and a minimal description, the tool does not disclose behavioral traits such as whether it is read-only, returns paginated results, requires authentication, or any rate limits. The description only restates 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.

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

The description is a single concise sentence. However, it is somewhat vague and could benefit from more specificity without becoming verbose.

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 lack of annotations, output schema, and usage guidance, the description is incomplete for an agent to confidently invoke the tool. It does not mention authentication, return format, or any operational context.

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?

The tool takes zero parameters, so according to the rules, the baseline is 4. The description does not need to explain parameters, and it appropriately avoids unnecessary detail.

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 '部門一覧を取得する' (retrieve a list of departments) states a clear verb (取得/retrieve) and resource (部門一覧/department list). However, it does not distinguish from siblings like mf_accounting_list_sub_accounts or mf_expense_list_depts, leaving ambiguity about which list tool applies.

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?

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent must infer usage context solely from the name.

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

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 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.

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies a read. It says nothing about whether the list is paginated, how large it can be, whether the account_id filter is required for meaningful results, or what happens when no filter is supplied.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though the brevity comes at the cost of substance rather than being paired with it.

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?

For a simple one-optional-parameter list tool with no annotations and no output schema, the minimum viable information is present, but the description omits the read/non-destructive framing and the relationship to the sibling account-listing tool, leaving genuine gaps.

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 account_id fully documented as a filter in the schema itself, so the baseline of 3 applies. The description adds no additional semantics, formatting, or interaction detail beyond the schema.

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 states a clear verb+resource pair (補助科目一覧を取得する = retrieve the sub-account list), so an agent knows exactly what is returned. However, it makes no attempt to distinguish this from the sibling mf_accounting_list_accounts, which an agent could easily confuse with it.

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?

There is no when-to-use guidance, no stated prerequisites, and no mention of alternatives such as mf_accounting_list_accounts. The agent is left to infer that this tool is for 補助科目 rather than top-level 勘定科目.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It does not disclose whether the operation is read-only (though 'list' strongly implies it), whether it requires authentication, the scope of results, or any other behavioral trait. It adds nothing beyond the bare possibility of 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.

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

The description is extremely concise (one short sentence) with no wasted words. It is front-loaded and direct. However, it may be overly terse for a tool in a crowded namespace, trading completeness for brevity.

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 absence of annotations, output schema, and usage guidelines, the description is too sparse to be complete. An agent needs more context to properly invoke this tool, such as authentication requirements, expected return type, or how it relates to sibling tools. The description does not compensate for these gaps.

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%, so the single 'available' parameter is fully documented in the schema. The description does not elaborate on parameter semantics, but the baseline of 3 applies because the schema handles this adequately.

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 states a specific verb ('一覧を取得する' = list/retrieve) and resource ('税区分' = tax categories). However, it does not differentiate itself from the many sibling list tools (e.g., mf_accounting_list_accounts, mf_accounting_list_sub_accounts), leaving the agent to infer from the name alone. The purpose is clear but minimal.

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?

No guidance is provided on when or when not to use this tool, nor are any alternatives mentioned. The description offers no context beyond the bare purpose, which is insufficient for an agent to select this tool over similar list operations.

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

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 via 取得する but never states that the operation is read-only/non-destructive, nor are auth requirements, rate limits, or result size/pagination behavior mentioned for this accounting-scoped 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?

A single compact sentence with no filler and the purpose front-loaded. It is efficient, though extremely terse for the only prose the agent gets.

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?

With no output schema and no annotations, the description is the sole source of information, yet it says nothing about the shape or contents of the returned settings list. For a simple parameterless read this is adequate but leaves clear gaps.

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?

The tool takes zero parameters, so there is nothing to document and no semantics to clarify; the baseline for a parameterless tool applies.

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 (取得する / retrieve) and a specific resource (会計年度設定 / fiscal-year term settings), so the agent knows exactly what is returned. It does not, however, differentiate itself from the many other mf_accounting_list_* siblings beyond the noun, so it stops short of a 5.

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?

There is no guidance on when to use this versus mf_accounting_list_accounts, mf_accounting_list_journals, or the other list tools, nor any prerequisites or exclusions. The agent must infer usage purely from the resource name.

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

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

No annotations provided, so the description carries full burden. It does not disclose pagination behavior, return format, whether results include inactive partners by default, or any constraints. For a list tool with 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.

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

A single concise sentence with no waste. It's appropriately sized for a simple list tool, though front-loading could be slightly improved with an English or explicit scope hint.

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?

For a tool in a crowded namespace with mf_list_partners as an obvious near-sibling, the description fails to distinguish scope, return behavior, or usage context. With no annotations and no output schema, it should do more to help an agent choose correctly.

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% – the single 'available' parameter is fully documented in the schema ('有効な取引先のみ取得する場合 true'). The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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?

Description states a specific verb (取得する/list) and resource (取引先/trade partners) with domain qualifier (会計/accounting). However it does not differentiate from siblings like mf_list_partners or mf_accounting_list_accounts, which follow the same list pattern. The 'accounting' qualifier helps somewhat but the specific scope is not clarified.

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?

No guidance on when to use this tool versus mf_list_partners (which appears to be a similar partner-listing tool). No prerequisites, no mention of the accounting context or when the 'available' filter is appropriate. The description merely states what the tool does, not when to invoke it.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about side effects, whether the refresh token is rotated, persistence of the new token, or failure modes. It adds only the bare operation name.

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?

A single short sentence that front-loads the verb and resource with no filler. It is appropriately sized, though it is so terse that it omits useful context rather than being optimally structured.

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?

For a zero-parameter token-refresh operation with no output schema the description is minimally viable, but it should at least mention when a refresh is needed and what the caller receives in return. The client has enough to call it, but not enough to use it confidently.

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?

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond the schema's empty object. No additional parameter meaning is needed.

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 names a specific verb+resource (refresh the accounting API access token) and the 'accounting' qualifier distinguishes it from the sibling mf_refresh_token and the expense auth family. It stops short of explicitly stating how it differs from those siblings, so it does not reach 5.

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?

No guidance on when this should be invoked (e.g., on 401/expired-token errors, or that it must follow mf_accounting_auth_callback), nor on prerequisites such as an existing refresh token. The agent must infer the trigger condition entirely.

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

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

Without annotations, the description carries the full burden. It discloses key behaviors: dry_run avoids the API call and returns the request body as JSON, and it validates that debits and credits balance per branch beforehand. However, it omits other important traits like required permissions, idempotency, or what happens to existing data not provided (partial update vs full replacement is only implied by the schema).

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

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

The description is a single, dense sentence that front-loads the core action and then adds two important behavioral notes. It avoids redundancy and is appropriately sized for a tool with complex schema. Minor improvement possible by separating concerns for readability.

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 complexity (7 parameters, nested objects, no output schema), the description covers the essential update operation, dry_run preview, and validation. However, it lacks guidance on error handling, required permissions, or side effects (e.g., full replacement of branches). For a mutation tool with no annotations, more context would be beneficial.

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%, so the schema already documents all parameters thoroughly. The description adds only the dry_run behavior and validation note, which are already partially covered in the schema. Baseline 3 applies because the schema does the heavy lifting.

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 it updates an existing journal entry and names the endpoint (PUT /api/v3/journals/{id}). It distinguishes the operation from sibling tools like create_journal or delete_journal. However, it does not explicitly mention alternatives or dependencies beyond the endpoint, making it clear but not maximally differentiated.

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 implies usage by specifying dry_run behavior and validation, but it does not state when to use this tool versus others (e.g., create_journal vs update_journal). There is no explicit when-not-to-use or alternative guidance, leaving the agent to infer context.

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

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 does not disclose whether the exchanged token is persisted for later calls, whether it expires, or what happens on an invalid/expired code, which matters for an OAuth token-exchange step.

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?

One sentence with the core action front-loaded and the usage context in a compact parenthetical. No wasted text, though the parenthetical is doing double duty for missing usage guidance.

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?

For an OAuth flow step in a family of auth siblings with no output schema, the description should state the return value (access token, and whether it is stored) and the flow ordering. It conveys the exchange but leaves the surrounding flow context for the agent to infer.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the required auth code. The description adds no syntax or format detail beyond that, making the baseline of 3 appropriate.

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 states a specific verb+resource: it obtains an access token from an authorization code. That is clear and distinct from the sibling token tools (mf_auth_start, mf_refresh_token), though it never names those siblings explicitly.

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 parenthetical 'used after authentication in OOB mode' implies the calling context, but it does not state the prerequisite chain (that mf_auth_start must precede it) or how it differs from mf_refresh_token, which is the obvious alternative for obtaining tokens.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose meaningfully that the default mode displays an auth code to the user, but omits other key behaviors: that the auth URL is returned immediately without waiting (only in the schema param text), that the user must complete authorization out-of-band, and whether credentials are persisted for later tools.

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 tightly packed sentences with the core action front-loaded and the mode distinction immediately after. No filler, no redundancy with the schema or title.

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?

For a zero-required-parameter auth entry point with no output schema, the description covers the mode mechanics but not the return value (the auth URL the agent must surface to the user) nor the sequencing with mf_auth_status/mf_auth_callback. An agent would have to infer the surrounding flow.

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 a single optional parameter, so the baseline is 3. The description adds no information about the 'wait' parameter (indeed it contradicts nothing but simply ignores it), though it does surface the non-parameter MF_REDIRECT_URI environment variable that governs behavior.

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+resource ('OAuth認証を開始します') and usefully distinguishes the two operating modes (OOB vs callback server). It never distinguishes itself from the sibling auth starters (mf_expense_auth_start, mf_accounting_auth_start) or from mf_auth_status/mf_auth_callback, leaving scope disambiguation to the naming convention alone.

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 explains how to switch modes via MF_REDIRECT_URI (default OOB vs localhost callback), which is genuine configuration guidance. However, it gives no explicit when-to-use ordering relative to mf_auth_status, mf_auth_callback, or mf_refresh_token, the natural companions in an auth flow, so usage is only implied.

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

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 checks authentication status, implying a read-only operation, but doesn't specify what the check entails (e.g., whether it validates tokens, returns user info, or indicates session validity). It also lacks details on permissions, rate limits, or error handling, which are critical for a tool dealing with authentication. The description is too vague to fully inform agent behavior.

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 a single, concise sentence ('認証状態を確認します') that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core function, making it easy for an agent to parse quickly. Every part of the sentence earns its place by delivering essential information.

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 complexity of authentication tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a boolean status, token details, or error messages), which is crucial for an agent to understand the result. Without this, the agent cannot properly handle the tool's output or integrate it into workflows, leaving significant gaps in usability.

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?

The tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required, but it also doesn't compensate for any gaps since none exist.

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 '認証状態を確認します' (checks authentication status) states a clear verb ('checks') and resource ('authentication status'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'mf_auth_start' or 'mf_refresh_token', which are also related to authentication but serve different functions. The purpose is understandable but lacks specificity about what aspect of authentication status is being checked.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether it requires prior authentication steps), exclusions, or how it compares to siblings like 'mf_auth_start' (which likely initiates authentication) or 'mf_refresh_token' (which might renew tokens). Without such context, an agent might struggle to select this tool appropriately in different scenarios.

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

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 conversion action but fails to mention critical details like whether this is a read-only or destructive operation, permission requirements, rate limits, or what the output entails (e.g., creates a new billing record). 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.

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 any unnecessary words. It is front-loaded and appropriately sized for its purpose, 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.

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

Given the complexity of converting a quote to a billing (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits, output format, error handling, or how it differs from sibling tools, making it incomplete for effective agent 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?

The description does not add any parameter-specific information beyond what the input schema provides. Since the schema description coverage is 100% (the 'quote_id' parameter is documented as '見積書ID'), the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.

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 action ('convert') and the resources involved ('quote to billing'), making the purpose understandable. However, it doesn't differentiate this tool from the sibling tool 'mf_create_billing_from_quote', which appears to serve a similar function, preventing 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.

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 'mf_create_billing_from_quote' or 'mf_create_billing'. It lacks context about prerequisites, such as needing a valid quote ID, or any 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.

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

No annotations are provided, so the description carries the full behavioral burden. Beyond 'creates an invoice', it reveals nothing about required authorization, whether creation is idempotent, what happens on missing required fields, or what the response contains (e.g., created ID). For a 9-parameter mutation tool this is minimal disclosure.

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?

It is a single, front-loaded sentence with no filler, which is structurally clean. However, it is so terse that it omits useful context that could have been included at little cost, so it is efficient but under-specified rather than genuinely well-crafted.

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?

For a mutation tool with 9 parameters, 3 required fields, no output schema, and no annotations, the description is far too thin. It does not explain the creation flow, required minimum inputs, or the relationship to sibling tools like mf_create_billing_from_quote, leaving significant gaps for the agent.

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%, so every parameter (partner_id, billing_date, items, department_id, etc.) is already documented in the schema, including enum values for excise and date formats. The description adds no parameter-level meaning beyond what the schema supplies, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (作成します = creates) and resource (請求書 = invoice/billing), plus a qualifier (インボイス制度対応 = qualified-invoice-system compliant). It is clear what the tool does, but it does not differentiate itself from the closely named sibling mf_create_billing_from_quote, so an agent cannot tell from the description alone which creation path to choose.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as mf_create_billing_from_quote or mf_update_billing. The description states only the outcome, leaving the agent to infer when this tool is appropriate.

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

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 creates an invoice from a quote but doesn't mention whether this is a mutating operation, what permissions are required, whether the quote is modified, what happens on failure, or what the response contains. 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.

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 core functionality.

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?

For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what side effects occur, or how it differs from similar sibling tools. The 100% schema coverage helps with parameters, but overall context for proper tool selection and invocation is lacking.

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%, providing clear documentation for all 7 parameters. The description doesn't add any additional parameter semantics beyond what's in the schema, but the schema adequately covers parameter purposes and formats. The baseline score of 3 reflects that the schema does the heavy lifting.

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 action ('作成します' - creates) and resource ('請求書' - invoice) from a source ('見積書から' - from quote). It's specific about the transformation process but doesn't explicitly differentiate from sibling tools like 'mf_convert_quote_to_billing' which appears to serve a similar purpose.

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?

No guidance is provided about when to use this tool versus alternatives like 'mf_convert_quote_to_billing' or 'mf_create_billing'. The description only states what the tool does without indicating appropriate contexts, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries full burden and delivers crucial behavioral information: it explicitly states the tool is non-functional ('機能しません'), explains why (v3 API doesn't support the endpoint), and provides workaround guidance. This goes well beyond what a typical description would cover, addressing operational status and limitations.

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 appropriately concise with two sentences that each serve distinct purposes: the first states the intended function, the second explains the current limitation and alternative. No wasted words, though the technical detail about v3 API could be slightly more front-loaded for immediate clarity.

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's non-functional status, the description provides complete contextual information: it explains what the tool would do if functional, why it doesn't work, and what to do instead. With no output schema and no annotations, this description adequately covers the essential context an agent needs to understand this tool's special situation.

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%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline 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.

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

The description clearly states the tool's purpose: '見積書から納品書を作成します' (creates a delivery slip from a quote). It specifies the resource (delivery slip) and source (quote), but doesn't distinguish from sibling tools like mf_convert_quote_to_billing or mf_create_billing_from_quote beyond mentioning it's for delivery slips specifically.

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 explicit usage guidance: it states the tool is currently non-functional due to v3 API limitations ('このツールは機能しません'), specifies when NOT to use it (for v3 API), and provides an alternative action ('納品書はマネーフォワードのWebUIから作成してください'). This is comprehensive guidance for both usage and alternatives.

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

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

With no annotations provided, the description carries the full behavioral burden and delivers almost none. It implies a mutating create, but says nothing about required permissions, auth flows (the sibling set has explicit auth tools), side effects, error behavior, or what the response contains. Only the 'invoice-system compliant' hint touches on behavior.

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?

A single front-loaded sentence with zero filler, which is structurally clean. But for a 7-parameter nested create tool it is under-specified rather than genuinely concise, so it earns only a middling score.

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?

For a complex create operation with 7 parameters, nested line items, no annotations and no output schema, one sentence is far too thin. The rich schema (especially department_id and the tax-type enum) is good, but the description omits prerequisites, required-field emphasis, and any notion of success/failure behavior an agent would need.

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%, so the schema already documents all seven parameters, including the detailed department_id validation logic and the excise enum. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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 gives a specific verb (作成/create) and resource (見積書/quote), and adds a qualifier — invoice-system (インボイス制度) compliant — that goes slightly beyond the tool name. However, it offers no scope details, no fields, and no differentiation from the many sibling quote tools (mf_update_quote, mf_get_quote, mf_list_quotes, mf_convert_quote_to_billing); the verb+resource is largely recoverable from the name alone.

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?

There is no when-to-use guidance, no prerequisites (e.g. that partner_id must reference an existing partner obtainable via mf_list_partners, or that items are mandatory), and no mention of alternatives such as mf_update_quote for editing an existing quote. The agent gets no routing help.

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

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

With no annotations, the description carries the behavioral burden and does disclose the critical trait that the operation is irreversible ('元に戻せない'), which is exactly the destructive-behavior fact an agent must know. It omits auth/permission requirements and any cascade or side-effect detail, but the irreversibility disclosure is the highest-value item and it is present.

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 tight sentences: the action comes first, followed immediately by the safety-critical warning. Zero filler and the danger signal is front-loaded where the agent will read it.

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?

For a single-parameter, no-output-schema delete tool, the description covers the action, the irreversibility, and the required confirmation step, which is sufficient to invoke it correctly. Remaining gaps (auth requirements, cascade effects) are minor.

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% (billing_id documented as 請求書ID), so the schema already carries all parameter meaning. The description adds no syntax, format, or sourcing detail about billing_id, so baseline 3 is appropriate.

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 ('請求書を削除します' = deletes an invoice) and the exact resource, which distinguishes it cleanly from mf_update_billing, mf_get_billing, and mf_create_billing in the sibling set. An agent can identify the operation without opening the schema.

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?

Gives an explicit precondition: '実行前に必ずユーザーへ確認してください' (always confirm with the user before executing), which tells the agent when/how to invoke it responsibly. It does not name alternatives (e.g., updating vs deleting, or a soft-delete path), so it stops short of full routing guidance.

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

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 PDF URL) but doesn't describe traits like whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or the format of the returned URL. 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.

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 zero waste, making it easy to parse quickly.

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, no output schema, and a simple input schema, the description is incomplete. It lacks details on behavioral traits (e.g., safety, authentication), output format, or error handling. For a tool that retrieves URLs, more context on what the URL represents (e.g., temporary, downloadable) would be helpful, but it's missing.

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?

The input schema has 100% description coverage (billing_id is documented as '請求書ID' meaning 'invoice ID'), so the baseline is 3. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. It compensates minimally by implying the parameter is needed but doesn't enhance semantics.

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: '請求書のPDF URLを取得します' translates to 'Get the PDF URL of an invoice.' This specifies the verb (get/retrieve) and resource (invoice PDF URL). It distinguishes from siblings like mf_get_billing (which likely returns billing data) and mf_download_quote_pdf (which handles quotes), but doesn't explicitly differentiate from other PDF-related tools beyond the resource type.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid billing_id), exclusions, or comparisons to siblings like mf_get_billing (which might return metadata) or mf_list_billings (for listing). Usage is implied by the purpose but lacks explicit context.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states what the tool does but doesn't disclose whether this is a read-only operation, if it requires authentication, what format the URL returns in, or any rate limits. For a tool that presumably accesses external resources, this is inadequate disclosure.

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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

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?

For a tool that retrieves PDF URLs (potentially involving external resources and authentication), the description is insufficient. With no annotations and no output schema, it doesn't explain what the return value looks like (e.g., URL format, expiration), authentication requirements, or error conditions. The description alone 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.

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

Schema description coverage is 100%, so the single parameter 'quote_id' is fully documented in the schema. The description doesn't add any additional parameter context 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.

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 ('見積書のPDF URL' - quote PDF URL), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling 'mf_download_billing_pdf' which handles billing PDFs, but the distinction is reasonably implied through the resource name.

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 no guidance on when to use this tool versus alternatives like 'mf_get_quote' (which might return quote data without PDF) or 'mf_download_billing_pdf' (for billing documents). There's no mention of prerequisites, such as needing an existing quote ID from another operation.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether approval is irreversible, what permissions/scope are required, whether a report can be re-approved, or what state change results. 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.

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

A single short sentence with no filler, and the verb+resource are front-loaded. It is terse but not padded.

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?

For a mutation tool with no annotations and no output schema, the description should disclose approval prerequisites, irreversibility, and required auth scope; it provides none of these, leaving the agent to guess at the workflow.

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 both office_id (事業者ID) and report_id (経費申請ID) documented in the schema, so the baseline is 3. The description adds no further parameter meaning, but the schema already does the work.

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 states a specific verb (承認します / approve) and resource (経費申請 / expense report), so the agent knows exactly what operation is performed. However, it does not differentiate from the sibling mf_expense_disapprove_report or mention the report-listing/retrieval siblings it depends on.

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?

There is no guidance on when to use this tool versus mf_expense_disapprove_report, nor any prerequisite (e.g., that the report must exist, be pending, or be fetched first via mf_expense_get_report). The agent must infer the approval workflow entirely.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only says an access token is obtained. It omits whether the authorization code is single-use, whether the token is cached/persisted, what happens on an expired or reused code, and what the failure response looks like.

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?

A single front-loaded sentence with the action first and the usage condition in parentheses; nothing is wasted. It is terse to the point of under-specifying, but there is no filler or repetition.

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?

For a simple one-parameter token-exchange tool with no output schema, the description does state the return (access token) and the trigger condition (OOB mode). It leaves out the prerequisite chain (mf_expense_auth_start) and any error or token-lifetime behavior, so an agent would still need to infer how this fits into the auth sequence.

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 a single required 'code' parameter that the schema already documents as '認可後に取得した認証コード'. The description's mention of 認証コード restates the schema without adding format, source, or expiration semantics, so baseline 3 applies.

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?

Description states a specific verb+resource pair (認証コードを使用してアクセストークンを取得します) scoped to the expense API, which correctly separates it from the sibling mf_auth_callback and mf_accounting_auth_callback that serve other APIs. It never explicitly names those siblings, so differentiation is implied by the 経費 prefix rather than stated.

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 parenthetical '(OOBモードで認証後に使用)' gives a clear usage condition: this is the step to call after an out-of-band authorization flow. No when-not guidance and no reference to the preceding mf_expense_auth_start / mf_expense_auth_status tools, so the workflow position is only partially pinned down.

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

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 one important behavioral trait (default OOB mode where the auth code is shown on screen), which is useful. But it omits other relevant behavior: that the auth URL is returned immediately, that the user must authorize in a browser, that credentials/tokens result, and any requirement to call status/callback afterward.

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?

One short sentence stating the action plus one clarifying sentence on the default mode. Front-loaded and free of filler, though the second sentence is parenthetical rather than adding net-new decision guidance.

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?

For a no-arg auth-flow entry point with no annotations and no output schema, the description gives the core action and the default mode, but does not describe the return value (the auth URL) or the follow-up flow steps. It is minimally viable but leaves the agent to infer the rest of the OAuth sequence from sibling names.

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?

Only one parameter, and the schema description already fully documents it (100% coverage), including the backward-compat rationale for ignoring `wait`. The description adds nothing about the parameter, so the baseline of 3 applies.

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 (start OAuth authentication for the 経費/expense API), which distinguishes it from the sibling auth tools for accounting (mf_accounting_auth_start) and the legacy mf_auth_start. It does not explicitly call out those alternatives, but the product-scoped naming plus verb is unambiguous.

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?

Implied usage is clear from the name and description (this is the entry point of an OAuth flow, ahead of the status/callback siblings). However, there is no explicit when-to-use guidance, no mention of what to do after receiving the URL, and no reference to the sibling mf_expense_auth_status/mf_expense_auth_callback that complete the flow.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it adds essentially nothing beyond the name: it does not say whether the call is read-only, what statuses can be returned (authenticated vs. expired vs. absent), whether it triggers or refreshes anything, or whether it has side effects. For a no-annotation tool this is a meaningful disclosure gap, though the name itself signals a passive status check.

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?

A single short sentence with zero filler, and the core action (status check) is front-loaded. Nothing wasteful is present.

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?

There is no output schema and no annotations, so the description is the only source of information. It confirms the tool's subject but leaves the returned status vocabulary and the correct next step on failure unspecified, which is barely adequate for a minimal status-check tool.

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?

The tool takes zero parameters, so the schema is trivially complete and no parameter meaning needs to be conveyed. Baseline for a parameterless tool is 4.

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 states a specific verb and resource: checking the authentication status of the expense API (経費API認証状態を確認します). This clearly distinguishes it from the generic mf_auth_status and from mf_accounting_auth_status via the '経費' (expense) qualifier. It lacks any explicit sibling differentiation statement, but the naming/scope makes the purpose unambiguous.

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?

Usage is implied: an agent would call this to verify whether expense API credentials are valid, presumably before invoking expense operations or after mf_expense_auth_start/mf_expense_auth_callback. However, the description names no prerequisites, no follow-up action when unauthenticated, and no alternative tool (e.g., mf_expense_auth_start) to route to. This is implied rather than stated guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it says only that a record is created. It does not disclose side effects, idempotency, required permissions, validation rules, or what the response contains for this mutation.

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 single short sentence is front-loaded and wastes no words, but it is so minimal that its conciseness reflects under-specification rather than efficient communication.

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?

For a 9-parameter mutation tool with no annotations and no output schema, a one-line description is inadequate; it omits required-field dependencies, ID sourcing, and any behavioral context an agent would need to invoke it correctly.

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%, so all nine parameters (office_id, value, recognized_at, etc.) are already documented in the schema with Japanese labels. The description adds no additional meaning such as format constraints or ID sourcing, so the baseline 3 applies.

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 states a specific verb (作成) and resource (経費明細), so the agent knows this creates an expense line item. However, it offers no differentiation from siblings like mf_expense_update_transaction or mf_expense_upload_receipt beyond the basic create verb.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g., which office/dept/科目 IDs must exist first), and no mention of auth requirements despite the presence of mf_expense_auth_start siblings. Usage must be entirely inferred from the name.

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

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

With no annotations provided, the description carries the full burden and delivers a critical behavioral warning: the operation is irreversible with no undo in the connector (元に戻せません). This is exactly the kind of information an agent needs before a destructive call. It does not, however, mention authorization requirements or rate limits.

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 sentences with no waste. The first states the action, the second leads with the irreversibility warning in bold and follows with the confirmation workflow. Front-loaded and efficient.

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?

For a destructive delete tool with no annotations and no output schema, the description covers the essential behavioral risk (irreversibility) and the required confirmation workflow. It could be strengthened with permission requirements or expected failure modes, but it is largely complete for a two-parameter delete.

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%, so both office_id and transaction_id are already documented in the schema (事業者ID, 経費明細ID). The description adds no param-specific syntax or format details beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

Stated with a specific verb and resource (経費明細を削除します), which clearly distinguishes it from sibling tools like mf_expense_update_transaction and mf_expense_create_transaction. An agent can immediately identify this as the delete operation for expense transactions.

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?

Explicitly instructs the agent to present the target's ID, date, amount, and summary to the user for confirmation before executing, which is clear when-to-use guidance. However, it does not name alternative tools or explicitly say when not to use it (e.g., use update instead for modifications).

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

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

With no annotations, the description carries the full burden of behavioral disclosure for a mutating operation. It does not say whether the rejection is reversible, what status the report moves to, whether a reason/comment is accepted, or what permissions are required.

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?

One short, front-loaded sentence with zero filler and no redundancy. It is not bloated, though the terseness comes at the cost of the missing context noted elsewhere rather than being a model of efficient completeness.

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?

For a destructive-ish state-changing tool with no annotations, no output schema, and no explanation of side effects or prerequisites, the definition is too thin. An agent has no information about consequences, idempotency, or error conditions.

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%, so both parameters (office_id, report_id) are already documented in the schema. The description adds no format, constraint, or sourcing detail beyond what the schema provides, so the baseline 3 applies.

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 states a specific verb and resource: '経費申請を却下します' (reject the expense report). It is unambiguous about the action, but it never distinguishes itself from the obvious sibling mf_expense_approve_report, which shares the same resource and inverse operation.

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?

There is no guidance on when to use this tool versus mf_expense_approve_report, nor any precondition (e.g., the report must be in a pending state). The agent must infer usage entirely from the tool name.

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

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 fetch via 取得, but says nothing about required authentication state, permissions, error behavior, or pagination/response shape for a detail endpoint that returns line items.

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?

A single, front-loaded sentence with no redundant or filler text. It is efficient, though very sparse for a tool whose behavior is otherwise undocumented.

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?

With only two required scalar parameters and no output schema, the description is minimally adequate: an agent can call it correctly, but the lack of any mention of returned content (header plus line items is only hinted at) or auth prerequisites leaves gaps for a tool with zero annotations.

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 both office_id (事業者ID) and report_id (経費申請ID) documented, so the baseline is 3. The description adds no meaning beyond the schema, e.g. where report_id comes from (mf_expense_list_reports).

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 (経費申請の詳細と明細), distinguishing the get-report operation from expense transactions. However, it does not name or contrast itself with the obvious sibling mf_expense_list_reports, so an agent must infer which one fetches a single report.

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?

There is no statement of when to use this tool versus mf_expense_list_reports or mf_expense_get_transaction, and no prerequisites (e.g. that expense OAuth must be completed via mf_expense_auth_start/callback). Usage context is left entirely to inference from the name.

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

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

アノテーションが提供されておらず、説明文が挙動開示の責任を負う必要があるが、認証要件・レート制限・該当IDが存在しない場合の挙動・返却内容のいずれにも触れていない。読み取り操作であることは動詞「取得」から推測できるが、それ以上の情報はない。

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?

一文のみで無駄がなく、動詞と対象が先頭に置かれている。ただし情報量が最小限にとどまり、簡潔さというよりは不足に近い面もある。

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?

2 パラメータの単純な参照系ツールで、スキーマが両パラメータを完全に文書化しており、出力スキーマは存在しない。そのため返却値の説明は必須ではないが、認証要件やエラー時の挙動についての言及がなく、完全とは言えない。

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?

スキーマ記述カバレッジが 100% で、office_id（事業者ID）と transaction_id（経費明細ID）の両方がスキーマ側で説明されている。説明文はパラメータについて何も追加しておらず、スキーマが役割を果たしているため基準値 3 が妥当。

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?

「経費明細の詳細を取得します」は明確な動詞（取得）と対象リソース（経費明細の詳細）を示しており、読み取り専用の単一項目取得であることが分かる。ただし mf_expense_list_transactions との違い（単一取得 vs 一覧）を明示的には述べておらず、兄弟ツールとの差別化は名前と「詳細」という語に依存している。

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?

いつ使うべきか、どのような前提条件（認証・office_id の取得元など）が必要かについての記述が一切ない。兄弟ツールである mf_expense_list_transactions や mf_expense_get_report との使い分けの指針も示されていない。

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

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

No annotations are supplied, so the description carries the entire burden of behavioral disclosure, and it says nothing about authentication requirements, the read-only nature of the call, or that results are scoped to a single office. For a bare listing tool the gap is small, but nothing beyond the title-level statement is provided.

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?

A single short sentence with no wasted words, which is appropriately front-loaded. It is, however, under-specified rather than genuinely concise, so it cannot score higher.

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?

For a one-parameter read tool with no output schema and no annotations, the description is minimally viable: the agent can infer the return type from the name. It does not explain the office-scoped nature of the results or how it relates to the accounting-namespace equivalent, which is the main thing an agent would need here.

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% (office_id is documented as 事業者ID), so the schema already carries the parameter meaning and the baseline of 3 applies. The description adds no additional context such as what happens if the office_id is invalid or whether it filters the returned departments.

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 ("部門一覧を取得します" – retrieve the department list), so an agent knows exactly what the tool returns. However, it does nothing to distinguish itself from the very similar sibling mf_accounting_list_departments, so sibling differentiation is absent.

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?

There is no indication of when this tool should be used versus alternatives such as mf_accounting_list_departments or mf_expense_list_offices, and no mention of preconditions (e.g., prior authentication via mf_expense_auth_start). The description only asserts what it does, leaving routing to the agent.

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

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

No annotations are provided, so the description must carry the full burden. It states that it retrieves a list but does not disclose any behavioral traits such as required permissions, rate limits, pagination, or whether the list is filtered by office. The sole parameter office_id is required, but the description does not explain its role beyond the schema.

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

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

The description is a single concise sentence that front-loads the action and resource. It is appropriately sized, though it lacks any additional structure or context.

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 complexity (a list tool with one required parameter) and the lack of annotations and output schema, the description is under-specified. It does not explain the return format, whether pagination is needed, or how the office_id scopes the results.

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%, so the schema already documents the office_id parameter as '事業者ID'. The description adds no parameter meaning beyond what the schema provides, but with high schema coverage, a baseline of 3 is appropriate.

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 '経費科目一覧を取得します' (retrieve expense category list) states a clear verb and resource, but it does not distinguish this tool from sibling tools like mf_expense_list_depts or mf_accounting_list_accounts. The name includes '_ex_items', which might be a subclass of items, but the description doesn't clarify how this differs from other list operations.

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?

There is no guidance on when to use this tool versus alternatives such as mf_expense_list_depts or mf_list_items. The description provides no context about the scenario or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about pagination, result ordering, scope of the list, or authentication needs. It conveys only that a list is returned, which is already implied by the name.

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?

A single compact sentence with no filler, and the purpose is front-loaded. It is efficient, though almost too terse to be informative.

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?

With no output schema, no annotations, and no parameters, the description should explain what a caller gets back and any scoping or auth constraints. It does none of this, leaving the agent with only the tool name to work from.

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?

The tool takes zero parameters, so the baseline is 4. There is no parameter semantics for the description to add, and the empty schema is self-consistent with a no-argument list tool.

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 states a clear verb and resource in Japanese: retrieving a list of 事業者 (business operators/offices). This is specific enough to distinguish a list operation, but it does not differentiate this tool from nearby siblings such as mf_expense_list_depts, mf_expense_list_projects, or mf_accounting_get_office.

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?

There is no guidance on when to use this tool versus the many sibling list tools, nor any stated preconditions (e.g., authentication requirement). The agent must infer usage purely from the name.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about auth requirements, scoping by office, pagination, or ordering. For a read-list tool the safety burden is light, but the behavioral disclosure is essentially absent.

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?

A single short sentence with no filler and the resource front-loaded. It is efficient, though sparse to the point of under-specification.

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?

For a simple one-parameter list tool this is minimally adequate, but with no output schema and no annotations the description should at least hint at what is returned (fields, pagination). It leaves the agent without return-shape context.

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% (the single office_id parameter is described as 事業者ID), so the schema already documents the parameter. The description adds no filtering or format semantics beyond it, which is the expected baseline when the schema does the work.

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 states a clear verb (取得します) and resource (プロジェクト一覧), so an agent knows it retrieves a list of projects. It distinguishes itself implicitly from siblings like mf_expense_list_offices and mf_expense_list_depts by resource name, but adds no further differentiation or scope detail.

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?

There is no guidance on when to call this tool versus the many sibling list tools, no prerequisites, and no exclusions. Usage is only inferable from the resource name.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it only states the resource and the 'own' scope. It says nothing about pagination behavior, ordering, default page size, or whether results are filtered by status/period, all of which matter for a list endpoint.

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?

A single, front-loaded sentence with no wasted words. It is appropriately terse, though it is arguably too short to carry behavioral context.

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?

For a low-complexity list tool with a fully documented schema and no output schema, the description is minimally adequate. It leaves return fields, pagination semantics, and scope limits unexplained, which an agent must guess at.

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% (page, limit with max 1000, office_id), so the schema already documents every parameter. The description adds no syntax, defaults, or format detail beyond what the schema provides, making the baseline 3 appropriate.

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 gives a specific verb (取得/list) and resource (自分の経費申請 / own expense reports), so an agent knows it retrieves a collection rather than a single report. It does not explicitly differentiate itself from siblings such as mf_expense_get_report or mf_expense_list_transactions, but the scope is unambiguous.

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

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

There is no guidance on when to use this list versus mf_expense_get_report for a single item, nor any mention of prerequisites such as authentication or office context. Usage must be inferred entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose pagination behavior (important given page/limit parameters), default sorting, maximum result limits, or required permissions. It only states the basic retrieval action with no additional 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.

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

The description is a single concise sentence with no wasted words, appropriately front-loaded. However, its brevity leaves room for additional helpful context without becoming verbose, and it lacks any routing or behavioral detail.

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?

With no annotations, no output schema, and six parameters (though schema coverage is high), the description is too sparse. It does not explain return format, pagination behavior, or relationship to sibling tools, leaving significant gaps for an agent to operate correctly in a complex expense API.

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%, so the schema already documents all six parameters including pagination, date range, and is_reported filtering. The description adds no parameter-level meaning beyond what the schema provides; baseline 3 applies when the schema fully handles parameter documentation.

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 clear verb+resource: '自分の経費明細一覧を取得します' (retrieve one's own expense transaction list). This distinguishes it from mf_expense_get_transaction (single transaction) and mf_expense_list_reports (reports) by its 'list' plural scope, though it does not explicitly name siblings.

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?

No when-to-use guidance is provided. The description does not mention alternatives like mf_expense_get_transaction for single records or mf_expense_list_reports, nor does it explain filtering scenarios such as the is_reported parameter. Agents must infer usage context solely from the name and schema.

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

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 implies a mutation via 更新 and says nothing about partial vs full update semantics, permission/auth requirements, reversibility, or what happens to fields omitted from the call.

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?

A single, front-loaded sentence with zero filler or repetition. It is efficient, though its brevity borders on under-specification rather than optimal conciseness.

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?

For a 10-parameter mutation tool with no annotations and no output schema, the description is far too thin. It omits which fields are updatable, whether updates are partial or whole-record, and any indication of the result of the operation.

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 every one of the 10 parameters (memo, value, remark, dept_id, ex_item_id, project_id, dr_excise_id, recognized_at, etc.) documented in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.

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 (経費明細), so an agent knows this mutates an expense line item. However it does nothing to distinguish itself from siblings like mf_expense_create_transaction or mf_expense_delete_transaction beyond the verb.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. that office_id and transaction_id must reference an existing record), and no routing to alternatives such as create/delete/get. The agent must infer all 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.

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

With no annotations, the description carries the full burden and does so unusually well: it discloses the non-obvious side effect that an upload may auto-create an expense entry via OCR, warns about double-counting, and states that credentials-directory files are rejected. It does not mention authentication requirements or file size limits, leaving a gap 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.

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

The action is front-loaded, followed immediately by the highest-risk warning in bold. Every sentence adds a distinct piece of information (side effect, sibling interaction, extensions, credential-dir rejection) with no filler.

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?

For a two-parameter tool with no output schema and a surprising mutation side effect, the description covers the critical behaviours (auto-creation, double-count risk, file constraints) well. Authentication prerequisites and any return-format detail are the only meaningful omissions.

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 meaning on top of the schema by enumerating the exact allowed extensions (jpg/jpeg/png/gif/heic/heif/pdf) that constrain the file_path parameter. office_id remains undocumented beyond the schema.

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 ('レシート画像・PDF をアップロードします') and immediately distinguishes itself from the sibling mf_expense_create_transaction by explaining the OCR auto-drafting behavior. An agent can identify the tool's role without opening the schema.

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?

Explicitly names the condition and the alternative: if you intend attachment-only but also call mf_expense_create_transaction, you risk double-counting, so verify the resulting '作成された明細数'. This is a concrete when/when-not routing instruction, not an implied one.

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

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 information, implying it's a read-only operation, but doesn't clarify aspects like authentication requirements, error handling (e.g., invalid billing_id), rate limits, or what '詳細情報' (detailed information) includes. 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.

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

The description is a single, efficient sentence in Japanese: '請求書の詳細情報を取得します'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple retrieval tool. Every part of the sentence directly 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.

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

Given the complexity (a retrieval tool with no output schema and no annotations), the description is incomplete. It doesn't explain what '詳細情報' includes (e.g., fields returned), error conditions, or authentication needs. Without annotations or an output schema, the description should provide more context to help the agent use the tool effectively, but it falls short.

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?

The input schema has 100% description coverage, with the billing_id parameter documented as '請求書ID' (invoice ID). The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily supplement the schema.

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: '請求書の詳細情報を取得します' (retrieves detailed information of an invoice). It specifies the verb '取得します' (retrieves) and the resource '請求書の詳細情報' (invoice details). However, it doesn't explicitly differentiate from sibling tools like mf_list_billings (which lists multiple invoices) or mf_get_quote (which retrieves quote details), though the resource specificity helps somewhat.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a billing_id), contrast with mf_list_billings for listing multiple invoices, or specify use cases like viewing specific invoice details after listing. Without such context, the agent must infer usage from the tool name and schema alone.

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

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 that it retrieves detailed information, without mentioning any behavioral traits such as read-only nature (implied by 'get'), potential authentication needs, rate limits, error handling, or what 'detailed information' entails. For a tool with no annotations, 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.

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

The description is a single, efficient sentence in Japanese ('品目の詳細情報を取得します'), which is appropriately concise and front-loaded with the core purpose. There's no wasted text, making it easy to parse, 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.

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

Given the tool's complexity (a read operation with one parameter), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral context. For a tool in this context, more information is needed to adequately guide an AI agent.

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?

The input schema has 100% description coverage (the 'item_id' parameter is described as '品目ID'), so the schema already documents the parameter fully. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to heavily.

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 states the tool's purpose as '品目の詳細情報を取得します' (retrieves detailed information of an item), which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'mf_list_items' (which likely lists items rather than getting details of a specific one), making it vague about differentiation. The purpose is understandable but lacks sibling context.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'mf_get_item' (for a specific item's details) compared to 'mf_list_items' (for listing items) or other sibling tools, nor does it specify any prerequisites or exclusions. This leaves usage entirely implied from the tool name.

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

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's a read operation ('取得します' - get), implying it's likely safe and non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., fields, format). This leaves significant gaps for an agent.

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 a single, efficient sentence in Japanese, front-loaded with the core action. It's appropriately sized for a simple tool, though it could be more informative without losing conciseness.

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 has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't cover what 'detailed information' means (output), authentication needs, or usage context, making it inadequate for an agent to fully understand the tool's behavior and application.

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?

The description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage with a clear description for 'partner_id' ('取引先ID' - partner ID), so the baseline is 3. The tool description doesn't explain the parameter's role or constraints (e.g., format, source).

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 '取引先の詳細情報を取得します' (Get detailed information of a partner) clearly states the verb ('取得します' - get) and resource ('取引先' - partner), but it's vague about what 'detailed information' entails. It doesn't distinguish from sibling tools like 'mf_list_partners' (which likely lists partners) or 'mf_get_billing' (which gets billing details).

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), differentiate from 'mf_list_partners' (for listing vs. getting details), or specify use cases (e.g., retrieving a specific partner by ID).

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

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 '取得します' (retrieve) implies a read-only operation, the description doesn't explicitly state whether this requires authentication, what permissions are needed, whether there are rate limits, or what format the response takes. For a tool with no annotation coverage, this is inadequate 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.

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

The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place.

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 that this is a retrieval tool with no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't help the agent understand what '詳細情報' (detailed information) includes, how this differs from mf_list_quotes, or what authentication/authorization is required. The description should provide more context for proper tool selection and usage.

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?

The schema has 100% description coverage with a clear parameter description ('見積書ID' - quote ID). 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.

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: retrieving detailed information about a quote/estimate. It uses a specific verb ('取得します' - retrieve/get) and resource ('見積書' - quote/estimate). However, it doesn't distinguish this from sibling tools like mf_list_quotes or mf_get_billing, 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.

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 related tools (mf_list_quotes, mf_get_billing, mf_get_item, mf_get_partner) that likely serve similar purposes for different resources, but the description doesn't help the agent choose between them. No explicit when/when-not instructions are provided.

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

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 verb '取得します' implies a read-only operation, but the description says nothing about permissions, pagination, rate limits, return format, or side effects, leaving the agent with very little 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.

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

The description consists of two short, front-loaded sentences with no wasted words. The purpose is stated first and the filtering capability second, making it efficient.

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 11 parameters, no annotations, and no output schema, the description is too thin. It omits important context such as pagination behavior, the fact that q overrides other filters (noted only in the schema), the default range key, and the read-only nature of the operation. An agent would need to rely almost entirely on the schema and name to use the tool correctly.

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%, so all 11 parameters are already fully documented in the input schema. The description adds only a generic note that filtering by partner or period is possible, which does not add meaning beyond what the schema provides. Baseline 3 is appropriate.

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 states a specific verb and resource: '請求書一覧を取得します' (retrieve billing list). It distinguishes this list operation from the singular sibling mf_get_billing and from create/update/delete tools by naming the resource and the list form. However, it does not explicitly name alternatives or differentiate itself from other list tools such as mf_list_quotes.

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 only notes that filtering by partner or period is possible ('取引先や期間で絞り込み可能です'). It gives no guidance on when to use this tool instead of alternatives like mf_get_billing (single record) or mf_create_billing, nor does it state any prerequisites or exclusions.

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

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 filtering capability but doesn't describe pagination behavior (implied by page/per_page parameters), rate limits, authentication requirements, error conditions, or what the return format looks like. For a list retrieval tool with zero annotation coverage, this leaves significant 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.

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

The description is appropriately concise with two clear sentences that communicate the core functionality. The first sentence states the primary purpose, and the second adds important filtering capability. There's no wasted verbiage or redundant information.

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?

For a list retrieval tool with 3 parameters and no output schema, the description is insufficiently complete. It doesn't explain what an 'item' represents in this context, what fields are returned, how pagination works, or any authentication requirements. The lack of output schema means the description should ideally provide some indication of return format, but it doesn't.

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%, so the schema already documents all three parameters (page, per_page, q) with their types and descriptions. The description adds minimal value beyond the schema by mentioning keyword filtering ('検索キーワードで絞り込み可能です'), which aligns with the 'q' parameter. However, it doesn't provide additional context about parameter interactions or constraints beyond what's in the schema.

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 verb ('取得します' - get/retrieve) and resource ('品目一覧' - item list), making the purpose immediately understandable. It also mentions filtering capability ('検索キーワードで絞り込み可能です'), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like mf_get_item, which appears to retrieve a single item rather than a list.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to use mf_list_items versus mf_get_item (for single item retrieval) or other list tools like mf_list_billings, mf_list_partners, or mf_list_quotes. There's no context about prerequisites, typical use cases, or limitations.

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

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 mentions the filtering capability but doesn't describe important behavioral aspects: whether this is a read-only operation, what the return format looks like (list structure), pagination behavior (implied by parameters but not explained), authentication requirements, rate limits, or error conditions. For a list 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.

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

The description is appropriately concise with just two sentences that directly state the tool's purpose and main capability. There's no wasted verbiage or unnecessary information. However, it could be slightly more front-loaded by explicitly stating it's a list/retrieval operation first.

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, no output schema, and a list operation with pagination parameters, the description is incomplete. It doesn't explain what the tool returns (partner list structure), how pagination works, authentication requirements, or error handling. For a tool that likely returns structured data with multiple records, this leaves significant gaps for an AI agent to understand how to properly use and interpret results.

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%, so the schema already documents all three parameters (page, per_page, q) with their descriptions. The description mentions filtering ('検索キーワードで絞り込み可能です') which corresponds to the 'q' parameter, but adds no additional semantic context beyond what's in the schema. 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.

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 ('取引先一覧' - partner list), making the purpose immediately understandable. It also mentions filtering capability ('検索キーワードで絞り込み可能です'), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like mf_get_partner or other list tools (mf_list_billings, mf_list_items, mf_list_quotes).

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to use mf_list_partners versus mf_get_partner (for individual partner details), nor does it provide context about prerequisites, limitations, or appropriate use cases. The only usage hint is the filtering capability, but this doesn't constitute proper guidance.

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

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 filtering capabilities but lacks critical details: it doesn't specify if this is a read-only operation, whether it requires authentication, what the return format is (e.g., paginated list), or any rate limits. For a list tool with 7 parameters, 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.

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

The description is a single, efficient sentence in Japanese that front-loads the core purpose and briefly mentions filtering capabilities. There's no wasted text, and it's appropriately sized for a list tool with good schema documentation.

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's complexity (7 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and hints at filtering, but lacks details on authentication, return format, pagination behavior, or error handling. With no output schema, the agent must infer the response structure, making the description incomplete for full contextual understanding.

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%, so the schema fully documents all 7 parameters with descriptions and an enum for 'status'. The description adds minimal value by mentioning partner and date filtering, but doesn't provide additional context beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.

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 verb ('取得します' - retrieve/get) and resource ('見積書一覧' - list of quotes), making the purpose evident. It distinguishes itself from siblings like mf_get_quote (singular) by focusing on listing multiple quotes. However, it doesn't explicitly differentiate from mf_list_billings or other list tools beyond the resource type.

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 implies usage for filtering by partner and date range ('取引先や期間で絞り込み可能です'), suggesting when to use it for filtered queries. However, it doesn't provide explicit guidance on when to choose this over alternatives like mf_list_billings or mf_get_quote, nor does it mention prerequisites or exclusions.

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

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 the action but doesn't explain what 'refreshing' entails—whether it requires existing credentials, returns a new token, has side effects like invalidating old tokens, or involves rate limits. For a security-sensitive operation, 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.

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

The description is a single, efficient sentence with zero waste. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, 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.

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

Given the complexity of token refresh (a security operation) and the lack of annotations and output schema, the description is incomplete. It doesn't cover what the tool returns (e.g., a new token), error conditions, or dependencies on other tools. This leaves critical context missing for an AI agent.

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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param details, which is appropriate, but it also doesn't compensate for any gaps (none exist). A baseline of 4 is given since no parameters are present.

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: 'アクセストークンをリフレッシュします' (refreshes an access token). It uses a specific verb ('リフレッシュします') and identifies the resource ('アクセストークン'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'mf_auth_start' or 'mf_auth_status', 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.

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 expired token), timing (e.g., after authentication), or related tools like 'mf_auth_start' for initial auth. This lack of context leaves usage ambiguous.

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

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

With no annotations, the description carries the full burden. It discloses a critical destructive behavior: specifying items replaces all existing line items by deleting then adding, with a risk of incomplete state on failure. It also notes that changing the partner is unsupported. Other behavioral aspects like permissions or partial-update semantics are omitted, but the key side-effect is clearly surfaced.

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?

Three sentences, front-loaded with the core action, followed by a critical caveat and a limitation. Every sentence earns its place; no redundancy or filler.

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?

For a 13-parameter mutation tool with no annotations and no output schema, the description covers the main purpose and one critical side effect, but leaves significant gaps: it does not clarify whether omitted fields are left unchanged or cleared (partial vs full update), nor does it mention authentication or rate-limit considerations. Adequate as a minimum, but incomplete.

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%, so the baseline is 3. The description adds meaningful nuance beyond the schema for the items parameter by explaining the delete-then-add mechanism and its failure risk, which is not present in the schema's brief '全置換' note. It does not add semantics for the other 12 parameters, but the added detail for the most complex parameter justifies a 4.

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 states a specific verb and resource: '請求書を更新します' (updates an invoice). It clearly identifies the tool's purpose, though it does not explicitly differentiate from the similarly named sibling mf_update_payment_status or other update tools.

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 implies usage (updating an invoice) and provides some context with the items replacement caveat and the note that partner changes are unsupported. However, it offers no explicit guidance on when to choose this tool over alternatives like mf_update_payment_status or mf_create_billing.

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

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

アノテーションが提供されていないため、説明が動作の透明性を完全に担う必要がありますが、「更新します」という記述のみで、認証要件、権限、変更の可逆性、既存値への影響などについて何も触れていません。更新系ツールとしての挙動開示が不足しています。

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?

一文のみで無駄がなく、目的が冒頭に示されています。簡潔さは高いものの、情報量が最小限であるため構造的な価値は限定的です。

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?

アノテーションなし、出力スキーマなしの更新系ツールであり、認証要件や更新後の挙動、エラー時の扱いなどについての記述が不足しています。2パラメータのシンプルなツールとはいえ、突然変異を伴う操作としては説明が不完全です。

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?

スキーマの説明カバレッジが100%であり、billing_id と payment_status（0/1/2の列挙とその意味）はスキーマ側で完全に説明されています。説明文はパラメータに関する追加情報を提供していないため、ベースラインの3が妥当です。

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?

「入金状態を更新します」は具体的な動詞（更新）と対象（請求書の入金状態）を明示しており、目的は明確です。ただし、mf_update_billing や mf_create_billing など類似する兄弟ツールとの違い（入金状態のみを更新する点）についての説明はありません。

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?

いつこのツールを使うべきか、また mf_update_billing などの代替ツールとの使い分けについての言及が一切ありません。入金状態の更新という文脈は暗黙的に推測できるものの、明示的なガイダンスは欠如しています。

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

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 the action ('updates a quote') without disclosing behavioral traits. It doesn't mention whether this is a destructive operation, what permissions are required, how errors are handled, or what the response looks like (since no output schema exists). 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.

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

The description is extremely concise with a single sentence ('見積書を更新します'), which is front-loaded and wastes no words. For a tool with a well-documented schema, this brevity is appropriate, though it may sacrifice completeness.

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 complexity (6 parameters, nested items array, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain the tool's behavior, return values, or usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly beyond the basic schema.

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?

The schema description coverage is 100%, with detailed descriptions for all parameters (e.g., quote_id, items with full replacement). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or enhance understanding.

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 '見積書を更新します' (Updates a quote) clearly states the verb (update) and resource (quote), but it's quite generic and doesn't differentiate from sibling tools like mf_update_billing or specify what aspects of a quote can be updated. It avoids being a tautology with the name (mf_update_quote), but lacks specificity about scope.

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?

No guidance is provided on when to use this tool versus alternatives like mf_create_quote or mf_get_quote, nor are there any prerequisites mentioned (e.g., needing an existing quote_id). The description implies usage for updates but offers no context about constraints or typical scenarios.

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