e-Boekhouden MCP by usefulapi

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

Annotations only carry destructiveHint=true, but the description adds crucial context beyond that: the operation is PERMANENT, invoices cannot be changed or deleted, and an invoice number is consumed. It also discloses side-effect scope (not emailed, not booked, no direct debit), which an agent cannot infer from the annotation alone.

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

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

Front-loads the purpose, then the irreversibility warning, then prerequisites, then the return value. Every sentence carries information an agent needs, 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?

Despite having no output schema, the description states the return value (new id and invoice number) and covers the mutation's irreversibility and side effects. For a 9-parameter write tool this is complete enough to invoke safely.

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 reinforces the required fields and points to eboekhouden_list_invoice_templates for template_id, but adds little syntax or format detail beyond what the schema already documents for all 9 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?

States a specific verb and resource ('Create a sales invoice for a relation') and clearly distinguishes itself from siblings like eboekhouden_get_invoice and eboekhouden_list_invoices. The scope is unambiguous without opening the schema.

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

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

Gives concrete prerequisites (relation_id, template_id, term_of_payment, at least one item with ledger_id) and explicitly scopes out adjacent behaviors ('NOT e-mailed', 'NOT booked as a mutation', 'no direct debit'). It does not name a competing sibling or a when-not-to-use alternative, so it falls short of a 5.

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

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

Annotations only supply destructiveHint=true, so the description carries most of the burden. It adds real value by disclosing the return ('Returns the new id') and the price XOR rule, but says nothing about idempotency, duplicate-code behavior, error conditions, or what the destructive hint means for a create operation.

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

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

Three short sentences, each earning its place: purpose, required inputs plus the key constraint, and the return value plus endpoint. Front-loaded with the action and free of 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 correctly compensates by stating the return value ('the new id'). Combined with the required-field and XOR rules, an agent has enough to invoke it correctly; only failure/idempotency behavior is unaddressed.

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

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

Schema coverage is 100%, so the schema already documents all 12 parameters including the price_excl/price_incl mutual exclusion. The description restates the required set and the XOR constraint, adding no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource ('Create a product or service') and names the endpoint (POST /v1/product), making it trivially distinguishable from siblings like create_invoice or create_relation. It also clarifies the tool covers services, not just physical products.

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

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

The description gives preconditions (needs code, description, sale VAT code, ledger id, and exactly one of price_excl/price_incl), which is useful invocation guidance. However, it never states when to prefer this tool over an update path or what prerequisites (e.g. fetching a ledger id) must exist first, so usage context is only implied.

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

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

Annotations only supply a title and destructiveHint=true, so the description carries most of the behavioral burden. It adds useful facts beyond annotations: the code is auto-generated when omitted, the call returns the new id and code, and the underlying endpoint is POST /v1/relation. However, it says nothing about authentication needs, whether a duplicate name is rejected, or what side effects creation has.

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, zero filler, and the core purpose is front-loaded ahead of the parameter rule and return/endpoint detail. Every sentence contributes something an agent can act on.

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

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

There is no output schema, and the description does cover the return value ('the new id and code'), which is the key completeness item. For a 23-parameter mutation with thin annotation coverage, though, the description leaves most fields and all permission/failure behavior undocumented, so it is only minimally 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?

With 23 parameters and only 43% schema description coverage, the description would need to compensate for a large documentation gap. It only addresses two fields ('only name is required', 'code generated when omitted'), and the required/auto-generation facts are already implied by the schema's required array and the code field description, leaving roughly twenty fields such as bic, iban, ledger_id and term_of_payment unexplained.

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 relation') and clarifies the entity scope by naming the two subtypes (customer or supplier) in the administration. It is clearly distinguishable from update_relation and list_relations by the verb, though it does not explicitly contrast itself with those 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?

Usage is only implied by the verb: an agent can infer this is for new relations rather than edits or lookups. There is no explicit when-to-use guidance, no mention of prerequisites (e.g. that ledger_id comes from list_ledgers), and no pointer to update_relation as the alternative for existing records.

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 already tells the agent this is a safe read. The description adds only the HTTP endpoint, which marginally signals it is a plain fetch, but says nothing about not-found behavior, return shape, or authentication needs.

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 with zero waste and no buried information. It is appropriately sized for a trivial single-record fetch, though close to under-specified rather than truly concise.

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

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

