Mekari Jurnal MCP by usefulapi

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

Annotations already declare openWorldHint=true, idempotentHint=false and destructiveHint=false; the description corroborates the write side effect ('writes to the user's books') and adds genuinely new context about reversibility (records can be archived or deleted later). It omits what happens on duplicate email/name, validation failures, and whether the created record is immediately usable elsewhere, which matters for an 11-param write 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?

Three short sentences, front-loaded with the action and with the required-field constraint early. The trailing 'POST /customers' is the only questionable sentence, though it does anchor the tool to a concrete API shape.

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 carries the burden of describing the return value, and it says nothing about what a successful create returns (e.g. the new customer id) or how the agent should reference the customer afterwards. For a mutation tool with 11 mostly-undocumented parameters, missing duplicate/validation behavior is a real gap.

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 only 27%, so the description needs to compensate, but it only restates the required-field fact ('Only display_name is required') which the schema's required array already conveys. Of the ten optional fields (tax_no, associate_company, billing_address, first/last name, etc.) none are explained, so an agent gets no help choosing between display_name and first_name/last_name or knowing how billing_address differs from address.

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

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

States a specific verb and resource ('Create a new customer contact in Jurnal'), which is unambiguous against read siblings like jurnal_get_customer and jurnal_list_customers. It never explicitly contrasts with jurnal_create_vendor, the closest sibling, but the resource noun does the disambiguation work.

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

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

Usage is implied by the verb and by 'Only display_name is required', so an agent knows the minimum viable call. There is no guidance on when to create a new customer versus pick an existing one, no duplicate-handling advice, and no mention of the vendor sibling.

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?

Adds meaningful context beyond the annotations: it explicitly frames the call as a write to the user's books and notes the created vendor can be archived or deleted later, which communicates reversibility. It also names the underlying endpoint (POST /vendors) and the single required field. It stops short of saying what happens on duplicate names or what permissions are needed.

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 short sentences, front-loaded with the purpose, then behavior, then the required-field constraint and endpoint. Nothing is redundant or padded.

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

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

With no output schema, the description should say what comes back (e.g., the new vendor ID) so the agent knows how to reference the created record. It also omits duplicate-name behavior, which matters for a non-idempotent create. Adequate for the happy path, incomplete for the full picture.

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 only 27% across 11 parameters, so the description should compensate more. It correctly highlights that only display_name is required, which is genuinely useful for an 11-param schema, but the remaining ten fields (email, phone, tax_no, address, billing_address, etc.) get no guidance in either place.

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

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

States a specific verb and resource ('Create a new vendor (supplier) contact in Jurnal') and disambiguates the synonym 'vendor/supplier'. It doesn't explicitly contrast with jurnal_create_customer, but the resource noun makes the split obvious.

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 instead of jurnal_list_vendors (to check for duplicates) or how it relates to jurnal_create_customer. The only usage-adjacent hint is 'This writes to the user's books', which is behavioral rather than routing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the underlying REST path (GET /accounts/{id}), which helps an agent reason about the API, but says nothing about failure behavior for a missing/invalid id or whether the full account object is returned.

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

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

Two short fragments, front-loaded with the resource and scope; nothing is padded. The endpoint sentence is close to redundant with the first but does add API-mapping context.

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

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

For a simple single-record read with full schema coverage and safety annotations, the essentials are present. With no output schema, though, the description could have said what an account entry contains or what happens on a bad id, which would make it self-sufficient.

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

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

The single id parameter is fully documented in the schema (100% coverage) with type and bounds, so the schema carries the parameter burden. The description only restates that lookup is keyed by id, adding no format or source guidance beyond the schema.

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

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

States a specific resource (one chart-of-accounts entry) and the retrieval key (by id), which implicitly separates it from jurnal_list_accounts. It does not name the list sibling explicitly, so an agent must infer the single-vs-many distinction, but the core purpose is unambiguous.

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

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

'by id' implies this is for looking up a known account rather than browsing, which points an agent away from jurnal_list_accounts. However, there is no explicit when-to-use or when-not-to-use statement, and nothing about what to do if the id is unknown.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the semantic meaning of the report and the GET endpoint, but does not mention permissions, rate limits, or output granularity; with annotations present, this is adequate but not rich.

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

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

Two short sentences with the definition front-loaded and no wasted wording. The endpoint path is compact and does not distract from the 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?

For a zero-parameter report with no output schema, the description gives enough context for an agent to understand what is returned. Bucket granularity and currency handling are not specified, but these are minor gaps for this simple read-only tool.

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

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

The tool takes zero parameters, so the baseline score is 4. There are no parameter semantics for the description to clarify.

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

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

The description states a specific resource (aged payables) and explains its meaning as vendor amounts bucketed by overdue age. It is clear but does not explicitly distinguish this from the closely related sibling jurnal_get_aged_receivables.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the report definition itself.

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?

readOnlyHint=true and openWorldHint=true already establish this as a safe read, so the description's job is lighter. It usefully discloses the return shape (buckets by overdue age), which annotations don't convey, but says nothing about the bucket boundaries or whether data is company-scoped.

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 compact sentences, front-loaded with the concept and then the endpoint. No filler.

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

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

With no parameters, no output schema, and read-only annotations, very little is required. The description's note about aging buckets partly compensates for the missing output schema, though bucket definitions or scope would make it fully complete.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The schema coverage is 100% for an empty object.

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

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

States a specific resource and elaborates what it contains: amounts customers owe bucketed by overdue age. This clearly separates it from jurnal_get_aged_payables, though the sibling is not named 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 indication of when to use this versus other financial reports like get_balance_sheet or get_executive_summary, and no prerequisites or exclusions. The usage context is only implied by the resource name.

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

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

readOnlyHint=true and openWorldHint=true already establish the safety profile, so the description's burden is reduced. It does disclose the shape of the result (assets, liabilities and equity grouped by account), which matters because there is no output schema, but it says nothing about response size, pagination, or whether comparative periods are included.

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 compact sentence with the report content and date semantics front-loaded, plus the endpoint. Nothing is padded, though the trailing 'GET /balance_sheet' is redundant for an agent that never sees HTTP paths.

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

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

For a single optional-parameter read-only report with no output schema, the description covers what the tool returns at a section level and how the date bounds the period. It stops short of describing row-level fields or ordering, which an agent summarizing the output might want.

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

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

Schema description coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description only restates the yyyy-mm-dd format and today's-date default — no added semantics such as fiscal-period behavior or timezone handling.

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?

Names a specific financial report (balance sheet) and states its contents — assets, liabilities and equity by account — plus the underlying endpoint. It is distinguishable from list/get tools, but it never contrasts itself with the closely related report siblings such as jurnal_get_profit_and_loss, jurnal_get_trial_balance or jurnal_get_cash_flow.

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 explicit when-to-use or when-not-to-use guidance is given. An agent choosing between this and the other financial-statement tools (profit and loss, trial balance, cash flow) gets no routing help beyond the report's name, leaving the selection to inference.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds modest value by disclosing the statement's structure (operating, investing, financing), but says nothing about currency scope, multi-company behavior implied by openWorldHint, or the effect of compare_type on the response shape.

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

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

Two short sentences, front-loaded with the resource and its sections. The trailing 'GET /cash_flow' is implementation detail rather than agent-facing meaning, a minor bit of low-value payload in an otherwise tight description.

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 does need to signal the return shape, and the parenthetical section list does that adequately for a read-only report. The fully described 3-parameter schema covers the input side, so only comparison-output semantics are left unstated.

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%, including the enum semantics for compare_type and the 'custom' interaction with start_date/end_date, so the schema carries the parameter burden. The description adds no parameter detail beyond 'for a period', which is the baseline-3 case.

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

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

The description names a specific report ('cash flow statement') and enumerates its sections (operating, investing, financing), so an agent knows exactly what data comes back. It does not explicitly distinguish itself from jurnal_get_balance_sheet or jurnal_get_profit_and_loss, which are the obvious confusable siblings, leaving the agent to infer the choice from the name alone.

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

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

Usage is only implied: 'for a period' suggests this is the per-period aggregated cash view, but there is no explicit statement of when to pick this over the balance sheet or P&L, nor any prerequisite or caveat. No exclusions or alternative-routing 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?

Annotations already cover readOnlyHint=true and openWorldHint=true, so the description's main added value is the exact endpoint (GET /public/jurnal/api/v1/users/me) and, importantly, the shape of the payload returned in the absence of an output schema. That is genuine context beyond the structured fields; it only lacks notes on auth failure behavior or entitlement scoping.

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

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

Two short fragments, front-loaded with the identity semantics before the endpoint path. The raw API path is mildly redundant for an agent that never constructs URLs, but it is compact and confirms the read-only nature.

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 parameters and no output schema, the description carries the burden of describing the return value, and it does so by listing the identity fields. Missing only usage framing (when an agent should resolve the acting user) to be fully complete.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description does not confuse the agent with any argument-like language.

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

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

The description states a specific resource ('The Jurnal user the credential acts as') and enumerates the identity fields returned (id, name, email, status, owner flag, roles). This clearly separates it from the resource-specific getters like jurnal_get_customer or jurnal_get_vendor, though it never names that distinction 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?

There is no guidance on when to call this versus alternatives (e.g., jurnal_list_companies for tenant scope), and no stated prerequisites or conditions. The phrase 'the credential acts as' hints at the use case, but the agent must infer it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /customers/{id}) and clarifies a single object is returned, but says nothing about error behavior for missing ids, auth requirements, or what the payload looks like.

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

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

