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 return content (past journal patterns, capitalization patterns, account items with tax codes) but does not mention side effects, idempotency, or authentication requirements. It is adequate but lacks depth for a tool with no annotations.

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

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

The description is two sentences, front-loaded with the core purpose and use cases, and includes practical examples. Every sentence adds value with no 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?

No output schema, but the description explains the return content adequately for a context tool. It covers what patterns and items are returned. Missing details on error handling or edge cases, but overall sufficient for its complexity.

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 baseline is 3. The description adds minor value by explaining optional parameters (amount, partnerName) and their effect, but mostly restates schema descriptions. It does not provide significant new meaning beyond what is in the input 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: 'Get accounting policy context for decision support' with specific examples like asset vs expense classification, depreciation methods, and deferred expense treatment. This distinguishes it well from sibling tools such as freee_item_suggestion_context and freee_master_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 explicitly states when to use the tool: 'Use when the user asks about asset vs expense classification, depreciation methods, deferred expense treatment, etc.' It provides clear context but does not explicitly mention when not to use or list 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?

No annotations are provided, so the description carries full burden. It reveals that the tool analyzes past deals by partner/amount and returns suggestions with usage frequency, tax classification, and patterns. This is sufficient for a read-like context tool, though it could mention that it does not modify data or any performance considerations.

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 covering purpose, methodology, and ideal usage. No wasted words. Information is front-loaded: first sentence states the core function. Each sentence adds value.

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?

No output schema, so description must explain returns. It states what is suggested (account items, usage frequency, tax classification, patterns). Given the sibling set, it sufficiently differentiates. Could be more explicit about the format or depth of context, but overall complete enough for an agent to understand the tool's utility.

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 describes all 5 parameters with 100% coverage, so baseline is 3. The description adds high-level context (e.g., 'analyzes past deals by partner/amount'), but it does not provide additional per-parameter details beyond the schema. The parameter descriptions in the schema are already adequate.

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: 'Get account item recommendation context for a transaction'. It explains the action (analyzes past deals) and the output (suggest account items, usage frequency, tax classification, patterns). This distinguishes it from siblings like 'freee_item_suggestion_context' or 'freee_master_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 usage context: 'Ideal for consistent bookkeeping when unsure which account item to use.' This implies when to use, but does not explicitly state when not to use or mention alternative tools. Sibling list shows similar tools, but no direct comparison is made, leaving some ambiguity.

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?

Indicates it is a mutation function (executes approval actions), but lacks details on idempotency, side effects, or error handling. Without annotations, some behavioral context is missing, such as whether actions are reversible or what happens on failure.

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, action-focused and front-loaded with the tool's purpose, prerequisite, and action list. No extraneous words.

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?

No output schema is provided, and the description does not mention return values or error behavior. For a mutation tool, knowing what response to expect (e.g., success message, updated object) is important but 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 coverage is 100%, but description adds valuable context by explaining that target_step_id and target_round come from the expense application detail, and by providing Japanese translations for approval actions. This goes beyond the schema's enum 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?

Description clearly states the tool can approve, reject, or send back an expense application, naming specific actions and stating it executes approval workflow actions. This distinguishes it from sibling tools like freee_get_expense_application which are read-only.

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 users to use freee_get_expense_application first to obtain required fields (target_step_id, target_round). Does not explicitly state when not to use, but provides necessary prerequisite 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?

Without annotations, the description fully carries the burden of behavioral disclosure. It explains the classification logic (aging buckets based on issue_date), aggregation behavior, and output (overdue highlights). While it doesn't detail side effects or exact return format, the description is sufficiently transparent for an analysis 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 description is two sentences long, front-loaded with the core functionality and followed by a usage note. Every sentence is informative and necessary, with no redundant or irrelevant 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 low complexity (two optional parameters, no output schema) and rich sibling context, the description adequately covers what the tool does and its intended use. It lacks explicit output structure details, but for a standard aging analysis, the description is complete enough for an agent to select and 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 coverage is 100% (both parameters described). The description adds marginal value beyond schema by mentioning 'by days since issue_date', which relates to as_of_date. However, no additional format or usage details are provided beyond what the schema already covers, justifying the baseline score of 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?

The description clearly states the tool performs accounts receivable aging analysis, classifying unsettled deals into specific aging buckets by days since issue_date, aggregating by partner, and highlighting overdue receivables. It clearly distinguishes from sibling tools by specifying the exact analysis 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 explicitly mentions usage for cash flow risk assessment and collection prioritization, providing clear context. It does not explicitly state when not to use it or compare to alternatives, but the purpose is well-defined enough to avoid misuse.

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 fully communicates behavior: it reports token validity, expiry, and remaining minutes for one or all authenticated companies. It implies a read-only, non-destructive operation, which is appropriate. No contradictions or hidden side effects are 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 sentences, front-loaded with purpose and immediate details. Every word earns its place without redundancies. Highly 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 no output schema, the description adequately explains what the tool returns (validity, expiry, remaining minutes) and when to use it. It could be more specific about the response structure, but for a simple status check, this is sufficient. It covers the optional parameter usage and the scope (one or all companies).

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 already covers the one optional parameter (companyId) with a clear description. The tool description adds the ability to check 'one or all' companies, but this is not reflected in the schema (which implies a single company via default). This creates slight ambiguity, but the description does add context beyond the schema's parameter 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 verb 'Check' and the resource 'authentication status for freee API tokens', then details what it shows: token validity, expiry time, and remaining minutes. This distinguishes it from sibling tools like freee_get_access_token (token acquisition) and freee_clear_auth (token revocation).

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 explicitly advises 'Use to verify auth before making API calls', providing clear context for when to invoke. While it doesn't list negative cases or alternative tools, this guidance directly supports agent decision-making.

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 explains what data is aggregated (walletable balances, invoices, expense deals) and the output metrics (total cash, net position, overdue amounts). However, it does not explicitly state that this is a read-only operation (e.g., no data modification) or disclose any authentication or rate limit requirements. While the description is fairly transparent, it could be more explicit about safety.

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: the first states purpose and components, the second lists outputs. Every word serves a purpose. No redundancy, front-loaded with the key verb 'Get'. Highly concise and efficiently 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 tool's simplicity (one optional parameter, no output schema), the description is sufficient. It explains the output fields (total cash, net position, overdue amounts), enabling the agent to understand what data to expect. Could potentially add currency details, but overall it's complete for a consolidated overview 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?