For a read-only single-record get with a fully documented parameter and no output schema, the minimum needed to invoke correctly is present. However, with no output schema, some indication of what the fetched cost center contains would improve completeness.

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

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

Schema description coverage is 100% and the single id parameter is documented in the schema, including where to obtain it (eboekhouden_list_cost_centers). The description adds nothing beyond this, so the 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 name plus 'One cost center' identifies the verb and resource, and the endpoint path adds specificity, but the description is largely a restatement of the tool name. It does not explicitly distinguish itself from the sibling eboekhouden_list_cost_centers, leaving the singular-vs-list distinction 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?

No statement of when to use this versus eboekhouden_list_cost_centers or any other tool. The word 'One' weakly implies fetching a single record, but there is no explicit context or alternative 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, so the safety profile is covered and the bar is lower. The description usefully discloses what the response contains (items, amounts, relation), which matters because no output schema exists, but it says nothing about pagination, error behavior, 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?

Two compact sentences with the returned content front-loaded and the endpoint pattern following. There is essentially no waste, though the raw endpoint string is somewhat redundant with the tool name. Appropriately sized for a one-parameter read 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 simple get-by-id tool with full schema coverage and readOnly annotations, the description supplies the one thing structured fields lack: what the returned invoice includes. No output schema exists, so this return-content note is the key piece and it is present, if brief.

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

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

Schema description coverage is 100%, so the single id parameter is already documented in the schema, including its source (eboekhouden_list_invoices). The description adds no further semantics such as id format or constraints, 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 ('one invoice with its items, amounts and relation') and effectively implies the retrieval verb through 'GET /v1/invoice/{id}'. An agent can tell it apart from eboekhouden_list_invoices because it clearly returns a single entity rather than a collection. It stops short of explicit sibling differentiation, 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?

No when-to-use guidance or alternatives are given in the description. It never states that this is the correct tool for fetching a single invoice by id versus using eboekhouden_list_invoices or eboekhouden_list_outstanding_invoices. The only hint about the id source lives in the schema parameter description, not the tool 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, so safety is covered; the description adds nothing behavioral on top. It does not say what happens for an unknown id, whether the ledger could be deleted/inactive, or what the response contains, leaving the description essentially a restatement of the 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 fragments, front-loaded, with no padding. The second fragment ("GET /v1/ledger/{id}") largely duplicates the tool name and endpoint metadata, which is minor waste but not bloat.

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 100% schema coverage this is nearly adequate, but there is no output schema, so nothing tells the agent what a ledger object contains or how a not-found case is signaled. Minimal but with a visible 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% and the single 'id' parameter is already documented in the schema, including the hint that it comes from eboekhouden_list_ledgers. The description contributes no additional 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?

"One ledger account" plus the endpoint GET /v1/ledger/{id} identifies both the resource and the singular-retrieval verb, so an agent can tell this is a single-record fetch rather than a list. It does not explicitly contrast with the closest siblings (eboekhouden_list_ledgers, eboekhouden_get_ledger_balance), so it stops short of a 5.

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

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

There is no statement of when to call this instead of eboekhouden_list_ledgers (fetch many) or eboekhouden_get_ledger_balance (balance for a ledger). The singular phrasing implies the distinction, but the description offers no explicit routing guidance or prerequisites.

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

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

Annotations already declare readOnlyHint=true, and the description's REST path 'GET /v1/ledger/{id}/balance' is consistent with that safe-read profile. With the safety bar already covered by annotations, the description adds only the endpoint and restates the parameter behavior, disclosing nothing extra about return shape, pagination, or error 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?

One compact sentence plus an endpoint reference; the scope constraint is front-loaded and nothing is padded. The raw REST path is mildly redundant with the tool name for an agent caller, which keeps it from 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?

There is no output schema, so the description carries some burden for describing the return value (a balance figure, and how it differs when 'from' is supplied), which it only gestures at. For a simple read with fully documented inputs the definition is adequate but not complete.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the important 'from' semantics (difference vs. actual balance). The description's 'optionally per cost center and for a period (from/to)' merely mirrors that, meeting the baseline without adding format or default 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?

