Yuki MCP by usefulapi

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds which data fields come back, which is useful given no output schema, but says nothing about not-found behavior, domain scoping needs, or permissions.

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 tight sentence with the resource and returned fields front-loaded, followed by a short internal API reference. The 'Archive.FindDocument' token is provenance rather than instruction but costs little.

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 lookup with full schema coverage and no output schema, the description covers what it returns and how it is addressed. Only the missing link to the download/lookup siblings and error behavior keep it from being fully complete.

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

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

Schema description coverage is 100% and both parameters (domain_id, document_id) are documented with patterns and sourcing hints. The description only echoes 'by id', adding no format or fallback 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?

States a specific verb and resource: retrieve details of one archive document by id, and enumerates the fields returned (subject, type, contact, dates, amounts, folder). The phrase 'one archive document by id' implicitly separates it from list/search siblings, though it never names yuki_list_documents or yuki_search_documents.

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 id' plus the schema note that the id comes from a document list suggests it is the follow-up call after listing or searching. No explicit when-to-use, when-not, or named alternative (e.g. yuki_get_document_download_url for the file itself) 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses genuinely useful behavior: the URL is presigned, time-limited, and meant to be opened in a browser rather than fetched by the agent. It stops short of saying whether URL generation requires specific permissions or what happens if the document has no attached file.

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 tightly packed sentence with the key fact (presigned URL) front-loaded and the two operational caveats in parentheses. The trailing 'Archive.DocumentDownloadUrl' identifier is redundant noise but costs only a few tokens.

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

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

There is no output schema, so the description carries the return-value burden and does: it explains that the result is a presigned URL, that it expires quickly, and how to use it. For a two-parameter read tool with full annotation coverage, nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, and both parameters already document their provenance (domain_id from yuki_list_domains, document_id from a document list), so the baseline of 3 applies. The description reinforces the single-document scope but adds no format or behavioral detail about the parameters themselves.

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 output: a presigned download URL for the file of one archive document. This clearly differentiates it from yuki_get_document (document metadata) and the list/search siblings, though it never names an alternative explicitly. The trailing 'Archive.DocumentDownloadUrl' is a bare API type reference that adds little.

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

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

The description implies the intended flow (obtain link, open in browser) and the schema hints the id comes from a document list, but there is no explicit when-to-use versus yuki_get_document or yuki_search_documents, and no stated prerequisite that a document_id must first be discovered. Usage must be inferred.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is genuinely useful, but says nothing about pagination limits, empty results, or result size behavior 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 with the key scoping detail (per-administration, per-date) front-loaded; the trailing 'Accounting.GLAccountBalance.' type reference is slightly cryptic filler but costs little.

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 list tool with a fully documented 4-parameter schema and no output schema, the description covers scope, date semantics and return fields adequately. Only cross-tool routing (vs. transactions/scheme tools) is left implicit.

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 already documented in the schema, including date pattern, limit bounds and the next_offset pagination hint. The description only restates the date format, adding no semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource: returns balances of every GL account for an administration on a given date, and even enumerates the returned fields (account code, description, amount). It implicitly separates itself from yuki_list_gl_account_transactions (balances vs. individual postings) but never names that sibling, so it stops short of a 5.

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

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

The 'on a date' scoping implies the tool is for point-in-time balance snapshots, but there is no explicit when-to-use/when-not, no mention of the alternative transaction-listing tool, and no stated prerequisite such as resolving administration_id via yuki_list_administrations.

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, destructiveHint=false, and openWorldHint=true, so safety is covered structurally. The description adds the field-level output shape and the underlying API method name, but says nothing about pagination limits, what an empty chart looks like, or latency/scope caveats beyond the annotations.

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

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

Two short sentences, front-loaded with what is returned before the cross-reference. The trailing API method token (AccountingInfo.GetGLAccountScheme) is developer metadata that adds little for an agent, keeping it just below a 5.

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 three fully documented optional params and no output schema, the description supplies the returned field list and the sibling relationship, which is what an agent needs. Missing only pagination behavior notes, which the schema largely covers.

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% — limit, offset, and administration_id are each documented with defaults and the next_offset continuation pattern. The description adds no parameter-level meaning, so the baseline 3 applies; the schema is doing all the work.

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

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

The description names the specific resource (general ledger accounts / chart of accounts), scopes it to an administration, and enumerates the returned fields (code, description, type). It is clearly distinguishable from sibling balance/transaction tools. The retrieval verb is only implicit, but the resource and output shape are 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?