One short sentence plus the endpoint path; the key disambiguating fact (source of the id) is front-loaded and nothing is padded.

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

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

For a trivial single-parameter read with annotations covering safety and no output schema, the description is adequate but thin. It never indicates what fields a customer record carries or whether related data (contacts, addresses) is included, which an agent needs to decide whether this call suffices.

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

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

Schema description coverage is 100% with a single documented parameter, so the baseline is 3. The description adds the useful hint that the id originates from jurnal_list_customers, but no format or constraint detail 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?

States the specific verb+resource ('One customer by id') and points to the sibling that produces ids, so an agent can distinguish it from jurnal_list_customers without opening the schema. It stops short of naming what a 'customer' record contains, but the retrieval intent is unambiguous.

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

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

'from jurnal_list_customers' implies the intended workflow: list first, then fetch a single record by id. There is no explicit statement of when to prefer this over the list tool or what happens with an invalid id, so guidance is implied rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds no behavioral context beyond the annotations—no note on data freshness, company scoping, currency, or period covered—so it does little to help an agent predict behavior beyond what structured fields provide.

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 compact sentence with the key content front-loaded. The trailing 'GET /executive_summary' is a minor technical redundancy but does not obscure the 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?

For a no-parameter read tool without an output schema, the description adequately names the main figures returned. However, it omits contextual details such as whether values are current snapshots or period-based, and how this summary relates to the more granular report tools, leaving some ambiguity for the agent.

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

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