States a specific verb+resource ('the balance of one ledger') and quantifies scope ('one ledger', optional cost center and from/to period), which implicitly separates it from the sibling list_ledger_balances. It never names that sibling explicitly, so it stops short of full 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?

The phrase 'the balance of one ledger' implies the single-ledger use case versus the batch list_ledger_balances, and the optional cost center/period modifiers hint at the supported modes. However, no explicit when-to-use or when-not-to-use guidance and no prerequisites are 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 declare readOnlyHint=true, so the safe-read profile is covered. The description adds the clubs/associations eligibility constraint and the raw endpoint, but says nothing about error behavior (e.g. what happens for a non-existent or non-member id) or what the response 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?

It is very short and never buries the point, but it reads as clipped fragments ('One member; only available to clubs and associations.') rather than a well-formed instruction, and the endpoint restatement is largely redundant with the schema.

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 with no output schema, the description covers the eligibility gating but omits the return shape and failure modes. It is minimally adequate, not complete.

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

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

Schema description coverage is 100% and the schema already explains 'The member id (from eboekhouden_list_members)', so the description adds nothing beyond echoing the path in the endpoint form. Baseline 3 applies when the schema does the work.

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

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

The description names the resource ('member') and the retrieval semantics (GET /v1/member/{id}), so an agent can tell it fetches one member rather than a list. However, the phrasing 'One member' is terse and does not explicitly contrast with the sibling eboekhouden_list_members.

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 the eligibility constraint ('only available to clubs and associations'), which is useful gating context, but gives no guidance on when to prefer this over eboekhouden_list_members or other get_* siblings. Usage is implied rather than spelled out.

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 readOnlyHint annotation already establishes this as a safe read. The description adds real value by disclosing return contents (rows with ledger, VAT code, amount, relation, invoice number) in the absence of an output schema. It says nothing about not-found behavior, auth, or pagination.

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

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

Two tight sentences with the resource and its row contents front-loaded. The raw endpoint reference is mildly redundant but not wasteful.

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 no output schema, listing the returned row fields largely closes the gap that the missing output schema would otherwise leave. The only real omission is routing guidance versus the list_mutations 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% and the single id parameter is fully documented in the schema, including its source. The description adds no format or semantics 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?

States a specific resource ('One mutation with its rows') and enumerates the row contents, which lets an agent distinguish it from the plural list tool. The verb is only implied via the title, but the singular 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?

Usage is implied: fetch a single booking by id, with the schema hinting the id comes from eboekhouden_list_mutations. The description itself never names the list sibling or states when to prefer one over the other, so the agent must infer the get-by-id vs list distinction.

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 already tells the agent this is a safe read. The description adds the REST path and the returned field set, but says nothing about auth requirements, error behavior for a missing id, or response shape, so credit is moderate.

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 no filler, and the field list is front-loaded. The first sentence is a noun fragment rather than a full clause, a minor structure blemish rather than wasted content.

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

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

For a simple read-by-id tool with full schema coverage and no output schema, enumerating the returned fields is exactly the right compensating detail. Only the missing existence/error behavior 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% and there is a single integer id parameter already documented as coming from eboekhouden_list_products. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (get) and resource (product) and enumerates the fields returned (price, VAT code, ledger, unit, stock setting), which lets an agent distinguish this from create_product and list_products. It does not name a sibling explicitly, 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 description offers no when-to-use guidance, no prerequisites, and does not point to list_products as the way to discover ids (that hint lives only in the schema). Usage is only weakly implied by the singular 'One product'.

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 readOnlyHint=true annotation already tells the agent this is a safe, non-mutating read. The description adds the useful scope detail that the full record (all fields) is returned, but does not disclose anything beyond that, such as error behavior for a missing id or pagination/format concerns.

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

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

A single front-loaded sentence that opens with the resource and enumerates the returned fields, followed by the endpoint. No wasted words, though the raw 'GET /v1/relation/{id}' string is borderline implementation detail.

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

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