"Use the codes in yuki_list_gl_account_transactions" gives a genuine relational hint about downstream use and implicitly signals this is the lookup step before transaction work. However, it never states when to call this versus yuki_get_gl_account_balance or when *not* to bother, so guidance is implied rather than explicit.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying that revenue is aggregated by transaction date and mapping to 'Accounting.NetRevenue', but it does not explain return units, currency, or aggregation behavior.

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

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

The description is compact and front-loads the resource and scope in a single sentence. The trailing 'Accounting.NetRevenue' reference is slightly opaque but does not waste much space.

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 tool with fully documented parameters, the description covers the essential purpose and date semantics. However, because no output schema exists, it leaves the return format, currency, and aggregation details unstated, which are relevant for interpreting a net revenue result.

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 are already documented. The description adds meaning beyond the schema by clarifying that the date range filters by transaction date rather than another accounting date, which is useful for correct invocation.

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 ('net revenue/turnover'), scopes it to 'an administration' and 'a date range', and clarifies the date basis ('by transaction date'). It is clearly a retrieval operation, though it does not explicitly distinguish itself from sibling reporting tools such as yuki_get_gl_account_balance.

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 stated preconditions or exclusions. Usage is only implied by the resource name and date-range mention.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value beyond that: it discloses the access-control scope ('this access key can reach') and the exact payload fields (id, name, address, CoC and VAT numbers, start date), which matters because there is no output schema. Pagination behavior 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 tight sentences: identity and returned fields first, then the actionable instruction. No filler, no restatement of the title.

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

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

With no output schema, the field enumeration is essential and present, and the access-key scoping is a meaningful constraint. The only shortfall is that it says nothing about result volume or how to page through a long list, which the schema only partially covers.

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 offset parameter is fully documented in the schema, including the next_offset continuation hint. The description says nothing about pagination or result-set size, so it adds no meaning beyond the schema — baseline 3 applies.

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

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

States a specific verb (List) and resource (administrations), disambiguates the term with a parenthetical definition ('companies with their own books'), and scopes it to what the access key can reach. It also enumerates the returned fields, so an agent can tell this apart from siblings like yuki_list_domains or yuki_list_projects without opening any 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?

'Use the ids in the other tools' gives downstream context — this is the id-discovery step — which implies when to call it. But no sibling is named as an alternative and no exclusion or precondition is stated, so the agent must infer that this is the entry point rather than, say, yuki_list_domains.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is handled. The description adds genuinely non-structured behavior: the implicit domain-resolution rule for multi-domain accountant keys and the default scoping when the parameter is omitted, which an agent cannot infer from the annotations.

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

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

Two sentences, front-loaded with the returned resource and fields, then the one conditional that matters. The trailing 'Archive.DocumentFolders.' is a bare API namespace tag that adds little for an agent choosing a tool, but it is a minor 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 single optional parameter, no output schema, and annotations covering safety — the description supplies the return fields and the domain-scoping behavior, which is enough to call it correctly. It does not mention ordering, volume, or whether folders are returned hierarchically, which would matter for a folder-listing call.

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 schema already tells the agent to source the id from yuki_list_domains. The description nevertheless adds the resolution rule that is not in the schema — that omission defaults to the key's only domain — which clarifies what actually happens rather than just repeating the pattern constraint.

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 precisely ('folders of the document archive') and the returned fields (id, name), so the agent knows exactly what it gets back. The verb is implicit ('The folders of...') rather than stated, and it never distinguishes itself from the nearby sibling yuki_list_document_folder_tabs, which an agent could easily confuse it with.

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 guidance is scoped to the parameter rather than the tool: it explains that domain_id should be passed when an accountant key spans several domains and that otherwise the key's single domain is used. There is no statement of when to choose this tool over yuki_list_documents, yuki_list_document_folder_tabs, or yuki_search_documents.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by stating the scope is one archive folder and that the results contain id and name, but it does not discuss pagination, permissions, or response behavior beyond those fields.

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, but it is a fragment rather than a front-loaded action statement, and the trailing internal reference 'Archive.DocumentFolderTabs' does not add useful guidance for an agent. It is concise but under-specified for a tool definition.

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

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

The tool is a simple read-only list operation with full schema coverage and annotations, and the description does mention the returned fields (id, name). However, it lacks usage context and any guidance about relationship to the parent folder-listing tool, leaving an agent to infer how this fits into the workflow.

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

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

Schema description coverage is 100%, and both parameters are documented in the schema, including where folder_id comes from. The description does not add meaning beyond the schema, which is expected when the schema already does the heavy lifting.

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

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