The tool has zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter schema warrants a baseline of 4 even when the description does not discuss parameters.

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

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

The description names the resource (executive summary) and enumerates the key figures returned (cash, revenue, profit, receivables, payables), so an agent can understand its purpose. However, it does not distinguish this high-level summary from sibling financial reports like jurnal_get_profit_and_loss or jurnal_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?

The term 'executive summary' and the listed metrics imply a high-level overview use case, but there is no explicit guidance on when to use this tool versus the more detailed financial report siblings. 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?

The annotations already state readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the returned expense includes its lines, which is useful behavioral context, but it does not mention not-found behavior, permissions, or response shape beyond that.

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 entire description is two short fragments, front-loaded with what the tool returns and followed by the endpoint. There is no filler.

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

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

For a single-record read tool with one fully documented parameter and read-only annotations, the definition is largely complete. It even indicates that the expense's lines are included, though it could say more about the returned object given there is 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 description coverage is 100%, and the sole 'id' parameter is fully documented as 'Expense id.' in the schema. The description only echoes the id through the endpoint path and adds no syntax or format details beyond the schema.

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

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

The description states a specific resource ('expense') and scope ('one expense with its lines'), and the endpoint makes the singular retrieval unambiguous. It doesn't explicitly name the sibling list tool, but the singular/plural contrast is easy to infer from 'One expense' versus 'jurnal_list_expenses'.

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 endpoint and required id imply that this is for fetching a single known expense, but there is no explicit when-to-use guidance, no mention of when not to use it, and no direct alternative such as the list 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description only adds that it is a period-scoped GET endpoint; there is no mention of volume, pagination, or what a period default of 'today' yields. Adequate but thin for a reporting endpoint.

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

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

Two short clauses plus the endpoint path; front-loaded with the resource and scope. The trailing 'GET /general_ledger.' is nearly redundant but harmless.

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 zero required parameters, no output schema, and a fully documented schema, the description is serviceable. It leaves the most error-prone behavior (compare_type shortcut vs custom date range) to the schema and says nothing about the response shape, which matters because no output schema exists.

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

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

Schema description coverage is 100%, so the schema already explains every parameter including the enum. The description's mention of 'ids from jurnal_list_accounts' repeats schema text, and it does not clarify the interplay between compare_type shortcuts and start_date/end_date beyond what the schema says.

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

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

States a specific resource (general ledger) with scope (a period, optionally limited to accounts), which is stronger than a title restatement. It does not differentiate itself from related financial reports like jurnal_get_trial_balance or jurnal_get_balance_sheet, so an agent must infer the distinction.

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?

Implies usage by noting the account filter and pointing to jurnal_list_accounts for obtaining ids, which is a useful prerequisite hint. However, it never says when to choose this report over the trial balance or balance sheet, nor any 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral detail – the response includes debit and credit lines – but says nothing about missing-id behavior (404/null) or the response envelope shape.

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

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

Two short sentences, front-loaded with what is returned. The trailing 'GET /journal_entries/{id}' is mildly redundant with the tool name and schema but does reinforce singular-by-id semantics at negligible cost.

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?

A simple single-parameter read tool with no output schema, and the description covers both what is fetched and the notable return content (debit/credit lines). Only error/empty-result behavior is unaddressed, which keeps it below a 5.

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 single parameter already carries a description ('Journal entry id.') plus type and positivity constraint. The description adds no format, range, or sourcing guidance beyond the schema, so the baseline 3 applies.

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

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

Specifies a clear verb+resource: fetches a single journal entry by id, and adds that the result includes its debit and credit lines. It implicitly contrasts with the singular-vs-list sibling (jurnal_list_journal_entries) but never names it, so differentiation is left to inference.

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

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

Usage is only implied: 'One journal entry' plus a required id signals retrieve-by-id. There is no explicit statement of when to use this versus jurnal_list_journal_entries or a general ledger query, and no preconditions 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds essentially nothing beyond restating the HTTP route — no error/not-found behavior, no note that the call hits an external system with possible latency or auth requirements. With the lower bar set by annotations this is still thin.

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 compact fragments with no filler, and the scoping statement is front-loaded. Nothing is padded, though the terseness borders on under-specification rather than optimal density.

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

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

For a single-parameter read tool with full schema coverage and readOnly annotations, the description covers what the tool is and where the id comes from. No output schema exists, so return-shape explanation is not required; only failure behavior is missing.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as 'Product id.' The description adds only provenance (the id comes from jurnal_list_products), which is modest value over the schema. Baseline 3 applies when the schema carries the parameter documentation.

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

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

States the resource and scope precisely ('One product by id') and names the sibling tool that produces the id (jurnal_list_products), which separates it cleanly from jurnal_list_products and other get_* tools. The retrieval verb is only implied rather than stated, but the endpoint path GET /products/{id} confirms it.

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

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

The parenthetical '(from jurnal_list_products)' implies the workflow for obtaining the id, which is useful. However, there is no explicit when-to-use/when-not guidance, no statement of what happens if the id does not exist, and no differentiation from other single-entity getters beyond the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the output is broken down 'by account' and repeats the endpoint, which is modest extra context; it says nothing about how comparison periods behave or whether periods with no activity return empty results.

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 what the report is and what it contains, followed by the format constraint and endpoint. No filler.

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

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