For a simple one-parameter read tool there is no output schema, so the description usefully enumerates the returned field groups, covering the main completeness need. It is largely sufficient against the annotations and full schema coverage, with only sibling-routing 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 already documented as coming from eboekhouden_list_relations. The description adds no format or constraint meaning beyond what the schema provides, so the baseline 3 for high coverage 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 action and resource ('One relation with all its fields') and enumerates what is returned (addresses, e-mail, VAT/KvK, IBAN, payment term, ledger), which is more than a tautology. It implicitly contrasts with the list_relations sibling by emphasizing a single relation, but never names any 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?

There is no explicit when-to-use or when-not-to-use guidance. The only routing hint ('from eboekhouden_list_relations') lives in the schema's parameter description, not the tool description, and it never distinguishes this from update_relation or get_member. Usage is only implied by the singular 'get by id' pattern.

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 already tells the agent this is a safe read, so the description only needs to add context. It adds the endpoint and paging behavior ('Paged: pass next_offset as offset'), but that paging advice largely restates the offset schema description. No auth, rate-limit, or return-shape detail 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?

Three short clauses, front-loaded with the resource and followed by filters, paging, and endpoint. Every sentence carries information 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 paged read-only list with no output schema and full schema coverage, the essentials (filters, paging handoff, endpoint) are present. It stops short of describing the returned object shape, which is the only notable gap 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%, so all five parameters are already documented in the schema, and the description adds no syntax or format detail (e.g., wildcard behavior of match) beyond restating the parent_id/description filters. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (List) and resource (cost centers/kostenplaatsen), and the read-only nature is unambiguous versus the sibling get_cost_center. An agent can distinguish this from the get/list/create siblings 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?

It says the listing can be filtered 'optionally by parent id or description', which implies the filter use case, but gives no explicit when-to-use-vs-alternatives guidance (e.g., when to use get_cost_center instead, or when to filter client-side). 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: it discloses the underlying GET /v1/emailtemplate endpoint and the pagination contract (next_offset feeding into offset), which the annotations do not carry.

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, front-loaded sentences with no filler. The purpose leads, followed by the pagination note and endpoint, which is the right ordering 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 listing tool with two fully documented optional params and annotations covering safety, this is nearly complete. The only minor gap is that nothing indicates what a returned template looks like, though no output schema exists to carry that.

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

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

Schema description coverage is 100%, so both limit and offset are already fully documented in the schema. The description adds only a cross-reference on how next_offset maps to offset, which is a marginal addition over the schema 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?

States a specific verb (List) and resource (e-mail templates), which cleanly separates it from sibling list tools like list_invoice_templates and list_ledgers. It does not, however, explicitly name or contrast with any 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 pagination sentence ('pass next_offset as offset') gives concrete operational guidance for continuing a result set, but there is no statement of when to use this tool versus alternatives or any exclusions. Usage is only implied.

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

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

Annotations declare readOnlyHint=true, so the safety profile is covered. The description adds paging behavior ('pass next_offset as offset') and the endpoint, which is useful, but says nothing about result ordering, default result size, or auth/permission needs.

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 tight sentences with no waste; filters are front-loaded and paging/endpoint follow. Slightly telegraphic but 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 read-only, unpaginated-output list tool with full schema coverage, the essentials are present. It lacks any note on what the response contains or how paging terminates, which is a modest gap given 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 coverage is 100%, so the schema already documents all 8 parameters, including match semantics and limit ranges. The description adds nothing beyond what the schema provides, 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?

States a clear verb+resource (search invoices) and scope (invoicing module), with the three filter axes. It does not explicitly distinguish itself from the sibling eboekhouden_list_outstanding_invoices, which is the nearest alternative for invoice 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?

Usage is implicit: it says what can be filtered by, but gives no explicit when-to-use versus eboekhouden_get_invoice (single fetch) or eboekhouden_list_outstanding_invoices. Paging guidance is the only procedural hint.

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 is already declared by annotations, so the safety profile is covered. The description adds genuinely useful context beyond the structured fields – the template_id/create_invoice linkage and the paging pattern (pass next_offset as offset) – though it omits auth and rate-limit details.

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, front-loaded with the purpose and followed by filters and paging. Nothing is wasted and the endpoint is noted compactly.

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

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