The description clearly identifies the resource (tabs inside one archive folder) and states the key return fields (id, name), so an agent can infer it is a listing operation. It does not explicitly differentiate itself from nearby siblings such as yuki_list_document_folders, but the per-folder scope 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites. The only implicit requirement is that it operates on an existing folder, but the description does not tell the agent when this is the right choice over other list tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered by structured data. The description adds the pagination strategy ('page with number_of_records and start_record') and the returned field set, but nothing about truncation behavior, batch limits, or ordering defaults beyond what the schema says.

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 payload, then filters, then paging — no wasted prose. The trailing 'Archive.Documents / DocumentsInFolder / DocumentsByType' string is cryptic service-operation jargon with no explained meaning, a minor blemish.

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 the document fields returned (id, subject, type, contact, dates, amount), which is the main gap it needs to fill for a 9-parameter read tool. The missing piece is guidance on large result sets and how this differs from the search sibling.

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

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

Schema description coverage is 100%, so every parameter including the offset/next_offset truncation note and the folder-vs-type exclusion is already documented in structured fields. The description's mention of folder, type, date range, and paging only restates schema content, earning the 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?

Opens with a concrete verb+resource ('Documents in the archive') and enumerates the returned fields plus the narrowing dimensions, so an agent knows exactly what it gets back. It never names the obvious sibling yuki_search_documents, so the boundary between plain listing and searching is left implicit.

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

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

Implied usage is clear — list, optionally narrowed by folder, type, or creation date range — but there is no statement of when to prefer this over yuki_search_documents or when to fall through to yuki_get_document. The mutual exclusivity of folder_id and document_type is only stated in the schema, not here.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the real behavioral fact that results are scoped by the access key and that accountant keys return many domains, but says nothing about result size, pagination behavior, or typical volume.

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 front-loads the resource and the returned fields, with no wasted clauses. The trailing fragment "Accounting.Domains." is leftover API-reference noise that an agent cannot use.

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, zero-required-parameter list tool with no output schema, the description covers what is listed and how results are scoped. The main omission is the relationship to yuki_list_administrations, which is likely the natural follow-up call.

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

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

There is a single optional parameter with 100% schema description coverage, including the cursor-continuation hint ("Use the previous reply's next_offset to read on"). The description adds no meaning beyond that, 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 gives a specific verb and resource and clarifies the domain model with a parenthetical ("customer environments"), plus the exact fields returned (id, name, URL). It does not differentiate from the sibling yuki_list_administrations, which an agent could easily confuse with domains in this API's terminology.

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?

"Accountant keys reach many domains" hints at the context in which this call is useful (discovering accessible environments), but no explicit when-to-use or when-not-to-use guidance is given, nor which sibling to call next. Usage 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?

Beyond the safety hints in annotations, the description lists the specific data fields returned (date, description, amount, contact, project). This informs the agent exactly what kind of data structure to expect in the output.

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 definition is concise, presenting the function and scope in one dense sentence. The information is front-loaded with the core 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?

The definition is highly complete for a retrieval tool. It defines the scope, provides the dependency (schemes), and specifies the result structure, leaving no critical operational details 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?

Since the input schema coverage is 100%, the description cannot add new semantic value to the parameters. It maintains the baseline score of 3, though the contextual reference to the prerequisite tool helps mitigate low semantics.

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

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

The tool clearly states its purpose: listing transactions booked on a single general ledger account within a specific date range. It provides the output fields (date, description, amount, etc.), which aids clarity.

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

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

The description provides a crucial workflow guideline by directing the user to the prerequisite tool (yuki_get_gl_account_scheme) for obtaining valid account codes. This guides the agent on the necessary sequence of calls.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is useful given there is no output schema, but says nothing about include_bank_transactions behavior or the difference between the two named API operations.

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 clauses front-load the resource and field list, then the optional range. The trailing "Accounting.OutstandingCreditorItems / OutstandingCreditorItemsByDate" is cryptic endpoint jargon but does hint at two modes.

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 enumerated field list is exactly what the description needs to carry, and the pagination hints live in the schema. It falls short only on explaining the bank-transactions flag and the dual-operation naming.

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

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

Schema description coverage is 100%, so the baseline is 3; the description's list of returned fields and the date-range note add mild corroboration. It does not extend meaning for parameters like include_bank_transactions or sort_order, so it stays close to baseline.

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

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

States a specific resource (open items on the creditors list) clarified as unpaid purchase invoices, and enumerates the fields returned. That wording implicitly separates it from yuki_list_outstanding_debtor_items (sales invoices), but the sibling is never named.

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?