With no output schema, the description usefully names the returned sections (revenue, cost of sales, expenses, net profit), which is the key missing piece an agent needs. Remaining gaps (comparison columns, pagination/aggregation shape) are minor for a read-only report 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%, so all three parameters including the compare_type enum are already documented in the schema. The description's only parameter-related note, 'Dates are yyyy-mm-dd', duplicates the schema, and it adds nothing about how compare_type interacts with start_date/end_date beyond what the schema states.

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

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

States a specific resource (profit and loss / income statement) and enumerates the line items it returns, plus the underlying endpoint GET /profit_and_loss. An agent can distinguish it from jurnal_get_balance_sheet or jurnal_get_cash_flow by resource alone, though it never names those siblings explicitly.

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

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

There is no guidance on when to pick this report over the balance sheet, cash flow, trial balance or executive summary, and no preconditions are stated. Usage is only implied by the word 'report' and 'for a period'.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing what comes back (lines, taxes, payments), which matters since there is no output schema. It says nothing about behavior for missing IDs or permissions, so it clears the lowered bar without exceeding it.

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

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

Two short sentences, zero filler, with the most useful information (what the response contains) placed first. The raw HTTP path adds little for an agent but is short enough not to be harmful.

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 is the only source on return values, and it only names three payload components at a high level. For a simple single-record read this is minimally adequate, though field-level expectations or not-found behavior are absent.

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% for the single required 'id' parameter, so the schema already carries the semantics. The 'GET /purchase_invoices/{id}' fragment confirms the id is a path identifier but adds no format or constraint detail beyond 'Purchase invoice id.'

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

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

States a specific verb-resource pair (fetch one purchase invoice) and enumerates the payload (lines, taxes, payments), which distinguishes it from jurnal_list_purchase_invoices without needing to open either schema. It never names the sibling explicitly, but the singular scope is unambiguous.

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

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

Usage is only implied by the singular 'One purchase invoice' versus the plural list tools. There is no explicit statement of when to use this over jurnal_list_purchase_invoices, and no prerequisites or error conditions 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value by disclosing that the response includes lines, taxes and payments, but says nothing about auth, missing-id behavior, or error cases.

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

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

Two short sentences, front-loaded with what is returned, then the endpoint. No waste and nothing buried.

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

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

With no output schema, the description usefully previews the response composition (lines, taxes, payments), which is the main thing an agent needs beyond the trivial single-parameter schema. Minor gap on error/not-found 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 coverage is 100% with a single documented 'id' parameter, so the schema carries the semantics. The description's '{id}' path template merely restates it without adding format or sourcing guidance (e.g., where to obtain the id).

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

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

The description states a specific verb and resource ('One sales invoice') and adds the returned content shape (lines, taxes, payments), making it distinguishable from the list_* siblings. It stops short of explicitly naming the alternative tool, but the singular scoping is 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?

Usage is only implied: 'one sales invoice' plus the path template conveys fetch-by-id rather than list. There is no explicit when-to-use or when-not-to-use guidance versus jurnal_list_sales_invoices.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that every account is returned with opening, movement and closing balances, which is genuinely useful behavioral detail in the absence of an output schema, but it says nothing about volume, aggregation level, or whether it is paginated.

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

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

Two short sentences, front-loaded with the content summary. The trailing "GET /trial_balance." is an endpoint restatement that adds little for an agent, but the overall text is far from bloated.

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 three optional parameters and no output schema, the definition covers the basics — the report's content and its period scoping. It leaves open how large the result set is and how it behaves with default (today) dates, gaps an agent may need to discover at call time.

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

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

Schema description coverage is 100% and the enum parameter is fully documented in the schema, so the description only needs to not contradict it. "For a period" adds no syntax, default behavior, or precedence rules beyond what start_date, end_date, and compare_type already state.

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?

"Trial balance for a period" names a specific resource and scope, and the clause about opening/movement/closing balances clarifies what the report contains. It does not, however, distinguish itself from adjacent financial reports such as jurnal_get_balance_sheet or jurnal_get_general_ledger, so an agent must infer which report to pick.

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

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

There is no guidance on when to use this tool versus alternatives — nothing says whether to reach for the trial balance instead of the balance sheet, general ledger, or profit and loss. The only contextual hint is the implicit 'for a period' framing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /vendors/{id}), which hints at a direct remote read, but says nothing about error behavior for a missing id or whether a 404-style result is surfaced.

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

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

One compact sentence with the identity and the provenance of the key argument front-loaded, plus a terse endpoint reference. Nothing redundant.

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

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

For a one-parameter read this is nearly sufficient, and the annotations carry the safety profile. However, with no output schema there is no structured signal about what a vendor record contains or how a missing id is reported, so the description leaves a small but real gap.

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 single 'id' parameter is already documented as 'Vendor id.' with type constraints. The description goes slightly beyond by saying where valid ids come from (jurnal_list_vendors), which is genuine added meaning over the schema.

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

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

States a specific verb and resource ('Get one vendor by id') and disambiguates from the sibling list tool by naming jurnal_list_vendors as the id source. An agent can distinguish this from jurnal_list_vendors and jurnal_get_customer without reading either schema.

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

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