With no output schema and a readOnly annotation, the description does enough: it names the filtering options and states that the key returned value is template_id. Minor gaps remain on exact return shape, but the essential call contract is covered.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters (name, type, match, active, limit, offset). The description restates the name/type/active filters and pagination mechanics without adding syntax or semantics beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (invoice templates) and further anchors it by explaining it supplies the template_id consumed by eboekhouden_create_invoice. This clearly separates it from siblings like list_invoices and list_email_templates.

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

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

Gives clear context: use it to obtain template_id for create_invoice, and it enumerates the optional filters (name, type, active). It stops short of explicit when-not guidance or alternative routing, but the intended use is 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's main addition is the 'trial balance' framing and the GET endpoint. It does not disclose return shape, pagination, or sorting behavior, but with annotations covering the safety profile this is a modest contribution.

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 tight sentence, front-loaded with the resource and scope, ending with the endpoint. Nothing is wasted.

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

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

For a read-only list tool with three optional, fully-documented parameters and no output schema to explain, the description is nearly complete; only the sibling relationship to get_ledger_balance 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 the schema already documents all three parameters in detail. The description's mention of cost center and from/to period maps onto the params but adds no syntax or default information beyond what the schema provides.

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

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

States a specific verb and resource — the balances of all ledgers, glossed as a trial balance — with scope (per cost center, period). It distinguishes itself from the singular get_ledger_balance by saying 'all ledgers', 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?

The phrase 'optionally per cost center and for a period (from/to)' implies when the optional filters apply, but there is no explicit guidance on when to use this list tool versus get_ledger_balance or list_ledgers, and no 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?

readOnlyHint=true already tells the agent this is a safe read. The description goes further by disclosing the exact shape of returned records, the valid category codes, and the pagination contract, which are not in the annotations. Missing are auth/permission notes or rate-limit behavior, keeping it below a 5.

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

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

Front-loaded with the resource identity, then return fields, then the id reuse hint and paging rule in a tight sequence. No filler sentences. The parenthetical category enumeration is long but functional.

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 enumerating the returned fields. The pagination contract and id-reuse guidance round it out. Only the absence of any filtering/usage caveats (e.g., how code/match interact) keeps it short of 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%, so the schema already documents all five parameters thoroughly (including the match enum and limit bounds). The description reinforces the next_offset/offset linkage and category values but adds little the schema doesn't already say. 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 resource with its Dutch synonym ('ledger accounts (grootboekrekeningen)') and enumerates the returned fields (id, code, description, category), so the agent knows exactly what this list contains. It doesn't explicitly differentiate from siblings like eboekhouden_get_ledger or eboekhouden_list_ledger_balances, but the purpose is unmistakable.

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 id as ledger_id in other tools' and 'Paged: pass next_offset as offset' give real usage context. However, there is no explicit when-to-use-this vs get_ledger / list_ledger_balances, so the guidance is implied rather than spelled out.

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, so safety is covered; the description adds genuinely new behavior: an account-type eligibility gate with a named error code and pagination mechanics. It stops short of describing rate limits, sorting, or default result 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 short clauses, front-loaded with the core action and the eligibility constraint before pagination and route details. No wasted words, though the fragments are slightly 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?

For a read-only paged list with no output schema, the description covers the essentials an agent needs: eligibility, error signal, and pagination. It does not summarize that filters (name/city/email/match) can be combined, but the schema carries that detail.

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 seven parameters including enum and range bounds are already documented; the description only restates the offset/next_offset convention that the schema itself explains. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('List members') plus a scope constraint that no sibling shares. It does not explicitly name a sibling (e.g. get_member) to contrast with, so it falls just short of full 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?

Gives a concrete availability condition ('only available to clubs and associations') and the failure signal (MEM_056), which tells the agent when this call is valid. It does not name an alternative tool for other account types, but the precondition is clear.

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

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

readOnlyHint=true already declares the safety profile, so the description earns credit for the extra operational detail: the explicit GET /v1/mutation endpoint and the pagination contract (next_offset returned via offset). It stops short of describing result fields or the default page size, but it adds real context beyond the annotation.

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 search action, then type codes, filters, paging and endpoint in a compact sequence with no filler. The type-code enumeration partially duplicates the schema field description, slightly reducing density, but the whole is short and skimmable.

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

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