Only one parameter exists (companyId), and the schema description coverage is 100% (the schema already provides a description). The description adds extra context: 'optional, uses FREEE_DEFAULT_COMPANY_ID if not provided.' This additional semantic information about default behavior adds value 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 clearly states the tool's purpose as 'Get consolidated cash position overview' and explicitly lists the components (walletable balances, unpaid invoices, unsettled expense deals) and outputs (total cash, net position, overdue amounts). This specificity distinguishes it from sibling tools like freee_ar_aging (focused on receivables aging) and freee_get_walletables (wallet balances).

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 this is the go-to for a quick financial health assessment by saying 'Single call combines... into one summary.' However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare to alternatives like freee_ar_aging for detailed receivables analysis. The context is clear but lacks exclusions or 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?

Discloses that it clears tokens and the behavior based on companyId. No annotations exist, but the description provides adequate behavioral context for a simple 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?

Two concise sentences that are front-loaded with the main action, followed by parameter details and usage guidance. No unnecessary words.

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?

Fully explains the tool's purpose, parameter behavior, and usage scenario. No output schema needed; everything is adequately covered.

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?

Adds meaningful explanation beyond the schema: explains the effect of providing or omitting companyId. Schema coverage is 100%, but description enhances 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?

Clearly states the action ('Clear stored authentication tokens') and the resource. Distinguishes between clearing a specific company vs all, and is distinct from sibling auth-related 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?

Explicitly states when to use: 'when you need to re-authenticate or resolve token issues.' Does not provide when-not-to-use or alternatives, but the context is clear.

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 must cover behavioral traits. It discloses output (metrics, diffs, percentages, significance) but omits safety (read-only nature), authentication needs, error handling, or rate limits. It adds some context beyond schema (pre-computed, significance highlights) but lacks full 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?

Two sentences: first states the function and benefit, second lists the outputs. No redundant information, front-loaded with the core purpose. Every sentence adds value.

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 complex with 5 parameters, nested objects, and no output schema. The description gives a high-level summary of outputs but lacks detail on return structure, error conditions, or edge cases. It leaves ambiguity for an AI agent to understand exact output format and potential failure modes.

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%; each parameter is well-described in the schema. The tool description adds high-level context (compare two periods) but does not provide additional semantics for individual parameters beyond what the schema already offers.

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 compares two financial periods with pre-computed diffs and percentages for YoY/MoM analysis. It specifies what it returns: metrics, absolute/percentage changes, and significance highlights. It differentiates from siblings by eliminating LLM-side math, making its unique value clear.

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 period comparisons (YoY/MoM) by stating 'Single call... Eliminates LLM-side math.' However, it does not explicitly state when not to use this tool or list alternative tools for other comparison needs.

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. It discloses that the tool compares current and previous year P/L, flags items exceeding a configurable threshold, and classifies costs as fixed/variable. It does not mention destructive behavior, auth needs, or output format, but covers the core behavioral traits adequately.

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 three sentences: a concise title-like first sentence, a detailed second sentence on functionality, and a third on usage. It is front-loaded with key information. A small amount of redundancy exists (e.g., 'expense structure' mentioned twice), but overall it is 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 the complexity (4 parameters, no annotations, no output schema), the description covers purpose, parameters, and usage scenarios adequately. It lacks explicit mention of return values or pagination, but for an analysis tool, this is 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 baseline is 3. The description adds value by explaining the anomaly detection threshold ('flags items with YoY change exceeding this percentage') and the month behavior ('cumulative year-to-date if omitted'). This goes beyond the schema 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 clearly states the specific function: 'Analyze expense structure with YoY anomaly detection and fixed/variable cost classification.' It uses specific verbs (analyzes, compares, classifies) and identifies the resource (expense structure). This differentiates it from sibling tools like freee_compare_periods and freee_monthly_trends by highlighting anomaly detection and cost classification features.

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 explicitly states when to use the tool: 'Use for cost health monitoring, identifying unexpected expense spikes, and understanding cost structure.' It provides clear usage context but does not mention when not to use or explicitly list alternatives, which would make it a 5.

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 of behavioral disclosure. It only states 'Create a new deal' without mentioning any side effects, authentication requirements, rate limits, or idempotency. The agent cannot assess risks or constraints from this description alone.

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 sentence, which is concise but overly brief. While it front-loads the purpose, it leaves no room for additional useful context. Every sentence should earn its place, and here the one sentence is adequate but could be expanded with minimal added length.

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 7 parameters (3 required) and no output schema, the description should provide context about the result of creating a deal (e.g., returns an ID) or error conditions. It does not. The schema covers parameter details, but the description lacks completeness about the tool's behavior and 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?

Schema description coverage is 100%, meaning each parameter already has a meaningful description in the schema. The tool description adds no additional explanation about parameters, so it meets the baseline expectation. It does not improve understanding beyond what the schema provides.

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 'Create a new deal (transaction)' clearly states the verb 'create' and the resource 'deal', and includes a parenthetical to clarify it's a transaction. This distinguishes it from sibling tools like freee_update_deal and freee_get_deal. However, it lacks additional context about what constitutes a 'deal' in this domain, which could be clearer.

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 such as freee_create_deal_payment or freee_create_invoice. It neither mentions prerequisites nor when not to use it, leaving the agent to rely solely on the tool 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 provided, so description carries burden. It mentions settling accounts and partial payments, but does not disclose side effects like deal status changes, reversibility, or idempotency.

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 focused sentences: action, partial payments, wallet reference, and use case. No wasted words.

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?

Covers purpose, parameter hints, and business context (closing). Lacks details on return values or idempotency, but acceptable given no output schema and moderate complexity.

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% schema coverage gives baseline 3. Description adds value by linking fromWalletableId/Type to freee_get_walletables and explaining amount semantics for partial payments.

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 uses a specific verb ('Record a payment') and resource ('deal'), and explicitly mentions supporting partial payments, distinguishing it from siblings like freee_create_deal or freee_update_deal.

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 advises using freee_get_walletables to find wallet account IDs and notes partial payment support. It lacks explicit when-not-to-use but implies context for monthly closing and cash management.

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?

The description states 'Create a new invoice,' implying a mutation, but it does not disclose side effects (e.g., does it send notifications?), required permissions, or whether the invoice is created as draft or issued. With no annotations, the agent gets no behavioral safety cues.

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 sentence 'Create a new invoice' is concise and immediately communicates the tool's purpose with no wasted words.

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?