"Optionally within a date range" hints at when the date parameters apply, but there is no explicit guidance on when to choose this over the debtor-items sibling or how the two underlying operations are selected. Usage has to be inferred.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered elsewhere. The description confirms the tool reads open (unpaid) items only, which is meaningful scope, but says nothing about pagination behavior, result size limits or how 'open' is determined (e.g. partial payments).

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, the core resource is front-loaded and the field inventory follows in a compact list. Nothing redundant, and the trailing API constant names cost little.

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 seven optional parameters and no output schema, listing the returned fields (date, contact, open and original amount, reference, due date) usefully compensates for the missing return spec. The remaining gap is that paging and administration scoping are left entirely to the schema descriptions.

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 limit, offset, sort_order, the date range and include_bank_transactions are all self-documented. The description only restates the optional date range and the returned field list, adding no semantics 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?

States a specific verb+resource: 'Open items on the debtors list (unpaid sales invoices)', and enumerates which fields come back. The debtor/creditor split implicitly separates it from yuki_list_outstanding_creditor_items, but that alternative is never named.

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?

Only 'Optionally within a date range' hints at usage. There is no statement of when to pick this over yuki_list_outstanding_creditor_items or yuki_list_gl_account_transactions, and no prerequisites such as needing an administration_id when the key spans multiple administrations.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds value by enumerating returned fields (code, description, company, contact, period, budgets) in the absence of an output schema, but says nothing about pagination, result caps, or auth/permission requirements.

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 front-loaded sentence covering purpose and returned fields, plus a short API-reference tag. Nothing is padded; the tag 'AccountingInfo.GetProjects' is low-value jargon 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 no output schema, listing the returned fields is the right compensating move, and the schema fully documents all five parameters. What remains missing is minor: no note on sizing expectations or cross-reference to yuki_list_administrations for the id.

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 each parameter documented including defaults, ranges, the enum, and the next_offset pagination idiom. The description's only added phrasing is 'optionally filtered', which does not explain how search_value and search_option interact beyond what the schema already 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 verb+resource ('Projects of an administration') and lists the fields returned, which lets an agent tell this apart from document/GL-account siblings. No sibling is named as an alternative, but none is a near-duplicate either.

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?

Only 'optionally filtered' hints at usage; there is no statement of when to choose this over other list tools, nor when it should not be used. An agent must infer that administration_id comes from yuki_list_administrations on its own.

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 destructiveHint=false, so safety is covered. The description adds pagination behavior (max 100 per page, follow next page_number until empty), which is useful, but says nothing about match semantics (partial vs exact), permissions, or result contents.

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?

Front-loaded with the purpose and searchable fields, then pagination in a compact second sentence. The trailing internal reference 'Contact.SearchContacts.' is clutter but minor.

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 search tool with a fully documented schema, the description covers domain scoping, empty-search behavior, and paging until empty. It is nearly complete, missing only how matching works (substring vs exact) and a brief note on returned contact 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 every parameter including enums is already documented. The description's field list largely duplicates the search_option enum and adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb and resource (search contacts, including customers and suppliers) and enumerates the searchable fields, so an agent can tell this is the contact-search tool. It does not explicitly contrast itself with the sibling yuki_search_documents, relying on the resource name to make 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?

The description implies usage (search by field, empty search lists all) and gives a pagination loop, but never states when to prefer this over sibling search/list tools or what prerequisites (domain id) are needed.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the search can be scoped to folder, tab, and date range, but says nothing about result batching/truncation behavior even though the schema's offset description hints at it, and the trailing 'Archive.SearchDocuments' is an endpoint tag rather than useful 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?

Two short sentences with the core action and the optional narrowing front-loaded, then a terse endpoint reference. Nothing is padded or buried.

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

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

For an 11-parameter read-only search, the description covers the primary search axis, the field selector, and all the optional scoping filters, and the schema carries the rest. It would be fully complete if it mentioned paging/next_offset behavior and how it differs from yuki_list_documents.

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

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented with defaults, ranges, enums, and date formats. The description restates the searchable field set and the optional filters, which reinforces the enum semantics but adds no format or constraint information beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource (search archive documents) plus the searchable fields and the optional folder/tab/date narrowing, so the operation is unmistakable. It never names yuki_list_documents or another sibling, so the agent must infer from the names that listing vs. text-searching are different entry points.

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: 'search by text' suggests this tool when the caller has a query string rather than a browse/list intent. There is no explicit when-to-use, when-not-to-use, or pointer to yuki_list_documents for unfiltered enumeration.

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