The parenthetical '(from jurnal_list_vendors)' tells the agent the prerequisite step and implicitly when to reach for this tool. It doesn't state exclusions or what to do if the id is unknown, but the usage context is clear for a simple single-record fetch.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond annotations: 'Not paged' — the agent knows the full set comes back in one response and needn't loop for pages. It stops short of noting response size or whether archived accounts appear (that lives only in 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 terse fragments, each earning its place: what it returns, how it behaves (not paged), and how to use the ids. Load-bearing information is front-loaded with no filler.

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

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

With no output schema, the field enumeration plus the 'Not paged' note covers what the agent needs to consume the result correctly. The main remaining gap is that archived-vs-active filtering is only discoverable through the schema parameter, not the description.

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

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

Schema description coverage is 100% and there is a single optional parameter (include_archive) whose schema description already explains the archived-record semantics. The description says nothing about that parameter, so it adds no meaning beyond the schema — baseline 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 names the resource ('chart of accounts') and enumerates the returned fields (id, number, name, category, currency, balance), making the scope concrete. It also gives the underlying endpoint GET /accounts. It doesn't explicitly distinguish itself from the sibling jurnal_get_account (single-account fetch), though the field list implies a bulk listing.

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 gives a clear downstream usage rule: 'Use the ids as account_id in jurnal_get_general_ledger,' which tells the agent when to reach for this tool as a lookup step. It doesn't state when NOT to use it versus jurnal_get_account or other list endpoints, but the context is clear enough for confident selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and openness are covered. The description adds value by enumerating the fields returned (currency settings, feature flags), but says nothing about authentication/credential scoping behavior or pagination semantics beyond what the schema states.

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

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

A single compact sentence that front-loads the resource and appends the endpoint reference; no filler. It could be slightly clearer about the list/pagination nature up front, but it's efficient.

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

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

For a simple read-only list tool with 100% schema coverage, annotations, and no output schema, the description is largely sufficient. The minor gap is that it doesn't flag pagination behavior or its overlap with jurnal_get_current_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 description coverage is 100%, so the schema fully documents both page and page_size. The description adds no parameter-level meaning beyond that, which is acceptable given the high coverage baseline 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 names the resource (the Jurnal company/companies the credential belongs to) and enumerates the fields returned (id, name, industry, address, tax number, currency, feature flags), plus the endpoint GET /companies. It's clear what the tool does, though it leans on the name/title for the 'list' verb and doesn't contrast itself with any sibling.

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

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

There's no when-to-use or when-not-to-use guidance. Notably it doesn't clarify its relationship to jurnal_get_current_user, which likely overlaps in returning credential-associated identity, leaving the agent to infer the boundary between the two.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the paged behavior and the return payload's fields, which annotations do not convey. It omits practical traits such as archived records being included by default (only visible in the schema) and is silent on rate limits or ordering defaults.

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 terse fragments; the returned-field list is front-loaded and the endpoint is appended as a compact anchor with zero filler. It is efficient to the point of being elliptical ('Customers with...' lacks a verb), but nothing is wasted.

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

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

With no output schema, the description usefully compensates by enumerating the returned fields, and the paged hint covers the main invocation concern; the schema handles all five optional parameters. The remaining gap is that it never says how to iterate (next_page) or that including archived records is optional.

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

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

Schema description coverage is 100%, with page, page_size, sort_key, sort_order and include_archive all documented inline, including the archived-by-default caveat. The description only gestures at pagination via 'Paged' and adds no format or default detail beyond the schema, so the baseline 3 applies.

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

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

The description names the exact resource (customers) and enumerates the fields returned (display name, addresses, email, phone, tax number, receivable balance), so an agent knows what the call yields. It states the HTTP verb/path (GET /customers) and that results are paged. It stops short of distinguishing the list operation from the sibling jurnal_get_customer for a single record.

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

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

There is no guidance on when to choose this tool over jurnal_get_customer for a single record, or over jurnal_list_vendors for the payable-side counterpart. The 'Paged' note implies iteration but never tells the agent to follow next_page, nor when to filter versus archive. Usage must be inferred entirely.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are paged and enumerates returned fields, but it does not explain pagination defaults, whether a total count is returned, or how next_page works; that detail exists only in the schema.

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

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

The description is very short and front-loads the useful information: returned fields, pagination, and endpoint. The fragmentary style is terser than ideal, but no sentence is wasted.

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

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

For a simple read-only list tool with full schema coverage and annotations, the description is sufficiently complete. It omits output shape details, but there is no output schema and the description does enumerate the returned fields.

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

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

Schema description coverage is 100%, so all four parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema already provides, which matches the baseline for high schema coverage.

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

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

The description identifies the resource (expenses), its paged nature, and the returned fields, which is enough to infer a paginated expense listing. It does not explicitly state a verb or distinguish itself from jurnal_get_expense, so it falls short of a 5.

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

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

The only usage cue is 'Paged' and the endpoint 'GET /expenses'. There is no guidance on when to use this instead of jurnal_get_expense or other list tools, and no exclusions or prerequisites are stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description's only behavioral addition is 'Paged', which is also fully documented in the schema's page/page_size descriptions, leaving no extra context about ordering, filtering, or what a page contains.

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 short fragments with zero filler, and the resource qualifier is front-loaded. It is efficient, though the telegraphic style leaves no room for any of the missing guidance.

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

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

With no output schema, the description should convey what a journal entry record looks like or at least note there is no filtering support. It says neither, leaving an agent to guess whether entries can be narrowed by date, account, or period.

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% — both page (1-based, use next_page) and page_size (1-100) are well documented in the schema. The description adds nothing about parameters, so the baseline of 3 applies.

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

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

The description identifies the resource as 'Manual journal entries (general journal)', which usefully narrows scope beyond the bare title, but it contains no verb of its own — the listing action is only implied by the tool name. It does implicitly distinguish itself from jurnal_get_journal_entry, but the differentiation is never made explicit.

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

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

There is no guidance on when to call this versus jurnal_get_journal_entry, jurnal_get_general_ledger, or jurnal_get_trial_balance, all of which touch similar accounting data. 'GET /journal_entries' is an implementation detail, not a usage condition.

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 annotations already declare this is a read-only, open-world operation, so the description need not carry the full safety profile. It adds useful behavior with 'Not paged' and the underlying GET endpoint, but does not describe authentication requirements, rate limits, or return shape.

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

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

The description is extremely short and front-loads the resource, the no-pagination behavior, and the endpoint. Every fragment adds some useful context without redundant explanation.

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

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

For a zero-parameter, read-only list endpoint with annotations covering safety, the description is sufficiently complete to call the tool correctly. It does not detail the returned fields, but the resource is simple and examples are provided.

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

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

The tool has zero parameters and an empty schema, so parameter semantics are inherently complete. The description also notes 'Not paged,' which reinforces that no pagination parameters are expected.

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 identifies the specific resource as payment methods and gives examples (cash, transfer), and the title/name supply the list verb. It is clear enough to distinguish this from siblings like jurnal_list_taxes or jurnal_list_accounts, though the description itself does not explicitly say '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?

Usage is implied: call this to obtain payment methods, and 'Not paged' indicates no pagination handling is needed. There is no explicit when-to-use guidance versus alternatives, but the resource is narrow and unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's one real contribution is "Not paged", which tells the agent the full set returns in a single call with no offset/limit — useful, but it says nothing about result size, ordering, or shape.

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 terse fragments, front-loaded and waste-free. "Product categories" largely duplicates the title, but no sentence is padded and the pagination constraint sits early.

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

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

For a zero-parameter read with annotations covering safety, this is minimally sufficient to call correctly. It falls short of complete because nothing describes what comes back or whether the list is large enough to need client-side handling.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; "Not paged" is consistent with an empty 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?

"Product categories" plus the endpoint identifies the resource, and the title supplies the verb (List). It is essentially a noun-phrase restatement though — it does not say what a category contains or how it differs from the nearby jurnal_list_products beyond the name itself.

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

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

No when-to-use guidance and no mention of alternatives such as jurnal_list_products (to resolve a product's category id) or jurnal_list_tags. The only usage-adjacent hint is "Not paged", which at least tells the agent not to look for page parameters.

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?

readOnlyHint=true and openWorldHint=true already establish this as a safe read against a live external system, so the description carries a reduced burden. It adds that results are paginated and names the upstream endpoint, but says nothing about default page size, rate limits, or the archive-inclusion behavior that a caller might care about — that detail is left entirely to 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?

Two terse sentences plus an endpoint marker, front-loading the resource and returned fields before the paging note. Nothing is wasted, though the telegraphic fragment style trades some readability for density.

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 compensates by listing the fields the caller will receive, which is exactly what's needed for a read-only list tool. Combined with full schema coverage and clear annotations, an agent has enough to call this correctly; only the sibling-routing guidance is missing.

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

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

Schema description coverage is 100% and each of the five optional parameters has its own description, including the include_archive default quirk. The description's field list loosely maps to some sort_key values but adds no new parameter meaning, so the baseline of 3 applies.

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

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

Names the resource (products and services) and enumerates the returnable fields (code, name, buy/sell prices, stock, category, units, active flag), which clearly identifies a product-listing operation. It does not explicitly distinguish itself from jurnal_get_product (single-record fetch) or jurnal_list_product_categories, so sibling differentiation is only implied.

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?

"Paged" and the endpoint hint imply a paginated listing, but the description gives no guidance on when to use this versus jurnal_get_product or jurnal_list_product_categories, and no prerequisites or exclusions. The only actionable direction (use next_page) lives in the parameter schema, not the description.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered. The description adds useful context that results are 'Paged' and gives the endpoint GET /purchase_invoices, but says nothing about auth, rate limits, or default ordering.

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

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

Three compact fragments with the resource and returned fields front-loaded and no filler. Terseness is appropriate for a list endpoint, though it borders on telegraphic.

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 usefully enumerates return fields (number, vendor, dates, status, total, balance due) and notes paging. Combined with full annotation and schema coverage, it is adequate, though usage routing is the one real gap.

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

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

Schema description coverage is 100%, so the schema fully documents all six parameters including the conditional date-range behavior. The description adds no parameter meaning beyond the 'Paged' hint, which the schema already covers via the page field.

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

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

States the resource (purchase invoices) and clarifies it as 'bills from vendors', then enumerates key fields. The plural 'list' contrast with the sibling jurnal_get_purchase_invoice is implicit but never named, so it stops short of explicit differentiation.

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

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

There is no when-to-use or when-not-to-use guidance. It does not point to jurnal_get_purchase_invoice for a single record or to jurnal_list_purchase_orders for a related resource, leaving the agent to infer selection from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the paged nature and the underlying endpoint, which is useful context for an agent, but says nothing about default sort order, filtering availability, or result limits beyond 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?

Three short fragments with zero redundancy; the resource and returned fields are front-loaded and the pagination/endpoint notes follow. Nothing could be cut without losing 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 two-param list tool with no output schema, this is adequate but thin: it never states that no filtering parameters are supported, nor what pagination metadata is returned. An agent knows how to call it but not much about what to expect back.

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

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

Schema description coverage is 100%, with page and page_size both documented including ranges and the next_page convention. The description only echoes 'Paged', adding no semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific resource (purchase orders) plus the fields returned (vendor, dates, status, totals) and the endpoint, so it is clearly a listing operation. It does not explicitly distinguish itself from the nearby jurnal_list_purchase_invoices or jurnal_get_purchase_invoice, relying on the name alone for that separation.

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

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

There is no guidance on when to use this versus the singular get_purchase_invoice or the often-confused purchase invoice list. The 'Paged' note implies bulk retrieval, but no exclusions, prerequisites, or alternative routing are offered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only 'Paged' and the endpoint path; it says nothing about ordering, default filters, auth requirements, or what a payment record looks like, which leaves meaningful behavioral gaps even at the lower annotated bar.

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 short fragments, front-loaded and free of filler. The trailing 'GET /purchase_payments' adds little an agent needs for selection, but the overall size is appropriate for a simple list tool.

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 read-only paged list with full schema coverage and no output schema, the minimum is met. However, nothing tells the agent what fields a returned payment contains or how pagination termination is signalled, so it is only barely 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% and both parameters (page, page_size) carry full descriptions including bounds and the next_page convention, so the schema does all the work here. The description adds no parameter meaning beyond it, which is the baseline 3 case.

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 identifies the resource as vendor payments tied to purchase invoices, which does separate it somewhat from jurnal_list_purchase_invoices and jurnal_list_receive_payments. But it is a noun fragment with no verb, so the agent must infer 'list' from the tool name and title rather than the description.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of when to prefer a sibling such as jurnal_list_purchase_invoices or jurnal_list_receive_payments instead. The only guidance-like content is the pagination note, which is not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only 'Paged' plus the raw endpoint; it says nothing about auth requirements, rate limits, ordering, or default page size behavior.

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

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

Three short fragments, front-loaded with the resource definition and zero filler. The trailing 'GET /receive_payments' is marginal but harmless; the telegraphic style stops just short of perfectly structured prose.

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 two-param paged list with annotations covering safety, this is adequate. However, with no output schema, the description gives no hint of what a payment record contains, leaving the agent to guess at the response shape.

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?

Both parameters are fully documented in the schema (100% coverage), including next_page guidance and the 1-100 page_size bound. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names the specific resource (customer payments received against sales invoices) and implies the list verb through 'Paged'. The 'customer ... against sales invoices' phrasing distinguishes it reasonably from jurnal_list_purchase_payments, though it never names that sibling 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?

Usage is only implied: an agent can infer it lists received customer payments, but there is no explicit 'use this when...' or exclusion against jurnal_list_purchase_payments, jurnal_get_sales_invoice, or the get_* payment siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds pagination behavior ('Paged', page_size limits implied) and the underlying GET endpoint. It stops short of stating that no filtering is available, which is the most consequential behavioral fact an agent needs here.

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 short sentences, front-loaded with the resource and its fields, then the sort use case, then pagination. The telegraphic style ('Paged. GET /sales_invoices.') is compact but slightly clipped.

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 field enumeration doubles as return-value documentation, which is exactly what's needed for a 4-parameter list tool. The main gap is the absence of any statement about filtering capability, so an agent may assume filters exist when only paging and sorting are supported.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns above that by translating raw field names into business meaning: original_amount is the invoice total and remaining is the balance due. It also explains the intent behind the sort_key values (recency vs. unpaid), which the enum alone does not convey.

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?

Names the resource (sales invoices) and enumerates the returned fields plus the sortable ones, and 'Paged' plus the endpoint confirm this is a collection read rather than a single-record fetch. It does not explicitly contrast itself with jurnal_get_sales_invoice, but the field-list-plus-pagination framing makes the distinction inferable.

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?

'Sort by transaction_date or remaining to find recent or unpaid ones' gives real usage guidance for a common task, but there are no exclusions or named alternatives (e.g. use jurnal_get_sales_invoice for a single invoice's detail). Usage is implied rather than prescribed.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered structurally. The description adds 'Paged' and the underlying endpoint GET /sales_orders, which is useful for understanding behavior, but says nothing about authentication, rate limits, default ordering, or whether any filtering is supported.

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 short fragments, front-loaded with the resource and its fields before the pagination and endpoint notes. Nothing extraneous, though the telegraphic style borders on under-specification rather than tightness.

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

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

For a zero-required-param paged list tool, the definition covers what the records contain and how pagination works via the schema. With no output schema, however, the agent gets no sense of the response envelope, pagination metadata, or how to narrow a potentially large result set.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including the useful hint to use next_page from the previous reply. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

The name plus description clearly indicate a list operation over sales orders, and the field list (customer, dates, status, totals) tells the agent what each record contains. It does not explicitly distinguish itself from near siblings like jurnal_list_sales_invoices or jurnal_list_purchase_orders, relying on the noun alone.

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

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

There is no guidance on when to choose this over jurnal_list_sales_invoices, jurnal_list_sales_quotes, or jurnal_list_purchase_orders, nor any statement of exclusions or prerequisites. The only call context given is the implicit 'it's paged'.

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?

readOnlyHint=true and openWorldHint=true already declare the safety profile, so the description's job is to add context. It contributes the pagination trait and the returned fields, which is useful, but it says nothing about ordering, default page size, or the empty-result case.

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 short fragments with zero filler, and the payload content (returned fields) is front-loaded. The telegraphic style borders on under-specification rather than verbosity.

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

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

For a two-parameter read-only lister with a fully described schema and annotations, this covers resource identity, payload fields and pagination. Only ordering/defaults are left implicit, which is a minor gap, not a blocking one.

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 both parameters are documented in the schema with bounds and a pointer to next_page. The description adds nothing parameter-specific beyond 'Paged', 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?

Names the resource precisely as 'Sales quotes (offers)' and enumerates the fields returned (customer, dates, status, totals), which lets an agent recognize it apart from the many sibling list_* tools for other resources. However, no verb is stated and it draws no line against jurnal_list_sales_orders or jurnal_list_sales_invoices, which are the genuinely confusable siblings.

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

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

The description says 'Paged' and the schema mentions next_page, but there is no statement of when to pick this tool over the sales-order or sales-invoice listers, no precondition, and no guidance on page_size selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description contributes "Not paged", which is genuinely useful — it tells the agent the whole collection comes back in one call with no offset/limit handling — but says nothing about return shape or result size.

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 short fragments, front-loaded with the resource, then the pagination trait, then the endpoint. Nothing is padded, though the telegraphic style borders on under-specification rather than tight prose.

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

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

For a zero-parameter read tool this covers the essentials (what, no paging, source endpoint), but with no output schema the description never indicates what a tag object contains or whether the list is account-wide. An agent knows how to call it but not what it will receive.

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

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

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter confusion is possible.

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?

"Transaction tags" plus "GET /tags" identifies the resource and implies a full retrieval, and the title supplies the verb "List". However the description itself is a noun fragment rather than a stated action, so an agent relies on the title to know it enumerates rather than filters or creates 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?

There is no guidance on when to call this versus siblings such as jurnal_list_journal_entries or jurnal_list_payment_methods, nor any prerequisite or exclusion. The only implied usage cue is that it is the sole tag-listing 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are paged and names the underlying endpoint, but says nothing about total counts, page limits, or what a tax record contains.

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 terse fragments with the resource front-loaded and no filler. The 'GET /taxes' endpoint note earns marginal keep for agents that map to HTTP, but it is telegraphic rather than explanatory.

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 two-parameter read-only list tool with full schema coverage, the description is minimally adequate. With no output schema, it doesn't describe what fields a tax record exposes (rate, code, whether it's a VAT/withholding type), leaving the agent to infer the return shape.

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 both parameters (page, page_size) are fully documented in the schema, including the 'use next_page from the previous reply' guidance. The description's only contribution is the word 'Paged', which duplicates rather than extends that.

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?

Names the resource specifically ('the company's tax rates') and gives concrete examples (PPN, PPh) that disambiguate it from the many other list_* siblings. It lacks an explicit verb like 'list' and relies on 'Paged' plus the tool name to convey it returns a collection.

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

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

There is no statement of when to use this versus alternatives (e.g., other lookups for tax-related data) and no prerequisites or exclusions. The only usage signal is the implied 'Paged' hint about iterating pages.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful signal by listing what fields come back (including payable balance), which matters because there is no output schema, but it says nothing about result volume, defaults, or ordering behavior beyond the word 'Paged'.

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 terse fragments with zero filler, front-loading the resource and its fields before the paging note. Nothing could be removed without losing 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?

With no output schema, the description correctly compensates by listing the returned fields, and the schema covers all five parameters including archive semantics and paging defaults. Only the absence of guidance on total counts or result caps keeps it from a 5.

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

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

Schema description coverage is 100%, with both enums and pagination bounds fully documented in the schema itself. The description adds no parameter-specific meaning beyond implying pagination, so the baseline 3 applies.

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

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

The description names a specific resource (vendors/suppliers) and enumerates the returned fields, so an agent immediately knows this is a paged vendor listing. It stops short of explicitly distinguishing itself from jurnal_get_vendor or jurnal_list_customers, relying on the name alone for that routing.

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?

'Paged. GET /vendors.' implies pagination usage, and the schema note about next_page reinforces it. But there is no explicit guidance on when to choose this over jurnal_get_vendor, or when to set include_archive, leaving retrieval strategy to inference.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context that results are paged and that an inventory-enabled plan is required, but it does not explain return format or failure behavior when the plan requirement is unmet.

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 very short and front-loads the resource, prerequisite, paging, and endpoint. The telegraphic fragments are efficient, though not fully sentence-structured.

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

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

For a simple read-only list tool with fully described parameters and safety annotations, the description supplies the key extra context: inventory-plan prerequisite, pagination, and endpoint. It could say more about returned warehouse fields, but no output schema exists and the core call context is present.

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

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

Schema description coverage is 100%, and the schema already documents page and page_size semantics. The description's 'Paged' note adds no parameter detail beyond the schema, 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?

The description identifies the resource (warehouses) and the endpoint (GET /warehouses), and the title/name make the list operation clear. It distinguishes itself from siblings by resource but does not explicitly contrast with other list endpoints.

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 states a prerequisite (a Jurnal plan with inventory) but does not say when to use this tool versus alternatives or when not to use it. No sibling routing guidance is provided.

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