No output schema exists, and the description does not mention return values, error conditions, or side effects. For a creation tool, the agent needs more context about what the response contains and what validates success.

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% with clear descriptions for each parameter (e.g., 'Invoice status' enum). The tool description adds no additional meaning beyond the schema, so 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 'Create a new invoice' clearly identifies the action (create) and the resource (invoice). It distinguishes this tool from read-focused siblings like freee_get_invoices and freee_summarize_invoices.

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, no prerequisites (e.g., partner ID must exist), and no when-not-to-use conditions. The description is purely declarative with no 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, the description carries the full burden. It discloses that the tool creates a new manual journal, requires balancing totals, and has an adjustment flag. It does not discuss authorization needs or side effects like irreversibility, but the core behavioral constraints (balancing) are well communicated.

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 three sentences with no wasted words. It front-loads the purpose, provides use cases, and gives essential instructions. Every sentence 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 the complexity (nested details array, balancing constraint) and no output schema, the description covers the main points. It could mention validation behavior (e.g., error if totals don't balance) but overall it provides sufficient context for correct invocation.

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%, but the description adds critical meaning beyond the schema. It explains that companyId defaults to an environment variable, details must include at least one debit and one credit with balancing totals, and adjustment defaults to false. The balancing requirement is a key business rule not expressed 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 tool creates a manual journal entry (振替伝票) with debit/credit entries. It provides specific use cases like closing adjustments (depreciation, prepaid expenses), distinguishing it from other transaction creation tools such as freee_create_deal. The verb 'Create' combined with the resource 'manual journal' 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?

The description gives concrete examples of when to use this tool (closing adjustments) and how to mark entries with adjustment=true. However, it does not explicitly mention when not to use it or suggest alternative tools for regular transactions. The context is clear but lacks explicit 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, the description carries full responsibility for behavioral disclosure. It only states the action without revealing side effects, idempotency, error conditions, or required permissions. This is severely lacking.

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 minimal (one sentence) but overly so; it does not earn its place as it merely restates the name. It lacks structure and depth, making it under-specified rather than efficiently 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?

Given 7 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain return values, error handling, or any contextual details needed for a new partner creation 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema provides, but it also does not contradict. Score reflects adequate coverage from 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 'Create a new partner' is a tautology of the tool name 'freee_create_partner', adding no new information. It does not distinguish the tool from siblings like 'freee_get_partners' or other create 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?

No usage guidance is provided. The description fails to indicate when to use this tool versus alternatives, such as when to create vs. update a partner, or prerequisites like authentication.

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; description only indicates creation and plan requirement. Lacks details on return value, error handling, or idempotency.

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?

Single, well-structured sentence with key information front-loaded. No superfluous text.

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?

No output schema and description does not explain what the tool returns, nor does it address potential errors or side effects, leaving the agent with incomplete context for invocation.

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%; description adds minimal parameter-specific context (e.g., 'department/project classification' for segmentId). 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?

Clearly states verb (Create), resource (segment tag), and scope (under segment 1-3 for department/project classification). Distinguishes from sibling tools like freee_get_segment_tags.

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?

Mentions requirement of a paid freee plan, but does not specify when to use this tool versus alternatives or provide 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?

No annotations are provided, so the description carries the full burden. It describes the tool as creating a transfer but does not disclose side effects, permissions required, or error conditions. Minimal behavioral disclosure beyond the basic action.

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

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

Two concise sentences achieve clarity: first states the purpose, second adds a prerequisite and supported types. No unnecessary words.

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 has 8 parameters (6 required) and no output schema. The description covers purpose and a prerequisite, but omits details on return value, error handling, or post-creation effects. Adequate but not complete for a potentially complex 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 coverage is 100%, so baseline is 3. The description reinforces that source/destination IDs are needed and lists supported wallet types, matching the schema enums. It adds no new meaning 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 clearly states the action ('Create a new bank transfer') and the resource ('口座振替'), with a specific verb and resource that distinguishes it from sibling tools like freee_get_transfers (read).

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 explicitly recommends using freee_get_walletables to look up account IDs, providing a clear prerequisite. It does not explicitly state when not to use the tool, but the context is sufficient for an AI agent to infer appropriate usage.

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 full burden. It does not disclose side effects, security requirements (e.g., client secret), or whether it is a mutation. Only minimal action stated.

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, no wasted words. However, could include essential context like 'after obtaining authorization code from freee_get_auth_url' without being 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?

For a simple OAuth token exchange, the description is minimal. It lacks details about response contents (e.g., access token, refresh token) and prerequisite flow, making it 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 coverage is 100% with one parameter 'code' described. The description adds no meaning beyond the schema, so baseline score 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 'Exchange authorization code for access token' clearly states the verb and resource, and distinguishes this tool from siblings like freee_get_auth_url which get the authorization URL.

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 alternatives. It is implied it follows obtaining an authorization code, but no explicit context or prerequisites are mentioned.

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 disclosure burden. It mentions efficiency and caching but does not explicitly state that the operation is read-only, non-destructive, or any rate limits. The behavior is implied but not fully transparent.

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 concise at three sentences, front-loaded with the action and resource. Every sentence provides value: purpose, usage context, and caching recommendation. No wasted words.

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 output schema and only 3 simple parameters, the description covers the core functionality well. It lacks details on return format (e.g., array of account items) but the statement 'retrieves chart of accounts' implies a structured list. Caching note adds practical 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?

The input schema already covers all 3 parameters with descriptions, achieving 100% coverage. The description adds caching advice that indirectly relates to parameter use but does not enhance understanding of parameter semantics 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 clearly states it retrieves a list of account items (chart of accounts) and emphasizes efficiency by doing so in one call. This distinguishes it from siblings like freee_get_item (singular) or freee_master_context, as it targets a specific entity group with a batch retrieval approach.

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 advises using this data for mapping/filtering in reports and recommends caching due to infrequent changes. However, it does not explicitly explain when NOT to use this tool or mention alternative sibling tools (e.g., freee_account_item_context for detailed context), leaving the agent to infer usage scope.

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 must carry behavioral info. It indicates a read-only operation (getting a URL) with no mention of side effects. However, it does not clarify that authentication is not needed for this step or that no state changes occur. Minimal but not contradictory.

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?

Single sentence, efficiently communicates the core function. No wasted words. Front-loaded with the primary action.

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?

Adequate for a simple tool, but lacks context within the OAuth flow. The description does not explain that after getting the URL, the user must authorize and then use freee_get_access_token. Sibling tools exist that require this 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter description ('Optional state parameter for CSRF protection'). No extra value.

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 retrieves an authorization URL for freee OAuth, with a specific verb 'Get' and resource 'authorization URL'. It distinguishes from siblings like freee_get_access_token and freee_auth_status, which have different purposes.

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

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

No guidance on when to use this tool vs alternatives such as freee_get_access_token or freee_auth_status. The description does not explain the OAuth flow step where this URL is required, nor does it mention post-authorization steps.

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 full burden. It discloses that the tool is efficient and returns pre-aggregated data via a single API call. However, it omits details like authentication requirements, rate limits, or side effects. The behavioral context is partial but not misleading.

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

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

The description is two sentences and to the point, with no wasted words. It front-loads the core purpose ('Get balance sheet'). Could be slightly more structured but is efficiently written.

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?

No output schema exists, so the description should hint at return values. It mentions assets, liabilities, and equity, which gives a basic idea. However, it lacks details on additional balance sheet components, pagination, or response format. Adequate for a simple 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?

Schema coverage is 100%, so the description adds limited value beyond the schema. It mentions pre-aggregated data but does not elaborate on parameter meaning or usage beyond what is already in the schema. 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 clearly states the tool retrieves a balance sheet with assets, liabilities, and equity pre-aggregated. It uses the specific verb 'Get' and resource 'balance sheet'. However, it does not explicitly distinguish from sibling tools like freee_get_trial_balance or freee_get_profit_loss, though it implies contrast by mentioning 'single API call replaces complex transaction aggregation'.

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 specific use cases: liquidity ratios, solvency analysis, working capital calculations. It implies when to use the tool but does not explicitly state when not to use it or name alternative tools. No exclusions or comparisons are given, which leaves room for ambiguity.

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. It states the tool retrieves data and implies a read-only operation, but does not disclose authentication requirements, potential errors, or rate limits. However, the behavior is simple and adequately described for a list retrieval, earning a mid-range score.

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 concise with three sentences: first states purpose, second explains usage importance, third provides caching guidance. Every sentence adds valuable information with no redundancy, and the most critical information is front-loaded.

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 simplicity (no parameters, no output schema), the description fully covers what the tool does, why it's useful, and how to handle results (cache). It provides sufficient context for an AI agent to know that this is a prerequisite for many other freee tools.

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 zero parameters, so schema description coverage is effectively 100%. The description adds no parameter details, which is appropriate since none exist. The baseline for zero parameters is 4, as the description cannot add value 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 explicitly states 'Get list of accessible companies' and 'Retrieves all companies linked to your freee account in one call', which clearly identifies the action and resource. It distinguishes itself from the sibling 'freee_get_company' by indicating it returns a list rather than a single company.

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 clear usage context: it's the 'essential first step to get company IDs for subsequent API calls' and suggests caching due to infrequent changes. While it does not explicitly list when not to use or name alternatives, the context strongly implies it is for initial setup, not for retrieving specific company details.

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, but description clarifies it's a read operation (retrieves), mentions fiscal year settings, and suggests caching behavior. Adequate for a simple getter.

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 efficient sentences, front-loaded with purpose, no unnecessary words 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 tool with one optional parameter and no output schema, the description covers purpose, usage context, and call frequency adequately.

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% with description for companyId. Description adds no extra meaning beyond 'specific company details,' 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?

Description clearly states 'Get specific company details' with verb and resource. Distinguishes from sibling freee_get_companies by specifying 'specific' company.

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 says to use for understanding accounting periods for report APIs and that one-time call per session is sufficient, implying when and how often to use.

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; description only states 'Get specific deal details', implying a read operation with no side effects. It does not disclose any behavioral traits beyond the obvious, but for a simple fetch, this is minimally sufficient.

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?

Extremely concise (three words), front-loaded with the action. Could be considered under-specified, but no waste.

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 low complexity (2 params, no output schema), the description is adequate but lacks details on what 'deal details' includes. It covers the basic purpose without extra 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% with descriptions for both parameters. The description adds no additional 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 verb 'Get' and resource 'specific deal details', which clearly indicates a read operation for a single deal. It distinguishes from siblings like 'freee_get_deals' (plural) by implying singular, though not 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?

No guidance on when to use this tool versus alternatives like 'freee_get_deals' or 'freee_search_deals'. No exclusions or context 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. It hints at efficiency concerns (date filters, pagination) but does not explicitly disclose behavior like rate limits, auth requirements, or data volume impacts. Adequate but not comprehensive.

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 brief sentences: first states purpose, second gives efficiency advice, third provides usage boundaries. Each sentence earns its place, front-loaded, no wasted text.

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 output schema, the description could better explain return values, but it sufficiently covers purpose, usage, and alternatives. Leaves some gaps in output details, but overall adequate for tool selection.

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 all parameters have descriptions. The description reiterates date filters and pagination but adds minimal extra meaning beyond the schema. 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 clearly states 'Get list of deals (transactions)', providing a specific verb and resource. It distinguishes from sibling tools like freee_get_deal (singular) and freee_search_deals.

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 advises using date filters and pagination for efficiency, recommends aggregated APIs (profit_loss, balance_sheet) for financial analysis, and states 'Only use for detailed transaction inspection'. Provides clear when-to-use guidance 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?

No annotations provided, so description carries full burden. Describes what is retrieved (line items, approvers, comments, logs), indicating a read-only operation. Does not mention side effects, permissions, or return format, but the description gives sufficient behavioral context for a GET 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?

Two sentences that front-load the purpose. Every word adds value. The Japanese parenthetical may be extraneous but does not detract significantly.

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 output schema, the description adequately explains the return contents (line items, approvers, comments, approval flow logs). Mentions specific fields (current_step_id, current_round) needed for follow-up actions. Could provide more structure, but sufficient for a simple retrieval 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?

Schema coverage is 100%, baseline 3. The description adds meaning by noting that companyId is optional and that expenseApplicationId is required. It also hints at the output (current_step_id, current_round) which adds value beyond 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?

Clearly states the verb 'Get', specific resource 'expense application details', and lists contents (line items, approvers, comments, logs). Differentiates from sibling 'freee_get_expense_applications' by focusing on a single application's 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?

Explicitly says to use this tool to get 'current_step_id and current_round needed for approval actions', implying it should be called before approval. Does not explicitly exclude alternatives, but sibling context suggests it is the singular retrieval tool.

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 description must cover behavior. It mentions retrieval and filtering but doesn't explicitly state read-only nature, rate limits, or authentication needs beyond the companyId parameter.

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, front-loaded with key information, no fluff. Every sentence adds value.

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?

13 parameters with no output schema and no annotations. Description covers high-level purpose and filtering but lacks details on pagination, return format, and default behavior.

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 baseline is 3. The description adds the 'compact mode' hint but otherwise repeats schema info.

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 'Get list of expense applications' with specific filtering dimensions. While it doesn't explicitly contrast with the singular 'freee_get_expense_application' sibling, the name implies a list 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?

The description implies usage for retrieving filtered lists but lacks explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description must fully disclose behavior. It explains retrieval of detailed entries, filtering, and compact mode for summaries. It does not mention read-only nature or rate limits, but the behavior is clear enough.

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 concise (two sentences) and front-loads the core purpose. Every sentence adds value, but could be slightly more 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?

With no output schema, the description does not explain the return format or pagination. It covers main usage and filtering but lacks details on what data is returned, which would help an agent handle the response.

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%, and the description adds value by explaining recommended usage of account_item_id and compact mode. It also clarifies companyId defaults. This goes beyond mere schema restatement.

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 retrieves detailed journal entries per account item (general ledger), with specific use cases like account analysis and consistency checks. It distinguishes itself among sibling tools by focusing on journal entries per account.

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 gives clear usage guidance: recommend using account_item_id to reduce response size and compact mode for overviews. It provides context for ideal use cases but does not explicitly mention when not to use this tool.

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. The description only states it retrieves filtered data, lacking disclosure of behavioral traits like pagination, rate limits, or safety. For a read operation, it's minimally adequate but misses opportunities to add 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?

Two concise sentences with no fluff. The first sentence states core function, the second provides usage guidance. Efficient 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?

With 9 parameters and no output schema, the description does not explain the return format or pagination details beyond schema. While schema covers parameters, the overall completeness for a tool with this complexity is adequate but could be improved.

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 description adds no extra meaning beyond what the schema already 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 clearly states the tool retrieves a list of invoices with filtering options, using specific verb (Get) and resource (invoices). It distinguishes itself from the profit_loss API for revenue analysis.

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 guides when to use this tool (specific invoice management and AR tracking) vs. alternatives (prefer profit_loss API for revenue analysis with partner breakdown).

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 present, so the description carries full responsibility for behavioral disclosure. It states 'Retrieves detailed information' but does not mention that it is a read-only operation, any required permissions, or potential side effects. For a read tool, this is a significant omission.

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 sentence that is front-loaded with the action and resource, then provides a brief elaboration. Every word is necessary and there is no extraneous content.

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 has no output schema, yet the description only says 'detailed information' without specifying the return structure. For a simple get-by-ID tool, this might be acceptable, but given no annotations, more context about the returned fields (e.g., name, type, pricing) would improve 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?

The input schema covers both parameters with descriptions (companyId notes default, itemId described as 'Item ID (品目ID)'). The description adds no additional semantics beyond confirming the item is a product/service item. Schema coverage is 100%, so 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 clearly states 'Get a single item (品目) by ID' and specifies it retrieves detailed information for a product/service item. The verb 'Get' directly matches the tool's function, and the resource 'item by ID' is unambiguous. This distinguishes it from sibling tools like freee_get_items, which likely returns 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?

No guidance is provided on when to use this tool versus alternatives such as freee_get_items. There is no mention of prerequisites, typical use cases, or when not to use it. The description lacks context for an AI agent to decide between this and related tools.

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 adds value by disclosing caching behavior (15 minutes) and the fact that items change infrequently. It implies a read-only operation. No contradictions.

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 concise sentences covering purpose, caching behavior, and usage context. No extraneous 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?

The description adequately explains the tool's role and caching. However, without an output schema, it could briefly mention typical response fields for completeness. Still sufficient given the simplicity.

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 schema already describes all parameters. The description does not add new meaning beyond what the schema provides.

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 list') and the resource ('items (品目) - product/service item master data used in invoices and deals'). It distinguishes from siblings like 'freee_get_item' and 'freee_item_suggestion_context' by specifying it retrieves a list of master data.

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 notes that items are cached for 15 minutes and change infrequently, implying it's for stable master data. It mentions it's a foundation for item suggestion and bulk context retrieval, but does not explicitly state when not to use it or list 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, the description carries full burden. It discloses the async download pattern (request→poll→download), typical latency (10-30s), and that output is parsed from CSV. It could add rate limits or error behavior, but covers the main behavioral traits.

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

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

Every sentence is purposeful: purpose, async method, use cases, output format, performance caveat. No redundancy, well-structured and front-loaded.

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 5 parameters, no output schema, and no annotations, the description explains the tool's purpose, method, use cases, and performance. It lacks detail on output structure (beyond CSV) and error handling, but is sufficient for an experienced user.

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 baseline is 3. The description does not add meaning beyond the schema for parameters like startDate, endDate, or visibleTags; it only restates the date range. The performance note is about execution, not parameter 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 gets journal entries for a date range, including all subtypes (deals, manual journals, auto-generated). It distinguishes from siblings like freee_get_manual_journals by being comprehensive, and gives specific use cases like monthly closing and audit review.

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 context for when to use (audit, anomaly detection, closing) and notes the async nature and time estimate. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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 full burden. It only states what the tool does (retrieves details) without disclosing behavioral traits such as read-only nature, authentication requirements, rate limits, or potential side effects. This is insufficient for a tool with no annotation support.

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 sentence that is concise and to the point, effectively communicating the core functionality. However, it could be slightly more structured (e.g., listing key features) without adding length.

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 description provides a high-level overview of the return value (full details with line items), but without an output schema, more detail on the response structure would be helpful for an AI agent to use the tool correctly. It is adequate but not 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 coverage is 100% with clear descriptions for both parameters (companyId optional with default, manualJournalId required). The description adds minimal value beyond the schema, only confirming that the tool returns line item details. 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 clearly states the action (get), the resource (manual journal), and the scope (specific entry with full details including all debit/credit line items). It effectively distinguishes from sibling tools like freee_get_manual_journals (list) and freee_create_manual_journal (create).

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 the tool is for retrieving details of a single manual journal, but it does not explicitly state when to use it versus alternatives (e.g., freee_get_manual_journals for listing) or provide any exclusions 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 provided, so description takes full burden. It mentions the max 500 records per page (key constraint) and lists filterable fields. Lacks detail on pagination behavior or response format, but is sufficient for basic understanding.

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: first states purpose and supported filters, second gives usage guidance. No unnecessary words, information is front-loaded.

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 and no output schema, the description covers purpose, filters, pagination limit, and alternatives. Missing details on error handling or response structure, but sufficient for selecting and using the 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?

Schema description coverage is 100%, so baseline is 3. The description enumerates filter types (date range, entry side, etc.) but adds no new meaning beyond what the schema already provides.

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 'Get list of manual journal entries' with the Japanese equivalent, indicating a specific verb and resource. It distinguishes from sibling tools like 'freee_get_manual_journal' (singular) by being the list version, and contrasts with aggregated report APIs.

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 advises when to use this tool (reviewing individual entries) and when to prefer alternatives (aggregated totals: profit_loss, trial_balance). No ambiguity.

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 description carries full burden. It implies read-only ('Retrieves') but does not explicitly state safety or side effects. Mentions efficiency and caching but omits details like pagination behavior or error handling.

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, no filler. First sentence states purpose, second provides usage guidance and caching tip. 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?

No output schema exists, so description should compensate. It explains the tool's purpose and usage, but does not describe the return structure (e.g., fields included) or handle pagination details beyond parameters. Lacks some completeness for a list endpoint.

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% with descriptions for all 5 parameters. The tool description does not add extra meaning beyond the schema; it only provides general context (caching). Baseline score 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 clearly states the verb 'Get list' and resource 'partners (customer/vendor master data)'. It distinguishes from siblings by suggesting profit_loss API for partner-based analysis, avoiding confusion with similar list tools like freee_get_invoices.

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 states when to use (retrieving partner master data) and when not to (use profit_loss API for analysis). Recommends caching due to infrequent data changes, providing clear usage 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 full burden. It mentions efficiency and a single API call, but lacks details on authorization needs, rate limits, or response format. The description does not contradict any annotations.

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 concise (3 sentences), front-loads purpose and efficiency, and includes actionable guidance without wasted words.

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 output schema, the description lists returned metrics (revenue, etc.) but omits structure, pagination, or response format. However, it is complete enough for a standard financial statement endpoint. Could better contrast with siblings for 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?

Input schema has 100% coverage (all parameters documented), so baseline is 3. The description adds context for breakdown_display_type and suggests usage scenarios, but does not provide additional parameter semantics 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 it gets a profit and loss statement, lists key metrics (revenue, COGS, operating profit, net income), and differentiates from siblings by emphasizing efficiency and specific use cases (monthly trends, YoY comparisons, KPI dashboards).

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 clear when-to-use guidance (profitability analysis, segment analysis via breakdown_display_type) and ideal scenarios, but does not explicitly contrast with sibling tools like freee_get_trial_balance or freee_segment_pnl, nor state when not to use.

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 description carries full burden. Discloses return contents (file URL, issue date, etc.) but does not discuss authentication, rate limits, or idempotency. Adequate but not comprehensive.

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: first explains functionality and key fields, second specifies usage. No fluff; every sentence 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?

No output schema, so description must explain return values. Lists major fields (file URL, issue date, user info, qualified invoice status). Could be more exhaustive but is sufficient for a simple retrieval 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?

Schema coverage is 100% with 2 parameters, both described. Description adds no additional semantic value beyond the schema, meeting baseline for high 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?

Description clearly states the verb 'Get' and resource 'specific receipt details' (証憑詳細), listing returned fields like file URL, issue date, user info, qualified invoice status. It distinguishes from sibling tool freee_get_receipts (plural).

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?

States 'Use for individual receipt inspection and compliance verification,' providing clear context. Does not explicitly mention when not to use or alternatives, but the purpose is well-scoped.

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 burden for behavioral disclosure. It states a constraint ('Max 100 records per page') and explains compact mode behavior, but does not disclose pagination details, authentication needs, or any side effects (e.g., data is read-only). This is adequate but not comprehensive.

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 well-structured sentences: first defines purpose and resource, second adds key behavioral notes (compact mode, limit). No redundancy or fluff. Essential information is front-loaded.

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 8-parameter tool with no output schema, the description covers main purpose, filtering, and specific modes. However, it lacks details about the response format (e.g., what fields are returned in normal mode) and pagination behavior beyond the limit. Compact mode is explained, but normal mode output is vague.

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%, setting baseline at 3. The description adds value by highlighting filtering by date, user, and status, and explaining compact mode's purpose ('summary statistics only'). This goes beyond individual parameter descriptions, earning a score above 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?

The description clearly states the verb ('Get list of'), resource ('receipts'), and purpose ('for electronic bookkeeping compliance'). It specifies the content type ('receipt images/PDFs') and filtering dimensions. This distinguishes it well from sibling tools like freee_get_receipt (singular) and other listing 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 mentions when to use compact mode but does not provide explicit guidance on when to choose this tool over alternatives like freee_get_receipt. No exclusions or prerequisites are stated, leaving the agent to infer context 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 provided, so description carries full burden. It only minimally discloses behavior (compact parameter behavior) but omits details like pagination, permissions, or whether data is read-only.

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, front-loaded with purpose, no fluff.

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?

Adequate for a simple list tool with two optional params, but lacks details about return structure or constraints, especially compared to sibling tools.

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% with descriptions for both parameters. Description adds usage context but no additional semantic detail beyond 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?

Description states it gets a list of sections for segment reporting and distinguishes from siblings by mentioning use with profit_loss breakdown_display_type="section". Specific verb and resource.

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?

Provides explicit context for use with profit_loss analysis, but no explicit when-not-to-use or 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?

No annotations are provided, so the description bears full responsibility. It does not disclose behavioral traits such as read-only nature, error handling, rate limits, or pagination behavior beyond parameters. The description is insufficient for a tool with no annotations.

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 concise sentences: first defines purpose, second provides usage guidance. No fluff, front-loaded with key 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?

Good coverage given 5 parameters and no output schema: explains purpose, usage, distinguishes sibling. Lacks details on return format and pagination, but schema covers parameters well.

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 baseline is 3. Description adds context about segment tags being for department/project tracking and up to 3 axes, but does not significantly augment parameter meanings beyond schema 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 explicitly states it retrieves segment tags for multi-axis analysis, clearly distinguishing from sibling tool freee_get_tags by explaining segment tags enable up to 3 independent classification axes for department/project tracking.

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?

Provides clear usage context: use with profit_loss breakdown for segment-based P&L analysis and notes requirement of a paid freee plan. Does not explicitly state when not to use, but differentiation from regular tags offers 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 must disclose behavioral traits. It only states 'Retrieves' implying read-only, but does not explicitly confirm no side effects, nor does it mention any default behavior for missing companyId or compact mode. The description adds minimal behavioral context beyond what the inferable, so a score of 3 reflects adequate but not exceptional 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 two concise sentences with no extraneous words, front-loading the main purpose immediately. Every sentence serves a purpose: stating the core function, providing usage guidance, and suggesting a use case.

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?

While the description covers the main purpose and usage context for a simple list tool, it lacks details on return format (e.g., what fields tags have) since there is no output schema. Given the low complexity (2 params, no enums), a score of 3 indicates it is minimally complete but could be improved.

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 already has 100% description coverage for both parameters: companyId (optional, uses default) and compact (returns summary stats). The tool description adds no further parameter meaning, meeting the baseline expectation of 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?

The description clearly states 'Get list of tags - Retrieves custom classification tags.' This uses a specific verb-resource pair and distinguishes from sibling 'freee_get_profit_loss' by suggesting it for tag-based analysis, indicating a clear 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?

The description provides explicit guidance: 'For tag-based analysis, use profit_loss API with tag breakdown for efficient aggregation.' This tells the agent when not to use this tool and points to an alternative, plus mentions usefulness for 'project/campaign tracking.'

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?

Discloses caching behavior ('Cached for 15 minutes as tax codes rarely change') and the scope of data ('in one call'). With no annotations, this adds valuable insight 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?

Three sentences, each providing distinct value: purpose, usage context, and caching behavior. No 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 simple list-retrieval tool with two optional parameters and no output schema, the description covers the essential aspects: what it returns, why it's needed, and a performance detail (caching). Complete enough for 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?

The input schema covers both parameters with descriptions, and the description does not add additional parameter semantics. Since schema coverage is 100%, a baseline score of 3 is appropriate.

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

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

The description clearly states 'Get list of tax codes' with specific resource and scope ('all available tax classification codes in one call'). It distinguishes itself from sibling tools by focusing on tax codes only.

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 mentions it is 'Essential for accurate deal and invoice creation' with examples of tax rates (10%, 8%, exempt), providing clear context for when to use this tool. No explicit exclusions or alternatives, but sufficient 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?

The description says 'retrieves' implying a read operation, but no annotations confirm safety. It lacks details on required permissions, rate limits, or side effects. The return format is not described since no output schema exists. Acceptable but not thorough.

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, no redundant words. All information is front-loaded. Every sentence serves a purpose. Highly 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 simple retrieval tool with 2 parameters and no output schema, the description covers the core purpose. It could mention expected response structure or that it's a read-only operation, but it's mostly adequate. Missing behavioral details slightly reduce 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 coverage is 100%, so the description adds minimal value. It only mentions 'by ID' which echoes the schema. The parameter descriptions in the schema are already clear. Baseline score 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 clearly states the tool retrieves full details of a single fund transfer by ID. The verb 'Get' and resource 'bank transfer details' are specific, and the singular 'single' distinguishes it from the sibling `freee_get_transfers`.

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 implicitly tells when to use (when you have a transfer ID) but does not explicitly mention when to avoid or provide alternatives like `freee_get_transfers` for listing or `freee_create_transfer` for creating. No exclusion guidance is given.

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, description carries full burden. It correctly characterizes as a read operation ('Retrieves') and mentions pagination. However, it does not disclose return format, auth requirements, or any potential side effects. Adequate but not thorough.

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 concise sentences that front-load the main purpose, then add essential details (prerequisite, pagination limit). No 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?

Lacks return structure description (no output schema). The description implies a list of transfers but doesn't specify fields. For a commonly used read tool, this is a gap. Also, the 'account filtering' claim is not reflected in schema. Adequate but with room for improvement.

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 has 100% coverage, so baseline 3. Description adds 'date range and account filtering' which aligns with startDate/endDate but 'account filtering' is not reflected in the parameter list (no account ID param). Minimal added value beyond 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?

Clearly states 'Get list of bank transfers' and describes what they are (fund movement records). Differentiates from sibling by explicitly mentioning prerequisite use of freee_get_walletables.

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?

Provides clear guidance on when to use ('to get transfers') and a crucial prerequisite ('Use freee_get_walletables first to get account IDs'). No explicit when-not or alternatives, but the prerequisite is very helpful.

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 must fully disclose behavioral traits. It mentions the tool is efficient and retrieves aggregated balances in one call, but omits critical details such as whether the operation is read-only, authentication requirements, rate limits, pagination behavior, or any side effects. The lack of such information leaves significant transparency gaps.

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

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

The description is two sentences long, front-loading the core action in the first sentence and useful context in the second. It avoids redundancy and every phrase contributes value. It is concise without being terse, though it could be slightly tighter.

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 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain what the response looks like, whether results are paginated, error handling, or any flags or sorting options. The description covers the basic purpose but leaves significant gaps for effective invocation.

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 on all four parameters, so the baseline is 3. The description adds minimal extra context beyond the schema, only noting support for monthly/quarterly/annual periods, which is already implied by the startMonth and endMonth parameters. It does not introduce new semantic 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 clearly identifies the tool as 'Get trial balance report' and specifies it retrieves aggregated account balances for all accounts in one API call. It provides concrete use cases (financial analysis, balance verification, period comparisons) and distinguishes itself from sibling tools that might handle individual transactions or different report types.

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 states 'Use for financial analysis, balance verification, and period comparisons without processing individual transactions,' implying it is suitable for aggregated data. However, it does not explicitly state when not to use this tool or directly compare it with siblings like freee_get_general_ledger or freee_get_balance_sheet, leaving usage boundaries implicit.

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 full burden. It implies a read operation and describes the data scope but could more explicitly state it is read-only and note any constraints like pagination.

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: first states purpose, second gives usage guidance and alternative. No unnecessary words, and the most important info is front-loaded.

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 tool with two optional parameters and no output schema, the description fully covers what the tool does, how to use parameters, and when to use alternatives.

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 baseline is 3. The description adds minor context (use case for withBalance) but does not significantly enhance meaning beyond the schema 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 clearly states the tool retrieves a list of bank accounts, credit cards, and wallets in one call, and distinguishes it from the balance_sheet API for aggregated analysis.

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?

Explicit guidance is provided: use withBalance=true for cash position, and prefer balance_sheet API for aggregated financial analysis, making when to use and when not to use clear.

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 present, so description fully bears the burden. Discloses pagination limit and filtering requirements. Implicitly a read operation. Could explicitly state read-only, but otherwise transparent.

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 with clear structure: purpose, requirements, alternatives. No wasted words. Front-loaded with main action.

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?

No output schema, so description should describe return shape. It doesn't. Lacks details on response structure. Otherwise covers key usage aspects.

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 description adds minimal value beyond schema. It reiterates that walletableType and walletableId are required for filtering and mentions page limit, which is already in schema. Baseline 3 justified.

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 retrieves wallet transactions, using specific verb and resource. It distinguishes itself from siblings by referencing wallet-specific accounts and providing alternatives for aggregated data.

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 mentions requirement of walletableType and walletableId, recommends using freee_get_walletables first, notes pagination limit, and suggests report APIs for cash flow analysis. Provides when-to-use and when-not-to-use 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, the description fully carries the transparency burden. It explains that the tool retrieves and aggregates item usage history, ranks by frequency, and recommends unit prices and tax codes. It does not explicitly state that it is read-only, but the actions imply no modification.

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 concise (3 sentences), front-loaded with the main purpose, and every sentence adds meaningful information without redundancy or fluff.

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 output schema, the description explains the conceptual output (ranked list with recommendations) but lacks specific details about the exact structure. It is mostly complete for a suggestion tool, covering retrieval, aggregation, and usage intent.

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 provides full descriptions (100% coverage). The tool description adds value by clarifying the relationship between partner_id and partner_name, and explaining the category parameter's purpose beyond its schema 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 it retrieves item suggestion context for a partner, including master list and usage history. It distinguishes itself from sibling tools like freee_get_items by focusing on ranked suggestions with recommended prices and tax codes, and explicitly ties it to bookkeeping for new deals or invoices.

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 advises using partner_id or partner_name to specify the partner and notes the tool is useful for consistent bookkeeping when creating deals or invoices. However, it does not explicitly state when not to use this tool or list alternatives, leaving some ambiguity.

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 the tool detects specific inconsistencies and returns severity-sorted findings with recommendations. However, it does not explicitly state if the tool is read-only or if it has any side effects, though 'check' strongly implies no 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 description is two sentences long, front-loaded with the main purpose, followed by specific detection examples. It is concise and well-structured, with no unnecessary 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?

Despite no output schema, the description sufficiently explains what the tool returns (severity-sorted findings with recommendations). For a checking tool, this is complete and provides enough context for the agent to understand the tool's functionality.

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 parameters are already documented. The description does not add meaningful new information beyond the schema, such as constraints or usage nuances. 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 clearly states the tool checks journal entry consistency across deals, with specific detection examples (e.g., partners using multiple account items, tax category inconsistencies). It distinguishes itself from sibling tools like freee_tagging_consistency_check by focusing on journal consistency rather than tagging.

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 consistency checking but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, such as when to use freee_monthly_closing_check instead. The context is clear but lacks comparative 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?

Describes parallel fetching of PL, BS, and walletable data, and computation of metrics with health indicators. No annotations provided, so the description carries the full burden. It is transparent about being a read-only aggregation 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?

Single, well-structured paragraph. Front-loaded with purpose, followed by details and usage advice. No extraneous content.

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, the description clearly states what the output contains (metrics and health indicators) and explains data sources. Sufficient for understanding the tool's return value.

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% with descriptions. The tool description adds context about companyId being optional with a default, but does not significantly extend beyond 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 'Get key management KPIs in a single call' and enumerates specific categories (profitability, safety, efficiency, liquidity). It distinguishes from sibling tools that focus on individual reports like freee_get_profit_loss or freee_get_balance_sheet.

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 advises 'Use for quick executive-level financial health overview.' While it doesn't explicitly state when not to use, the context of sibling tools provides alternatives for detailed analysis.

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?

The description mentions 'Uses parallel API calls with caching', which gives insight into performance and efficiency. However, without annotations, it does not explicitly state read-only or non-destructive nature, though the context suggests it is safe. A more explicit behavior statement would improve 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 relatively short and front-loaded with the key action. The parenthetical Japanese list may be less useful for English agents, but it is still concise. Every sentence adds value, though the Japanese could be translated for broader applicability.

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 bulk retrieval and the presence of many sibling tools, the description adequately positions the tool. However, without an output schema, it does not describe the return structure. The mention of caching and parallel calls helps, but completeness could be improved by explaining the response format.

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 parameter descriptions already explain companyId and include. The description adds that include fetches only specific categories, but this is mostly redundant with the schema. No additional semantic depth is provided 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 clearly states the tool fetches all master data in one call, listing specific categories (勘定科目・メモタグ・部門・セグメント・品目・取引先) and emphasizing bulk retrieval for advisory context. This distinguishes it from sibling tools like freee_get_account_items and freee_get_tags that retrieve individual categories.

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 advises using the 'include' parameter to fetch specific categories and notes it is essential for providing accounting advice without multiple tool calls. It implicitly suggests use when you need reference data, but does not explicitly state when to use alternative individual get tools.

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 full burden. It describes the execution of checks and return format (per-check status with details and overall assessment). It does not explicitly state if the tool is read-only or any side effects, which is a minor 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?

Two sentences: first explains what it does and lists checks, second covers output and usage. No unnecessary words, front-loaded purpose.

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 (running multiple checks) and 100% schema coverage, the description explains output structure and usage timing. Minor gaps: no mention of prerequisites or that checks are cumulative over the year, but overall adequate.

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 baseline is 3. The description adds minimal value beyond the schema listing the check types. It reinforces optionality of companyId but adds no new semantic 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 clearly states it runs a monthly closing checklist and lists all 6 automated checks. It distinguishes from sibling tools like freee_ar_aging and freee_cash_position by being a consolidated batch check tool.

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 says 'Use after month-end to identify outstanding items before closing.' This provides clear context for when to use it. It does not explicitly exclude alternatives, but it's sufficient.

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, and the description does not disclose side effects, required permissions, rate limits, or whether the operation is read-only. It focuses on output but omits behavioral details beyond the general nature of fetching trends.

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 two-sentence description is concise and front-loaded with the core purpose and value proposition. Every sentence adds information without unnecessary 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?

The description explains return values (averages, max/min, trend direction) but lacks output schema or detail on structure and edge cases. While adequate, it could be more complete for a tool with no output 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?

Schema coverage is 100%, providing adequate descriptions for all four parameters. The tool description adds no additional semantics beyond what the schema already states, meriting the baseline score of 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?

The description clearly states the tool retrieves monthly financial trends with summary statistics, specifies output includes pre-computed averages, max/min, and trend direction, and distinguishes it from siblings by noting it replaces 12 separate API calls.

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 this tool is for aggregated monthly trends rather than raw data from individual endpoints, contrasting with sibling tools like freee_get_profit_loss. It lacks explicit 'when not to use' guidance but provides strong 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 must disclose behavioral traits. It mentions using freee native multi-year trial balance APIs and returning certain data, but does not specify if it is read-only, required permissions, or how months interact with fiscal years, leaving some ambiguity.

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, each delivering value: first sentence states purpose, second describes output, third adds quality claim. No wasted words, front-loaded.

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?

No output schema, so description must explain return values. It does so adequately (account-level data, current/last/optional two-years prior, year-on-year changes and percentages). Could be clearer on how fiscal periods are applied, but sufficient for the tool's complexity.

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 baseline is 3. The description adds minimal beyond schema—only mentions reportType and years—but doesn't clarify the role of startMonth/endMonth or companyId defaults. No significant enhancement.

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 retrieves multi-year comparison reports for P/L or BS using native APIs. It distinguishes from siblings like single-period reports by specifying multi-year scope and mentions account-level data with year-on-year changes.

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 says to use for annual growth analysis and claims greater accuracy over manual comparisons, providing clear context. However, it does not explicitly state when not to use this tool or name alternative tools for single-year reports.

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