For a 10-parameter, read-only list tool with no output schema and only a readOnlyHint annotation, the description covers invocation (filters, paging, endpoint) well. The main residual gap is that it never sketches what a returned mutation contains, which is normally covered by an output schema that is absent here.

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

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

Schema description coverage is 100%, including the same type enumeration, date semantics, match modes and limits, so the schema already documents all 10 parameters. The description's restatement of the type codes and filter list adds marginal value but no syntax beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Search the bookkeeping mutations') and scopes it with an enumerated type list and the filters that are available. It is clearly a filtered-list tool, but it never names its closest sibling get_mutation, so the list-vs-single distinction must be inferred from the word 'Search'.

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 filter enumeration ('Filter by type, mutation number, description, invoice number or date') and by the paging hint ('pass next_offset as offset'). There is no explicit when-to-use/when-not statement and no alternative tool (e.g. get_mutation) is named for the single-record case, so an agent must infer the 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds pagination mechanics ('pass next_offset as offset') and the underlying endpoint, but says nothing about the shape of the reply, result volume, or failure modes. Useful but thin given the schema already repeats the next_offset guidance.

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 what the tool returns, then pagination, then the endpoint. Nothing is padded, though the raw endpoint path is marginal value for an agent.

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 no output schema, the description covers the key mechanics (pagination via next_offset) and the D/C semantics. It stops short of describing any returned fields, which an agent might want 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 coverage is 100% and every parameter is documented in-schema, so the baseline is 3; the description adds a small amount by restating the D/C meaning in business terms ('customers still owe' vs 'still to be paid'). The other parameters (limit, match, invoice_number) get no additional meaning beyond the schema.

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

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

Gives a specific verb+resource ('Open (unpaid) invoices') and immediately defines the two scopes (D = debtors/sales invoices owed to you, C = creditors/purchase invoices you owe), so 'outstanding' is unambiguous. It does not explicitly name the sibling it differs from (eboekhouden_list_invoices), but the scope distinction is inferable from the wording.

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 conveys the domain context (only open/unpaid invoices, split by debtor vs creditor) which implies when to use it, but never states when to prefer it over eboekhouden_list_invoices or eboekhouden_list_mutations, and there are no exclusions or prerequisites. Usage is implied rather than directed.

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, so safety is covered structurally. The description adds only the raw endpoint path (GET /v1/product/groups), which conveys little beyond the annotations, and says nothing about pagination, result size, or coverage of inactive groups.

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 fragments with zero waste and the resource front-loaded. It is efficient, though the telegraphic style leaves it slightly under-narrated for a 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?

For a parameterless list tool with annotations covering the safety profile, the description is minimally adequate. It omits any hint about return shape (no output schema exists) or pagination behavior, which is the main 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?

The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to clarify beyond the schema, and it correctly implies no filtering inputs are accepted.

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

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

The description states the resource (product groups) and implies a full listing via 'All', matching the verb in the name/title. However, it essentially restates the title plus an endpoint path, without distinguishing its scope from siblings like eboekhouden_list_products or eboekhouden_list_units beyond the resource noun.

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

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

There is no guidance on when to use this tool versus alternatives such as eboekhouden_list_products or eboekhouden_get_product. No prerequisites, no exclusions, no context — the agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, and the description adds real behavioral context beyond that: results are paged and the agent must feed next_offset from the previous reply back in as offset. It still omits any note on response envelope, total count, or result 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?

Two tight sentences with the core purpose and scope front-loaded; nothing is padded. The trailing 'Paged: pass next_offset as offset' is mildly redundant with the offset schema description but is short and useful enough to earn its place.

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

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

With no output schema, the description carries the burden of describing returns and does partially discharge it by naming the product attributes returned, plus GET /v1/product and pagination mechanics. It would be stronger if it enumerated the full response shape or stated defaults, but it is adequate for a five-parameter read-only list tool.

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

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

Schema description coverage is 100%, so the schema already documents code, limit, match, offset, group_code, and even the next_offset-to-offset continuation. The description restates the code/group_code filtering and the offset mapping without adding syntax or format detail the schema lacks, so baseline 3 is correct.

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 ('List products and services (articles)') and even enumerates the returned attributes (price, VAT code, ledger, unit), so the agent knows exactly what comes back. It does not explicitly name sibling tools like eboekhouden_get_product or eboekhouden_list_product_groups, so differentiation is left to the verb, but the 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?

The description hints at usage ('optionally by code or group code', 'Paged: pass next_offset as offset') but never states when to prefer this tool over get_product for a single lookup or list_product_groups for groupings. Usage is implied rather than stated, and no exclusions are 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 only declare readOnlyHint=true; the description adds real behavioral context — filters combine with AND, text matching defaults to exact, and pagination continues via next_offset from the previous reply. It stops short of describing result shape or rate limits, but it clearly exceeds the annotation baseline.

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, front-loaded sentences with no filler. Minor redundancy: the text-filter matching clause repeats semantics already spelled out in the 'match' parameter description, so it is efficient rather than perfectly edited.

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

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

For a 9-parameter, zero-required list tool with no output schema, the description covers filtering semantics and the pagination loop, which is what an agent most needs. It leaves the returned relation fields unspecified, but that gap is modest given the read-only, low-risk nature of the 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 description coverage is 100%, so the baseline is 3; the schema already documents each filter, the type enum, match enum, limit and offset. The description only restates the AND-combination and match-default behavior, adding little beyond the 'match' parameter's own description.

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

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

The description states a specific verb and resource ('List relations') and defines the domain term ('customers and suppliers of the administration'), so an agent knows exactly what is returned. It does not, however, differentiate itself from the sibling eboekhouden_get_relation, which retrieves a single relation.

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

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

It implies usage through the filtering and paging mechanics ('optionally filtered', 'Paged: pass next_offset as offset') but never states when to prefer this over get_relation or create/update_relation. Usage is inferable but no explicit when-to-use or exclusion 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 establish readOnlyHint=true, so the safety profile is covered. The description adds the pagination contract (next_offset recycled as offset) and the underlying endpoint 'GET /v1/unit', which is useful behavioral context, but it says nothing about ordering, default page size behavior, or what the payload 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?

Two short sentences, zero filler, with the resource identity front-loaded and the pagination caveat immediately after. Every clause carries 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?

No output schema exists, yet the description notes that ids accompany each unit, and pagination is explained, which covers the main gaps for a filtered list tool. It stops short of describing additional returned fields or result ordering, a minor omission for a low-complexity read.

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, match, offset, plural, and singular are all documented in the schema, including the enum semantics and wildcard rules. The description adds only the next_offset/offset linkage, which is already restated in the offset field description, so baseline 3 is correct.

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 ('List product units') and even gives concrete examples (piece, hour) plus the returned key ('with their ids'). It implicitly distinguishes itself from siblings like list_products and list_product_groups, but never explicitly contrasts them.

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 instruction is procedural pagination guidance ('Paged: pass next_offset as offset'). There is no statement of when to call this versus list_products/list_product_groups or any prerequisite conditions, so usage is implied rather than explained.

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?

Goes well past the idempotentHint/destructiveHint annotations by disclosing the read-modify-write implementation, the fact that the API requires name on every update, that unpassed fields retain values, and that passed fields are overwritten. That is exactly the mutation behavior an agent needs before invoking.

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 tight sentences: purpose, then semantics of the merge, then the underlying endpoint. No filler, and the most decision-relevant fact (unpassed fields survive) is front-loaded.

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

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

For a 25-parameter mutation tool with no output schema, the description supplies the missing behavioral contract: partial update semantics, the name requirement, and destructive scope. Nothing essential to invoking it correctly 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?

With only 48% schema description coverage across 25 parameters, the description carries real weight: it explains that name must effectively be supplied on every update even though the schema lists only id as required, and that omitted fields are preserved. Many of the remaining 25 fields (city, iban, address) are self-evident, but the partial-update contract is a meaningful addition.

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 ("Change fields of an existing relation") and names the endpoint (GET + PATCH /v1/relation/{id}), which the siblings create_relation/get_relation/list_relations do not. It implicitly separates itself from creation by saying "existing relation", but never names those siblings explicitly.

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

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

It gives clear context for the partial-update case (fields not passed keep their values), but offers no explicit when-to-use/when-not guidance and never routes the agent to create_relation for new records or get_relation for reads. Usage is implied rather than instructed.

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