Server Quality Checklist

Tool Scores

• wafeq_revenue_recognitions_listC
  2.4/5.0
  Behavior2/5

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

  Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description only repeats 'READ-ONLY' and restates the GET endpoint, adding no behavioral context such as pagination behavior, default page size, result ordering, or filtering semantics. It does not contradict 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.

  Conciseness2/5

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

  The description is short but redundant: 'List revenue recognitions' and 'Endpoint for retrieving a list of revenue recognitions' convey the same idea. The front-loaded READ-ONLY/GET line is useful, but the repeated phrasing does not earn its place.

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

  Completeness2/5

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

  For a tool with 9 optional parameters, no output schema, and low schema description coverage, this description is too minimal. It omits semantics for filters like duration, start/end date ranges, recognition_type, and pagination defaults, leaving the agent to guess.

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

  Parameters1/5

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

  Schema description coverage is only 33%, with duration, date filters, and recognition_type undocumented. The description provides zero explanation of any parameter, so the agent receives no additional semantic help beyond the sparse schema.

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

  Purpose4/5

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

  The description clearly states a specific verb and resource: 'List revenue recognitions' and 'Endpoint for retrieving a list of revenue recognitions.' It does not explicitly contrast with the sibling retrieve endpoint, but the list vs. single-item distinction is evident from the name and wording.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this list endpoint instead of related endpoints like revenue_recognitions_retrieve, revenue_recognitions_destroy, or the preview/end_early actions. No conditions, prerequisites, or alternative routing are mentioned.

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

• wafeq_beneficiaries_listC
  2.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description repeats this via '🟢 READ-ONLY' and 'GET' but adds no new behavioral details such as pagination behavior, default page size, filtering semantics, or response characteristics. No contradiction exists, but no additional value beyond structured metadata is provided.

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

  Conciseness2/5

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

  The description is short but repetitive: 'List beneficiaries' appears as a heading and again in prose, and 'Endpoint for retrieving a list of beneficiaries' restates the same idea. The READ-ONLY/GET prefix is useful but mostly duplicates annotations, so not every sentence earns its place.

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

  Completeness2/5

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

  For a list endpoint with 11 optional parameters and no output schema, the description is minimal. It does not explain pagination, available filters, how results are ordered, or how this list relates to retrieving a single beneficiary. An agent would need to inspect the schema and infer usage without sufficient narrative support.

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

  Parameters2/5

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

  The input schema covers 64% of parameters with descriptions, leaving contact, country, currency, and charge_type undocumented. The description does not mention any parameters or compensate for the gap, missing an opportunity to explain filtering options for a list endpoint.

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

  Purpose4/5

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

  The description clearly states the tool lists beneficiaries ('List beneficiaries', 'Endpoint for retrieving a list of beneficiaries'), with a specific verb and resource. It is distinct from single-record retrieval tools like wafeq_beneficiaries_retrieve, though it does not explicitly contrast itself with siblings.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this list vs. other operations such as wafeq_beneficiaries_retrieve or wafeq_beneficiaries_create, nor when to apply filters. Usage is only implied by the endpoint path and name, with no exclusions or alternative recommendations.

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

• wafeq_bills_partial_updateC
  2.5/5.0
  Behavior2/5

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

  Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description only restates the write nature ('WRITE · updates data') and HTTP verb. It adds no behavioral context about PATCH merge semantics, whether an empty body is valid, status-transition side effects, or idempotency behavior beyond what the schema's idempotency_key parameter already documents.

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

  Conciseness2/5

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

  The description is redundant: 'Partial update bill' and 'Endpoint for partially updating an existing bill' say nearly the same thing, and the emoji-prefixed line also repeats the write/update idea. Three near-duplicate statements of one concept earned no structural credit.

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

  Completeness2/5

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

  This is a complex tool — deeply nested body (line_items with amortization objects, debit_notes, custom_fields), no output schema, and a single required id. The one-line description leaves agents without guidance on partial-update semantics, which sub-fields are safely updatable, or how this endpoint relates to the dedicated line-items partial-update sibling.

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

  Parameters2/5

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

  Schema coverage is 67%, below the 80% baseline, so the description needed to compensate — it does not. The required 'id' parameter has no schema description and none in the tool description either. The body parameter's schema description ('Adds nested create feature') is a confusing DRF artifact that mischaracterizes a partial-update payload, and the description does nothing to clarify it.

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

  Purpose4/5

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

  The description states a specific verb and resource ('partially updating an existing bill') and the PATCH /bills/{id}/ endpoint, making the operation unambiguous. It is clear but does not explicitly differentiate from siblings like wafeq_bills_update or wafeq_bills_line_items_partial_update — the 'partial' qualifier does that work implicitly.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus the many bill-related siblings. With wafeq_bills_update, wafeq_bills_destroy, wafeq_bills_line_items_partial_update, and wafeq_bills_create all present, an agent gets no help selecting between full update, partial update, or line-item-scoped partial update.

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

• wafeq_branches_updateC
  2.5/5.0
  Behavior2/5

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

  The annotations already convey readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description only restates the write nature with 'WRITE' and 'updates data' and adds the endpoint, without disclosing behavioral context such as whether omitted fields are reset, what side effects occur, or any authorization requirements. No contradiction exists, but no meaningful behavioral detail is added.

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

  Conciseness2/5

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

  The description is short but highly repetitive: 'WRITE · updates data · Branches · PUT /branches/{id}/', 'Update branch', and 'Endpoint for updating an existing branch' all say essentially the same thing. The redundancy wastes space and adds no new information beyond the first line.

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

  Completeness2/5

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

  With nested required body fields, no output schema, and a sibling partial_update tool, the description should clarify full-replacement behavior and distinguish this from partial updates. It does neither. The annotations cover idempotency and non-destructiveness, but the description leaves important operational context missing.

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

  Parameters2/5

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

  The description does not explain any parameters. Schema coverage is 67%, but the body parameter's description is generic serializer boilerplate, and the top-level 'id' has no description. The nested field descriptions in the schema carry most of the meaning, so the description provides no additional semantic value for parameters.

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

  Purpose4/5

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

  The description clearly states a specific action ('updating') and resource ('branch'), and the explicit PUT endpoint identifies this as the full-update operation rather than a create or partial update. However, it does not explicitly name or contrast sibling tools like wafeq_branches_partial_update or wafeq_branches_create, so differentiation is implicit rather than stated.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to choose this tool over alternatives such as wafeq_branches_create, wafeq_branches_partial_update, or wafeq_branches_destroy. It does not mention prerequisites, full-vs-partial replacement semantics, or any condition that should trigger its use.

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

• wafeq_items_updateC
  2.5/5.0
  Behavior2/5

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

  Annotations already cover readOnlyHint, destructiveHint, and idempotentHint. The description adds no behavioral context beyond restating 'WRITE' and 'updates data'. It does not disclose full-update semantics such as omitted fields being reset, required prerequisites, or effect on existing related units of measure.

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

  Conciseness2/5

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

  The description repeats the same information three times: the emoji line, 'Update item', and 'Endpoint for updating an existing item'. While short, the redundancy wastes tokens and does not add value beyond the first phrase.

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

  Completeness2/5

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

  For a complex nested body with many optional fields and a partial_update sibling, the description is far too thin. It does not explain full vs. partial semantics, the required 'name' field, or the behavior of omitted fields. No output schema exists, so the description should carry more weight.

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

  Parameters2/5

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

  With 67% schema description coverage and a confusing body description ('Shared validation and save logic for item_units_of_measure...'), the tool description does not compensate. The endpoint path implies id means the item ID, but the body parameter's meaning and structure are not clarified beyond the schema.

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

  Purpose4/5

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

  The description clearly identifies the operation as updating an existing item, including the HTTP method and resource path (PUT /items/{id}/). It does not explicitly distinguish from the sibling tool wafeq_items_partial_update, but the core purpose is unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this full update versus wafeq_items_partial_update or wafeq_items_create. The description only restates that it updates an existing item, leaving the agent to infer selection criteria from the tool name and endpoint.

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

• wafeq_bills_line_items_partial_updateC
  2.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false; the description merely restates that this is a write operation using PATCH. It adds no context about side effects, authentication requirements, or how omitted fields behave in a partial update.

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

  Conciseness3/5

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

  The opening line is front-loaded and compact, using clear signals like 'WRITE', 'PATCH', and the resource path. However, 'Partial update bill line item' and 'Endpoint for partially updating an existing bill line item' are near-identical restatements, making the description redundant despite being short.

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

  Completeness2/5

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

  This is a nested-object partial update with no output schema, yet the description only identifies the endpoint. It omits how partial update semantics work, what a successful response looks like, and any prerequisites or side effects. The detailed input schema partially compensates, but the description itself is not complete enough for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is only 50%, and the tool description does not clarify the path parameters bill_id and id, the body structure, or the confusing body description about augmenting custom_fields. The nested field schemas provide some value, but the description itself adds no parameter-level meaning.

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

  Purpose4/5

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

  The description clearly names the verb ('partial update'), the resource ('bill line item'), and the HTTP method (PATCH), so an agent can tell what action is being performed. It does not explicitly distinguish this from the sibling full-update tool wafeq_bills_line_items_update, 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.

  Usage Guidelines2/5

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

  There is no explicit guidance about when to choose this tool over alternatives like wafeq_bills_line_items_update or wafeq_bills_line_items_create. The phrase 'partial update' implies only a subset of fields will be changed, but the description leaves the selection logic entirely to the agent.

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

• wafeq_credit_notes_updateC
  2.6/5.0
  Behavior2/5

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

  The annotations already indicate a write operation (`readOnlyHint: false`) and idempotency (`idempotentHint: true`). The description adds no behavioral context beyond repeating 'updates data' and showing the PUT endpoint; it does not clarify that this is a full replacement rather than a partial update, nor does it mention side effects, permissions, or response behavior. No contradiction with the annotations exists.

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

  Conciseness3/5

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

  The description is very short, which is good, but '🟡 WRITE · updates data', 'Update credit note', and 'Endpoint for updating an existing credit note' all restate the same idea. The redundancy means not every sentence earns its place, though the overall size is appropriate.

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

  Completeness2/5

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

  For a tool with a complex nested body and a partial-update sibling, the description is incomplete. It does not mention that the PUT operation replaces the credit note, that `body` must contain all required fields, or how this differs from `wafeq_credit_notes_partial_update`. With no output schema, the description also leaves the expected response unaddressed.

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

  Parameters2/5

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

  The description adds essentially no parameter semantics beyond the URL placeholder for `id`. The input schema carries most of the burden with descriptions for many body fields, but the top-level `body` description ('Adds nested create feature') is generic and unhelpful, and the tool description does not compensate for the moderate 67% schema coverage or explain that the full required body must be supplied.

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

  Purpose4/5

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

  The description clearly states the action: 'Update credit note' and 'Endpoint for updating an existing credit note,' naming both the verb and the resource. However, it does not distinguish this full-update operation from the sibling `wafeq_credit_notes_partial_update`, so it lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus `wafeq_credit_notes_partial_update` or other credit-note tools. The description merely states that it updates an existing credit note, leaving the agent to infer the full-update semantics from the HTTP method and schema.

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

• wafeq_files_listC
  2.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds the HTTP endpoint and repeats READ-ONLY, but provides no further behavioral context such as pagination behavior, filtering effects, or response characteristics.

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

  Conciseness3/5

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

  The description is short and front-loaded with READ-ONLY and the endpoint, but it is repetitive: 'List files' and 'Endpoint for retrieving a list of files' say essentially the same thing. It is concise but contains redundancy.

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

  Completeness2/5

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

  For a list endpoint with 10 optional filter parameters and no output schema, the description is too sparse. It does not explain how to use pagination, filtering by mime type, file size, creation/modification dates, or what the returned file objects look like.

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

  Parameters2/5

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

  The description adds no meaning for any of the 10 parameters. Schema coverage is only 60%, leaving parameters like mime_type, file_size_max, file_size_min, and original_filename undocumented in both schema and description, and the description does not mention filtering or pagination capabilities.

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

  Purpose4/5

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

  The description clearly states the tool lists files and retrieves a list of files, with the endpoint 'GET /files/' and a READ-ONLY marker. This is clear and differentiates from file creation/update/destroy operations, though it does not explicitly name sibling alternatives like wafeq_files_retrieve.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as wafeq_files_retrieve or wafeq_files_destroy. The only signal is the implicit 'list' versus 'retrieve' distinction, which is not stated explicitly.

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

• wafeq_warehouses_updateC
  2.6/5.0
  Behavior2/5

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

  Annotations already establish that this is a mutating, idempotent, non-destructive operation, so the description adds little behavioral context. The PUT method is mentioned but not explained as full-replacement semantics; no details about overwritten fields, required permissions, or side effects are provided.

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

  Conciseness3/5

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

  The description is short and front-loaded with the endpoint and write intent, but “Update warehouse” and “Endpoint for updating an existing warehouse” are redundant. Every line does not earn its place, though the overall size is reasonable.

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

  Completeness2/5

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

  For a write operation with a nested required body and a dedicated partial_update sibling, this description is incomplete. It omits the full-vs-partial distinction, the effect of not sending optional fields, and any return/error behavior, leaving the agent to infer critical usage details from the schema alone.

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

  Parameters2/5

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

  The description adds no parameter meaning beyond the schema. The id parameter lacks a schema description and is not explained, and the body parameter is described with generic serializer boilerplate rather than the fact that it must supply the full warehouse representation for this PUT update.

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

  Purpose4/5

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

  The description clearly identifies the resource (Warehouses), the operation (update), and the HTTP endpoint (PUT /warehouses/{id}/). It does not explicitly contrast with the sibling partial_update tool, but the verb and resource are unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is given about when to choose this full update over wafeq_warehouses_partial_update, which appears in the sibling list. The description does not state that body must contain the full set of required fields or any conditions/preconditions for calling the endpoint.

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

• wafeq_bills_line_items_listC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safe read-only nature is covered. The description adds the endpoint pattern (GET) and the 'READ-ONLY' flag in text, but those mostly repeat annotation info. It doesn't add meaningful behavior beyond what annotations provide, such as pagination defaults or error conditions.

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

  Conciseness2/5

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

  The description repeats 'List bill line items' three times (in the emoji header, the plain sentence, and the endpoint line) with the endpoint path adding little informational value. It is padded rather than concise, and the redundant phrasing costs tokens without adding agent-useful detail.

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

  Completeness3/5

  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 rich annotations, the core purpose is conveyed. However, missing guidance on pagination behavior, the meaning of bill_id, and how this relates to sibling line-item lists leaves the agent short. It doesn't explain ordering, default page size, or what counts as a bill line item.

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

  Parameters3/5

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

  The page and page_size parameters already have descriptions in the schema (67% coverage). The description does not add any extra meaning to bill_id beyond its presence in the path. Since schema description coverage is high and the tool is simple, the description's silence on params is acceptable but not value-adding.

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

  Purpose3/5

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

  The description states it lists bill line items and includes the endpoint path, which is clear about the resource. However, it doesn't differentiate itself from sibling tools like wafeq_purchase_orders_line_items_list or wafeq_invoices_line_items_list beyond the name itself. There's also redundant repetition of 'List bill line items' across the title, emoji header, and endpoint description.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that bill_id is required, how pagination works, or when to use wafeq_bills_line_items_retrieve instead for a single item. The context signals show many similar line-item list tools, but the description offers no routing or selection help.

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

• wafeq_bills_line_items_updateC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description only restates the write nature ('🟡 WRITE · updates data') and the endpoint, adding no behavioral context such as whether omitted fields are reset, how totals are recalculated, or how amortization is affected. No contradiction with annotations.

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

  Conciseness4/5

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

  The definition is short and front-loaded, with the operation type, resource, and endpoint in a compact structured prefix. However, 'Update bill line item' and 'Endpoint for updating an existing bill line item' are redundant restatements of the same idea, so not every line fully earns its place.

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

  Completeness2/5

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

  For a write tool with a complex nested body (amortization configuration, discount constraints, custom_fields) and no output schema, the description provides no usage context, no note on full vs. partial update behavior, and no pointer to related retrieval tools. The schema and annotations carry nearly the entire burden.

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

  Parameters2/5

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

  Schema description coverage is only 50%, and the two path parameters (bill_id and id) are undocumented in the schema; the description's URL template only implicitly clarifies their roles. The description names no body fields and adds nothing beyond the schema about required fields like account, description, quantity, and unit_amount.

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

  Purpose4/5

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

  The description states a specific verb ('Update') and resource ('bill line item'), reinforced by the endpoint template 'PUT /bills/{bill_id}/line-items/{id}/'. This clearly distinguishes the operation from create, retrieve, and destroy siblings, though it does not explicitly differentiate it from the closely related wafeq_bills_line_items_partial_update.

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

  Usage Guidelines2/5

  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 full update vs. the sibling wafeq_bills_line_items_partial_update, no mention that PUT implies full replacement semantics, and no prerequisites or exclusions. The closest alternative tool is never referenced.

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

• wafeq_bills_updateC
  2.7/5.0
  Behavior2/5

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

  The 'WRITE · updates data' label and PUT path largely restate what annotations already convey through readOnlyHint=false and destructiveHint=false. The description adds no behavioral context such as full-replacement semantics, status restrictions, or side effects, and the idempotency behavior is explained only in the schema parameter description, not in the tool description.

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

  Conciseness4/5

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

  The description is short and front-loaded with a write indicator and the endpoint. It is not bloated, though 'Update bill' and 'Endpoint for updating an existing bill' redundantly restate the same idea.

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

  Completeness2/5

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

  For a complex update operation with a large nested body schema and no output schema, the description leaves important context unstated: full versus partial update behavior, required body fields, and the relationship to sibling tools like wafeq_bills_partial_update and wafeq_bills_line_items_update. The rich schema partially compensates, but the description itself is not complete.

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

  Parameters2/5

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

  The description contributes no parameter-level meaning. Schema coverage is 67%, and the top-level body parameter description ('Adds nested create feature') is unhelpful and potentially misleading for an update operation, while 'id' has no description. The tool description does nothing to compensate for these gaps.

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

  Purpose4/5

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

  The description clearly identifies the action ('updating an existing bill') and resource (Bills), and includes the HTTP method and path (PUT /bills/{id}/). It does not explicitly distinguish itself from the sibling wafeq_bills_partial_update, so it misses the top score for sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this full-update tool versus wafeq_bills_partial_update, wafeq_bills_create, or wafeq_bills_retrieve. It only restates the operation and gives no conditions, exclusions, or alternative routing.

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

• wafeq_debit_notes_listC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false; the description only repeats READ-ONLY and the HTTP method. It adds no behavioral context such as pagination behavior, default sorting, or result-set characteristics, so it contributes little 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.

  Conciseness2/5

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

  The description is short and front-loaded with the endpoint, but it is redundant: 'List debit notes' and 'Endpoint for retrieving a list of debit notes' say the same thing. Two of the three sentences add little unique value.

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

  Completeness2/5

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

  With 12 optional parameters and no output schema, the description should explain filtering, pagination, or return expectations, but it does none of this. It is complete only for the most trivial reading of the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the description provides no additional parameter semantics. The baseline of 3 applies because the schema already documents all 12 parameters, although several schema descriptions are not particularly informative.

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

  Purpose4/5

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

  The description clearly states the action and resource: 'List debit notes' and 'GET /debit-notes/'. It is unambiguous about the target resource, though it relies on the resource name rather than explicitly distinguishing this list endpoint from sibling list tools like credit notes, bills, or invoices.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this tool over alternatives, no exclusions, and no mention of intended use cases or filtering scenarios. The text only restates that the tool retrieves a list of debit notes, leaving usage selection entirely to the agent.

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

• wafeq_employees_updateC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description's 'WRITE · updates data' merely restates that. It adds only the PUT verb, which hints at full-replacement semantics, but does not disclose what happens to omitted body fields (e.g., whether they are reset to defaults), nor how this differs behaviorally from partial_update. No contradiction with annotations, but no meaningful added context either.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the WRITE badge, method, and resource path, so the essential purpose is visible immediately. There is mild redundancy—'Update employee' is restated as 'Endpoint for updating an existing employee'—but overall it is appropriately sized with no filler.

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

  Completeness2/5

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

  For a mutation tool with a nested required body, no output schema, and a closely related sibling (wafeq_employees_partial_update), the description is too thin. It does not explain PUT full-replace semantics, what happens to unspecified fields, expected response behavior, or when to prefer partial_update. The key differentiator (PUT vs PATCH) is present only as a bare method token, leaving an agent to guess at important invocation consequences.

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

  Parameters2/5

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

  The description mentions no parameters at all; the agent must rely entirely on the schema. Schema coverage is 67%, and though the nested body fields (city, name, email, etc.) have useful descriptions, the top-level id parameter is undocumented and the body's DRF boilerplate description ('A ModelSerializer that takes additional arguments...') adds no operational meaning. The description does nothing to compensate for these gaps and even fails to note that name is required.

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

  Purpose4/5

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

  The description states a specific action and resource ('updates data · Employees'), reveals the REST method and path (PUT /employees/{id}/), and is clearly about updating an existing employee. It is self-contained and understandable, though it never explicitly contrasts with the sibling wafeq_employees_partial_update; the differentiation is left to the inferred PUT vs PATCH distinction rather than stated.

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

  Usage Guidelines2/5

  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 wafeq_employees_partial_update (PATCH), wafeq_employees_retrieve, or other employee tools. No prerequisites (e.g., employee must exist), no exclusions, and no mention that this is the full-update counterpart to the partial update sibling. The only usage signal is the bare 'PUT' token in the description, which is implicit rather than actionable guidance.

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

• wafeq_payments_retrieveC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description only repeats READ-ONLY and GET, adding no behavioral context such as response format, authentication requirements, error behavior, or rate limits. There is no contradiction, but the description adds little 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.

  Conciseness3/5

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

  The description is short and front-loaded with the READ-ONLY label and endpoint, which is good. However, 'Retrieve payment' and 'Endpoint for retrieving a single payment' are redundant; the same information could be expressed in one sentence without losing clarity.

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

  Completeness3/5

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

  For a simple one-parameter retrieve operation with strong annotations, the core call is clear. However, there is no output schema and the description does not mention what the response contains, whether the payment object is nested, or any error conditions. It is adequate but leaves some gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only shows {id} in the URL path. It does not clarify whether the id is a UUID, internal identifier, or external reference, nor does it explain how to obtain it. The property name 'id' is self-explanatory to a degree, but the description does not compensate for the missing schema documentation.

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

  Purpose4/5

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

  The description clearly states the verb 'retrieve' and the resource 'payment', and the phrase 'single payment' distinguishes it from list endpoints. The GET path /payments/{id}/ makes the scope unambiguous. It doesn't explicitly name sibling tools, but the singular scope is sufficient for basic differentiation.

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

  Usage Guidelines2/5

  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 wafeq_payments_list, wafeq_payments_create, or wafeq_payments_update. The singular phrasing implies single-record retrieval, but the agent is left to infer this rather than being told directly.

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

• wafeq_purchase_orders_line_items_partial_updateC
  2.7/5.0
  Behavior2/5

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

  Annotations already carry readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description merely repeats that this is a write/update operation without adding behavioral details such as that omitted fields are left unchanged. It does not contradict the annotations, but it also contributes no new behavioral context.

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

  Conciseness2/5

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

  Three sentences are present, but the last two ('Partial update purchase order line item' and 'Endpoint for partially updating...') are near-duplicates, so not every sentence earns its place. The first badge line is informative, but the redundancy and lack of additional detail make the structure weak.

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

  Completeness2/5

  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 not say what the endpoint returns. It also omits partial-update semantics (only included fields change), prerequisites, and any error/edge-case context, leaving the agent to infer important behavior from the tool name alone.

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

  Parameters2/5

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

  The description adds no parameter guidance; required path parameters id and purchase_order_id are undocumented in the schema, and the body parameter has a confusing serializer-oriented note about augmenting custom_fields output rather than explaining that it contains the fields to update. The idempotency_key is well explained in the schema, but the description itself fails to clarify the body semantics.

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

  Purpose4/5

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

  The description clearly states the operation as 'Partial update purchase order line item' and includes the HTTP method (PATCH) and resource path, making it unambiguous which resource is being modified. It does not explicitly name sibling alternatives, 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.

  Usage Guidelines3/5

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

  The word 'partial' and the endpoint design imply this tool should be used to update a subset of fields on an existing purchase order line item, but the description never states when to use it versus the full-update sibling or other line-item tools. No alternatives or exclusions are mentioned.

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

• wafeq_purchase_orders_line_items_updateC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description's WRITE label is consistent with them. The description adds the HTTP method and endpoint path, but adds little behavioral context beyond the annotations — no mention of the response, effect on purchase order totals, or overwrite semantics. No contradiction.

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

  Conciseness2/5

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

  The description states the same fact three times: the 'WRITE · updates data' label, 'Update purchase order line item', and 'Endpoint for updating an existing purchase order line item' are all redundant. Only the PUT path carries new information; the sentences do not each earn their place.

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

  Completeness2/5

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

  This is a write operation with a nested 10-property body and 3 required params, and no output schema. The three-line description explains none of the required body fields, the PUT-versus-PATCH choice against partial_update, or what the response contains, leaving an agent to fully parse the schema and infer behavior.

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

  Parameters2/5

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

  With 50% schema coverage, the path params purchase_order_id and id have no schema descriptions, but the URL template in the description partially reveals their role. However, the tool description does not clarify the required body fields (description, quantity, unit_amount) or their semantics, and the body's schema description is confusingly framed around serializer internals like 'get_resolved_custom_fields'.

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

  Purpose4/5

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

  States a specific verb and resource twice: 'Update purchase order line item' and 'Endpoint for updating an existing purchase order line item', and includes the exact PUT path /purchase-orders/{purchase_order_id}/line-items/{id}/. This differentiates it from create/destroy/list siblings, though it does not explicitly distinguish it from the partial_update sibling.

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

  Usage Guidelines2/5

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

  No guidance on when to use this full PUT update versus the sibling wafeq_purchase_orders_line_items_partial_update, no prerequisites (e.g., the line item must exist, purchase order state), and no exclusions or alternatives. The description only restates the operation without any usage context.

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

• wafeq_simplified_invoices_partial_updateC
  2.7/5.0
  Behavior2/5

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

  The annotations already convey readOnlyHint=false and idempotentHint=true; the description merely restates 'WRITE · updates data' and adds the PATCH endpoint without any behavioral depth. It discloses nothing about partial-update semantics, validation failures, or leftover-field behavior — the valuable idempotency detail lives in the schema, not the description. No contradiction with annotations.

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

  Conciseness2/5

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

  The three lines contain clear redundancy: 'Partial update simplified invoice' and 'Endpoint for partially updating an existing simplified invoice' say the same thing. The endpoint banner earns its place, but the repetition wastes space that could have been used for usage guidance.

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

  Completeness2/5

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

  For a tool with a large nested body, strict enums, and no output schema, this description is too thin. An agent is left without essential operational context: whether line_items replaces or merges, which body fields are valid to send on a partial update, and what a successful response looks like. The strong idempotency_key schema documentation is the only compensating factor.

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

  Parameters3/5

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

  The description itself mentions no parameters, but schema coverage at 67% means most of the load is already carried by the schema, which documents idempotency_key thoroughly and every body field individually. The cryptic 'Adds nested create feature' and the DRF ModelSerializer boilerplate for line_items remain unexplained, but that is a schema gap, not a description gap.

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

  Purpose4/5

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

  The description clearly identifies the operation (partial update) and resource (simplified invoice), reinforced by the PATCH /simplified-invoices/{id}/ endpoint banner. The word 'partial' implicitly differentiates it from the full-update sibling, though it never names that sibling or explains when one is preferred over the other.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus wafeq_simplified_invoices_update, wafeq_simplified_invoices_destroy, or the dedicated line-items endpoints. Nothing states that only supplied body fields are modified, or what the behavior is when line_items is provided.

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

• wafeq_units_of_measure_partial_updateC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the PATCH method and endpoint path, but beyond the '🟡 WRITE · updates data' label (which duplicates annotation info) it discloses nothing new about behavior, such as that only supplied fields are modified or what happens on invalid input. No contradiction with annotations.

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

  Conciseness2/5

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

  The description is short but redundant: 'Partial update unit of measure' and 'Endpoint for partially updating an existing unit of measure' convey the same meaning twice. The header line with the emoji, method, and path is genuinely useful, but the duplicated sentence does not earn its place, making the structure wasteful rather than concise.

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

  Completeness2/5

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

  For a write tool with no output schema, the description is incomplete. It does not explain the core semantic of a partial update (only provided fields change), does not disambiguate from the full-update sibling or the similar wafeq_item_units_of_measure_partial_update (nested item-level variant), and gives no context on prerequisites or effects. Annotations cover idempotency and non-destructiveness, but the tool-specific behavior is unexplained.

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

  Parameters2/5

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

  With schema coverage at 67%, the schema documents the body fields (name, name_ar, is_active) and the idempotency_key well, but the required 'id' parameter has no schema description. The description adds nothing about any parameter — it never explains that 'id' is the unit-of-measure identifier or that body is optional. The description fails to compensate for the one undocumented required parameter.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Partial update unit of measure' and 'Endpoint for partially updating an existing unit of measure.' The word 'partial' implicitly distinguishes it from the full-update sibling (wafeq_units_of_measure_update), and the header provides the HTTP method and endpoint path. However, it stops short of explicitly naming the sibling it is not, and the same statement is repeated twice.

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

  Usage Guidelines2/5

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

  No guidance is given on when to choose this tool versus the full-update sibling wafeq_units_of_measure_update, nor when not to use it. There is no mention of the partial-vs-full tradeoff (only provided fields change) or any alternatives. The only hint is the word 'partial,' which is too weak to count as implied usage guidance.

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

• wafeq_bank_accounts_statement_transactions_listC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the '🟢 READ-ONLY' marker in the description adds nothing new. The description does contribute the HTTP method and full endpoint path (GET /bank-accounts/{bank_account_id}/statement-transactions/), which gives mild behavioral context. No additional traits such as pagination behavior, result ordering, or response shape are disclosed.

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

  Conciseness3/5

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

  The description is very short and front-loads the safety marker and endpoint, which is good. However, 'List bank statement transactions' and 'Endpoint for retrieving a list of bank statement transactions' are redundant restatements of the same thing, wasting one of only three sentences.

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

  Completeness2/5

  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 says nothing about what fields are returned or how results are ordered. Most importantly, it fails to clarify the distinction between statement transactions and ledger transactions, leaving an agent unable to choose correctly between this tool and the near-identical sibling. The low parameter complexity helps, but the missing differentiation is a significant gap.

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

  Parameters2/5

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

  Schema description coverage is 67%; page and page_size are already documented in the schema, leaving the required bank_account_id undocumented in both the schema and the description. The description adds no parameter meaning beyond the endpoint path's implicit hint that bank_account_id identifies the bank account. It does not compensate for the uncovered required parameter.

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

  Purpose4/5

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

  The description states a clear verb and resource: 'List bank statement transactions' and 'Endpoint for retrieving a list of bank statement transactions.' The endpoint path in the header adds useful specificity about the resource. However, it does not differentiate this tool from the similarly-named sibling wafeq_bank_accounts_ledger_transactions_list, and the two main sentences are essentially redundant restatements of the same idea.

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

  Usage Guidelines2/5

  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. Critically, it does not explain how statement transactions differ from ledger transactions, despite the highly confusable sibling wafeq_bank_accounts_ledger_transactions_list also being available. No conditions, prerequisites, or exclusions are stated.

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

• wafeq_bank_accounts_statement_transactions_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the '🟡 WRITE · updates data' prefix adds little. The explicit PUT method offers mild extra context implying full-resource update semantics consistent with the required amount/date/statement_balance fields, but no further behavior such as validation rules or effects on related records is disclosed. No contradiction with annotations.

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

  Conciseness3/5

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

  The description is short and front-loaded with a useful WRITE/PUT marker, but it restates the same operation three times ('updates data', 'Update bank statement transaction', 'updating an existing bank statement transaction'). The final two sentences are redundant and could be merged into one.

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

  Completeness2/5

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

  For a tool with a nested body object, three required parameters, and no output schema, this description is too thin. It provides no domain context about statement transactions, no update semantics beyond the bare verb, and no validation constraints, and with 50% schema coverage the unexplained parameters leave an agent under-informed.

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

  Parameters2/5

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

  Schema description coverage is only 50%, and several parameters (bank_account_id, id, date, reference, description, bank_reference) have no descriptions. The tool description adds nothing about parameter meaning, relationships, or required body fields, so it fails to compensate for the coverage gap; only the idempotency_key schema text is genuinely informative.

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

  Purpose4/5

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

  The description names a specific verb and resource ('Update bank statement transaction', 'updating an existing bank statement transaction') and the PUT path identifies the exact target. The action distinguishes it from the create/retrieve/list/destroy siblings on the same resource, though it does not explicitly contrast with partial_update.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus the sibling partial_update, create, retrieve, or destroy variants. There is no mention of prerequisites, typical use cases, or exclusions, so an agent gets no help choosing this over alternatives.

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

• wafeq_bills_listC
  2.8/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'READ-ONLY' and 'retrieving' add no new behavioral information. It does not disclose pagination behavior, response shape, filtering semantics, or any side effects.

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

  Conciseness3/5

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

  The description is very short but repetitive: 'List bills' and 'Endpoint for retrieving a list of bills' say essentially the same thing. The front-loaded endpoint/read-only marker is useful, but the redundancy slightly reduces clarity.

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

  Completeness2/5

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

  With 14 optional parameters, no output schema, and no mention of default pagination, filter behavior, or how parameters combine, the description is too thin to fully guide an agent. The schema covers parameter names, but the endpoint semantics remain under-explained.

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself adds no parameter-level meaning beyond the schema, but it does not need to because the schema is thorough.

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

  Purpose4/5

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

  The description clearly states the tool lists bills and is an endpoint for retrieving a list of bills. It is a specific verb+resource combination that distinguishes it from retrieve/create/update/delete bill tools, though it does not explicitly name any sibling alternative.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this over wafeq_bills_retrieve, wafeq_bills_create, or other list endpoints. The description merely states what it does, not the conditions or context in which it should be used.

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

• wafeq_contacts_listC
  2.8/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description's 'READ-ONLY' adds no new behavioral information. It also does not disclose pagination behavior, filtering semantics, default page size, or what data is returned. There is no contradiction, but the description adds little 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.

  Conciseness3/5

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

  The description is short and front-loaded, but it is redundant: 'List contacts' and 'Endpoint for retrieving a list of contacts' say the same thing. The emoji and endpoint line add some context, but the duplicate phrasing means not every sentence earns its place.

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

  Completeness2/5

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

  With 10 parameters, no output schema, and no explanation of pagination or filtering behavior, this description is too minimal for an agent to fully understand the tool's behavior. The schema supplies parameter names, but the description misses guidance about result shape, default behavior, or how the filters interact.

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

  Parameters3/5

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

  Schema description coverage is 90%, and most parameters have their own descriptions, so the baseline is 3. The tool description itself contributes nothing about parameters, but the schema carries the burden. Some schema descriptions are inaccurate or repetitive, such as the date filters referring to 'bill' rather than 'contact,' and the description does not help resolve that.

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

  Purpose4/5

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

  The description clearly states the operation: 'List contacts' and 'Endpoint for retrieving a list of contacts.' It identifies the resource and distinguishes itself from the sibling contact tools like wafeq_contacts_retrieve, create, update, and destroy. It could be stronger by noting list-specific scope or contrast, but it is unambiguous.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives. Among the many list endpoints in the sibling set, the description does not explain that this is for contact retrieval or mention any prerequisites, exclusions, or related tools. The intended usage must be inferred entirely from the tool name.

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

• wafeq_employees_partial_updateC
  2.8/5.0
  Behavior2/5

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

  Annotations already convey readOnlyHint=false and destructiveHint=false, so the '🟡 WRITE · updates data' badge adds nothing new. The description fails to disclose the core behavioral trait of a PATCH operation — that omitted fields remain unchanged and only supplied body fields are merged in. It also doesn't mention response shape, validation errors, or permission requirements. Given annotations exist, the bar is lower, but the description still contributes almost no behavioral context beyond what structured fields already state.

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

  Conciseness3/5

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

  The description is short at roughly four lines, but it is redundant: 'Partial update employee' and 'Endpoint for partially updating an existing employee' say the same thing twice. The metadata badge line (write indicator, resource, HTTP method) is useful and front-loaded, but the duplicated prose wastes space that could have been used for behavioral detail.

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

  Completeness2/5

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

  For a write operation with a nested request body, no output schema, and a closely related full-update sibling, the description is under-specified. It omits what a successful response contains, the merge semantics of partial update versus full replacement, and any note about the idempotency behavior that would matter for retries. The schema is moderately rich, but the description carries too much of the explanatory burden for this operation's complexity and fails to meet it.

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

  Parameters3/5

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

  Schema coverage is 67%; the body fields and idempotency_key are well-documented in the schema, with each nested field (city, name, user, email, address, country, date_hired) carrying a meaningful description. The id parameter lacks a schema description and the description text does not compensate for it. The body's own schema description is unhelpful DRF boilerplate ('A ModelSerializer that takes additional arguments...'), but the nested field descriptions mostly carry the weight. The tool description itself adds no parameter-level meaning, so it neither improves nor degrades the 67% coverage baseline.

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

  Purpose4/5

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

  The description states a clear verb+resource combination ('updates data · Employees · PATCH /employees/{id}/') and explicitly says 'partially updating an existing employee.' The word 'partial' implicitly distinguishes it from the full-update sibling wafeq_employees_update, and the HTTP method PATCH reinforces the intent. However, it never names the alternative or spells out that only submitted fields are modified, so sibling differentiation is implicit rather than explicit.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use partial update versus the full update (wafeq_employees_update) or the retrieve/destroy siblings. No prerequisites, no exclusions, and no mention of required permissions or whether the employee must already exist. The phrase 'an existing employee' is the only faint contextual signal, which is not enough for an agent to reliably choose among the four employee operations.

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

• wafeq_expenses_updateC
  2.8/5.0
  Behavior2/5

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

  The '🟡 WRITE · updates data' phrasing merely restates what the annotations already convey via readOnlyHint=false, and 'existing' only mildly implies the expense must already exist. The critical PUT behavior — that a full update typically replaces the record and requires all required body fields — is not disclosed, which is especially important given the partial_update sibling. The description does not contradict the annotations (idempotentHint=true is consistent with PUT), but it adds little beyond them.

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

  Conciseness3/5

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

  The description is short and front-loaded with the action marker, but it expresses the same idea three times: 'updates data', 'Update expense', and 'Endpoint for updating an existing expense'. The redundancy wastes valuable space that could have clarified update semantics. One clear statement plus the method would be tighter.

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

  Completeness2/5

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

  For a PUT endpoint with a nested body of 15+ properties and no output schema, the description is too thin. It fails to state the full-update semantics, what happens to omitted fields, or what the response contains. An agent choosing between this and wafeq_expenses_partial_update cannot determine correct invocation from the description alone.

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

  Parameters3/5

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

  With 67% schema description coverage, the nested body properties are individually well documented in the schema (date, amount, currency, account, paid_through_account, and others all have descriptions). The description itself adds almost no parameter meaning — it doesn't clarify that 'id' is the expense identifier beyond the URL pattern, nor that the body's six required fields must all be present. This lands at the baseline level rather than compensating for the undocumented top-level parameters.

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

  Purpose4/5

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

  The description states a specific verb and resource — 'updates data · Expenses' and 'updating an existing expense' — and includes the HTTP method and path (PUT /expenses/{id}/). It clearly identifies this as a write operation on an existing expense, distinguishing it from creation tools. However, it does not differentiate itself from the sibling wafeq_expenses_partial_update, which also updates expenses, leaving the PUT-vs-PATCH distinction implicit.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. The description never mentions wafeq_expenses_partial_update for partial edits, wafeq_expenses_create for new expenses, or the trade-offs of a full PUT update. An agent must infer selection criteria entirely from the tool name and the HTTP method.

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

• wafeq_invoices_line_items_partial_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the HTTP method and update semantics, but says nothing about side effects, response behavior, or which fields are affected. No contradiction with annotations exists.

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

  Conciseness3/5

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

  The description is short and front-loaded with the method and resource, which is good. However, 'Partial update invoice line item' and 'Endpoint for partially updating an existing invoice line item' redundantly restate the same fact, so structure is functional but not tight.

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

  Completeness2/5

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

  Given the complex nested body, lack of output schema, and many sibling line-item tools, this description is too thin. It does not define what 'partial' means operationally, which fields can be updated, how the idempotency key works, or how this tool differs from wafeq_invoices_line_items_update.

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

  Parameters2/5

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

  The description does not explain any parameters. The body parameter's schema description is unrelated to the line item body itself, mentioning custom_fields and CALCULATED fields, which is confusing. The schema provides descriptions for many nested fields, but the top-level body, id, and invoice_id parameters are poorly documented and the description does not compensate.

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

  Purpose4/5

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

  The description clearly states the verb and resource: 'Partial update invoice line item' with endpoint PATCH /invoices/{invoice_id}/line-items/{id}/. It is distinguishable from sibling tools like wafeq_invoices_line_items_update by the explicit 'partial' qualifier, though it does not explicitly name that sibling.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus the full-update sibling or when a partial update is appropriate. It does not state prerequisites such as the invoice or line item needing to exist, nor does it exclude cases where full update is required.

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

• wafeq_invoices_line_items_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description's '🟡 WRITE · updates data' marker is consistent with these annotations, and the PUT method implies idempotent full-update semantics. However, the description does not explicitly disclose that a PUT replaces the line item and that omitted fields may be reset, which is meaningful behavioral context beyond what the annotations state.

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

  Conciseness3/5

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

  The first line is an effective front-loaded summary, but the remaining two lines are redundant: 'Update invoice line item' and 'Endpoint for updating an existing invoice line item' say nearly the same thing. Compact overall, but every sentence does not earn its place.

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

  Completeness2/5

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

  For a tool with a complex nested body (including revenue_recognition sub-object, write-only fields, and 11 body properties) and no output schema, the description is too thin. It omits the critical PUT-vs-PATCH behavioral difference, the fact that this is a full replacement update, and any indication of which body fields are required. The schema and annotations partially compensate, but significant agent-facing context is missing.

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

  Parameters2/5

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

  Schema description coverage is 50%, and the tool description adds zero parameter-level guidance. The top-level params invoice_id and id have no schema descriptions, and the 'body' property's schema description is a confusing internal serializer note ('Augment custom_fields in the output with computed CALCULATED field values...') that reads like output documentation, not request-body semantics. The description does nothing to compensate for these gaps.

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

  Purpose4/5

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

  The description clearly states the action ('Update invoice line item') and the exact resource (invoice line items) with the HTTP method and endpoint (PUT /invoices/{invoice_id}/line-items/{id}/). The verb+resource is specific and unambiguous. However, it does not distinguish itself from the sibling wafeq_invoices_line_items_partial_update, which has nearly identical purpose.

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

  Usage Guidelines2/5

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

  No guidance is given for when to use this full PUT update versus the nearly identical sibling wafeq_invoices_line_items_partial_update. The tool description never mentions alternatives, exclusions, or the PUT-vs-PATCH selection criterion. An agent must infer the difference solely from the HTTP method embedded in the endpoint string.

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

• wafeq_invoices_partial_updateC
  2.8/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description's '🟡 WRITE · updates data' adds only the HTTP method, which is already visible in the endpoint string. The description omits key behavioral facts: that omitted body fields are left unchanged, whether a FINALIZED invoice can still be edited, and what side effects (e.g., audit, numbering) occur. No contradiction with annotations, but little value added beyond them.

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

  Conciseness3/5

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

  The description is short and front-loaded with the write indicator and endpoint, which is structurally good. But it is repetitive: 'updates data', 'Partial update invoice', and 'Endpoint for partially updating an existing invoice' all convey the same information. A single well-formed sentence would carry the same signal with less noise.

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

  Completeness2/5

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

  For a tool of this complexity — deeply nested line_items with revenue_recognition, credit_notes, custom_fields, many enums, and no output schema — the description is far too thin. It omits the core semantics of partial update (unmentioned fields are preserved), any editing restrictions tied to invoice status, and the relationship to the full-update and line-item sibling tools. An agent must infer critical call constraints from an unwieldy nested schema.

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

  Parameters3/5

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

  Schema description coverage is 67% and the schema documents most body fields (status, currency, line_items, etc.), so the schema carries most of the load. The tool description adds no parameter-level detail, and the required `id` parameter is undocumented in both the schema and the description. Some schema descriptions are auto-generated junk (e.g., 'Adds nested create feature' for the body, a ModelSerializer note for credit_notes), so 67% coverage overstates quality.

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

  Purpose4/5

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

  The description states a specific operation — 'partially updating an existing invoice' — with a clear resource (Invoices) and endpoint (PATCH /invoices/{id}/). The word 'partial' distinguishes it from the sibling wafeq_invoices_update, and the write semantics distinguish it from retrieve/destroy siblings. However, the same idea is stated three times ('updates data', 'Partial update invoice', 'Endpoint for partially updating an existing invoice') and no sibling is explicitly named.

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

  Usage Guidelines2/5

  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 wafeq_invoices_update (full update) or wafeq_invoices_line_items_partial_update. The description never explains that PATCH means only supplied fields change, nor that this tool should be preferred over the full update when modifying a subset of fields. An agent has no basis to choose between this and its update siblings.

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

• wafeq_item_units_of_measure_updateC
  2.8/5.0
  Behavior2/5

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

  Annotations already convey that this is a write, non-destructive, idempotent operation. The description adds only 'WRITE', 'updates data', and a PUT endpoint, offering little behavioral context beyond the annotations, such as PUT replacement semantics, validation side effects, or response behavior. No contradiction is present.

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

  Conciseness3/5

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

  The emoji-prefixed summary line is compact and informative, but the following two sentences both restate the same idea. The description could be reduced to one sentence without losing content.

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

  Completeness2/5

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

  For a mutation tool with a nested required body and no output schema, the description is sparse. It does not clarify the difference between this full update and the partial_update sibling, nor describe what a successful update returns or how missing optional body fields are treated. The agent must rely almost entirely on the schema and name.

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

  Parameters3/5

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

  The description adds no parameter-level meaning, but the input schema already documents the body fields and idempotency_key clearly. With 67% schema description coverage and detailed nested field descriptions, the schema carries the semantic weight, so the description does not need to compensate.

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

  Purpose4/5

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

  The description states 'Endpoint for updating an existing item unit of measure', which clearly identifies the action and resource. It distinguishes the tool from create, retrieve, and destroy, though it does not differentiate it from the sibling partial_update tool.

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

  Usage Guidelines2/5

  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 full update over the sibling partial_update variant, and no context about prerequisites or typical use cases. The description only restates that it updates an item unit of measure, which is purpose, not usage direction.

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

• wafeq_payment_requests_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, so the 'WRITE' marker adds little novel information. The description does add the PUT method and endpoint path as genuine behavioral context, and the schema's idempotency_key description reinforces idempotentHint=true. No contradiction with annotations.

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

  Conciseness3/5

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

  Short and front-loaded with the WRITE marker and endpoint, which is good. But the content is redundant: 'Update payment request' and 'Endpoint for updating an existing payment request' restate the same point and duplicate the title.

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

  Completeness2/5

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

  The tool has a nested body object with 9 required fields and a sibling partial-update variant, yet the description is only a title-length clause. It does not explain full-update semantics, the id+body requirement, or why an agent would choose this over wafeq_payment_requests_partial_update, and there is no output schema to fall back on.

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

  Parameters2/5

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

  The description adds nothing about parameters. Schema coverage is 67%, so the schema documents most fields, but the id parameter has no schema description and the description does not clarify it. The body description ('An entity that can have attachments') is weak, and the tool description does not compensate.

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

  Purpose4/5

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

  States a specific verb and resource ('Update payment request') and identifies the HTTP method (PUT) and endpoint path. The purpose is unambiguous, but it does not differentiate from the sibling wafeq_payment_requests_partial_update, whose reason for existing is the full-vs-partial update distinction.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. Critically, it never explains that PUT implies full replacement semantics versus wafeq_payment_requests_partial_update, or when an agent should prefer one over the other. Usage is only implied by the verb 'update'.

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

• wafeq_payments_listC
  2.8/5.0
  Behavior2/5

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

  The description mostly repeats what the annotations already state: ✅ READ-ONLY aligns with readOnlyHint=true, and 'List payments' matches the title. It adds the HTTP method and path, which is mild context, but it does not disclose anything beyond the annotations such as pagination behavior, response shape, or any default filtering semantics. With 13 parameters and no output schema, more behavioral context would be valuable.

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

  Conciseness3/5

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

  The description is short and front-loaded with the READ-ONLY badge and endpoint, which is good. However, 'List payments' and 'Endpoint for retrieving a list of payments' are redundant, so not every sentence earns its place. It is concise but slightly repetitive and under-specified for a tool with 13 optional filters.

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

  Completeness2/5

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

  For a list endpoint with 13 parameters, no output schema, and a large sibling set, the description is too minimal. It does not explain whether all parameters can be combined, what the default page size is, what fields are returned, or how this differs from related payment tools. An agent would have to infer most context from parameter names alone.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all 13 parameters including date filters, pagination, and related-entity identifiers. The description adds no parameter-level meaning beyond 'list payments', which is exactly what the baseline 3 captures: the schema does the heavy lifting and the description contributes nothing extra.

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

  Purpose4/5

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

  The description clearly states the operation ('List payments') and the resource ('/payments/'), so an agent can tell this is a read-only list endpoint. However, it does not explicitly distinguish it from sibling tools like wafeq_payments_retrieve, wafeq_payments_download_retrieve, or wafeq_payment_requests_list, relying mostly on the tool name and the word 'list'.

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

  Usage Guidelines2/5

  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 wafeq_payments_retrieve for a single payment, wafeq_payments_download_retrieve for downloading payments, or wafeq_payment_requests_list for payment requests. The description simply restates the endpoint and provides no exclusions or selection criteria.

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

• wafeq_payments_partial_updateC
  2.8/5.0
  Behavior2/5

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

  Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) already carry the safety profile, and the description adds no behavioral context on top — it merely restates 'updates data.' Given openWorldHint=true, an agent gets no warning that updating a payment can cascade to linked invoices, bills, or reconciliation state. There is no contradiction with 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.

  Conciseness3/5

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

  The essential signal (WRITE · PATCH · /payments/{id}/ · partial) is front-loaded in a compact prefix line, which is good. But the same fact is restated three times — 'updates data,' 'Partial update payment,' and 'Endpoint for partially updating an existing payment' — adding redundancy without information.

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

  Completeness2/5

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

  The rich schema and annotations carry most of the burden, but for a write operation on a complex nested financial resource with openWorldHint=true, the description offers no guidance about effects on reconciliation or when partial update is preferable to full update. No output schema exists and the description explains no return behavior. The missing sibling differentiation and behavioral context leave the agent under-informed.

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

  Parameters3/5

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

  Schema description coverage is 67% and the body parameter's nested fields are documented exhaustively in the schema (amount reconciliation, payment_fees semantics, advance blocks), so the description does not need to compensate. It contributes the path template /payments/{id}/, which clarifies that id is the URL path parameter. The idempotency_key semantics are fully described in the schema.

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

  Purpose4/5

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

  The description states the operation precisely: 'Endpoint for partially updating an existing payment,' with the HTTP method and path (PATCH /payments/{id}/) front-loaded. The verb phrase 'partially updating' distinguishes it from the full-replacement sibling wafeq_payments_update, 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.

  Usage Guidelines2/5

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

  No guidance is given on when to use this PATCH instead of wafeq_payments_update (full update) or wafeq_payments_create, nor any mention of prerequisites such as an existing payment or its reconciliation state. The only usage signal is the implicit REST convention that 'partial' means only supplied fields change; the sibling list makes the choice relevant, but the description leaves it to inference.

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

• wafeq_payslips_updateC
  2.8/5.0
  Behavior2/5

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

  The annotations already convey that this is a non-read-only, non-destructive, idempotent write operation (readOnlyHint=false, idempotentHint=true). The description's 'WRITE · updates data' adds nothing beyond those annotations. It does not disclose whether the update performs full replacement of payslip fields (as the required body fields suggest) or a merge, and does not discuss side effects such as status transitions or versioning.

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

  Conciseness3/5

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

  The description is short and front-loaded, but it redundantly restates the same idea four times: 'WRITE', 'updates data', 'Update payslip', and 'Endpoint for updating an existing payslip'. A single concise sentence would convey the same meaning with less noise.

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

  Completeness2/5

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

  For a mutation tool with a nested body, three top-level parameters, no output schema, and a close sibling (wafeq_payslips_partial_update), the description is too thin. It leaves the agent to guess full-replacement semantics, the difference from partial update, and any constraints on updating posted payslips. The schema and annotations are rich, but the description fails to tie them together with operational context.

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

  Parameters3/5

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

  Schema description coverage is 67%, and the nested body object is richly documented with per-field descriptions for currency, employee, pay_items, status, and others — so the schema carries the parameter-semantics burden. The description itself contributes zero parameter-level information. The body property's schema description ('Adds nested create feature') is a confusing template artifact that mentions 'create' for an update tool, slightly undermining clarity.

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

  Purpose4/5

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

  The description states a clear verb and resource: 'Endpoint for updating an existing payslip' and 'PUT /payslips/{id}/'. This unambiguously identifies the operation as a full update to a payslip resource. However, it does not explicitly differentiate itself from the sibling wafeq_payslips_partial_update, relying on the name and HTTP method to imply the distinction.

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

  Usage Guidelines2/5

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

  No usage guidance is given. The description does not say when to prefer this full update over wafeq_payslips_partial_update, nor does it mention the relationship to wafeq_payslips_create or when an update is appropriate (e.g., only on DRAFT vs POSTED status). An agent must infer the selection criteria entirely from tool names.

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

• wafeq_projects_partial_updateC
  2.8/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds 'WRITE', 'updates data', and 'PATCH', which largely restate the annotations and the endpoint. It does not disclose additional behavioral details such as what happens to omitted fields, whether the operation is reversible, or any response characteristics.

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

  Conciseness3/5

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

  The description is short and front-loaded with the method and path, but it repeats itself: 'Partial update project' and 'Endpoint for partially updating an existing project' convey the same information. Some sentences are redundant rather than earning their place.

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

  Completeness2/5

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

  For a mutation tool with no output schema and a sibling full-update tool, the description is too sparse. It does not explain the distinction from wafeq_projects_update, the semantics of partial update, or what the response looks like. The annotations and schema fill some gaps, but the description leaves selection and invocation nuances unaddressed.

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

  Parameters3/5

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

  Schema description coverage is 67%, with body and idempotency_key reasonably documented inside the schema. The tool description adds almost no parameter meaning beyond implying that 'id' refers to an existing project. It does not compensate for the undocumented id parameter, but the schema carries most of the load.

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

  Purpose4/5

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

  The description clearly states the resource (projects), the verb (partial update), and the HTTP method/path (PATCH /projects/{id}/). It is unambiguous about what the tool does, though it does not explicitly contrast itself with the sibling full-update tool.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this tool over alternatives such as wafeq_projects_update, wafeq_projects_create, or wafeq_projects_destroy. The only signal is the word 'partial' in the name and description, which is implied rather than explicitly explained.

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

• wafeq_purchase_orders_updateC
  2.8/5.0
  Behavior3/5

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

  The description adds the HTTP method 'PUT /purchase-orders/{id}/' and the 'WRITE' signal, which is mildly informative beyond the readOnlyHint=false annotation. However, it does not disclose PUT replacement semantics, whether omitted fields are reset, or the consequences of updating an existing purchase order. It mostly restates what annotations already convey.

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

  Conciseness3/5

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

  The description is short and front-loaded with the endpoint and method, but it repeats itself: 'updates data', 'Update purchase order', and 'Endpoint for updating an existing purchase order' all convey the same information. The redundancy reduces conciseness without adding value.

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

  Completeness2/5

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

  This is a complex update tool with nested line_items, required currency and body fields, an idempotency key, and a sibling partial_update endpoint. The description provides no context about full-update behavior, differences from partial updates, how line_items are replaced, or what the response looks like. The lack of an output schema makes the missing contextual guidance more impactful.

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

  Parameters2/5

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

  The description adds no parameter-level explanation. The schema itself provides descriptions for most body fields, but the body's own description 'Adds nested create feature' is confusing and irrelevant for an update operation. With 67% schema description coverage, the description still fails to clarify the required top-level body structure or the meaning of the idempotency key beyond what the schema already says.

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

  Purpose4/5

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

  The description clearly states the operation: 'Update purchase order' and 'Endpoint for updating an existing purchase order.' The verb and resource are explicit. However, it does not differentiate from the sibling wafeq_purchase_orders_partial_update, which also updates purchase orders, 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.

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus wafeq_purchase_orders_partial_update, wafeq_purchase_orders_create, or other purchase order endpoints. No conditions, exclusions, or alternatives are mentioned. An agent must infer its usage solely from the name and endpoint.

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

• wafeq_quotes_line_items_partial_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description's 'WRITE · updates data' is consistent with them rather than adding much. It contributes the PATCH semantics and the idempotency behavior is covered by the idempotency_key parameter description. No contradiction with annotations, but little extra behavioral context beyond the structured data.

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

  Conciseness3/5

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

  The description is short but repetitive: the WRITE status line, the title, and the closing sentence all restate the same 'partially update quote line item' idea three times. It is compact, but the redundancy wastes the few sentences it uses.

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

  Completeness2/5

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

  For a nested-body partial update with no output schema, the description is too thin. It does not explain that only supplied fields change, which fields are updatable, where quote_id/id come from, or what the response contains. An agent would need to open the schema and infer the rest.

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

  Parameters2/5

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

  Schema description coverage is only 50%, leaving quote_id and id entirely undocumented, and the main description adds no parameter-level meaning. The body description in the schema is an auto-generated serialization note about custom_fields rather than an explanation of the request payload. The description fails to compensate for the coverage gap.

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

  Purpose4/5

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

  The description identifies a specific verb and resource: 'Partial update quote line item' with the exact HTTP path 'PATCH /quotes/{quote_id}/line-items/{id}/'. This clearly distinguishes it from quote-level updates (wafeq_quotes_partial_update) and full line-item updates (wafeq_quotes_line_items_update), though it does not explicitly name those siblings.

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

  Usage Guidelines2/5

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

  No guidance is given on when to choose a partial update (PATCH) over a full update (PUT), when to use create/destroy instead, or how to obtain the required quote_id and line-item id. The agent is left to infer usage from the HTTP method alone.

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

• wafeq_quotes_line_items_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description is not solely responsible for conveying write behavior. The description adds the HTTP method PUT and the precise resource path, which is useful but thin. There is no contradiction with annotations, but no deeper behavioral context such as full-replacement semantics is disclosed.

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

  Conciseness3/5

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

  The description is short and front-loaded with a structured summary line, which is good. However, it redundantly repeats the same idea three times: 'updates data · Quote Line Items', 'Update quote line item', and 'Endpoint for updating an existing quote line item'. It could be tightened into one or two non-repetitive sentences.

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

  Completeness2/5

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

  With no output schema and a nested required body, the description should clarify response behavior and distinguish this full PUT update from the partial_update sibling. It does neither. The many similar sibling tools make the missing usage semantics a real gap for agent selection.

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

  Parameters2/5

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

  Top-level schema description coverage is only 50%, and quote_id and id have no descriptions while the body schema's description is a confusing leftover about augmenting custom_fields in output rather than explaining the update payload. The nested field descriptions and the path template provide some help, but the tool description itself adds no parameter guidance, so it does not compensate for the coverage gap.

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

  Purpose4/5

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

  The description states 'Update quote line item' and 'Endpoint for updating an existing quote line item,' with a resource-specific path /quotes/{quote_id}/line-items/{id}/. This clearly identifies the verb and resource and differentiates it from sibling line-item updates for invoices, bills, credit notes, etc. It loses a point for not listing which fields are updatable or otherwise deepening the resource description.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus the directly relevant sibling wafeq_quotes_line_items_partial_update, nor versus line-item update tools for other document types. The description only restates the operation and gives no conditions, exclusions, or alternatives.

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

• wafeq_accounts_listC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description mostly repeats this as 'READ-ONLY'. It adds no additional behavioral context such as pagination behavior, filtering semantics, default page size, or what the response list contains.

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

  Conciseness3/5

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

  The description is short and front-loaded with the endpoint and read-only indicator, which is good. However, 'List accounts' and 'Endpoint for retrieving a list of accounts' are redundant, so not every sentence earns its place.

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

  Completeness3/5

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

  For a simple list endpoint, the description combined with the schema covers the basic action and all filter parameters. It is missing guidance on pagination defaults, response format, and how this list relates to other account operations, but it is minimally adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 10 parameters are already documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the operation as listing/retrieving accounts, with the endpoint 'GET /accounts/' and the title 'List accounts'. It is distinguishable from siblings like wafeq_accounts_retrieve by the plural 'list' framing, though it does not explicitly contrast itself with any sibling.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus the many related account tools such as wafeq_accounts_retrieve, wafeq_accounts_create, or wafeq_accounts_update. The description simply states what it does and provides no selection criteria or exclusions.

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

• wafeq_bank_accounts_ledger_transactions_listC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description merely restates 'READ-ONLY' and GET. It adds no new behavioral context such as pagination behavior, filtering, ordering, or response shape, so it does not meaningfully supplement 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.

  Conciseness3/5

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

  The description is short and front-loaded with a safety marker and endpoint, but 'list bank ledger transactions' is effectively stated three times, making the final sentence redundant.

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

  Completeness3/5

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

  For a read-only list operation, the endpoint and required parameter are present, and pagination is covered by the schema. However, there is no description of what is returned, no filtering/sorting details, and no distinction from the statement-transactions list, leaving a meaningful gap for an agent navigating many similar bank-account endpoints.

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

  Parameters3/5

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

  The schema documents page and page_size, and the description's endpoint path clarifies that bank_account_id is a path parameter. However, bank_account_id itself has no description, and the description adds little meaning beyond what the schema already contains.

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

  Purpose4/5

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

  The description clearly identifies the operation as 'List bank ledger transactions' with an exact GET endpoint path, so an agent can tell it retrieves ledger transactions for a specific bank account. It does not explicitly contrast this with sibling statement-transaction or other list endpoints, so it is clear but not strongly differentiated.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus wafeq_bank_accounts_statement_transactions_list or related ledger-transaction endpoints. Usage context must be inferred entirely from the tool name and endpoint path.

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

• wafeq_bank_accounts_ledger_transactions_partial_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already cover write behavior, idempotency, and non-destructiveness. The description adds the PATCH method and the "partial" semantics, but it does not explain behavioral details such as whether omitted fields remain unchanged, whether the request is a true PATCH, or what validations apply. No contradiction with annotations is present.

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

  Conciseness3/5

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

  The description is short and the key information is front-loaded, but it is repetitive: "Partial update bank ledger transaction" and "Endpoint for partially updating an existing bank ledger transaction" say the same thing. The header line also restates what the tool name already communicates.

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

  Completeness2/5

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

  This is a nested-body PATCH operation with no output schema, yet the description provides only minimal context. It does not describe the response, which fields are actually updatable, how the body object relates to the endpoint, or any edge cases such as validation constraints or required field combinations. The description relies heavily on the schema and annotations to carry the meaning.

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

  Parameters3/5

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

  The path template in the description helps identify bank_account_id and id as URL parameters, which the schema itself does not describe. The body parameter's fields are documented in the schema, but the description does not explain how to construct the body object or where to obtain the required IDs, leaving the 50% schema coverage gap only partially compensated.

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

  Purpose4/5

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

  The description clearly identifies the verb (updates), resource (bank ledger transaction), and HTTP method (PATCH), and repeats this in plain language: "Partial update bank ledger transaction." It is unambiguous, but it does not explicitly contrast itself with the sibling full-update tool, so it does not fully earn a 5.

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

  Usage Guidelines2/5

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

  No guidance is given about when to choose this partial-update tool versus the sibling update, retrieve, create, or destroy tools. The word "partial" implies a use case, but the description never states that this should be used when only a subset of fields needs changing or that the full-update sibling should be used otherwise.

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

• wafeq_bank_accounts_ledger_transactions_retrieveC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only the HTTP method (GET) and endpoint path, which is mild operational context but no deeper behavioral traits such as 404 behavior, permission requirements, or ledger-versus-statement semantics. The description's READ-ONLY label is consistent with annotations — no contradiction.

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

  Conciseness3/5

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

  The description is short and reasonably front-loaded with the badge and endpoint path, but it is redundant: 'Retrieve bank ledger transaction' and 'Endpoint for retrieving a single bank ledger transaction' say the same thing in consecutive lines. That wasted sentence could have been used for disambiguation or usage guidance.

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

  Completeness3/5

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

  For a simple two-parameter read-only retrieve with rich safety annotations, the endpoint, method, and schema cover most invocation needs. Missing are domain context (what a ledger transaction is versus a statement transaction) and any hint about the response, since no output schema exists. The ambiguity with wafeq_bank_accounts_statement_transactions_retrieve is a real gap the description does not resolve.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries the full burden, but it adds little. The URL template /bank-accounts/{bank_account_id}/ledger-transactions/{id}/ does imply the parent-child hierarchy and clarifies that 'id' is the transaction identifier, and the parameter names are fairly self-explanatory. However, the description never explains what a ledger transaction is, how to obtain valid IDs, or any format constraints, leaving the agent to infer everything from names.

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

  Purpose4/5

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

  The description states a specific verb and resource ('Retrieve bank ledger transaction') and specifies it targets a single record via the GET endpoint path. This distinguishes it from the sibling list/create/update/destroy tools for the same resource. However, the same idea is repeated twice ('Retrieve bank ledger transaction' / 'Endpoint for retrieving a single bank ledger transaction'), and it does not differentiate from the closely-related wafeq_bank_accounts_statement_transactions_retrieve.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. It never mentions that the list variant should be used for multiple transactions, nor does it clarify when one would choose ledger transactions over statement transactions — a genuine ambiguity given the sibling list. The word 'single' is the only implicit usage signal, and no exclusions are stated.

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

• wafeq_beneficiaries_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false), non-destructive, and idempotent. The description adds that the beneficiary must already exist and exposes the PUT method, which hints at full-replacement semantics, but it does not explain side effects, required-field reset behavior, or response details.

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

  Conciseness3/5

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

  The description is short and front-loaded with the HTTP method and endpoint, but it is repetitive: 'Update beneficiary' and 'Endpoint for updating an existing beneficiary' restate the same idea. It is not bloated, but it does waste some words.

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

  Completeness2/5

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

  For a write endpoint with a nested body and a close sibling partial_update tool, the description leaves important behavior implicit, particularly full-update semantics and when to choose this over partial_update. There is no output schema and the description does not clarify what the caller should expect in return.

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

  Parameters3/5

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

  The description itself adds no parameter-level meaning, but the schema provides solid documentation for most fields, including enums, formats, and required nested properties. With 67% top-level schema coverage and detailed nested field descriptions, the schema carries most of the burden, so the description is not required to compensate heavily.

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

  Purpose4/5

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

  The description clearly states the operation ('updating') and the resource ('an existing beneficiary'), and the HTTP method/path (PUT /beneficiaries/{id}/) is explicit. It does not explicitly differentiate itself from the sibling partial_update tool, but the core purpose is unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives such as wafeq_beneficiaries_partial_update or wafeq_beneficiaries_create. The description implies an existing beneficiary but does not explain the difference between full PUT updates and partial updates.

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

• wafeq_contacts_partial_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the partial-update behavior and notes that the target is an existing contact, which gives modest context beyond the structured annotations.

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

  Conciseness3/5

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

  The description is short and front-loaded with a clear WRITE/PATCH tag, but it repeats itself: 'Partial update contact' and 'Endpoint for partially updating an existing contact' convey the same information. It is compact but not maximally efficient.

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

  Completeness2/5

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

  For a tool with a complex nested body, no output schema, and several close siblings, the description is too thin. It does not explain what the response contains, how partial update behaves for omitted fields, or when to choose this over the full-update sibling.

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

  Parameters3/5

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

  Schema description coverage is 67%, and the schema itself provides detailed descriptions for body fields and idempotency_key, while the endpoint path in the description explains the id parameter. The description adds no direct parameter meaning, but the schema mostly carries that burden.

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

  Purpose4/5

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

  The description clearly states that the tool partially updates an existing contact, with a specific verb and resource. The term 'partial update' differentiates it from the full-update sibling wafeq_contacts_update, though it does not explicitly name that alternative.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus wafeq_contacts_update, wafeq_contacts_destroy, or wafeq_contacts_create. The description only defines what the endpoint does and does not mention when it should be preferred or which sibling handles full replacement.

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

• wafeq_contacts_retrieveC
  2.9/5.0
  Behavior2/5

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

  The description repeats the read-only safety signal already provided by annotations ('READ-ONLY', 'GET') and adds no meaningful behavioral context beyond that. It does not mention authentication, error behavior, response format, or any side effects, though annotations do confirm the operation is read-only and idempotent.

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

  Conciseness3/5

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

  The description is short and front-loaded, but it contains redundancy: 'Retrieve contact' and 'Endpoint for retrieving a single contact' say essentially the same thing. The first line already provides the key information, so the extra sentences add little value.

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

  Completeness3/5

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

  For a simple read-only retrieve operation with one parameter and strong annotations, the description is mostly adequate. However, it does not describe what the response contains, and it lacks any routing to sibling tools, so the agent gets no help choosing between this and related contact endpoints.

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

  Parameters3/5

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

  The description does not explicitly describe the 'id' parameter, but the endpoint 'GET /contacts/{id}/' makes it clear that id is the path identifier of the contact. Given that there is only one simple string parameter, this is minimally sufficient despite the 0% schema description coverage.

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

  Purpose4/5

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

  The description states a specific verb and resource ('Retrieve contact') and gives the exact endpoint 'GET /contacts/{id}/'. The phrase 'a single contact' distinguishes it from list-type tools in the sibling set, though it does not explicitly name alternatives.

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

  Usage Guidelines2/5

  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 sibling tools like wafeq_contacts_list, wafeq_contacts_create, or wafeq_contacts_update. The only implied usage is that it retrieves one contact by ID, but no explicit when-to-use or when-not-to-use direction is provided.

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

• wafeq_contacts_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description is consistent with them. The description adds the PUT method, which implies idempotent full-replacement behavior, but it does not disclose that omitted body fields with defaults may be overwritten, nor any other operational behavior. No contradiction with annotations.

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

  Conciseness3/5

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

  The description is brief and front-loads the key signal (WRITE · PUT /contacts/{id}/), which is good. But it contains redundancy: 'Update contact' and 'Endpoint for updating an existing contact' say the same thing, and 'updates data' is generic filler. A single crisp sentence would be tighter.

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

  Completeness2/5

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

  Given a complex nested body, no output schema, and a closely-related sibling (wafeq_contacts_partial_update), the description is incomplete. It never explains PUT-vs-PATCH semantics, what happens to unspecified optional fields, or what the response contains. The rich schema helps, but the critical selection question between update and partial_update is left unanswered.

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

  Parameters3/5

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

  With 67% schema description coverage, the description itself adds nothing about parameters, but the schema compensates well: idempotency_key has an excellent explanation (header name, auto-generated UUID, retry safety), and the nested body fields are individually documented. The description's silence on parameters is acceptable because the schema carries the semantic weight.

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

  Purpose4/5

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

  The description states a specific verb and resource ('Update contact', 'Endpoint for updating an existing contact') and includes the HTTP method PUT /contacts/{id}/, which hints at full-update semantics. However, it never explicitly names or distinguishes itself from the sibling wafeq_contacts_partial_update, so the differentiation is only implicit via the PUT marker.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this tool over wafeq_contacts_create, wafeq_contacts_partial_update, or wafeq_contacts_retrieve. The 'PUT' in the header line implies full replacement versus PATCH, but the description never states this or gives a selection rule, leaving the agent to infer usage entirely.

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

• wafeq_cost_centers_listC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the 'READ-ONLY' label adds no new behavioral information. The description adds only the HTTP path and does not disclose pagination defaults, auth requirements, rate limits, or response behavior. No contradiction exists, but the description contributes little 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.

  Conciseness3/5

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

  The front-loaded line with the read-only badge and endpoint is useful, but 'List cost centers' and 'Endpoint for retrieving a list of cost centers' are redundant restatements. The text is short, but one of the sentences could be removed without losing information.

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

  Completeness4/5

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

  For a simple read-only list operation with zero required parameters and full schema coverage for its two optional pagination inputs, the description is mostly sufficient. The endpoint path and 'list of cost centers' return intent give an agent enough to select and invoke the tool. Strong annotations further reduce the burden.

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

  Parameters3/5

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

  Both parameters, page and page_size, have clear descriptions in the input schema, giving 100% schema description coverage. The description adds no additional parameter semantics, which is acceptable because the schema already fully documents the parameters. The baseline of 3 applies.

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

  Purpose4/5

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

  The description clearly identifies the operation as 'List cost centers' and provides the collection endpoint 'GET /cost-centers/'. The verb and resource are unambiguous, and the read-only framing distinguishes it from mutation siblings. It does not explicitly contrast with wafeq_cost_centers_retrieve, but the list/collection semantics are clear.

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

  Usage Guidelines2/5

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

  The description offers no guidance about when to use this tool versus wafeq_cost_centers_retrieve, create, update, or destroy. It only restates that it retrieves a list, leaving the agent to infer selection from the tool name alone. No alternatives, exclusions, or context are provided.

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

• wafeq_cost_centers_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is captured by structured data. The description adds the HTTP method (PUT) and endpoint path but provides no detail about full-overwrite semantics or response behavior. It does not contradict the annotations, which is consistent with the write and idempotency hints.

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

  Conciseness4/5

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

  The description is compact and front-loaded: the first line packs in the write indicator, resource, and HTTP method. It loses a point because 'Update cost center' and 'Endpoint for updating an existing cost center' redundantly restate the same idea.

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

  Completeness2/5

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

  For a write operation with a required nested body and no output schema, the description is too thin. It omits the full-update semantics implied by PUT, offers no guidance on choosing between this and partial_update, and gives no response context — leaving the agent to infer critical behavior solely from the schema.

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

  Parameters2/5

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

  Schema coverage is 67% and the body fields plus idempotency_key are documented within the schema itself. However, the required id parameter has no schema description and the tool description adds nothing to clarify it, contributing no parameter meaning beyond the bare path template '/cost-centers/{id}/'.

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

  Purpose4/5

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

  The description uses a specific verb ('update') with a clear resource ('cost center') and identifies the operation as a PUT endpoint for an existing cost center. It is unambiguous about the core function, though it does not explicitly differentiate itself from the sibling wafeq_cost_centers_partial_update, which performs a closely related operation.

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

  Usage Guidelines2/5

  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 wafeq_cost_centers_partial_update or wafeq_cost_centers_create. The critical distinction — that PUT requires the full body (is_active, name_ar, name_en all required) while PATCH allows partial changes — is never stated, leaving an agent likely to pick the wrong update variant.

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

• wafeq_credit_notes_line_items_listC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and resource path but does not disclose additional behavior such as pagination behavior, sorting, filtering, or response structure.

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

  Conciseness3/5

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

  The description is short and front-loaded with the endpoint, but it is somewhat redundant: 'List credit note line items' and 'Endpoint for retrieving a list of credit note line items' say nearly the same thing. It is not bloated, but not every sentence adds unique value.

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

  Completeness3/5

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

  For a simple list endpoint with rich annotations, the core operation is clear. However, missing contextual details such as pagination defaults, any ordering/filtering behavior, and the meaning of the required credit_note_id leave some gaps for an agent to infer.

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

  Parameters2/5

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

  The schema documents page and page_size well, but credit_note_id has no schema description. The description only indirectly hints at credit_note_id through the endpoint path and does not explain its meaning or format, so it does not compensate for the missing parameter documentation.

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

  Purpose4/5

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

  The description clearly states the operation: listing credit note line items via a specific GET endpoint. It is unambiguous about the resource, but it does not differentiate itself from sibling list tools for other document types beyond the resource name in the endpoint.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as credit note line item retrieve, create, update, or destroy. The READ-ONLY badge implies it is for listing, but no explicit exclusions or selection criteria are stated.

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

• wafeq_credit_notes_partial_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the HTTP endpoint and confirms write semantics ('WRITE · updates data') without contradicting the annotations. It does not add deeper behavioral context such as what 'partial' preserves (omitted fields retain values) or any status-based constraints on what may be updated.

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

  Conciseness3/5

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

  The prefix line ('🟡 WRITE · updates data · Credit Notes · PATCH /credit-notes/{id}/') is compact and front-loaded, but the two sentences that follow are redundant: 'Partial update credit note' and 'Endpoint for partially updating an existing credit note' convey the same information twice, and both echo the title annotation.

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

  Completeness2/5

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

  For a complex endpoint with a large nested line_items schema, no output schema, and a partial-update semantic, the description is too thin. It does not clarify that body is optional and only supplied fields are changed, nor does it mention any constraints around updating finalized/sent credit notes, required line-item subfields, or the relationship to wafeq_credit_notes_update. The idempotency_key description is a strong asset but lives in the schema, not the tool description.

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

  Parameters3/5

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

  Schema description coverage is 67%; the schema's own descriptions for the nested body fields (notes, branch, status, line_items, etc.) and especially the idempotency_key are informative. The tool-level description adds no parameter semantics of its own, and the body's schema description ('Adds nested create feature') is an internal developer note rather than useful guidance. The id parameter has no description, though its purpose is self-evident from the name.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Partial update credit note' and 'Endpoint for partially updating an existing credit note.' The HTTP method (PATCH) and path are provided. It is clear what the tool does, though it relies on conventional PATCH-vs-PUT semantics rather than explicitly naming the sibling wafeq_credit_notes_update to differentiate.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this partial update versus the full update sibling (wafeq_credit_notes_update), the retrieve sibling, or line-items-specific endpoints. The distinction between PATCH and PUT is implied by the HTTP method and the word 'partial,' but nothing states the selection criteria (e.g., use this to update only specific fields while leaving others untouched).

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

• wafeq_custom_fields_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations carry the main safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and the description is consistent with them. The description adds the PUT method as minor behavioral context, but does not explain PUT full-replacement semantics or what happens to unspecified fields. No annotation contradiction.

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

  Conciseness3/5

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

  The first line is compact and front-loaded with the write indicator, resource, and endpoint. However, the following two sentences ('Update custom field' and 'Endpoint for updating an existing custom field') are largely redundant restatements of the title, wasting space that could have carried usage guidance.

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

  Completeness2/5

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

  Despite a rich schema and informative annotations, the description omits key context for a tool with a complex nested config: what PUT full-update semantics mean compared to partial_update, whether field_type or config can be changed on an in-use field, and what the response looks like (no output schema). An agent could invoke the wrong sibling without additional clues.

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

  Parameters3/5

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

  Schema description coverage is 100% and the schema thoroughly documents id, body, and idempotency_key, including the oneOf config variants, the discriminator, and the idempotency header behavior. The description adds no parameter information, but the baseline 3 applies because the schema carries the full burden.

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

  Purpose4/5

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

  The description states a specific verb and resource ('Update custom field', 'Endpoint for updating an existing custom field') and the first line adds the HTTP method and path (PUT /custom-fields/{id}/). It is clear about what the tool does, though it does not distinguish itself from the closely related wafeq_custom_fields_partial_update sibling.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. The description never mentions wafeq_custom_fields_partial_update, wafeq_custom_fields_create, or any condition for choosing between full PUT update and partial PATCH update. The usage context is only implied by the verb 'update'.

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

• wafeq_debit_notes_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method and endpoint path, which is useful, but it does not disclose whether this is a full replacement update, what happens to unspecified fields, or how line_items are handled. No contradiction with annotations.

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

  Conciseness3/5

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

  The description is short and front-loaded with method and path, but it contains redundancy: 'updates data', 'Update debit note', and 'updating an existing debit note' all say the same thing. It could be trimmed to a single informative sentence.

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

  Completeness2/5

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

  For a mutation tool with a complex nested body and no output schema, the description is too thin. It omits response behavior, full-replacement semantics, relationship to partial_update, and any guidance on required body construction. The annotations cover idempotency, but the tool description alone is insufficient for reliable invocation.

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

  Parameters3/5

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

  Schema coverage is 67% and the body schema provides detailed field descriptions, so the parameter meanings are mostly discoverable. The description itself adds little beyond identifying the resource path; it does not clarify the body behavior or the nested line_items semantics beyond the schema.

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

  Purpose4/5

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

  The description clearly states the verb 'update', the resource 'debit note', and that it acts on an existing record via 'PUT /debit-notes/{id}/'. It is readily distinguishable from create, retrieve, and destroy tools, though it does not explicitly differentiate itself from the sibling wafeq_debit_notes_partial_update.

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

  Usage Guidelines2/5

  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 partial_update or create. The description only restates that it updates a debit note, leaving the agent to infer context and selection criteria on its own.

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

• wafeq_expenses_partial_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's '🟡 WRITE · updates data' is consistent with those, so there is no contradiction. The description adds the PATCH verb and resource path but discloses no behavioral context beyond the annotations—critically, it never states that partial update means only supplied body fields change while omitted fields are preserved. Neutral and non-contradictory, but with little added value.

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

  Conciseness3/5

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

  The description is compact and front-loads the method and path, which is good. But 'Partial update expense' and 'Endpoint for partially updating an existing expense' are redundant restatements of each other and of the tool name, so not every line earns its place. Could be trimmed to one tight sentence without losing information.

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

  Completeness2/5

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

  For a complex PATCH tool with a nested body and no output schema, the description is too thin. It doesn't explain partial-update semantics (which fields are affected, that omitted fields are left untouched), how to choose between this and wafeq_expenses_update, or what the response looks like. The rich schema and idempotency annotations cover a lot, but the missing usage and behavioral context leaves an agent to infer the most important operational detail.

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

  Parameters3/5

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

  The description adds no parameter information at all, so the schema carries the burden. Schema coverage is 67% at the top level: idempotency_key is excellently documented in the schema, the nested body properties are individually well described, but id has no description and the body's own description is the generic 'An entity that can have attachments,' which adds no meaning for an expense. The description neither compensates for these gaps nor reinforces the strong parts.

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

  Purpose4/5

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

  The description states a specific verb ('partially updating'), resource (Expenses), and the HTTP method/path (PATCH /expenses/{id}/), so an agent knows what operation this performs. However, it doesn't explicitly contrast with the sibling wafeq_expenses_update, and 'Endpoint for partially updating an existing expense' largely restates the title/name rather than adding differentiation.

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

  Usage Guidelines2/5

  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. The sibling set includes wafeq_expenses_update (full update), create, destroy, and mark_as_draft/posted, but the description never tells an agent to prefer partial update when only some fields need changing or to avoid it when a full replacement is intended. No prerequisites or exclusions are mentioned.

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

• wafeq_invoices_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description does not contradict them. The description adds minor context beyond annotations — the PUT method and that the target is an 'existing' invoice — but it does not disclose the key behavioral trait of a full PUT update: what happens to fields omitted from the required body, or why partial_update would be preferable.

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

  Conciseness3/5

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

  The description is short and front-loaded with a safety signal and HTTP method, which is good. However, it is redundant: 'Update invoice' and 'Endpoint for updating an existing invoice' say essentially the same thing, and '🟡 WRITE · updates data' repeats what readOnlyHint=false already conveys. Every line should earn its place, and two of the three lines are near-duplicates.

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

  Completeness2/5

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

  This is a complex write tool — a large nested body with multiple required fields, no output schema, and a sibling partial_update tool — yet the description provides almost no orienting context. It fails to explain full-replacement semantics, the expectation that the body contain all required invoice fields, or the difference from partial update. The rich schema and annotations do heavy lifting, but the description is inadequate for a tool of this complexity.

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

  Parameters3/5

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

  Schema coverage is 67%; the nested body fields are richly documented in the schema itself, and idempotency_key has a thorough description. The tool description adds no parameter-level meaning, but the poorly-covered parameters (id, body) are semantically self-evident from the endpoint and context. The body object's cryptic schema description 'Adds nested create feature' is a minor quality issue the tool description does nothing to fix.

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

  Purpose4/5

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

  The description states a specific verb and resource — 'updates data · Invoices · PUT /invoices/{id}/' and 'updating an existing invoice' — so an agent knows exactly what operation this performs. The HTTP method PUT signals full-update semantics and loosely separates it from create/destroy siblings, but it does not explicitly distinguish itself from wafeq_invoices_partial_update.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention that wafeq_invoices_partial_update exists for partial changes, nor does it state any conditions, prerequisites, or exclusions. An agent must infer use cases entirely from the tool name and sibling list.

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

• wafeq_manual_journals_listC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description redundantly repeats READ-ONLY and adds only the HTTP endpoint. It does not disclose pagination behavior, default page size, result ordering, or filter-combination semantics, so it adds modest context beyond annotations but no contradiction.

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

  Conciseness2/5

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

  The description states the same idea three times: the header line "🟢 READ-ONLY · Manual Journals · GET /manual-journals/", "List manual journals", and "Endpoint for retrieving a list of manual journals" are semantically redundant. A single sentence with the endpoint would have been tighter; the repetition wastes tokens without adding information.

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

  Completeness2/5

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

  For a list tool with 10 filter parameters and no output schema, the description is too thin. It does not explain what fields a manual journal record contains, how filters combine, what the default page size is, or what the response shape looks like. With no output schema to fill that gap, the description leaves an agent guessing about return values and pagination behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline of 3 applies. All 10 parameters (page, page_size, reference, date_after, date_before, external_id, and timestamp ranges) already have descriptions in the schema. The tool description adds zero parameter-level meaning, which is acceptable given full schema coverage.

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

  Purpose4/5

  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 manual journals" and "retrieving a list of manual journals," with the endpoint path GET /manual-journals/ adding precision. It is clearly a list operation, distinguishable from siblings like wafeq_manual_journals_retrieve by the plural resource scope, but it does not explicitly differentiate itself from related list tools such as wafeq_journal_line_items_list.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. There is no mention that wafeq_manual_journals_retrieve should be used for a single journal, that journal_line_items_list covers line-item details, or any conditions about filtering vs. pagination. The READ-ONLY marker implies safe usage but does not address selection criteria.

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

• wafeq_manual_journals_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already establish that this is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and not destructive (destructiveHint=false). The description's 'WRITE · updates data' is consistent with those annotations and adds the PUT endpoint, but it does not disclose extra behavioral details such as full-replacement semantics or side effects on nested line items.

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

  Conciseness2/5

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

  The first line usefully packs the write category, resource, and HTTP endpoint, but 'Update manual journal' and 'Endpoint for updating an existing manual journal' are redundant restatements of the same idea. The description is short but repetitive, so not every sentence earns its place.

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

  Completeness2/5

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

  For a tool with a large nested body and no output schema, the description only says it updates a manual journal. It does not explain whether unspecified fields are reset, how line_items should be provided, or what a successful update returns. The schema provides field-level detail, but the description leaves important invocation context missing.

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

  Parameters3/5

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

  The tool description adds no parameter-level meaning, but the schema documents the nested body fields, required date, line_items structure, and idempotency_key in good detail. With moderate schema coverage, the schema carries most of the burden, though the description does not compensate for the undocumented id parameter.

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

  Purpose4/5

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

  The description clearly identifies the operation as updating an existing manual journal and includes the HTTP method and endpoint, so an agent can tell this is the update tool for that resource. It does not explicitly contrast itself with wafeq_manual_journals_partial_update, so it stops short of full sibling differentiation.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus wafeq_manual_journals_partial_update, create, retrieve, or destroy. The phrase 'updating an existing manual journal' implies a general use case, but it does not explain when a full PUT update is appropriate or when partial_update should be chosen instead.

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

• wafeq_payments_destroyC
  2.9/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds that the record is permanently removed, which usefully signals irreversibility beyond a bare 'delete' label. However, it does not disclose any side effects, required permissions, or failure conditions, so the added behavioral context is limited.

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

  Conciseness2/5

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

  The first line is a compact, front-loaded summary, but 'Delete payment' and 'Endpoint for deleting an existing payment' restate the same idea. The only non-redundant addition is 'Permanently removes the record.' The redundancy makes the description less efficient than it should be.

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

  Completeness3/5

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

  For a simple two-parameter destroy endpoint, the description covers the core operation and permanence, and the idempotency_key comment in the schema covers retry behavior. It is missing any indication of success/response shape or preconditions (e.g., whether the payment must be in a deletable state). Overall it is adequate but not thorough for an agent invoking a destructive operation.

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

  Parameters3/5

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

  The input schema documents id only as a string, while idempotency_key receives a thorough explanation. The description's 'DELETE /payments/{id}/' line gives meaning to the id parameter as the path identifier for the payment, adding a little beyond the schema. With 50% schema coverage, the description partially compensates but id still lacks dedicated semantic detail.

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

  Purpose4/5

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

  Clearly identifies the operation as deleting a payment, with the resource and HTTP endpoint spelled out in the summary line. It is unambiguous against sibling payment tools like wafeq_payments_retrieve/update/partial_update, though it doesn't explicitly name them. The permanent-deletion wording reinforces the purpose.

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

  Usage Guidelines2/5

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

  Provides no explicit guidance on when to choose this over wafeq_payments_update or wafeq_payments_partial_update, and no exclusions. The phrase 'Permanently removes' implies it is for irreversible deletion, but that is inferred rather than stated as a rule. Since there is no 'use this when...' direction, an agent is left to assume the standard CRUD meaning.

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

• wafeq_payments_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the write-and-idempotent behavior is covered by structured metadata. The idempotency_key parameter description adds meaningful behavioral context about automatic UUID generation and safe retries, which is a genuine disclosure beyond annotations. The description does not contradict annotations — 'updates data' is consistent with readOnlyHint=false. No annotation contradiction found.

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

  Conciseness3/5

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

  The description is short: 'Update payment' plus a redundant top line '🟡 WRITE · updates data · Payments · PUT /payments/{id}/'. The zero-value meta line provides HTTP method and resource context, which is useful, but 'Update payment' and 'Endpoint for updating an existing payment' are nearly tautological repeats of the tool name/title. It is brief but takes three lines to say essentially the same thing twice. Some structure is present with the prefix, but the redundancy costs it a higher score.

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

  Completeness2/5

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

  The tool is highly complex: 3 parameters, one of which is a large nested body with many conditional fields (payment_fees_account required if payment_fees is set, employee required for payslip payments, etc.). With no output schema, the description carries responsibility for explaining what the update does and what a successful call returns. The description says only 'Update payment' and provides none of that context. The heavily annotated schema compensates somewhat, but the description itself is inadequate for an operation with this complexity.

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

  Parameters3/5

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

  The schema itself is rich and covers 67% of parameters with detailed descriptions (amount reconciliation rules, exchange rate semantics, list types). The tool description adds no parameter-level meaning beyond the schema. The `id` parameter (path identifier) has no description, and the body parameter's schema description is a DRF boilerplate string ('A ModelSerializer that takes additional arguments...') that adds little functional guidance. However, the nested payment lists and amount semantics are thoroughly documented in the schema itself, so the description does not need to repeat them. Baseline 3 applies given the high schema coverage.

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

  Purpose4/5

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

  The tool name `wafeq_payments_update` combined with the title 'Update payment' and description 'Update payment' clearly identifies this as updating an existing payment, which is a specific verb and resource. It also includes the HTTP method and endpoint (PUT /payments/{id}/) in the prefix line, which adds technical clarity. However, the core description is terse and does not differentiate it from siblings like `wafeq_payments_partial_update` beyond implying full update vs partial update — the distinction is left to the name.

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

  Usage Guidelines2/5

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

  The description states 'Endpoint for updating an existing payment' but gives no guidance on when to use this tool versus `wafeq_payments_partial_update` or `wafeq_payments_create`. There is no mention of the PUT vs PATCH distinction, whether the full body must be supplied, or that `wafeq_payments_partial_update` is for selective field updates. An agent cannot determine when to choose this tool over alternatives from the description alone.

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

• wafeq_payslips_pay_items_listC
  2.9/5.0
  Behavior2/5

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

  The description repeats the read-only nature already declared in annotations but adds no extra behavioral context such as pagination behavior, response structure, required permissions, or ordering. The HTTP GET and path are already implied by the tool name and schema, so no new operational insight is provided.

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

  Conciseness3/5

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

  The description is appropriately short and front-loaded with the read-only and endpoint context. However, the final two lines are largely redundant: 'List pay items' and 'Endpoint for retrieving a list of pay items' add little beyond each other, wasting space in a definition that should be information-dense.

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

  Completeness3/5

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

  For a simple read-only list endpoint with annotations covering safety, the description is minimally sufficient. However, with no output schema, it does not describe what fields a pay item contains or how pagination results are returned, leaving some ambiguity for an agent deciding whether this tool returns the needed data.

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

  Parameters3/5

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

  Page and page_size are already described in the schema, so the description does not need to restate them. It does add mild meaning by showing payslip_id as the parent resource in the path, but it does not explain payslip_id format or the relationship beyond what the schema and tool name convey.

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

  Purpose4/5

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

  The description clearly states a specific verb and resource: 'List pay items' and 'Endpoint for retrieving a list of pay items.' This distinguishes it from single-item retrieve operations, even though it does not explicitly name sibling tools. The path pattern reinforces that it targets the pay-items subresource of a payslip.

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

  Usage Guidelines2/5

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

  The description gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as wafeq_payslips_pay_items_retrieve for a single item. Usage must be inferred from the word 'list' and the URL structure, providing minimal directional help.

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

• wafeq_purchase_orders_listC
  2.9/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'READ-ONLY' label adds no new safety information. It also does not disclose behavioral details like pagination behavior, filtering semantics, or response format.

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

  Conciseness3/5

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

  The description is short and front-loaded with the read-only and endpoint metadata. However, 'List purchase orders' and 'Endpoint for retrieving a list of purchase orders' are redundant, and the saved space could have been used for more useful guidance.

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

  Completeness3/5

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

  For a read-only list operation with no required parameters, this is minimally viable. However, with 13 optional filters and many sibling list tools, the description does not clarify pagination, response shape, or when to prefer this tool over related purchase-order endpoints.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies: every parameter has some schema-level documentation. The description itself adds no parameter context, but the schema already carries the documentation burden.

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

  Purpose4/5

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

  The description states a clear action and resource: 'List purchase orders' with the endpoint 'GET /purchase-orders/'. It is unambiguous, but it does not explicitly distinguish itself from sibling tools like wafeq_purchase_orders_retrieve or wafeq_purchase_orders_line_items_list.

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

  Usage Guidelines2/5

  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 retrieving a single purchase order or listing line items. The intended usage is only implied by the word 'List' in the name and title.

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

• wafeq_quotes_listC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description only repeats 'READ-ONLY' and adds the HTTP method/path, which are essentially structured metadata. It discloses no additional behavioral traits such as pagination behavior, response shape, or open-world implications beyond what annotations already provide.

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

  Conciseness3/5

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

  The description is short and front-loaded with a badge and endpoint, but it contains redundancy: 'List quotes' and 'Endpoint for retrieving a list of quotes' say the same thing. The final sentence earns no additional value, so the structure is acceptable but not tight.

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

  Completeness3/5

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

  For a list endpoint with 13 optional parameters and no output schema, the description is minimally viable because annotations cover the safety profile and the schema covers parameters. However, it does not explain what the response contains, how pagination works, or how filters combine, leaving the agent to infer important invocation details.

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

  Parameters3/5

  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 even though the description itself adds no parameter details. The description does not explain any filters, and the schema descriptions must carry all meaning. Some schema descriptions are slightly inconsistent (e.g., referring to invoices in a quotes tool), but that is outside the tool description's scope.

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

  Purpose4/5

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

  The description states the verb 'List' and the resource 'quotes', and the endpoint path clarifies it is a collection operation. This distinguishes it from sibling quote tools like retrieve, create, update, and destroy. However, it largely restates the title and annotations without adding scope details, so it is clear but not exemplary.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives such as wafeq_quotes_retrieve or wafeq_quotes_create. The READ-ONLY badge and GET method imply a safe read operation, but the description does not explain whether this lists all quotes, how it relates to pagination, or when filters should be used. No alternatives or exclusions are mentioned.

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

• wafeq_quotes_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already establish write, non-destructive, idempotent behavior; the description adds the PUT method and /quotes/{id}/ path, which hints at full-replacement semantics. It does not disclose effects on line items/status or retry behavior beyond what the idempotency_key schema describes, but there is no contradiction with annotations.

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

  Conciseness2/5

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

  'updates data', 'Update quote', and 'Endpoint for updating an existing quote' all restate the same idea across four short lines. The structured prefix is fine, but the redundancy means each sentence does not earn its place.

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

  Completeness2/5

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

  This is a complex PUT operation with a nested body, required fields, status enums, and no output schema, yet the description provides no guidance on return values, validation, status transitions, or how it differs from partial_update. An agent can construct a payload from the schema but not understand the operational semantics.

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

  Parameters3/5

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

  The description's only parameter contribution is signaling that id belongs in the URL path. The input schema itself documents most fields, including the detailed idempotency_key behavior, so the description does not need to repeat them; however, the body property's description 'Adds nested create feature' is not useful and no clarification is provided.

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

  Purpose4/5

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

  The description clearly states the operation ('updates data', 'Update quote') and the resource ('Quotes', 'existing quote'), so an agent can tell this is the update operation for quotes. It does not differentiate from wafeq_quotes_partial_update or explain full-vs-partial semantics, which keeps it from a 5.

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

  Usage Guidelines2/5

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

  The description only says 'Endpoint for updating an existing quote,' which implies not-create/destroy but gives no explicit when-to-use or when-to-choose-partial_update. With several sibling quote tools, especially wafeq_quotes_partial_update, the absence of exclusion/alternative guidance is a clear gap.

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

• wafeq_simplified_invoices_line_items_updateC
  2.9/5.0
  Behavior3/5

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

  The annotations already declare this as a non-readonly, non-destructive, idempotent write operation, and the description's WRITE marker is consistent with that. The description adds no meaningful behavioral context beyond the annotations, such as what fields get overwritten, side effects on totals, or authorization requirements.

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

  Conciseness2/5

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

  The first line is dense and front-loaded with the route and operation category, but the following two sentences both restate the same idea: 'Update simplified invoice line item' and 'Endpoint for updating an existing simplified invoice line item.' This redundancy makes the definition less concise than it should be.

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

  Completeness2/5

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

  For a nested-body update operation with no output schema and a partial-update sibling, the definition should explain full replacement semantics, whether omitted body fields are reset, and what response the caller can expect. The description only restates the endpoint and leaves critical context for the agent to infer.

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

  Parameters3/5

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

  The route template usefully reveals that invoice_id and id are path parameters, but the description does not clarify how the body should be structured for a full update. The schema's nested body properties are reasonably self-documenting, yet the generic ModelSerializer text does not compensate for the 50% schema description coverage.

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

  Purpose4/5

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

  The description clearly states the verb ('Update') and resource ('simplified invoice line item'), so an agent can tell what operation is being exposed. However, it does not contrast itself with the sibling 'wafeq_simplified_invoices_line_items_partial_update', leaving the full-vs-partial update distinction implicit.

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

  Usage Guidelines2/5

  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 instead of the partial-update sibling, nor any explanation of PUT semantics vs PATCH. The only hint is the HTTP method in the route, which is not expanded into actionable usage direction.

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

• wafeq_simplified_invoices_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and idempotentHint=true, and the description adds the explicit PUT endpoint, which hints at full-replacement semantics. It does not, however, disclose that a PUT overwrites the existing invoice and requires all required body fields to be re-supplied — a key behavioral trait of this operation that the description leaves to inference.

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

  Conciseness3/5

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

  The description is short and front-loaded with the WRITE badge and endpoint path. The three clauses 'updates data', 'Update simplified invoice', and 'Endpoint for updating an existing simplified invoice' are near-duplicates, wasting a sentence's worth of space on repetition.

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

  Completeness2/5

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

  For a tool with a deeply nested body schema and no output schema, this description is a minimal stub that explains neither the PUT replacement semantics nor what the response looks like. The idempotency_key guidance lives only inside the schema, so crucial invocation details are left for the agent to discover on its own.

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

  Parameters3/5

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

  Schema description coverage is 67%, with useful per-field descriptions on most body properties (status, currency, place_of_supply, line_items) and a thorough explanation of idempotency_key. The description text itself adds zero parameter meaning, but at this coverage level the schema carries the weight, so baseline 3 applies; the unhelpful 'Adds nested create feature' body description is a minor detractor.

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

  Purpose4/5

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

  The description names the verb (update), resource (simplified invoice), and HTTP method (PUT /simplified-invoices/{id}/), so an agent can tell what this tool acts on. However, it does not explicitly contrast itself with the sibling wafeq_simplified_invoices_partial_update, leaving differentiation to be inferred from the PUT method rather than stated intent.

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

  Usage Guidelines2/5

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

  No conditions, prerequisites, or exclusions are stated in the description. With siblings like wafeq_simplified_invoices_partial_update, wafeq_simplified_invoices_create, and wafeq_invoices_update, an agent gets no cue about when to choose this tool over those, which is a meaningful gap.

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

• wafeq_bank_accounts_ledger_transactions_updateB
  3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description merely restates that this is a WRITE operation and gives the HTTP method, adding no meaningful behavioral context such as field replacement semantics, validation behavior, idempotency usage, or 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.

  Conciseness2/5

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

  The description is short but redundant: 'Update bank ledger transaction' and 'Endpoint for updating an existing bank ledger transaction' repeat nearly the same idea. The emoji prefix and repeated phrasing add noise without adding informative value.

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

  Completeness2/5

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

  This is a write operation with a nested body object, required path parameters, no output schema, and a large sibling set including a partial_update variant. The description is too thin to give an agent enough context about full vs partial update semantics, response expectations, or how to construct a valid request beyond what the schema provides.

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

  Parameters2/5

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

  Schema description coverage is about 50%, and the description itself says nothing about the parameters. The nested body fields are documented in the schema, but the required path parameters bank_account_id and id have no descriptions, and the description does not compensate for that gap.

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

  Purpose5/5

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

  The description identifies the specific operation ('Update'), the resource ('bank ledger transaction'), and the HTTP endpoint (PUT /bank-accounts/{bank_account_id}/ledger-transactions/{id}/). It clarifies the target is an existing transaction, making it distinguishable from create, retrieve, destroy, and partial_update siblings.

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

  Usage Guidelines3/5

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

  It provides basic context that this endpoint updates an existing bank ledger transaction. However, it does not explain when to choose this tool over the partial_update sibling, nor does it mention that PUT typically implies a full replacement rather than a partial update.

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

• wafeq_bank_accounts_statement_transactions_partial_updateB
  3/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds 'WRITE' and PATCH, which is marginal, but it does not disclose key partial-update behavior such as omitted fields remaining unchanged or side effects beyond what annotations already imply.

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

  Conciseness3/5

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

  The description is short and front-loaded with method and path, but 'Partial update bank statement transaction' and 'Endpoint for partially updating an existing bank statement transaction' are redundant restatements. It could be trimmed to a single non-repetitive sentence.

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

  Completeness2/5

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

  For a nested-resource write operation with no output schema, the description leaves out important context: that the body can contain only a subset of fields, that omitted fields are left unchanged, and how this differs from the full update sibling. Annotations and schema cover some aspects, but the description itself is insufficient.

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

  Parameters2/5

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

  Schema description coverage is 50% and the description adds no parameter-level meaning. While the body schema and idempotency_key have descriptions, the path parameters are undocumented and the description does not compensate for the gap or clarify how the body should be structured.

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

  Purpose4/5

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

  The description states a specific verb ('partially updating') and resource ('bank statement transaction'), and includes the HTTP method and URL path, making the operation clear. It does not explicitly differentiate from the sibling full-update tool, but 'partial update' and PATCH imply the distinction.

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

  Usage Guidelines3/5

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

  The phrase 'Partial update' and the PATCH method imply when to use this tool, but there is no explicit guidance about when to choose it over wafeq_bank_accounts_statement_transactions_update or any mention of alternatives. No exclusions or prerequisites are stated.

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

• wafeq_debit_notes_line_items_partial_updateB
  3/5.0
  Behavior3/5

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

  Annotations already declare this as a write operation (readOnlyHint=false), idempotent, and non-destructive. The description adds the PATCH method and 'partial update' semantics, which provide some behavior context beyond annotations, but it does not disclose side effects, permissions, or response behavior.

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

  Conciseness3/5

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

  The description is short but redundant, repeating 'partial update debit note line item' in both the second and third lines. The first line provides useful endpoint metadata, but the repeated statements could be collapsed into one sentence.

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

  Completeness2/5

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

  For a nested, partially updatable resource with no output schema, the description is too thin. It does not explain that body fields are optional, what a typical partial update body looks like, or what the response contains. An agent would need to infer most operational details from the schema and siblings.

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

  Parameters2/5

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

  The description adds no parameter-level meaning. Schema coverage is only 50%: id and debit_note_id lack descriptions, the body property's description appears irrelevant (referring to custom_fields computed values), and the description text does not explain how to structure the body or which fields are commonly updated. The idempotency_key is well-described in the schema, but the description fails to compensate for the gaps.

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

  Purpose4/5

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

  The description states a specific verb and resource: partially updating an existing debit note line item, and includes the HTTP method and path. It is clear about the operation, though it does not explicitly contrast with sibling tools like the full update variant.

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

  Usage Guidelines3/5

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

  The word 'partial' implies use when only a subset of fields needs updating, as opposed to a full update. However, the description does not explicitly state when to choose this over wafeq_debit_notes_line_items_update or other alternatives, leaving the guidance mostly implied.

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

• wafeq_manual_journals_partial_updateB
  3/5.0
  Behavior3/5

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

  Annotations already convey that this is a mutating, non-destructive, idempotent write operation. The description adds the 'partial update' semantics, which is useful, and the PATCH endpoint reinforces that only provided fields are updated. However, it does not add deeper behavioral context such as authentication requirements, validation behavior, or effects on existing line items.

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

  Conciseness3/5

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

  The description is short and front-loads the HTTP method and resource, but it is redundant: 'Partial update manual journal' and 'Endpoint for partially updating an existing manual journal' say essentially the same thing. The repetition makes it less efficient than it could be.

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

  Completeness2/5

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

  For a partial-update tool with a nested body schema and no output schema, the description is too thin. It does not explain that omitted fields remain unchanged, which fields are commonly updated, how idempotency works in practice, or anything about the response. An agent would have to infer most operational context from the schema and annotations.

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

  Parameters2/5

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

  Schema description coverage is only 67%, and the description itself says nothing about parameters. The schema does describe the body fields and idempotency_key well, but the required path parameter 'id' has no description and the tool description does not compensate for that gap.

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

  Purpose4/5

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

  The description clearly states the verb ('partially updating'), the resource ('manual journal'), and includes the HTTP endpoint 'PATCH /manual-journals/{id}/'. It is easy to tell this is the partial-update variant, though it does not explicitly contrast with the full update sibling wafeq_manual_journals_update.

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

  Usage Guidelines3/5

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

  The phrase 'Endpoint for partially updating an existing manual journal' implies when to use the tool, but it does not explicitly say when to prefer this over wafeq_manual_journals_update or wafeq_manual_journals_destroy. No exclusions or decision guidance is provided.

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

• wafeq_payslips_pay_items_updateB
  3/5.0
  Behavior3/5

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

  Annotations already declare this as a write (readOnlyHint=false) and idempotent. The description adds the HTTP PUT method and resource path, but does not disclose behavioral details such as whether the entire pay item is replaced or how missing resources are handled. No contradiction with annotations.

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

  Conciseness2/5

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

  The description is short but redundant: '🟡 WRITE · updates data', 'Update pay item', and 'Endpoint for updating an existing pay item' all say the same thing. It is front-loaded but contains unnecessary repetition.

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

  Completeness2/5

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

  With no output schema, the description should at least hint at the response or any side effects. More importantly, it does not clarify that this is a full replacement-style PUT update, which is essential given the existence of a sibling partial_update tool. This leaves selection and invocation partially ambiguous.

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

  Parameters4/5

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

  Schema coverage is 50%, but the inline URL pattern /payslips/{payslip_id}/pay-items/{id}/ gives semantic meaning to the otherwise undocumented path parameters. The schema already documents the body fields and idempotency_key, so the description adequately compensates for the coverage gap.

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

  Purpose4/5

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

  The description clearly identifies the operation as an update to a pay item within a payslip, reinforced by the URL pattern and the repeated phrase 'updating an existing pay item.' It does not, however, explicitly distinguish itself from the sibling partial_update tool.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this full update versus the sibling partial_update or when an update is appropriate. The statement 'updates data' adds no practical selection criteria.

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

• wafeq_projects_updateB
  3/5.0
  Behavior2/5

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

  Annotations already state readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description adds only 'WRITE / updates data / PUT', which largely repeats those cues. It does not disclose that PUT likely replaces the project or that omitted fields may be cleared, which is important given a partial_update sibling exists.

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

  Conciseness3/5

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

  The definition is short and front-loaded with the HTTP method and endpoint, which is good. But 'Update project' and 'Endpoint for updating an existing project.' are near-duplicates, and the emoji/prefix is mostly noise.

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

  Completeness2/5

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

  With no output schema and a sibling partial_update tool, the agent needs at least a statement of full-update semantics and when to choose it. The description gives only the bare endpoint and a generic update sentence, leaving the PUT/PATCH distinction and body construction requirements implicit.

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

  Parameters3/5

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

  The schema provides rich semantics for idempotency_key and descriptions for name and attachments, but not for id or body beyond 'An entity that can have attachments.' The tool description itself adds no parameter explanation, so it stays at the baseline for 67% schema description coverage.

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

  Purpose4/5

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

  The description identifies the action ('updates data'), the resource ('Projects'), and the exact endpoint ('PUT /projects/{id}/'), so the agent can determine the tool updates an existing project. It doesn't distinguish this full update from the sibling partial_update tool, but it names the resource and verb unambiguously.

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

  Usage Guidelines3/5

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

  The phrase 'updating an existing project' implies this is for modifying a project that already exists, which gives some usage context. However, it does not explicitly contrast with the sibling wafeq_projects_partial_update (or create/retrieve), so the agent gets no help choosing between full and partial update.

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

• wafeq_accounts_updateB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's '🟡 WRITE' plus PUT method are consistent with those. The only added context is the HTTP method and path, which imply full-replace semantics, but the description never discloses that omitted fields may be reset to defaults or that all required fields must be present — significant for a PUT operation. No contradiction with annotations.

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

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is dense and front-loaded, conveying method, resource, and path in one glance. However, 'Update account' and 'Endpoint for updating an existing account' are largely redundant with the tool name and title, meaning two of the three lines add little new information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a full PUT operating on a complex nested body with a partial_update sibling, the description leaves critical context out: full-update semantics, behavior of omitted body fields, and how this differs from wafeq_accounts_partial_update. Since no output schema exists, a brief note on what the endpoint returns would also have been valuable, but nothing is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description contributes zero parameter information; the schema does the heavy lifting, covering roughly 67% of parameters. Body fields like parent, name_en, account_code, and classification carry their own descriptions, and idempotency_key is well documented, while the self-evident id parameter has none. Since coverage is moderate rather than high, the description's silence is acceptable but not ideal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('updates data'), the resource ('Accounts'), and the endpoint (PUT /accounts/{id}/), and confirms it is for 'updating an existing account.' However, it does not explicitly distinguish itself from the sibling wafeq_accounts_partial_update — the PUT-versus-PATCH distinction is only implicit and never stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this full PUT update instead of wafeq_accounts_partial_update, wafeq_accounts_create, or other account tools. The phrase 'existing account' implies a prerequisite, but the description never mentions that all required body fields (account_code, classification, is_payment_enabled, name_en, sub_classification) must be supplied, which is the key behavioral difference from a partial update.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the HTTP endpoint 'GET /amortizations/' and a READ-ONLY label, which is mildly useful, but it does not disclose pagination behavior, response shape, or filter semantics beyond what the schema provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint path. However, it contains redundancy: 'List amortizations' is repeated in the following sentence 'Endpoint for retrieving a list of amortizations,' which prevents a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 9 optional parameters, no output schema, and only 33% schema coverage, a minimal two-line description is not enough. The agent lacks guidance on date filters, duration/recognition_type enums, pagination behavior, and what fields each returned amortization record contains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%: page, page_size, and status__in have descriptions, while duration, recognition_type, start_date_after, start_date_before, end_date_after, and end_date_before are undocumented. The tool description does not compensate by explaining any of these parameters, so an agent is left guessing about key filtering fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource: 'List amortizations' and 'Endpoint for retrieving a list of amortizations.' It is unambiguous about the operation, but it does not explicitly differentiate itself from sibling tools like wafeq_amortizations_retrieve or other amortization endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'retrieving a list of amortizations' implies this tool is for list-style, multi-record retrieval, which provides some usage context. However, it offers no explicit guidance about when to choose this over alternatives such as wafeq_amortizations_retrieve, or when to use filters like status__in or date ranges.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_listB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only '🟢 READ-ONLY' and the GET endpoint, which duplicate the annotation rather than adding new behavioral traits such as pagination behavior, filtering defaults, or required scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is a compact header, but the phrase 'List bank accounts' and 'Endpoint for retrieving a list of bank accounts' are redundant. This wastes one sentence and slightly reduces precision.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list endpoint with no required parameters and a fully documented input schema, the definition is adequate. However, with no output schema, it does not describe the response shape, sorting, or default page size, and it gives no hint about when not to use it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% description coverage for all 9 optional parameters, so the baseline is 3. The description does not mention any parameters, but it does not need to since the schema fully documents them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Uses the verb 'List' and a specific resource 'bank accounts', also includes the endpoint GET /bank-accounts/. This differentiates it from sibling tools that manage other resources or perform create/update/destroy operations, though it does not explicitly contrast with wafeq_accounts_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to choose this list endpoint over related tools such as wafeq_accounts_list or other bank-account operations. The description only states what the tool does, not when to use it or what it is not for.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_partial_updateB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds only the PATCH endpoint and 'updates data', which largely restates the annotations and title. It does not add context such as whether omitted fields are preserved, what happens on invalid input, 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The endpoint and WRITE label are front-loaded and informative. However, the two following sentences, 'Partial update bank account' and 'Endpoint for partially updating an existing bank account.', are redundant and could be condensed into one sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and annotations cover idempotency, non-destructive behavior, and the updatable fields, so the definition is minimally adequate. Still, there is no explanation of partial-update semantics (e.g., only provided fields are changed) and no output schema to clarify the return value.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the body subfields and idempotency_key with descriptions, so the description does not need to repeat them. The tool description itself adds no parameter semantics, and the required id parameter has no explicit description, but its meaning is clear from the endpoint and context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a write/PATCH operation on a bank account and includes the endpoint path. It distinguishes this from list/retrieve/destroy siblings, though it does not explicitly contrast it with the full-update sibling wafeq_bank_accounts_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for partially updating an existing bank account, but it provides no explicit when-to-use guidance or alternatives. It relies on the standard PATCH semantics and the 'partial' name rather than spelling out that this is the right choice when only a subset of fields needs changing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_retrieveB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered structurally; the description's READ-ONLY label merely restates readOnlyHint=true. It does add the HTTP method and endpoint path (GET /bank-accounts/{id}/), which is mildly useful context beyond the annotations. No contradiction exists between description and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the read-only marker, resource label, and endpoint on the first line. However, 'Retrieve bank account' and 'Endpoint for retrieving a single bank account' are redundant restatements of the same idea, so not every sentence earns its place. The title annotation repeats 'Retrieve bank account' as well.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only retrieve with five rich annotations, the description identifies the resource and endpoint adequately. However, with no output schema, the description does not hint at what the response contains, and with 0% schema coverage the id semantics remain thin. Adequate for a simple tool, but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% — the single id parameter has no schema description, so the description carries the burden. It only reveals that id is a URL path parameter via 'GET /bank-accounts/{id}/', adding minimal meaning. It does not compensate for the coverage gap: no indication of id format (numeric vs UUID), how to obtain it, or any constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource: 'Retrieve bank account' and 'Endpoint for retrieving a single bank account.' The qualifier 'single' distinguishes it from the list operation, though it never explicitly names sibling alternatives like wafeq_bank_accounts_list. Clear and specific, just lacking explicit sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied rather than stated — 'retrieving a single bank account' combined with the {id} path parameter signals this is a by-ID lookup, but there is no explicit guidance on when to use it versus wafeq_bank_accounts_list or its sibling retrieve operations. No alternatives are named and no when-not-to-use conditions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_updateB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as a write, idempotent, non-destructive operation. The description adds the HTTP method and path ('PUT /bank-accounts/{id}/') and the precondition that the account is existing. However, it does not explain whether the update fully replaces all fields, what side effects occur, or what response shape to expect, so it adds only modest behavioral context 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the method and resource. However, 'Update bank account' and 'Endpoint for updating an existing bank account' largely restate the first line and the annotation title, so not every sentence adds unique value. It is not overly verbose, but it is somewhat redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an update tool with a nested body and no output schema, the description provides the essential endpoint and target but does not clarify full-vs-partial update semantics relative to the sibling tool, nor does it describe the response. The schema and annotations carry most of the parameter and safety burden, making the description minimally viable but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool description adds no parameter-level detail, but the input schema documents the required body fields ('name', 'currency', 'sub_classification') with clear descriptions, and 'idempotency_key' is well explained. The main gap is the top-level 'id' parameter, whose meaning is left to inference, and the description does not compensate for that gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a concrete action ('updates data', 'updating an existing bank account') on a specific resource ('Bank Accounts') and includes the PUT endpoint. This makes the tool's function clear and separates it from list/retrieve/destroy siblings, though it does not explicitly distinguish it from the closely related partial_update tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives. In particular, the sibling wafeq_bank_accounts_partial_update is not mentioned, and the description does not clarify when a full update is required instead of a partial update. The only implied usage cue is that the bank account must already exist ('existing').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_retrieveB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with '🟢 READ-ONLY' and the GET method. It adds the useful scope that exactly one bill is returned, but does not disclose additional behavioral details such as auth requirements, error behavior, or response contents.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The endpoint and READ-ONLY marker are front-loaded and useful, but 'Retrieve bill' and 'Endpoint for retrieving a single bill' are redundant restatements of the same idea. It is compact, yet a single non-repetitive sentence would be cleaner.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity read with one required parameter and rich safety annotations, so the basics are covered. However, with no output schema, the description does not indicate what fields or structure the retrieved bill contains, nor what happens for invalid ids, leaving a modest but real gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema description coverage at 0%, the description carries the burden of explaining the id parameter, but it only echoes /bills/{id}/ and never states id's format, source, or whether it is the Wafeq bill UUID. The schema's 'id: string' plus the URL template is minimal and does not compensate for the missing parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('retrieving') and a specific resource ('a single bill') and includes the exact endpoint GET /bills/{id}/, so an agent can tell this is the detail fetch for one bill rather than a list operation. It does not explicitly differentiate from wafeq_bills_list or wafeq_bills_line_items_retrieve, but the 'single bill' wording and path do most of the work.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Endpoint for retrieving a single bill' implies the tool should be used when the agent has a bill id and needs that one bill's details. It gives no explicit when-not-to-use guidance or pointer to alternatives such as wafeq_bills_list for finding bills, so the usage guidance remains 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.

• wafeq_credit_notes_line_items_updateB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description repeats the write nature already encoded in readOnlyHint=false and adds the HTTP method, but it does not disclose full-update semantics, required authorization, or effects on omitted fields. Annotations already cover idempotency and non-destructiveness, so the description contributes no behavioral context beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is short and front-loads the HTTP method and resource, but 'Update credit note line item' and 'Endpoint for updating an existing credit note line item' are redundant. The last sentence adds no information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and annotations provide most of the needed detail (required body fields, idempotency, read/write profile), so the tool is callable. However, the description never explains that PUT implies a full replacement and never points to partial_update for partial edits, leaving an important selection gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The endpoint path clarifies that credit_note_id is the parent credit note and id is the line item, which helps map the two undocumented string parameters. The body and idempotency_key semantics are handled by their schema descriptions, so with ~50% coverage the description only partially compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the exact operation ('Update credit note line item') and the resource with its endpoint path (PUT /credit-notes/{credit_note_id}/line-items/{id}/), making it distinct from sibling line-item tools for invoices, bills, quotes, and debit notes. The only weakness is it doesn't contrast with partial_update, but that is a usage-guidance concern, not purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to choose this update over wafeq_credit_notes_line_items_partial_update or the create/retrieve/destroy siblings. The 'Endpoint for updating...' sentence simply restates the action without adding selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal extra context: the HTTP method/path (GET /credit-notes/) and the redundant '🟢 READ-ONLY' label. It does not disclose pagination behavior, filtering semantics, or response shape, but with strong annotations the bar is lower and the endpoint detail earns a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, but 'List credit notes' and 'Endpoint for retrieving a list of credit notes' are redundant restatements of the same idea. A single crisp sentence would have been equally clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 12-parameter list tool with comprehensive schema coverage and safety annotations, the description is adequate but thin. There's no output schema, so a note on return shape or pagination defaults would help, and nothing clarifies that all filters are optional. The openWorldHint also suggests unlisted capabilities that the description doesn't acknowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 12 parameters is already documented in the input schema. The description adds zero parameter-level 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource pair ('List credit notes') and confirms it with the collection endpoint 'GET /credit-notes/'. The plural resource and 'list' verb clearly distinguish it from siblings like wafeq_credit_notes_retrieve, though it doesn't explicitly name them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to choose this tool over alternatives. The description merely states what the endpoint does ('Endpoint for retrieving a list of credit notes') without explaining scenarios, exclusions, or how it differs from retrieve/create/destroy siblings. Nothing is left to inference except the generic meaning of 'list'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_custom_fields_listB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description merely restates 'READ-ONLY' and 'GET', adding no new behavioral context such as pagination behavior, default page size, ordering, or response structure. It does not contradict the annotations, but it also does not go beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the endpoint, but 'List custom fields' and 'Endpoint for retrieving a list of custom fields' are redundant. It could be reduced to a single sentence without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list endpoint with optional pagination, the description plus annotations are minimally sufficient. However, the lack of an output schema means the description could have usefully described the response shape or pagination behavior, which it does not.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both page and page_size have clear descriptions in the input schema. The tool description adds no parameter-specific 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('List') and resource ('custom fields'), and includes the collection endpoint GET /custom-fields/, which makes the basic purpose clear. It does not explicitly contrast with the sibling custom_fields_retrieve tool, but the collection endpoint and list verb make the listing intent recognizable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description only implies usage: if you need a list of custom fields, call this endpoint. There is no explicit guidance on when to choose list over retrieve, when pagination is appropriate, or how this relates to other custom_fields_* siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_line_items_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds the HTTP method (GET) and endpoint path, reinforcing that this is a nested read operation, and the READ-ONLY badge matches the annotations. It does not add pagination-behavior or response-format details, but it also does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The header line is well front-loaded and information-dense ("🟢 READ-ONLY · Debit Note Line Items · GET /debit-notes/{debit_note_id}/line-items/"). However, "List debit note line items" and "Endpoint for retrieving a list of debit note line items" are redundant — one could be dropped without losing any information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter read-only list endpoint with rich annotations, the schema and annotations cover most operational needs. The description adds the endpoint signature but omits when to prefer this over `wafeq_debit_notes_line_items_retrieve`, and with no output schema it offers no hint about the response shape beyond the implied list of line items. Adequate, but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67%: page and page_size are already documented in the input schema. The description adds modest value by showing `{debit_note_id}` as a path segment, implying it is the parent-document identifier rather than a query filter. It does not explain any additional meaning for page/page_size beyond the schema, so value added is limited.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 debit note line items" and "Endpoint for retrieving a list of debit note line items," with a concrete endpoint path `GET /debit-notes/{debit_note_id}/line-items/`. The resource (debit note line items) is clearly identified against the many sibling line-item listings, but the description never explicitly contrasts it with any sibling (e.g., credit_notes_line_items_list or the debit-note line-items retrieve tool), 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.

  Usage Guidelines2/5

  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. It does not mention the single-item sibling `wafeq_debit_notes_line_items_retrieve`, the create/update/destroy siblings, or other document types' line-item list endpoints, nor any conditions or exclusions. The only implied context is that a `debit_note_id` is required.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_employees_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the endpoint path and a read-only marker, but nothing about pagination behavior, filtering semantics, default page size, or response payload. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but it repeats itself: 'List employees' and 'Endpoint for retrieving a list of employees' say essentially the same thing. The first metadata line also partly duplicates the tool name and annotations, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only list with strong annotations and a rich parameter schema, the description is mostly adequate, but it leaves gaps: no mention of how pagination/filters are intended to be used, no default behavior, and no explanation of the return shape (there is no output schema). It is usable but not complete enough to score higher.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is high (86%), with page, page_size, created_ts_*, and modified_ts_* already documented in the schema. The description itself does not mention any parameters, so it adds no meaning beyond the schema; the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the action ('List employees', 'retrieving a list of employees') and the resource (employees), and includes the HTTP path 'GET /employees/'. It clearly identifies a collection/list operation, though it does not explicitly contrast with the sibling retrieve tool, so differentiation is only implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to choose this tool instead of wafeq_employees_retrieve or the employee write/update/delete tools. It provides no prerequisites, conditions, exclusions, or alternatives; the only context is a restatement of the list purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method and path ('GET /expenses/') and labels the operation READ-ONLY, but it does not disclose pagination defaults, result ordering, or response shape beyond the generic notion of a list.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY label and endpoint path. However, 'List expenses' and 'Endpoint for retrieving a list of expenses' are redundant, so a sentence does not earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list endpoint with 15 optional filters and no output schema, the description is minimal but not misleading. It communicates the core operation, while filter semantics are covered by the schema. It lacks useful operational context such as pagination defaults or whether any parameters are commonly required in practice.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds no value beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List expenses') and the resource ('GET /expenses/'), so an agent can identify this as a read-only collection endpoint. It does not explicitly differentiate from wafeq_expenses_retrieve, but the tool name and 'list' wording make the distinction reasonably clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus wafeq_expenses_retrieve, wafeq_expenses_create, or other expense endpoints. It also does not mention that this is the appropriate tool for filtering by branch, status, account, contact, project, or date ranges, leaving usage context to be inferred from the parameter names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_files_retrieveB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description repeats READ-ONLY and GET but adds no additional behavioral context such as response format, authentication needs, or side effects. No contradiction exists, so it is acceptable but not enriching.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY marker and endpoint, but 'Retrieve file' and 'Endpoint for retrieving a single file' are redundant restatements. It is concise but contains some repetition that prevents a higher score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter read-only tool with strong annotations, so a minimal description can be sufficient. However, without an output schema or any description of the response or id source, the description leaves minor gaps that an agent would need to infer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain what the 'id' parameter represents beyond showing it in the URL path. It fails to compensate for the schema gap by not stating that the ID identifies the file or where an agent might obtain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Retrieve file') and resource ('Files · GET /files/{id}/'), and says it retrieves a single file, which distinguishes it from list/upload/destroy siblings. It does not explicitly name a sibling to differentiate from, but the single-file 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving one file by ID, but it does not explicitly say when to use it over wafeq_files_list or wafeq_upload_file. There is no when-not guidance or named alternative, 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.

• wafeq_invoices_line_items_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already establish that this is read-only, idempotent, and non-destructive. The description adds the HTTP method and endpoint path, but offers no additional behavioral detail such as pagination behavior, error cases, or response format. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but it is redundant: 'List invoice line items' and 'Endpoint for retrieving a list of invoice line items' say essentially the same thing. The endpoint path is useful, but the repeated sentence adds no value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with supportive annotations and pagination parameters in the schema, the description is mostly sufficient. However, there is no output schema and the description does not mention what fields the returned line items contain or how pagination behaves, leaving some uncertainty for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents page and page_size, and the endpoint path makes it clear that invoice_id refers to the parent invoice. The description does not add detail beyond that, but with 67% schema coverage, the combination is adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly uses 'List' as the verb and identifies the resource as 'invoice line items' with the exact endpoint. It is unambiguous, though it relies on the resource name rather than explicitly distinguishing it from sibling line-item list tools for bills, purchase orders, quotes, etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternative line-item list tools such as wafeq_bills_line_items_list or wafeq_purchase_orders_line_items_list. It simply states what the endpoint does without any context or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_listB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds no new behavioral information beyond repeating 'READ-ONLY' and 'List invoices.' It does not mention pagination behavior, filtering semantics, or any operational caveats.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but 'List invoices' and 'Endpoint for retrieving a list of invoices' are redundant restatements. It could be condensed to a single informative sentence without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list endpoint with no required parameters and fully documented filter parameters, the description is minimally functional. However, with no output schema, it does not explain pagination details, return shape, or how to navigate multi-page results, and it offers no differentiation within the large sibling group.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all 12 parameters already documented in the input schema. The description itself adds no parameter-level meaning, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'List invoices' and identifies the endpoint 'GET /invoices/', naming both the verb and resource. This clearly distinguishes the tool from invoice retrieve/update/create/destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as wafeq_invoices_retrieve, wafeq_invoices_line_items_list, or wafeq_simplified_invoices_list. There are no context cues, exclusions, or selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_item_units_of_measure_partial_updateB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's '🟡 WRITE · updates data' badge is consistent with them — no contradiction. The idempotency behavior is meaningfully disclosed in the schema's idempotency_key parameter description (auto-generated UUID prevents duplicate operations on retry). The description text itself adds little beyond the PATCH verb, which is already implied by 'partial update,' so a baseline 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The badge line is well front-loaded with the key facts (WRITE, updates data, resource, HTTP method, path). However, the following two lines — 'Partial update item unit of measure' and 'Endpoint for partially updating an existing item unit of measure' — restate the same information, making roughly two-thirds of the description redundant. Short but padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter partial update with no output schema, the description plus annotations and schema cover the mutation semantics and field meanings adequately. However, it fails to explain when partial update is preferable to the full-update sibling in the same resource family, and with no output schema the response format is left unspecified. These are real but moderate gaps for agent tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, and the schema does the heavy lifting: all body sub-fields (item, is_base, conversion_factor, etc.) have meaningful descriptions, and idempotency_key is thoroughly explained. The description text adds no parameter-level meaning. The 'id' parameter is undocumented in both schema and description, and the 'body' schema description is a generic DRF serializer note rather than practical guidance, but the description's silence is acceptable given the schema's overall coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Endpoint for partially updating an existing item unit of measure,' and reinforces it with the HTTP method and path 'PATCH /item-units-of-measure/{id}/'. The 'partial' qualifier distinguishes it from the sibling full-update tool wafeq_item_units_of_measure_update. It loses a point only because the same fact is stated three times (badge line, title line, final sentence), which adds noise but not clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 its alternatives. The description never states when partial update is preferred over the full update sibling wafeq_item_units_of_measure_update, nor does it mention prerequisites (e.g., the item unit of measure must already exist, or which fields are safe to omit). An agent must infer usage purely from the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payment_requests_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description redundantly repeats 'READ-ONLY' with the green emoji and adds the GET endpoint context. No deeper behavioral detail such as pagination defaults or result shape is disclosed, but the annotations lower the bar.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  At three lines, the description is brief, but 'List payment requests' and 'Endpoint for retrieving a list of payment requests' are redundant restatements of the same idea. The emoji and endpoint prefix are efficient front-loaded context. One sentence could carry the same information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only filtered-list operation with full schema coverage and strong annotations, the description is nearly sufficient. It omits any note on pagination semantics or when to prefer retrieve over list. No output schema exists, so return-value expectations are left entirely to the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 12 parameters are documented in the schema itself. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 applies per the coverage rule.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'List payment requests' and 'Endpoint for retrieving a list of payment requests.' The HTTP method GET and the 'Payment Requests' resource marker make the operation unambiguous. It doesn't explicitly contrast with sibling retrieval tools, but the list-vs-single semantics are strongly implied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus wafeq_payment_requests_retrieve for a single record, or versus the create/update/destroy siblings. The agent must infer selection from the name alone. There are no exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payment_requests_retrieveB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered and the description does not contradict it. The description adds only minor behavioral context (the GET method and path template). It doesn't disclose behavior for nonexistent IDs, authentication requirements, or rate limits, but with strong annotations the bar is lower and no contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, which is good. But 'Retrieve payment request' and 'Endpoint for retrieving a single payment request' restate nearly the same idea, and the former duplicates the annotation title. One line is redundant and could be cut without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only tool with strong annotations, the description is mostly adequate for invocation. The notable gap is that no output schema exists and the description never hints at what the response contains (a full payment request object), leaving the agent without a return-shape expectation or any error-case awareness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the bare schema. It partially does: the endpoint template /payment_requests/{id}/ clarifies that the required 'id' is the path-level resource identifier. However, it doesn't explain the id's expected format, how to obtain a valid id (e.g., from a list call), or behavior for an invalid/unknown id.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (Retrieve), resource (payment request), and singular scope ('a single payment request'), reinforced by the endpoint template GET /payment_requests/{id}/. The word 'single' and the {id} path implicitly distinguish it from wafeq_payment_requests_list and the create/update/destroy siblings, though it never explicitly names or contrasts them, which keeps it just below a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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: it doesn't say to use the list endpoint for multiple payment requests, to use this after finding an id in a list, or to use update/destroy for mutations. The description is purely declarative labeling with no when/when-not context, so an agent must infer all usage decisions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_destroyB
  3.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry destructiveHint=true and readOnlyHint=false, and the description adds value on top by flagging '🔴 DESTRUCTIVE' and emphasizing 'Permanently removes the record,' which communicates irreversibility beyond the structured hint. The idempotency_key schema text also transparently covers retry-safety behavior. No contradiction with annotations was found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The front-loaded '🔴 DESTRUCTIVE · deletes · Payslips' marker and endpoint are effective, but the description then repeats the same idea three times: 'Delete payslip,' 'Endpoint for deleting an existing payslip,' and the header line. Only 'Permanently removes the record' carries new information after the first line.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an irreversible destructive operation with no output schema, the description omits expected response behavior (e.g., 204 vs. deleted object), consequences for related data (relevant given openWorldHint=true and the existence of payslip pay-items siblings), and safe id-acquisition guidance. The core facts are present, but consequential details that an agent needs before invoking an irreversible delete are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%: idempotency_key is richly documented in the schema, but the required id parameter has no description. The description's endpoint path 'DELETE /payslips/{id}/' obliquely clarifies that id is the payslip identifier, but it adds no format, source, or example for id and nothing further about idempotency_key beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deleting') and resource ('payslip') and reinforces it with the endpoint path 'DELETE /payslips/{id}/' and 'Permanently removes the record.' This clearly distinguishes the destroy action from the create/retrieve/update/partial_update payslip siblings, though it never explicitly names a sibling to differentiate from.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no when-to-use guidance, no mention of prerequisites (e.g., fetching the record first to confirm its id), and no explicit routing away from alternatives. 'Permanently removes the record' serves as a caution, but the description leaves the agent to infer all usage context from the tool name, which is already self-evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_line_items_listB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the description's '🟢 READ-ONLY' merely restates that. It does add the exact HTTP method and resource path (GET /purchase-orders/{purchase_order_id}/line-items/), which is mildly useful, but it discloses nothing about pagination behavior or response shape. No contradiction with 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The header line is compact and front-loaded with the READ-ONLY signal and endpoint. But the final two sentences are redundant: 'List purchase order line items' and 'Endpoint for retrieving a list of purchase order line items' say the same thing, and the annotation title already repeats it as well.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter list tool with rich annotations, this is nearly adequate: it names the endpoint, the parent resource, and the pagination parameters are visible in the schema. However, with no output schema it never describes what fields each line item contains, and there is no note on pagination semantics or any ordering/filtering behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67% — page and page_size already have descriptions, and the description adds nothing about them. However, the endpoint path clarifies that the undocumented required purchase_order_id parameter is the parent purchase order's identifier, partially compensating for that schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource ('List purchase order line items') and gives the exact endpoint path, making the scope unambiguous. The word 'list' inherently distinguishes it from the singleton retrieve/create/update/destroy siblings for the same resource, though it never names them explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no guidance on when to choose this tool over the many sibling line-item tools (wafeq_purchase_orders_line_items_retrieve, _create, _update, _destroy, _partial_update, plus equivalent lists for bills, invoices, and quotes). There is no when-to-use, when-not-to-use, or alternative routing — the agent must infer selection from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_revenue_recognitions_retrieveB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description reinforces this with a READ-ONLY badge and the GET method, but adds no further behavioral context such as authentication needs, response shape, or any side-effect caveats. Value beyond annotations is modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, which is good. However, 'Retrieve revenue recognition' appears in the title, in the description sentence, and is essentially restated by the final sentence, adding redundancy without much new information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, safe, one-parameter retrieve operation, the description is mostly usable: it conveys the endpoint, the single id requirement, and the read-only nature. It lacks any explanation of what a revenue recognition is, how to source the id, or what to expect in the response, which is more noticeable 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.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description needed to compensate by explaining the id parameter. It only shows the id in the path and does not clarify its format, origin, or how to obtain a valid revenue recognition id, leaving the agent to infer from the parameter name alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action and resource: 'Retrieve revenue recognition' and 'Endpoint for retrieving a single revenue recognition.' It is distinguishable from sibling operations like list or destroy by emphasizing 'single' and the GET path, though it does not explicitly differentiate itself from other *_retrieve tools beyond the resource name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: this is the retrieve-by-id tool for revenue recognitions, as opposed to list/destroy/update siblings. However, there is no explicit guidance on when to choose this over alternatives, no mention of prerequisites, and no indication of where the id comes from.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_units_of_measure_updateB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish that this is not read-only, not destructive, and idempotent. The description adds the PUT method and says it updates an existing record, which is mildly useful, but it does not disclose full-replace semantics, required-field handling, or any side effects beyond the annotation-implied mutation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, but it repeats the same idea three times: 'WRITE · updates data', 'Update unit of measure', and 'Endpoint for updating an existing unit of measure'. It would be tighter with a single clear sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Annotations and schema cover idempotency, safety, and field meaning, so the tool is minimally callable. Still, there is no output schema and no explanation of the difference between this full update and the partial_update sibling, leaving some contextual ambiguity for an agent choosing among similar update tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides descriptions for name, name_ar, is_active, and idempotency_key, so the description does not need to restate them. However, the description adds no parameter-level meaning, and the required 'id' parameter lacks a schema description; the endpoint template partially compensates by showing it as a path parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Update unit of measure' and 'Endpoint for updating an existing unit of measure', with the resource and HTTP method explicit. It is unambiguous about the verb and resource, though it does not explicitly contrast with the sibling wafeq_units_of_measure_partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as partial_update, create, or destroy. 'Updating an existing unit of measure' implies a use case, but there are no explicit conditions, prerequisites, or sibling comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_retrieveB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds the GET endpoint and singles out one resource, but provides no additional context such as error responses, auth requirements, or return payload behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the read-only badge and endpoint. The only flaw is redundancy: 'Retrieve amortization' and 'Endpoint for retrieving a single amortization' restate the same idea.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter retrieve-by-ID tool with rich annotations, the core invocation is clear. However, without an output schema the description does not explain what the response contains, and it gives no context for how to obtain a valid id.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. The path 'GET /amortizations/{id}/' and the phrase 'single amortization' imply that id is the amortization identifier, but the description never explicitly explains id format, source, or validation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb and resource: 'Retrieve amortization' and 'Endpoint for retrieving a single amortization'. It also says 'single', which distinguishes it from wafeq_amortizations_list, though it does not explicitly name the sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to call this instead of related amortization tools. It does not mention that this is the detail-lookup counterpart to the list endpoint, nor does it explain prerequisites such as obtaining an id from the list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_destroyB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation layer already marks the operation as destructive, so the description does not carry the full burden. It adds the meaningful trait that the record is permanently removed, but it does not describe side effects, permissions, or response behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The destructive warning and endpoint are front-loaded, but the text repeats 'delete bank account' three times across the tag line, title, and body. It is short, yet the redundancy means not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-resource delete, the essential operation and permanence are clear, and annotations cover the destructive/idempotent profile. However, with no output schema, the description does not explain expected response behavior or error conditions, leaving a moderate completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50%, and the only parameter described in the schema is idempotency_key; `id` has no description. The description does not compensate for this, aside from implying `id` is the bank account identifier via the endpoint path, which is insufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with an explicit action-resource pair ('deletes · Bank Accounts') and an exact endpoint, then states the operation is permanent. This clearly identifies the tool as the bank-account deletion operation and distinguishes it from bank account retrieve/update/partial_update siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The description only restates that the endpoint deletes an existing bank account, leaving the agent to infer that it is appropriate when permanent removal is intended.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_branches_destroyB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the irreversibility context 'Permanently removes the record.' It does not disclose auth requirements, effects on associated records, or failure behavior, but the core destructive trait is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but redundant: 'Delete branch' and 'Endpoint for deleting an existing branch' convey the same idea, and the banner repeats the destructive hint. It is front-loaded but several sentences do not add distinct information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destroy operation the description states the core outcome and the schema plus annotations cover idempotency and destructive behavior. However, with no output schema, it does not describe the expected response/status, nor whether deletion is conditional on the branch existing or being unused.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With only 50% schema description coverage, the endpoint line 'DELETE /branches/{id}/' clarifies that 'id' is the branch identifier, while the idempotency_key parameter's semantics are fully documented in the schema. The description adds just enough meaning beyond the schema, though it could explicitly name the required id parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action ('deletes'), resource ('Branches'), and HTTP route 'DELETE /branches/{id}/', and adds 'Permanently removes the record.' This clearly separates it from sibling branch tools like wafeq_branches_retrieve or wafeq_branches_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells what the tool does ('Delete branch') but gives no guidance on when to choose it over alternatives, no prerequisites, and no caution about related data. Usage must be inferred entirely from the action and destructive annotation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_line_items_updateB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description notes it is a WRITE operation and provides the HTTP method, giving clear mutation intent. Annotations already indicate idempotentHint=true and destructiveHint=false, so the description need not repeat those. However, it does not disclose whether omitted fields are reset or how the API handles conflicts, but for a simple update this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the WRITE action and endpoint. The repeated 'Update debit note line item' line is somewhat redundant with the title, but it does not harm clarity or brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a nested-object mutation with no output schema, the description is brief but adequate. It lacks information about response format, error conditions, or required relationships, but the schema supplies required fields and the annotations cover idempotency and destructive behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50%, and the description adds no parameter explanation beyond what the schema provides. The nested body fields have individual descriptions, but the path parameters (id and debit_note_id) are undocumented. The description does not compensate for that gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Update debit note line item' and includes the endpoint path, so the action and resource are unambiguous. The title and schema align. It does not explicitly differentiate from sibling update tools, but the resource name is specific enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives like 'partial_update' or 'destroy'. There is no mention of prerequisites, such as needing the debit_note_id and line item id, or when a full update is preferable to a partial update.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_destroyB
  3.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces and adds value by stating the record is 'Permanently removes the record' and exposing the exact DELETE endpoint. This informs the agent that the operation is irreversible, which is meaningful behavioral context beyond the structured annotation flag.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is repetitive: 'deletes · Expenses', 'Delete expense', 'Endpoint for deleting an existing expense', and 'Permanently removes the record' all say essentially the same thing. A single well-structured sentence would be more effective and less noisy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive endpoint, the description covers the core facts: what is deleted, the HTTP method/path, and permanence. However, it lacks explicit usage caution, does not mention response/status behavior, and does not discuss any side effects or prerequisites, so it is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 50% because the 'id' property has no description, while 'idempotency_key' is fully documented. The description partially compensates by showing 'id' in the URL path /expenses/{id}/, making it clear that id identifies the expense to delete, but it does not explain id format or where to obtain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise action and resource: 'deletes · Expenses · DELETE /expenses/{id}/' and clarifies the effect with 'Permanently removes the record.' This is clear and easily distinguishable from sibling operations like retrieve, update, or partial_update, though it does not explicitly name those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 wafeq_expenses_update or wafeq_expenses_partial_update. The destructive intent is implied by 'deletes' and the red warning, but the description never explicitly says 'only use when permanent deletion is intended' or cautions against accidental use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_files_destroyB
  3.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds 'Permanently removes the record', which goes beyond the destructiveHint=true annotation by disclosing irreversibility — valuable for an agent deciding whether deletion is safe. The 🔴 DESTRUCTIVE marker and delete wording are consistent with readOnlyHint=false, idempotentHint=true, and destructiveHint=true; no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four statements where three restate the same fact — 'deletes · Files', 'Delete file', and 'Endpoint for deleting an existing file' — and the emoji/uppercase warning duplicates the destructiveHint annotation. The genuinely informative content (endpoint path, permanence) is front-loaded, but the repetition wastes tokens and should be collapsed to one or two lines.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool (2 params, no output schema, rich annotations) the core is covered: what it deletes, that it is permanent, and idempotency behavior in the schema. Gaps remain: no mention of where the id comes from (files_list/upload siblings), no consequences of deleting a referenced file, and no error/response behavior given the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is exactly 50%; the idempotency_key parameter is thoroughly documented in-schema (header name, UUID v4 auto-generation, retry safety), while the required id parameter has no schema description. The tool description does not explain id, though 'DELETE /files/{id}/' in the opening line offers a minimal hint that id is the file path identifier. Neutral baseline with partial compensation from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource: 'deletes · Files', 'Delete file', 'Endpoint for deleting an existing file', and gives the HTTP method/path 'DELETE /files/{id}/', which makes the target concrete and distinguishes it from files_list, files_retrieve, and upload_file siblings. Not a 5 because the same idea is repeated three-plus times and 'Permanently removes the record' slightly blurs whether the file blob or just the database record is removed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to choose this over alternatives, no prerequisites (e.g., obtaining the id from wafeq_files_list or a prior upload), and no exclusions such as files still referenced by invoices. The only usage signal is the implied 'use this to delete a file' carried by the purpose statement itself.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_retrieveB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description is fully consistent with these, adding only the HTTP method and endpoint path (GET /invoices/{id}/) while largely repeating the READ-ONLY flag. It adds no context about response contents, 404 behavior, or permissions, but for a trivial read with strong annotation coverage the bar is lower. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Short and front-loaded with the READ-ONLY badge, resource, and endpoint. However, 'Retrieve invoice' and 'Endpoint for retrieving a single invoice' are redundant restatements of the same fact, so one of the two sentences is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with rich annotations, the description is nearly sufficient for correct invocation (pass the invoice id). Gaps remain: no mention of what the response contains (and there is no output schema), error behavior, or how standard invoices relate to simplified invoices in this large toolset. These are modest for a trivial retrieve but still leave the agent without a full picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It partially does: the endpoint 'GET /invoices/{id}/' clarifies that id is the invoice identifier used as a path parameter. For a single self-evident parameter this is sufficient, but the description adds no meaning beyond what the tool name and endpoint already imply.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the specific operation ('Retrieve invoice', 'retrieving a single invoice') with the resource and endpoint. The word 'single' distinguishes it from wafeq_invoices_list, and the resource naming separates it from retrieve tools for other resources (bills, quotes, credit notes, expenses). However, it does not clarify the distinction from wafeq_simplified_invoices_retrieve, and it largely restates the tool name and annotation title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no guidance on when to choose this tool over alternatives. With a huge sibling set including wafeq_invoices_list (when you need multiple/filtered invoices), wafeq_invoices_download_retrieve (when you need the PDF), and wafeq_simplified_invoices_retrieve (simplified vs standard invoices), the description offers no routing conditions or exclusions. The only usage signal is the name itself.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_item_units_of_measure_listB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description mostly repeats this with 'READ-ONLY' and adds no new behavioral facts such as default pagination, maximum page size, ordering, or filtering behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and the READ-ONLY/endpoint line is front-loaded, but it is repetitive: 'List item unit of measures' and 'Endpoint for retrieving a list of item unit of measures' convey the same information twice. Every line does not earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list endpoint with two optional pagination parameters, the annotations plus schema are sufficient to invoke it correctly. The only notable gap is not distinguishing this from the similarly named wafeq_units_of_measure_list, but that is not required for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both page and page_size already have clear descriptions. The tool description adds no parameter-level meaning, so the baseline of 3 is appropriate; the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'List item unit of measures' and identifies the exact endpoint GET /item-units-of-measure/. The list semantics separate it from the sibling create, retrieve, update, and destroy tools for the same resource, so an agent can tell them apart without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to select this list endpoint instead of alternatives such as wafeq_item_units_of_measure_retrieve or wafeq_units_of_measure_list. No exclusions, prerequisites, or use-case hints are provided beyond the implied 'if you need a list' reading of the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_listB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description includes '🟢 READ-ONLY'. This aligns with annotations. The description does not add details about pagination defaults, filtering behavior, or result ordering beyond what the schema parameters imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the read-only status and endpoint. However, it is slightly redundant: 'List payslips' is repeated verbally and in the title/annotation, and 'Endpoint for retrieving a list of payslips' restates the same idea.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint with 11 optional filter parameters and full schema coverage, the description provides the basic purpose and safety profile. It does not mention pagination behavior, default page size, or whether filters can be combined, which would help an agent use it correctly. No output schema exists, so the returned shape is not documented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter already has a description. The tool description itself does not explain how the filter parameters interact (e.g., whether branch, project, and employee are combinable or exclusive), which could add value but is not required given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource ('List payslips', 'Endpoint for retrieving a list of payslips') and includes the GET path. It does not explicitly differentiate from sibling tools like wafeq_payslips_retrieve or wafeq_payslips_pay_items_list, but the verb 'list' distinguishes it as the collection endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as wafeq_payslips_retrieve or wafeq_payslips_pay_items_list. The description only states what it does, not when it should be chosen.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_pay_items_createB
  3.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds practical value beyond the annotations by explaining that calling twice creates two records and that an idempotency_key (or server-generated UUID) makes retries safe. This is consistent with idempotentHint=false and readOnlyHint=false, so there is no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the write indicator and endpoint, but 'Create pay item' and 'Endpoint for creating a new pay item' are redundant. The idempotency sentence is useful and placed at the end.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with a nested body and no output schema, the description does not mention required body fields, payslip prerequisites, or what the response will be. The idempotency guidance is helpful, but the overall context is thin.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, and the schema already documents body fields and idempotency_key in detail. The description adds little beyond naming idempotency_key for safe retries; payslip_id remains directly undocumented, though the endpoint path provides some context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create pay item' and provides the explicit endpoint POST /payslips/{payslip_id}/pay-items/, making the operation specific and concrete. It is clearly the create operation among the sibling pay-item tools, though it does not explicitly contrast itself with them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to prefer this tool over list/retrieve/update/destroy, nor any preconditions such as the payslip having to exist. The idempotency note is useful for retry behavior but does not help with tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_pay_items_retrieveB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false. The description's 'READ-ONLY' and 'GET' merely restate those flags and adds no further behavioral context such as return format, error cases, 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the route and read-only marker, but 'Retrieve pay item' and 'Endpoint for retrieving a single pay item' are redundant. It could be tightened to a single informative phrase.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieve with two string parameters, the core operation is conveyed. However, without an output schema, parameter semantics, or guidance on locating pay item IDs, the description feels minimally adequate rather than complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not fill that gap. The path shows payslip_id and id as identifiers, but it does not explain their exact meaning, relationship, format, or how the agent should discover valid values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Retrieve pay item' and 'Endpoint for retrieving a single pay item.' The exact path GET /payslips/{payslip_id}/pay-items/{id}/ plus 'single' distinguishes it from the list/create/update/destroy pay-item siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: an agent can infer it should call this when retrieving one pay item by payslip_id and id. However, it does not explicitly say when to prefer this over wafeq_payslips_pay_items_list, nor mention any exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_projects_retrieveB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already specify readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the GET method and single-object scope but no additional behavioral context such as response shape, errors, or prerequisites, so it provides modest value beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the endpoint, but 'Retrieve project' and 'Endpoint for retrieving a single project' are redundant. The third line adds only a repeated statement, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only retrieve endpoint, the existing annotation set and endpoint description are nearly sufficient for an agent to invoke it correctly. It lacks response or error details, but the tool name and resource path communicate the expected return reasonably well.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the id parameter. It partially does by showing id in the URL /projects/{id}/, which identifies it as the project identifier, but it does not explain the id format or where to obtain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific operation: retrieving a single project via a GET endpoint. The word 'single' distinguishes it from wafeq_projects_list, and the resource name separates it from create/update/destroy siblings, though no alternative is named explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus wafeq_projects_list or other retrieve tools. The intended use is only implied by the endpoint and the word 'single', with no exclusions or alternative routing provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_listB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description adds essentially no behavioral context beyond repeating 'READ-ONLY' and 'GET'. It does not disclose pagination behavior, filtering semantics, or any other runtime traits beyond what annotations and schema already provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a useful READ-ONLY badge and endpoint path, but it contains redundancy: 'List simplified invoices' and 'Endpoint for retrieving a list of simplified invoices.' say the same thing, so the last sentence does not earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 11 optional filter parameters, no output schema, and close siblings such as wafeq_simplified_invoices_retrieve and wafeq_invoices_list, the description is too thin. It does not mention that the endpoint supports filtering by branch, contact, project, dates, or timestamps, nor does it distinguish listing from retrieval.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and all 11 parameters already have individual descriptions. The tool description adds no extra parameter meaning, which matches the baseline of 3 when the schema carries the documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the exact operation ('List simplified invoices') and resource, and the endpoint path 'GET /simplified-invoices/' reinforces the scope. The 'Simplified Invoices' qualifier clearly separates it from the sibling wafeq_invoices_list, so an agent can tell what resource is being acted on.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool to use when a list of simplified invoices is needed, but it gives no explicit when-to-use/when-not-to-use guidance. It does not mention alternatives such as wafeq_simplified_invoices_retrieve for a single invoice or wafeq_invoices_list for regular invoices, leaving the agent to infer from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_units_of_measure_listB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description merely repeats 'READ-ONLY' and adds the HTTP method/path, but it does not disclose any new behavioral traits such as pagination behavior, response characteristics, auth requirements, or ordering defaults.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and puts the resource and path up front, but 'List unit of measures' and 'Endpoint for retrieving a list of unit of measures' are near-duplicates. The emoji/label line also repeats the read-only annotation, adding mild redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint with no output schema, the description gives enough context: it names the resource, the operation, and the path, while the input schema fully documents pagination parameters and annotations cover the safety profile. It could additionally clarify the difference from wafeq_item_units_of_measure_list, but that is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both page and page_size already have clear descriptions, and both are optional. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('List', 'retrieving a list') and the resource ('unit of measures'), and also gives the HTTP path GET /units-of-measure/. It is not a tautology and distinguishes list from retrieve semantics, though it does not explicitly contrast with the similarly named wafeq_item_units_of_measure_list sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies it should be used to fetch the collection of unit-of-measure records, but it gives no explicit when-to-use guidance, no exclusions, and no comparison to related siblings such as wafeq_units_of_measure_retrieve or wafeq_item_units_of_measure_list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_accounts_destroyB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds 'Permanently removes the record,' reinforcing irreversibility, but it does not mention cascading effects, dependency failures, or what happens to linked records. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but contains repetition: 'Delete account' appears in the annotation title and body, and 'Endpoint for deleting an existing account' restates 'deletes Accounts.' It is not bloated, but not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Core facts—destructive, permanent, requires account id—are present, and annotations cover idempotency and destructiveness. However, there is no output schema and no mention of response behavior, error cases, or restrictions on deletion. Adequate for a simple delete tool, but with notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents idempotency_key, while the required id parameter has no schema description. The path template /accounts/{id}/ and the phrase 'existing account' clarify that id identifies the account to delete, but the description does not explain id format or how to obtain valid values. It partially compensates for the 50% schema coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation is to delete an account, using the verb 'deletes' and the resource 'Accounts', and adds 'Permanently removes the record.' This is specific and unambiguous, and it distinguishes the tool from account retrieve/update/list siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool instead of update, partial_update, or other account operations. The destructive marker and name make the intent obvious, but there are no stated conditions, preconditions, or explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_destroyB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds the meaningful context that the record is 'permanently removed.' It also labels the operation as destructive up front, reinforcing the irreversible nature beyond what the annotation alone conveys.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats 'Delete bill' or its equivalent multiple times: 'DESTRUCTIVE · deletes · Bills,' the title, and 'Endpoint for deleting an existing bill.' It is short but redundant; a single concise sentence would be more effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The essential facts are present: the action is destructive, permanent, and targets a specific bill, with idempotency protection covered in the schema. However, it does not explain whether deletion is allowed in all bill states, what happens to associated line items, or when not to use this operation, leaving moderate gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents idempotency_key well, but the required 'id' parameter has no description. The tool description adds no parameter-specific meaning, so 50% of the parameters remain semantically under-specified and the agent must infer that 'id' is the bill identifier from the endpoint path.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: deleting a bill via DELETE /bills/{id}/, and explicitly notes that the record is permanently removed. This distinguishes it from sibling retrieve, update, and partial_update operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by saying it deletes a bill, but it offers no guidance on when to choose this tool versus alternatives, no prerequisites, and no warnings about deleted bills with related data. An agent must infer the appropriate usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_cost_centers_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the key safety profile: readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds the PATCH method and 'existing cost center' context, but does not disclose additional behavioral details such as whether omitted fields remain unchanged or what happens if the cost center does not exist. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the method and resource, but it is somewhat redundant: 'Partial update cost center' and 'Endpoint for partially updating an existing cost center' repeat the same information. It is not bloated enough to be a serious problem, but the redundancy keeps it from being tightly structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a straightforward partial-update CRUD tool with moderately descriptive schema fields and helpful annotations. The description is minimally sufficient for invoking the tool, but it lacks usage guidance, prerequisites, and any statement about response behavior. Given no output schema, a bit more context about what happens after the update would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description itself adds no parameter-level detail, but the input schema provides decent coverage: body fields have descriptions, and idempotency_key has a thorough explanation. The 'id' parameter has no description beyond its type, and the description does not clarify it as the path identifier, but the endpoint path already signals this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('updates data'), the resource ('Cost Centers'), the HTTP method (PATCH), and the specific scope ('partially updating an existing cost center'). This distinguishes it from sibling tools like wafeq_cost_centers_update, wafeq_cost_centers_retrieve, and wafeq_cost_centers_destroy without needing to open their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to choose this tool over alternatives such as wafeq_cost_centers_update. The word 'partial' implies use when only a subset of fields needs updating, but the description offers no clear context, exclusions, or conditions, leaving the agent to infer usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_line_items_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide the write nature (readOnlyHint=false), non-destructive hint, open-world hint, and idempotency hint. The description adds the HTTP verb and 'partial update' semantics, but does not disclose any additional behavior such as field-level merge behavior, validation effects, or 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the same information three times: the first line, the standalone sentence 'Partial update credit note line item', and the following 'Endpoint for partially updating an existing credit note line item.' The useful path information is present but the redundancy wastes space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and only moderate schema description coverage, the description should clarify the response behavior, the partial-update semantics, and any important side effects. It does none of these. The reader is left to infer what the API returns and what happens to unspecified fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The endpoint path adds meaning by showing that credit_note_id and id are path parameters. The nested body properties are individually described in the schema. However, the description itself adds no parameter-level guidance, and the body description in the schema is oddly phrased about augmenting custom_fields rather than explaining the partial-update payload.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('partial update'), the resource ('credit note line item'), and the exact HTTP method and path (PATCH /credit-notes/{credit_note_id}/line-items/{id}/). This distinguishes it from the sibling full-update and retrieve tools based on the 'partial' qualifier and resource naming.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is only implied by the phrase 'partially updating an existing credit note line item.' The description does not explicitly explain when to prefer this over the sibling wafeq_credit_notes_line_items_update, nor does it state that only provided fields are affected while omitted fields are left unchanged.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_retrieveB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description only adds the endpoint path and a READ-ONLY label, with no extra context about return shape, not-found behavior, or authentication. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY label and endpoint, which is good. However, 'Retrieve credit note' and 'Endpoint for retrieving a single credit note' are redundant, so the structure includes unnecessary repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple single-parameter read tool, and the description is adequate for basic invocation. But with no output schema, it does not state what the returned credit note contains, nor any expected response or error behavior, leaving some uncertainty for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only an `id` string with no description. The endpoint path `{id}` adds minimal semantic context by showing it is a path parameter identifying a single credit note, but it does not explain the expected format or meaning beyond that. With 0% schema coverage, the description only partially compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('Retrieve credit note') and the resource ('credit note'), and reinforces it with the endpoint GET /credit-notes/{id}/. It distinguishes from list-style siblings by saying 'single credit note', though it does not explicitly differentiate from other credit-note-related retrieve tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this when a specific credit note needs to be retrieved by ID. However, it gives no explicit guidance on when to prefer this over list, create, update, destroy, or line-item retrieve tools, so an agent must infer the context from the name and endpoint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_custom_fields_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's '🟡 WRITE · updates data' is consistent with them — no contradiction. The description adds modest context beyond annotations: the PATCH method and endpoint path. It does not discuss partial-update semantics (omitted fields remain unchanged) or side effects, but with annotations covering the safety profile, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The most useful line ('🟡 WRITE · updates data · Custom Fields · PATCH /custom-fields/{id}/') is front-loaded with method and path, but the next two lines — 'Partial update custom field' and 'Endpoint for partially updating an existing custom field' — are near-duplicates of each other and essentially restate the first line. The redundancy wastes space that could hold behavioral guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a complex nested discriminated-union schema, the definition is passable: annotations establish safety and idempotency, the schema explains every parameter (including per-field_type metadata structure), and the description gives method and endpoint. The gaps are the absence of an output schema or any description of the response, and no statement of partial-update semantics (e.g., omitted fields are left untouched). An agent could call it correctly, but not with full confidence about consequences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline of 3 applies. The schema fully documents id, body, and idempotency_key, including a detailed explanation of the X-Wafeq-Idempotency-Key header, auto-generated UUID v4, and retry-safety behavior. The description itself contributes nothing about parameters, which is fine because the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('partially updating') and resource ('an existing custom field'), and adds the HTTP method and endpoint path (PATCH /custom-fields/{id}/) which anchors the operation precisely. It is clear what the tool does, and the word 'partial' implicitly separates it from the full-update sibling wafeq_custom_fields_update, though it never explicitly names or contrasts a sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'partial update' framing implies the use case — modify a subset of fields on an existing custom field rather than create, retrieve, or fully replace it. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of alternatives like wafeq_custom_fields_update, and no exclusions (e.g., whether field_type can be changed after creation).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_createB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds concrete behavioral context beyond the annotations: it states that the operation is not idempotent and that calling twice creates two records, and it offers the mitigation of passing idempotency_key or letting the server generate one. This complements the idempotentHint=false annotation with real-world consequences and a remedy. It doesn't cover auth requirements or rate limits, but for a create endpoint against a schema-documented API, the non-idempotency disclosure is the key risk vector and it's handled well.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The tag line "🟡 WRITE · creates data · Expenses · POST /expenses/" is compact and front-loaded, and the idempotency sentence is genuinely useful. However, "Create expense" followed immediately by "Endpoint for creating a new expense" is redundant phrasing that wastes a line. The structure is serviceable but not tight.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description doesn't hint at what the endpoint returns (e.g., the created expense object), leaving the agent to guess the response shape. The nested body parameter with 15 properties is fully covered by the schema, and the non-idempotency behavior is well disclosed, so the core calling mechanics are adequate. Missing return-value context and entity-reference semantics (whether account/contact/project values are IDs) are the notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline of 3 applies. The description's mention of idempotency_key aligns with and echoes the schema's own detailed parameter description (X-Wafeq-Idempotency-Key header, auto-generated UUID v4), adding nothing semantically new. The body parameter's nested fields are fully documented in the schema, so the description doesn't need to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation: "Create expense" / "Endpoint for creating a new expense," with a specific verb (create), resource (expense), and HTTP endpoint (POST /expenses/). The leading "WRITE · creates data" tag also distinguishes it from read-only siblings like wafeq_expenses_list and wafeq_expenses_retrieve. It stops short of a 5 because it never explicitly names sibling alternatives or differentiates from the related mark_as_draft/posted operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description contains no guidance on when to select this tool over alternatives such as wafeq_expenses_update, wafeq_expenses_partial_update, or wafeq_expenses_mark_as_posted_create. The only usage advice given is about retry safety with idempotency_key, which is operational guidance rather than tool-selection guidance. There are no exclusions, prerequisites, or conditions stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_destroyB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly warns with '🔴 DESTRUCTIVE' and states 'Permanently removes the record,' adding irreversibility context beyond the destructiveHint annotation. It does not disclose side effects such as cascading deletion or authorization requirements, but the annotation already covers the destructive flag, so the added context is meaningful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The text repeats the same idea several times: 'DESTRUCTIVE · deletes · Invoices', 'Delete invoice', 'Endpoint for deleting an existing invoice', and 'Permanently removes the record'. It is short, but the redundancy wastes space and the structure is choppy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The combination of annotations, schema, and description covers the core destructive behavior and the idempotency semantics. However, it leaves gaps such as what the required `id` refers to, whether deletion can be undone, and what response or related records are affected; for a destructive endpoint this is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter documentation comes from the schema's detailed idempotency_key description; `id` is left as a bare string. The description adds nothing about either parameter, so it fails to compensate for the undocumented required invoice id.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly that the tool deletes an invoice, gives the HTTP endpoint, and adds that the record is permanently removed. It clearly identifies the target resource (invoices) and the delete action, so an agent can distinguish it from retrieve/update invoice tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when deletion is appropriate, what prerequisites exist, or which alternative to use instead (e.g., update/partial_update rather than destroy). The text only restates the action and endpoint, leaving the agent to infer the usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_line_items_destroyB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly warns '🔴 DESTRUCTIVE' and states that the record is 'Permanently removed,' which adds meaningful behavioral context beyond the destructiveHint annotation. This makes the irreversibility of the operation clear, even though auth, rate limits, and side effects are not mentioned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The destructive warning and endpoint path are front-loaded, which helps an agent quickly recognize the nature of the operation. But 'Delete invoice line item' and 'Endpoint for deleting an existing invoice line item' are near-duplicates, making the description slightly padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive endpoint with only two required parameters, the description gives enough resource and path context to understand what will be deleted, and the annotations cover safety and idempotency. What is missing is usage guidance and any note about downstream effects, such as whether deleting a line item recalculates invoice totals.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The endpoint path clarifies that invoice_id identifies the parent invoice and id identifies the line item, which is useful because the schema gives only bare string types for these required parameters. However, the description does not add much beyond that path context, and the idempotency_key parameter is already well-covered by the schema description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and identifies the exact resource ('Invoice Line Items'), reinforced by the DELETE endpoint path. It is clear and unambiguous, though it does not explicitly differentiate itself from sibling line-item destroy tools and largely restates the tool title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 over alternatives such as update, partial_update, or other line-item destroy endpoints. Saying it is an 'Endpoint for deleting an existing invoice line item' restates the operation rather than providing decision criteria, preconditions, or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_items_listB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds the HTTP method and path, but discloses no additional behaviors such as pagination defaults, response shape, or filtering semantics beyond what the schema already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY label and endpoint. However, 'List items' and 'Endpoint for retrieving a list of items' are redundant, so not every line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list endpoint with rich annotations and fully described parameters, so the basic invocation context is present. Missing context includes what the response looks like, whether pagination is required, and how this endpoint relates to sibling item tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all seven parameters. The description adds no parameter-level information, but it does not need to since the schema already carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the verb ('List') and resource ('items'), and includes the endpoint path 'GET /items/'. It is unambiguous about what the tool does, though it does not explicitly contrast itself with wafeq_items_retrieve.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by 'List items' and 'Endpoint for retrieving a list of items'. There is no explicit guidance about when to use this over alternatives like wafeq_items_retrieve, nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_item_units_of_measure_retrieveB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds no contradictions—just reinforces READ-ONLY and provides the GET path. It does not add meaningful behavioral context like error cases or preconditions, but the annotations carry the safety profile well.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The endpoint header is compact and front-loaded, but the following two sentences ('Retrieve item unit of measure' and 'Endpoint for retrieving a single item unit of measure') restate the same operation. A single merged sentence would carry the same information with less redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only retrieve operation with rich annotations, the description together with the schema is largely sufficient. The endpoint, resource, and single-item scope give an agent enough to select and invoke it; only output-shape details are absent, which is acceptable given no output schema and the simple resource type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only provides a required id string with 0% description coverage. The endpoint template shows that id is a path identifier, which partially compensates, but the description does not explain where the id comes from, its format, or any constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: retrieving a single item unit of measure via GET /item-units-of-measure/{id}/. It is unambiguous for the retrieve operation, though it does not explicitly differentiate from the similarly named units_of_measure_retrieve sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'retrieving a single item unit of measure' implies this tool is for fetching one record by id, which gives some usage context. However, there is no explicit when-to-use or when-not-to-use guidance, and no reference to list/create/update alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_pay_items_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, destructive, and idempotency hints. The description adds the PATCH method and the 'existing pay item' precondition, but it does not disclose response behavior, error cases, or other side effects beyond what annotations state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the endpoint, but it repeats 'partial update pay item' twice and the 'WRITE · updates data' prefix duplicates the annotation. Some redundancy could be replaced with more useful guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a partial update with nested body fields, the description plus schema is adequate to invoke the tool: required IDs are visible in the path and body fields are documented. Missing context includes the response format and explicit statement that omitted body fields remain unchanged.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description contributes only the path template showing payslip_id and id as identifiers; the input schema carries the detailed meaning for body fields and idempotency_key. With 50% schema coverage, the description does not compensate for undocumented id and payslip_id beyond their self-explanatory names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a partial update operation on a Pay Item, reinforced by the PATCH endpoint path. It is distinguishable from full-update and create siblings through the word 'partial', though it does not explicitly name an alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this endpoint to partially update an existing pay item. There is no explicit guidance on when to prefer this over wafeq_payslips_pay_items_update or when not to use it, leaving the choice mostly to the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_line_items_createB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare idempotentHint=false, but the description goes further by stating the concrete consequence — "calling twice creates two records" — and the mitigation: pass idempotency_key or let the server generate one for safe retries. This is genuinely useful operational context beyond what the structured fields provide. The description is consistent with all annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false); no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear WRITE prefix and the endpoint, and the idempotency note is valuable. But it contains redundancy: "Create quote line item" and "Endpoint for creating a new quote line item" restate the same purpose, which the annotation title also repeats. It could be trimmed to the prefix line plus the idempotency sentence without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a write tool with a nested 10-property body and no output schema, the description covers the most critical non-obvious behavior (duplicate-record risk and retry safety) well. However, it omits the success response shape, prerequisites (e.g., the quote must exist), and error/validation behavior. It is adequate but leaves the agent to infer these from the schema and context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67%, and most body properties (description, quantity, unit_amount, tax_rate, discount, custom_fields, etc.) are already documented in the schema. The description adds marginal value: the endpoint path clarifies quote_id's role as a URL path parameter, and it re-emphasizes idempotency_key, though the schema's idempotency_key description is already thorough. Notably, the confusing body-level schema description ("Augment custom_fields in the output...") is a backend artifact that the tool description does nothing to correct.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource — "creating a new quote line item" — and pins it to the exact endpoint POST /quotes/{quote_id}/line-items/. It is unambiguous about what the tool does. However, it does not explicitly differentiate itself from the many sibling line-item create tools (invoices, bills, purchase_orders, credit_notes, debit_notes, simplified_invoices); the 'quotes' scope is carried by the tool name and endpoint path rather than by the description itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives. It never mentions the sibling update/partial_update/destroy/retrieve/list operations on quote line items, nor does it state prerequisites such as the parent quote needing to exist. The only contextual note is about idempotency and retry safety, which addresses invocation behavior, not tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_createB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds real value beyond the annotations. While idempotentHint=false declares non-idempotency, the description explains the actual consequence ('calling twice creates two records') and provides the mitigation strategy (pass idempotency_key or let the server generate one). The WRITE/creates data label aligns with readOnlyHint=false. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and scannable, but redundant: 'Create simplified invoice' and 'Endpoint for creating a new simplified invoice' both restate the information already in the first line's 'Simplified Invoices · POST /simplified-invoices/'. The valuable idempotency guidance is appropriately placed at the end.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with a complex nested body, the schema covers parameter details well. However, with no output schema, the description doesn't mention return behavior, and notable constraints like the UAE place_of_supply requirement are only documented in the schema. Adequate but with clear gaps for a high-complexity operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline of 3 applies. The description mentions idempotency_key and its retry-safety role, but this largely mirrors the schema's own detailed description of the parameter. No new meaning is added for the body fields, which the schema already documents thoroughly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Create simplified invoice' with the endpoint 'POST /simplified-invoices/'. The 'Simplified Invoices' resource naming differentiates it from sibling tools like wafeq_invoices_create and wafeq_quotes_create. However, it doesn't explicitly contrast with those alternatives, 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternative tool routing is provided. The idempotency note addresses how to invoke safely, not when to choose this tool over wafeq_invoices_create, wafeq_quotes_create, or other invoice-family tools. The agent is left to infer usage context from the resource name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_line_items_listB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description restates READ-ONLY while adding the HTTP method and path. However, it does not mention pagination behavior, default page size, ordering, or authentication requirements. Since the safety profile is covered by annotations, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is front-loaded with emoji, read-only status, and the endpoint path, which is good. However, the second and third lines are redundant, saying nearly the same thing in two different ways. The description is short but a single sentence would have been tighter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint, the description plus annotations and schema give the agent the core info: read-only nature, required invoice_id, and pagination parameters. There is no output schema and no statement about what fields are returned or how pagination behaves by default. This is minimally complete for invocation, with a few gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents page and page_size but not invoice_id, and the description adds no parameter explanations. The endpoint path 'simplified-invoices/{invoice_id}/line-items/' does make it clear that invoice_id is the required invoice identifier. With 67% schema coverage, the description contributes only marginal semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Simplified Invoice Line Items' and states the action 'List' and 'retrieving a list', clearly identifying the resource. The word 'simplified' distinguishes it from the regular invoices line items sibling. An agent can tell exactly what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to choose this over the many sibling line-items list endpoints, such as wafeq_invoices_line_items_list. The description only states the endpoint and resource, with no conditions, prerequisites, or exclusions. The agent is left to infer that this is for simplified invoices from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_line_items_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds only a generic 'WRITE / updates data' label and the PATCH method, without disclosing side effects, required permissions, or the nuance that only provided fields are changed. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is a good front-loaded summary, but the second and third lines repeat the same 'partial update' concept. Compact, yet slightly redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and annotations carry much of the context (field descriptions, idempotency, non-destructive write). Still, the description omits partial-update semantics (only supplied fields change), return-value expectations, and any guidance on valid field combinations, which matters for a nested-object PATCH endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The path template adds useful context that invoice_id and id are URL parameters, and the schema already describes the body fields and idempotency_key. However, the description does not explain how the body maps to a partial update, and coverage is only about 50%, so the description itself contributes limited parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names an exact verb ('partial update'), a specific resource ('simplified invoice line item'), and the HTTP method/path. 'Partial update' clearly separates it from the full-update and destroy siblings for the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description only restates that this endpoint partially updates an existing line item. It gives no explicit when-to-use guidance, no alternative recommendation (e.g., full update vs partial update), and no prerequisite such as requiring the invoice and line item to exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_units_of_measure_createB
  3.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the annotations: it explicitly says 'Not idempotent — calling twice creates two records' and explains how idempotency_key makes retries safe. This is consistent with the idempotentHint=false and readOnlyHint=false annotations, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The header is compact and informative, but the description repeats the same idea: 'Create unit of measure' and 'Endpoint for creating a new unit of measure' are redundant. It could be tighter without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the endpoint, creation behavior, and idempotency, but there is no output schema and no mention of what a successful response returns. It also does not clarify the relationship to wafeq_item_units_of_measure_create, which leaves an ambiguity an agent might need to resolve.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 body fields and idempotency_key in detail. The tool description's mention of idempotency_key adds little beyond what the schema already states, and no additional parameter-level meaning is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create unit of measure' with endpoint POST /units-of-measure/. It is clear about the action but does not explicitly differentiate this from the sibling wafeq_item_units_of_measure_create, which is also a 'create' tool for units of measure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as wafeq_item_units_of_measure_create or wafeq_units_of_measure_update. It only states that it creates a unit of measure, leaving the selection logic largely to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_warehouses_partial_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's WRITE/PATCH language is consistent with those. The description adds the endpoint and partial-update semantics but does not disclose additional behavioral details such as response shape, side effects, or field-level validation. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the resource and HTTP method, but it repeats the same idea: 'updates data,' 'Partial update warehouse,' and 'Endpoint for partially updating an existing warehouse' are near-duplicates. A single concise sentence would have been sufficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Together with the schema, the description provides the resource, method, required id, updatable body fields, and idempotency key behavior. However, it does not state the response format or whether an empty body is acceptable, leaving minor gaps for an agent trying to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description provides no parameter-level explanation, relying entirely on the schema. The schema itself documents most body fields and gives a detailed explanation of idempotency_key, so the gap is not severe, but the description adds no extra semantic value for the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource and action: 'Partial update warehouse' and 'Endpoint for partially updating an existing warehouse.' It also includes the HTTP method and path. It distinguishes from the full update by emphasizing 'partially,' though it does not explicitly name the sibling wafeq_warehouses_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'partial' wording and PATCH method imply this tool is for updating a subset of warehouse fields, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention the full-update wafeq_warehouses_update alternative or any conditions for choosing one over the other.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_accounts_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'READ-ONLY' label adds no new safety information. The description adds only the endpoint path and 'single account' semantics, with no mention of 404 behavior, authentication needs, or return shape. This is adequate for a simple retrieve operation but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint path, which is good. However, 'Retrieve account' and 'Endpoint for retrieving a single account' are redundant restatements of each other and the tool name, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter retrieve shape and the strong annotation coverage, the description is mostly complete. It identifies the HTTP verb, resource path, and single-account behavior. It lacks explicit guidance about when to use this versus list, but for a straightforward retrieval tool the core information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must clarify the id parameter. The endpoint path /accounts/{id}/ implies that id is the account identifier, but the description does not explicitly explain its meaning, format, or how to obtain it. It partially compensates for the schema gap but leaves some ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a single account and exposes the HTTP endpoint GET /accounts/{id}/, which distinguishes it from list/create/update/destroy variants. It could be more explicit about the distinction from sibling list tools, but 'single account' provides enough differentiation for a simple CRUD retrieve.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: this is the endpoint for retrieving one account by ID, while siblings like wafeq_accounts_list handle multiple accounts. However, the description does not explicitly state when to prefer this over alternatives, nor does it mention any prerequisites such as the account ID being a Wafeq account ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_beneficiaries_destroyB
  3.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds the crucial qualifier 'Permanently removes the record,' clarifying irreversibility. It also front-loads the 🔴 DESTRUCTIVE warning. However, it does not disclose whether related records are affected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the same facts multiple times: the destructive indicator line, 'Delete beneficiary', and 'Endpoint for deleting an existing beneficiary' all say essentially the same thing. Only 'Permanently removes the record' adds new information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destroy endpoint, the description covers the core behavior, permanence, and endpoint. Annotations provide idempotency and destructiveness signals, and the schema covers idempotency_key. Still, side effects, error/response behavior, and deletion restrictions are absent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides rich detail for idempotency_key, and the endpoint path clarifies that 'id' is the beneficiary identifier. But the description adds no further meaning about the id parameter itself, and with 50% schema coverage the undocumented id is only minimally explained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action and resource: 'deletes · Beneficiaries' and 'Delete beneficiary', reinforced by the explicit endpoint 'DELETE /beneficiaries/{id}/'. It unambiguously distinguishes this destroy operation from the many update/retrieve/list beneficiary sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to delete a beneficiary versus updating or retrieving one, nor any mention of prerequisites or alternatives. The description only states mechanics, not usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_beneficiaries_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with '🟢 READ-ONLY' and the GET method but adds no new behavioral context such as auth requirements, error behavior, or response shape. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, but it is redundant: 'Retrieve beneficiary' and 'Endpoint for retrieving a single beneficiary' repeat the same idea. One concise sentence would be sufficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read operation, the annotations and schema cover safety and the required id, making invocation fairly clear. However, there is no output schema and the description does not mention what the retrieved beneficiary object contains or how errors like not-found are reported, leaving response behavior to inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain the id parameter beyond placing it in the URL path. The only hint is that id identifies a single beneficiary, which is already implied by the parameter name, so it does not compensate for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation as 'Retrieve beneficiary' and 'Endpoint for retrieving a single beneficiary,' providing a specific verb, resource, and scope. The 'single' qualifier and the /beneficiaries/{id}/ path differentiate it from list-style siblings like wafeq_beneficiaries_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The wording 'single beneficiary' implies this tool is for fetching one record by ID rather than listing many, but it never explicitly names the alternative (list) or states when NOT to use this tool. No preconditions or selection guidance are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_line_items_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's '🟢 READ-ONLY' marker just repeats the annotation, and it only adds the transport detail (GET endpoint path). No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is short and front-loaded with the READ-ONLY marker and endpoint path, which is good. However, 'Retrieve bill line item' and 'Endpoint for retrieving a single bill line item' are near-duplicates that restate the same idea, wasting one of the three lines.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only retrieve with rich annotations and no nested objects, the description is largely sufficient: it conveys the operation, the endpoint, and the read-only nature. The main gap is the absence of any return-value description given there is no output schema, but this is minor for a conventional single-resource retrieve.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, and the URL template '/bills/{bill_id}/line-items/{id}/' does clarify the role of each parameter: bill_id scopes the parent bill and id identifies the specific line item. However, it does not explain ID formats, where to obtain them, or any constraints, leaving the agent partially informed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Retrieve bill line item') and includes the HTTP method plus endpoint path, so an agent can clearly tell this is the single-item GET operation. The word 'single' differentiates it from the list sibling, but no sibling is explicitly named, so differentiation relies on RESTful convention rather than direct statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied rather than stated: an agent can infer this tool is for fetching one bill line item when both bill_id and id are known, given the endpoint template. However, there is no explicit when-to-use guidance, no mention of how this differs from wafeq_bills_line_items_list, and no exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_branches_listB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, fully covering the safety profile. The description adds only the HTTP method/path and a redundant 'READ-ONLY' marker; it does not disclose pagination behavior (defaults, limits) or any filtering capability. With annotations carrying the burden, this is adequate but adds little beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is short and front-loaded with a compact summary line (🟢 READ-ONLY · Branches · GET /branches/). However, 'List branches' and 'Endpoint for retrieving a list of branches' restate the same idea, so two of the three sentences are redundant with each other and with the title annotation — not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 two optional parameters, no output schema, and full annotation coverage, little is missing. The only gap is behavioral detail such as default page size, result ordering, or response shape, which is minor at this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — both page and page_size have their own descriptions covering their meaning. The tool description adds nothing about either parameter, so the baseline 3 applies; description and schema are consistent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 branches', 'Endpoint for retrieving a list of branches') and pins the HTTP endpoint (GET /branches/), so an agent can identify it as the collection-read operation for branches. It does not explicitly contrast with the sibling wafeq_branches_retrieve tool, though the 'list vs retrieve' naming and the collection endpoint make the distinction inferable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance is provided — the description never says 'use this to fetch all branches' or contrasts it with wafeq_branches_retrieve for a single branch or wafeq_branches_create to add one. Usage is only implied by the tool name and the collection endpoint, which fits 'implied usage' but not explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_cost_centers_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method (GET) and endpoint path, which is mild extra context, but it discloses no additional behaviors such as auth requirements, error conditions, or response characteristics. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the useful READ-ONLY/HTTP-method header line, but it is redundant: 'Retrieve cost center' and 'Endpoint for retrieving a single cost center' say essentially the same thing. One of these sentences could be trimmed without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-retrieve tool with one required parameter and strong safety annotations, the description is nearly complete: it provides the endpoint, the read-only nature, and the single-item scope. It does not describe the return value shape, and there is no output schema to compensate, but the implied response (the cost center object) is predictable for this operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the burden for the single 'id' parameter. The path template GET /cost-centers/{id}/ usefully signals that id is a URL path parameter, which is a small addition beyond the bare schema. However, it does not define the id's format, source, or semantics beyond what the tool name already implies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('retrieve') and resource ('cost center') with a clear single-item scope ('retrieving a single cost center'), and the GET /cost-centers/{id}/ path reinforces this. It implicitly differentiates from sibling wafeq_cost_centers_list and wafeq_cost_centers_create, though it does not name alternatives explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied rather than stated: an agent can infer this tool is for fetching one cost center by ID when the ID is already known, versus listing all cost centers. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_destroyB
  3.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true, but the description adds explicit behavioral context by stating the operation 'Permanently removes the record' and labeling it with 🔴 DESTRUCTIVE. This makes the irreversibility clear beyond a generic 'delete'. No information in the description contradicts the annotations; the idempotentHint is consistent with the schema's idempotency_key explanation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is redundant: '🔴 DESTRUCTIVE · deletes · Credit Notes', 'Delete credit note', and 'Endpoint for deleting an existing credit note' all express nearly the same information. The core safety message is front-loaded, but repeated restatements waste tokens and add no new meaning, so the structure does not earn its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation, the description plus annotations cover the essential facts: it is destructive, permanent, and targets an existing credit note by id. However, it omits any mention of the response/return behavior (e.g., 204 or deleted object), possible 404 conditions, or downstream effects on linked records. These gaps are not fatal for invocation but leave the agent with incomplete expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents idempotency_key thoroughly but leaves `id` with only a type string. The description partially compensates by showing `/credit-notes/{id}/`, which implies `id` is the credit note identifier, but it never explicitly describes the `id` parameter or its required value. With 50% schema coverage, this is adequate but not strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('delete'), a specific resource ('credit note'), and the exact endpoint (DELETE /credit-notes/{id}/), so an agent can clearly identify what this tool does and distinguish it from credit note create/retrieve/update tools. The phrase 'Permanently removes the record' sharpens the intent and distinguishes it from soft-delete or draft-state operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given for when to choose this tool over alternatives, such as wafeq_credit_notes_update, wafeq_credit_notes_partial_update, or the list/retrieve operations. The description merely restates the purpose ('Endpoint for deleting an existing credit note') without explaining when destruction is appropriate, what prerequisites exist, or when a non-destructive alternative should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_line_items_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description confirms READ-ONLY/GET. It adds the endpoint path but no further behavioral detail such as response shape, error semantics, or authentication needs. For a simple retrieve with strong annotations this is acceptable but not additive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is a strong front-loaded summary of method, resource, and endpoint. However, 'Retrieve invoice line item' and 'Endpoint for retrieving a single invoice line item' are redundant restatements of the same idea, so one sentence does not earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two required path parameters and annotation coverage for safety and idempotence, no output schema is needed to describe return values. The endpoint path makes the required parameters self-explanatory. The main gap is the absence of usage guidance, but the description is otherwise sufficient for a basic read-only retrieve.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has only two string parameters with no descriptions (0% coverage). The endpoint line maps invoice_id to the invoice path segment and id to the line-item path segment, adding the hierarchy. It does not explain value formats, relationships to list operations, or where the IDs come from.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear READ-ONLY marker and the exact endpoint GET /invoices/{invoice_id}/line-items/{id}/, then states 'Retrieve invoice line item' and 'Endpoint for retrieving a single invoice line item.' This identifies the specific verb, resource, and parent-child relationship, distinguishing it from the many sibling line-item retrieve endpoints by specifying invoice line items.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no statement of when to choose this tool instead of, e.g., wafeq_invoices_line_items_list or wafeq_invoices_line_items_update. The description only defines what the endpoint does, not the context, prerequisites, or alternatives. An agent must infer usage from the name and HTTP method.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_items_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds the HTTP method and endpoint path but no additional behavioral context such as authentication needs, rate limits, or response shape. There is no contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but 'Retrieve item' and 'Endpoint for retrieving a single item' are nearly redundant. The content is compact yet does not fully make every sentence earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only endpoint, the description is mostly sufficient, especially with strong annotations. However, with no output schema, it does not describe what the returned item contains, nor does it reference the list operation for finding valid IDs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not elaborate on the 'id' parameter beyond the URL placeholder. An agent must infer that 'id' is the item identifier and how to source it, though the single-parameter schema keeps the ambiguity limited.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Retrieve item') and clarifies it is for retrieving a single item via GET /items/{id}/. This distinguishes it clearly from item list, create, update, and delete operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you need one item by its ID, but it does not explicitly mention when to use this instead of wafeq_items_list or how to obtain the ID. The usage is inferable from the endpoint and wording but not explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_partial_updateB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation with idempotent behavior and no destructive effect. The description adds the HTTP method PATCH and notes it updates data, which is consistent but not a substantial addition 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, front-loaded with the action and endpoint, and avoids unnecessary fluff. There is slight redundancy between 'Partial update purchase order' and 'Endpoint for partially updating an existing purchase order', but overall it is appropriately sized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and annotations carry most of the load for parameters, safety, and idempotency behavior. However, with no output schema and no explanation of return values or update semantics, the description is adequate but not fully complete for nuanced tool selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description itself does not explain parameters, but the schema covers 67% of parameters with detailed descriptions for body fields and idempotency_key. The id parameter is self-evident from the path, and body fields are well-documented in the schema, so the description adds little but is not required to compensate heavily.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as a partial update of an existing purchase order via PATCH. It is specific about the verb and resource, though it does not explicitly distinguish itself from sibling wafeq_purchase_orders_update beyond the word 'partial'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool should be used when partially updating an existing purchase order, but it does not explicitly explain when to prefer it over the full update tool or mention any exclusions. It gives clear context but no direct alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_retrieveB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'READ-ONLY' and GET wording adds no new behavioral information. It does not disclose permission requirements, error behavior, response shape, or any other context 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is short and front-loads the endpoint and read-only flag, but 'Retrieve purchase order' and 'Endpoint for retrieving a single purchase order' are redundant with each other and with the annotation title. It could be tightened to one sentence without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only fetch, the description plus annotations provide enough to select and call the tool correctly. It lacks explicit response or error expectations, but those are not critical for this simple GET-by-id operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only defines a required string 'id', and the description's endpoint path shows it is used as a path placeholder. This adds some context beyond the raw schema, but the description does not explain the id's format or confirm its meaning beyond what the resource name and schema imply.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource ('Retrieve purchase order') and explicitly narrows the scope to 'a single purchase order', with the endpoint path showing GET /purchase-orders/{id}/. This distinguishes it from list, update, and destroy siblings even without naming them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for fetching one purchase order by ID, but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives such as wafeq_purchase_orders_list. An agent must infer the intended use from 'single purchase order' and the {id} path placeholder.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_destroyB
  3.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent with both. It adds value beyond the annotations with 'Permanently removes the record,' which tells the agent the deletion is irreversible (not a soft delete) — a behavioral fact the annotations do not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The structured first line effectively front-loads the destructive warning, but the prose is redundant: 'Delete simplified invoice' and 'Endpoint for deleting an existing simplified invoice' restate the same fact, leaving only 'Permanently removes the record' as unique content. Three of the four lines could be collapsed into one.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a simple 2-parameter delete: it identifies the target resource, the endpoint, and permanence, while the annotations cover the safety and idempotency profile. It is silent on cascading effects (e.g., what happens to the invoice's line items) and on any preconditions or status restrictions for deletion, which matter for a destructive operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is exactly 50%. The idempotency_key parameter is already richly documented in the schema (header name, auto-generated UUID, retry safety), so the description adds nothing there. For the undocumented id parameter, the description offers only marginal help by showing it as the path variable in 'DELETE /simplified-invoices/{id}/'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('deletes', 'removes') and a specific resource ('simplified invoice'), and repeats it consistently across the label and prose. The resource scope also distinguishes it from sibling wafeq_invoices_destroy, which targets regular invoices.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is provided. The description never explains when this destroy tool should be selected over wafeq_simplified_invoices_update/partial_update, nor does it warn that deletion is irreversible as a usage caution — the 'DESTRUCTIVE' label and 'Permanently removes' read as behavior warnings, not selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_line_items_retrieveB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds a redundant '🟢 READ-ONLY' badge and the HTTP GET method, but discloses nothing beyond that, such as auth requirements or not-found behavior. This is acceptable given the annotations but adds only marginal behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the READ-ONLY badge and endpoint path, which is good. However, the final two lines are largely redundant: 'Retrieve simplified invoice line item' and 'Endpoint for retrieving a single simplified invoice line item' say essentially the same thing, so one sentence could be cut without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with only two required string parameters, rich safety annotations, and no output schema requirement, the description is nearly complete: it names the resource, the HTTP method, the endpoint pattern, and the safety profile. The only minor gap is the lack of explicit parameter guidance, which the URL template partially covers.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and neither parameter has a description, so the burden falls on the tool description. The URL template '/simplified-invoices/{invoice_id}/line-items/{id}/' conveys the roles of both parameters (which ID identifies the invoice, which identifies the line item), providing partial compensation. Still, it offers no format guidance or hints about where an agent would obtain these IDs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource pair: 'Retrieve simplified invoice line item' and clarifies scope with 'single', distinguishing it from the list variant. The endpoint path 'GET /simplified-invoices/{invoice_id}/line-items/{id}/' also anchors the resource hierarchy. However, it never explicitly differentiates from wafeq_invoices_line_items_retrieve, so an agent could still confuse the simplified vs. standard invoice families without relying on the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied, not stated: the READ-ONLY label and 'retrieve a single ... line item' signal a safe read operation, and the name indicates it targets simplified invoices. But there is no explicit guidance about when to prefer this over the sibling list tool (wafeq_simplified_invoices_line_items_list) or over the standard invoices line item retrieve tool, which are its closest alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_tax_rates_listB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method and endpoint path but no additional behavioral context such as pagination defaults, filtering semantics beyond schema names, or response shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the read-only marker and endpoint. However, 'List tax rates' and 'Endpoint for retrieving a list of tax rates' are redundant restatements, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only list endpoint, the description plus fully described schema and safety annotations are nearly complete. Pagination is implied by the page/page_size parameters, and no output schema exists to require return-value documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema carries full parameter meaning. The description itself contributes no parameter information, which is acceptable given the high schema coverage; the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource: 'List tax rates' and 'Endpoint for retrieving a list of tax rates.' It identifies the resource and operation unambiguously; however, it largely restates the annotation title and doesn't actively distinguish from sibling list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'List tax rates' and the GET endpoint imply when to call the tool: whenever a list of tax rates is needed. There is no explicit guidance about when not to use it or which alternative to choose, but the operation is so specific that the intended usage is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_warehouses_listB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the read-only behavior is covered. The description adds the GET endpoint and green READ-ONLY marker but no new behavioral context such as pagination behavior or result shape; it is consistent with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but 'List warehouses' and 'Endpoint for retrieving a list of warehouses' are redundant. The READ-ONLY badge duplicates the annotation, so the extra lines do not each earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity read-only list endpoint, the combination of description, rich annotations, and full schema coverage is sufficient for an agent to invoke it correctly. The lack of an output schema is mitigated by the 'list of warehouses' phrasing, though return fields are unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; both page and page_size are self-documenting. The description adds no parameter semantics beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as listing warehouses ('List warehouses', 'retrieving a list of warehouses'), with resource and verb explicit. It does not explicitly contrast itself with sibling tools like wafeq_warehouses_retrieve, though the collection vs. item distinction is implied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for fetching the warehouse collection, but gives no explicit when-to-use guidance or exclusions. An agent must infer from the endpoint and name that this is the list alternative to single-warehouse retrieve/create/update endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_beneficiaries_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the write, idempotent, non-destructive nature of the tool. The description adds the HTTP PATCH method and the 'existing beneficiary' scoping, but does not go further into side effects, authorization needs, or failure behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The badge line is compact and informative, but the two prose sentences are redundant: 'Partial update beneficiary' and 'Endpoint for partially updating an existing beneficiary' say essentially the same thing. A tighter description would keep one of them.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for identifying the tool but minimal for a nested-body mutation operation with no output schema. It does not explain what the response looks like, whether at least one body field should be provided, or how errors surface. The schema compensates for field details, but the overall context remains basic.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description's endpoint path clarifies that `id` is a URL path parameter, which is useful since the schema's id property has no description. The body fields are well documented in the schema, and idempotency_key already has a detailed explanation. The description does not add rich parameter meaning, but the path mapping and schema coverage provide a reasonable baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'PATCH /beneficiaries/{id}/', 'updates data', and 'partially updating an existing beneficiary'. It specifies the resource (beneficiaries) and the partial-update verb, which distinguishes it from siblings like wafeq_beneficiaries_update and wafeq_beneficiaries_retrieve.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says this is for partially updating an existing beneficiary, which gives clear context for when to use it. However, it does not explicitly contrast it with the full update tool, mention when not to use it, or state prerequisites beyond 'existing'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_line_items_destroyA
  3.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive, but the description adds meaningful context: 'Permanently removes the record' and the red 'DESTRUCTIVE' warning make the irreversibility clear. It does not contradict the annotations and communicates the key behavioral risk beyond the structured hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a clear destructive warning, but it repeats the same idea multiple times: 'deletes', 'Delete bill line item', and 'Endpoint for deleting an existing bill line item.' It could be condensed without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete endpoint, the description covers the core behavior and permanence. However, it omits important operational context such as whether deleting a line item affects the parent bill totals, whether there are state restrictions on deletion, or what the response looks like on success or failure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only describes idempotency_key, leaving bill_id and id undocumented. The description partially compensates by showing the URL pattern /bills/{bill_id}/line-items/{id}/, which reveals the role of these parameters. However, it does not add further detail about value formats or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'deletes', 'Delete bill line item', and 'Permanently removes the record.' It identifies the exact resource (bill line item) and the HTTP endpoint, making it distinct from sibling operations like retrieve, update, or partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as using update or partial_update to modify a line item instead of deleting it. The description only states what the endpoint does, not the conditions, prerequisites, or exclusions for using it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_branches_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the partial-update/PATCH behavior but provides no additional context about side effects, permissions, or consequences. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the write indication and endpoint, but it is redundant: 'Partial update branch' and 'Endpoint for partially updating an existing branch' express the same idea. The header line also repeats information available in the endpoint path.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a partial update with rich schema coverage and helpful annotations, the description is minimally adequate: it states the operation, resource, and endpoint. However, it does not clarify the optionality of the body, the effect of omitting fields, or the idempotency behavior beyond what the schema already states.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides detailed descriptions for the nested body fields and the idempotency_key, while the id parameter is left self-evident. The tool description itself adds no parameter-level meaning, and the body description in the schema is boilerplate. With 67% schema coverage, the description does not compensate for the remaining gap, but the key parameters are reasonably documented in structured data.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as updating a branch, specifies partial update semantics, names the resource, and gives the HTTP method and endpoint path (PATCH /branches/{id}/). This distinguishes it from full-update and destroy siblings without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'partially updating an existing branch' implies this tool should be used when only a subset of branch fields need to be changed, in contrast to a full update. However, it does not explicitly name alternatives, exclusions, or when a different tool like wafeq_branches_update would be preferable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_line_items_destroyA
  3.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint and readOnlyHint, and the description adds the important consequence 'Permanently removes the record.' It does not restate idempotency or auth, but the annotations and schema cover idempotency_key behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the same core statement three times: 'deletes Credit Note Line Items', 'Delete credit note line item', and 'Endpoint for deleting an existing credit note line item.' Only the permanence statement and endpoint add real value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter destructive operation, the endpoint, permanence warning, and idempotency_key schema are sufficient. No output schema exists, so return-value documentation is not required, and nothing critical appears missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Only idempotency_key has a schema description, so coverage is low. The endpoint path in the description helps map credit_note_id and id to their roles, but id is still generic and no additional parameter details are provided beyond the path template.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description names the action 'deletes' and the exact resource 'Credit Note Line Items', and includes the full DELETE endpoint. This clearly differentiates it from sibling destroy tools like wafeq_invoices_line_items_destroy or wafeq_bills_line_items_destroy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The intended use is only inferable from the resource name rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a write operation (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description reinforces this with 'WRITE · updates data' and 'PATCH'. It adds no additional behavioral context beyond annotations, such as effects on omitted fields or required preconditions, so it earns only a baseline 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description has redundant statements: 'Partial update debit note' and 'Endpoint for partially updating an existing debit note' convey the same information. The PATCH line is useful, but the duplicate sentences could be collapsed into one concise statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a large nested body and no output schema, the description is very terse. It does not explain that only provided body fields are changed, nor does it mention that body is optional. The schema and annotations compensate partially, but the key partial-update behavior is left implicit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, so the schema already documents most fields. The tool description adds no parameter-level detail; the id and body semantics are left entirely to the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Partial update debit note' and 'Endpoint for partially updating an existing debit note.' It specifies the HTTP verb (PATCH) and resource (debit notes), and the word 'partial' distinguishes it from the sibling wafeq_debit_notes_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for updating only some fields of a debit note, but it does not explicitly say when to choose it over wafeq_debit_notes_update, nor does it state that omitted fields remain unchanged. The context is present but not spelled out.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_retrieveA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'READ-ONLY' and 'GET' labels merely echo these hints. It adds no new behavioral context such as error behavior, response shape, or authentication requirements. Since annotations carry the safety profile, the description offers only minimal additional value beyond consistency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint path. Yet 'Retrieve debit note' and 'Endpoint for retrieving a single debit note' are redundant, saying essentially the same thing twice. Replacing the redundant clause with useful details would improve the score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only retrieval with strong annotations, the description is mostly adequate: it gives the endpoint, scope, and safety profile. It is incomplete regarding the response payload and failure cases, especially since no output schema exists. The simplicity of the operation makes these gaps tolerable, so the description is minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a required id string with no description and schema coverage is 0%. The description partially compensates by showing /debit-notes/{id}/, which identifies the id parameter as the debit note identifier. It does not explain format, source, or constraints, though for a single string ID this may be sufficient for a simple retrieve operation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Endpoint for retrieving a single debit note' and includes the explicit path GET /debit-notes/{id}/. This provides a specific verb, resource, and scope ('single'), distinguishing it from sibling list, create, update, and destroy tools. Although it repeats the annotation title, the path and single-item scope make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies use for fetching one debit note by ID, reinforced by the GET path with {id}. However, it does not explicitly state when to prefer this over wafeq_debit_notes_list or other debit-note tools, nor does it mention alternatives or exclusions. An agent must infer usage from the name and path rather than receive direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_employees_retrieveA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reinforces safety with 'READ-ONLY' and 'GET', and the annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. It adds the concrete path, but no additional behavioral context such as error behavior, authentication requirements, or rate limits; the annotations carry most of the transparency burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the endpoint, but 'Retrieve employee' and 'Endpoint for retrieving a single employee' are near-duplicates, and the emoji header repeats annotation information. It is compact but contains redundancy rather than each sentence earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only fetch, the endpoint, resource, and safety annotations give an agent enough to select and invoke it correctly. It lacks output/error notes and explicit routing to list, but these are minor for such a simple retrieve operation given no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description only echoes the id in the URL path without explaining the value's expected format, provenance, or why it identifies the employee. With low schema coverage, the description was expected to compensate, and it does not.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('retrieve'), a resource ('employee'), and the exact endpoint (GET /employees/{id}/), and explicitly scopes it to a single employee. This clearly distinguishes it from list, update, and destroy siblings even without opening their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Retrieve a single employee' implies the tool is for fetching one record by ID, but it never states when to prefer this over employees_list, or when to avoid it. No alternatives or exclusions are named, so the agent must infer usage from the endpoint and sibling names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_line_items_createA
  3.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes well beyond the annotations by explicitly warning 'Not idempotent — calling twice creates two records' and explaining the concrete mitigation via idempotency_key with server-side UUID v4 generation. This adds real behavioral context that the idempotentHint=false flag alone does not convey. Consistent with annotations; no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, but 'Create invoice line item' and 'Endpoint for creating a new invoice line item' state the same thing redundantly, and the emoji metadata line partially duplicates the title annotation. The important non-idempotency caveat is placed at the end, which is acceptable but not front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a nested-object create operation with no output schema, yet the description does not mention what the response returns, prerequisites for the parent invoice, or clarify the confusing body parameter description. The strong idempotency guidance partially offsets these omissions, so the tool remains callable, but an agent would be guessing on several key aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67%, and the description reinforces the idempotency_key semantics already in the schema. However, invoice_id lacks any schema or description explanation, and the body parameter's schema description is a garbled internal note ('Augment custom_fields in the output with computed CALCULATED field values...') that does not explain what the body should contain. The description does not compensate for these gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('create'), a specific resource ('invoice line item'), and the full endpoint path (POST /invoices/{invoice_id}/line-items/). The invoice-scoped target is unambiguous, distinguishing it from sibling line-item creators on bills, credit notes, quotes, and purchase orders.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage ('Endpoint for creating a new invoice line item') but gives no explicit guidance on when to choose this over siblings like wafeq_invoices_line_items_update, wafeq_invoices_line_items_partial_update, or wafeq_invoices_line_items_list. It also omits prerequisites, such as whether the parent invoice must exist or be in a specific state.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_items_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the write nature is established. The description adds the partial-update behavior and that the item must already exist, which is useful, but it does not disclose response behavior, side effects, or update-specific details beyond what annotations and schema already provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the endpoint and write label. The second sentence ('Endpoint for partially updating an existing item') largely repeats the first, a minor redundancy that keeps it from a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists and the payload is complex and nested, yet the description gives no indication of the response shape, which fields are required versus optional, or practical usage guidance. An agent could call it from the schema, but the description alone leaves too much unsaid for a mutation tool with this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides detailed descriptions for the body fields and the idempotency_key, and the description adds the essential partial-update semantic that omitted fields remain unchanged. However, the id parameter itself has no description, and the body description is oddly serializer-focused rather than explaining the payload's purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a partial update for Items, gives the HTTP method and path (PATCH /items/{id}/), and the 'partial' modifier distinguishes it from wafeq_items_update. The resource and action are unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The partial-update semantics imply when to use it, but there is no explicit guidance about when to choose this over wafeq_items_update or when only some fields should be supplied. The intended usage is clear only by inference from the name and the word 'partial'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payments_createA
  3.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that this is a write ('WRITE · creates data') and, more valuably, spells out the concrete consequence of non-idempotence: 'calling twice creates two records.' It then provides the mitigation ('Pass idempotency_key (or let the server generate one) to make a retry safe'), which adds context beyond what idempotentHint=false alone conveys. No contradiction with 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded: the WRITE label, resource, and endpoint appear first, followed immediately by the essential non-idempotence warning. There is minor redundancy between 'Create payment' and 'Endpoint for creating a new payment,' but no sentence is wasted and the critical retry guidance is positioned prominently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Inputs are fully covered by a rich schema, and the description closes the main behavioral gap an agent would face — duplicate creation on retry — with the idempotency_key instruction and a server-generated UUID fallback. It does not describe the response shape, and no output schema exists, but for a create endpoint the input requirements and safety behavior are the parts that matter most, and both are well covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the body schema already exhaustively documents amounts, currency, document-linked lists, and payment_fees with detailed semantics, so the description need not repeat them. The description adds only a brief behavioral note about idempotency_key that complements, but does not substantially extend, the schema's own description. The baseline of 3 applies when the schema carries the parameter-documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with '🟡 WRITE · creates data · Payments · POST /payments/' and states 'Create payment' / 'Endpoint for creating a new payment.' This is a specific verb+resource that an agent can act on without ambiguity. It does not explicitly contrast with the similarly named wafeq_payment_requests_create, but the 'Payments' resource label and endpoint make the target resource clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance is provided relative to alternatives. The description never names sibling tools or states conditions for choosing this over wafeq_payment_requests_create or wafeq_payments_update. The only guidance present is the idempotency-key retry note, which addresses invocation safety rather than tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey readOnly=false, destructive=false, and idempotent=true; the description adds 'WRITE' and PATCH, which are consistent but not contradictory. It does not describe side effects, field-merge behavior, or response characteristics beyond the partial-update concept.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the endpoint, but 'Partial update payslip' and 'Endpoint for partially updating an existing payslip' are redundant. The generic 'updates data' phrase adds little beyond the WRITE label.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and annotations carry enough detail for basic invocation, including field enums, idempotency, and non-destructive intent. However, there is no output schema and no guidance on what the response contains or how omitted fields are treated, leaving the definition adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool description itself does not enumerate body fields, but the input schema documents most nested fields and gives a strong explanation for idempotency_key. The 'partial update' wording signals that body fields are optional/subset updates, though the top-level body description ('Adds nested create feature') is unhelpful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('partial update'), the resource ('payslip'), and the HTTP endpoint ('PATCH /payslips/{id}/'). This differentiates it from siblings such as wafeq_payslips_update and wafeq_payslips_destroy without needing to inspect their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'partially updating an existing payslip' implies it is meant for subset modifications on an existing record, but it never explicitly contrasts it with wafeq_payslips_update or states when not to use it. No alternative tool or exclusion condition is named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_projects_listA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the GET method and READ-ONLY label, but does not disclose pagination behavior, response shape, or ordering. With annotation coverage this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the emoji, HTTP method, and resource. However, 'List projects' and 'Endpoint for retrieving a list of projects' are redundant, so not every sentence fully earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list endpoint with zero required parameters and fully documented optional pagination params, the description is nearly complete. It omits details like default page size or ordering, but these are not necessary for selecting or invoking the tool correctly. Annotations and schema cover the remaining context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes both parameters (page and page_size) with 100% coverage, and the description adds no parameter-level meaning. Under high schema coverage, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the resource ('Projects'), the verb ('List'), and the HTTP method/path (GET /projects/). An agent can immediately distinguish this from sibling operations like wafeq_projects_retrieve because this is explicitly a collection-list endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is provided. The description only restates that the tool lists projects and does not mention that wafeq_projects_retrieve should be used for a single project, nor any context around pagination. This is essentially no guidance beyond the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_bill_createA
  3.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing that the result is a draft bill, that the operation is non-idempotent ('calling twice creates two records'), and that passing an idempotency_key makes retries safe. These statements are consistent with annotations (readOnlyHint=false, idempotentHint=false) and add useful operational safety context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The header line is compact and informative, but the non-idempotency warning is stated twice nearly verbatim ('Not idempotent — calling twice creates two records...' and 'Calling twice creates two bills — pass an idempotency_key if you may retry'), adding redundancy without introducing new information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool, the description covers the core behavior, the draft-bill state, and the retry risk. Gaps remain: idempotency_key is referenced but not present in the schema, and the description does not say what happens to the source purchase order after conversion or what the response contains (and there is no output schema to fill that gap).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does clarify that the only schema parameter, id, identifies the purchase order, via the endpoint URI and the 'Convert purchase order to bill' phrasing. However, it repeatedly references an idempotency_key that is absent from the input schema, leaving ambiguity about how the agent is expected to supply it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Convert purchase order to bill' and 'Creates a NEW draft bill from the purchase order,' and it includes the endpoint path POST /purchase-orders/{id}/bill/. What the tool does is unambiguous, though it does not explicitly contrast itself with the sibling wafeq_bills_create (which creates a bill from scratch), leaving that differentiation implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use case ('convert a purchase order to a draft bill') is clearly implied by the description and endpoint path. However, there is no explicit when-to-use vs when-not-to-use guidance, and no alternative tool such as wafeq_bills_create is mentioned, which an agent could otherwise confuse as a substitute path to the same result.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_partial_updateA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as a write operation (readOnlyHint=false), non-destructive, and idempotent; the description adds the PATCH route and 'partial update' semantics without contradicting those hints. It does not disclose additional operational context such as what happens to omitted fields or what the response contains, so it remains at the annotation-covered baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the method and path. However, 'Partial update quote' and 'Endpoint for partially updating an existing quote' are redundant restatements of the same point, so one line does not earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema carries most field and idempotency details, and the annotations carry the write/non-destructive/idempotent profile. The description adds the HTTP semantics but says nothing about patch behavior on omitted fields, so completeness is adequate but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool description contributes the meaningful detail that id is a URL path parameter and that the body is a partial patch. Most field-level semantics already live in the schema, including a thorough idempotency_key explanation, so the description adds only modest meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with the PATCH route and explicitly states 'Partial update quote' and 'Endpoint for partially updating an existing quote'—a specific verb, resource, and HTTP method. This unambiguously identifies the operation and distinguishes it from the full-update sibling wafeq_quotes_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this tool is for updating a subset of quote fields on an existing quote. However, it does not explicitly name alternatives such as wafeq_quotes_update or state when not to use this tool, so the usage guidance is adequate but implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_units_of_measure_retrieveA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower. The description adds the HTTP method and endpoint path ('GET /units-of-measure/{id}/') and repeats 'READ-ONLY,' but it does not disclose error behavior, authentication needs, or what happens for invalid IDs. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, but it contains redundancy: 'Retrieve unit of measure' appears in the heading and is then restated as 'Endpoint for retrieving a single unit of measure.' The same idea is expressed three times across the description, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval endpoint with one parameter, the description provides the essential purpose and endpoint. However, with no output schema and no mention of response contents or error behavior, it is only minimally complete. An agent can call it correctly based on the input schema, but would need to infer return semantics and failure modes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description bears more responsibility. The endpoint path '/units-of-measure/{id}/' implicitly communicates that 'id' is the identifier of the unit of measure to retrieve, which adds slight meaning beyond the bare schema property. However, it does not explicitly describe the id or explain where to obtain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('Retrieve unit of measure') and the specific resource ('Unit Of Measures'), and emphasizes 'a single unit of measure,' which distinguishes it from list or create siblings. The endpoint path 'GET /units-of-measure/{id}/' reinforces the exact action and resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this when you need to retrieve one specific unit of measure by ID. However, it does not explicitly state when to prefer it over related siblings like list, create, or update, nor does it mention any alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_accounts_partial_updateA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry the key safety signals (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds that this is a PATCH/partial update, but it does not disclose further behavioral details such as what happens to omitted fields 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a write indicator and endpoint. However, 'Partial update account' and 'Endpoint for partially updating an existing account' are redundant restatements of each other and of the annotation title.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a PATCH operation with a complex optional body and no output schema, the description is minimally sufficient: it states the resource and partial-update semantics, and the schema covers field details. It lacks guidance on full-update alternatives, return behavior, and the effect of omitting fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, and the schema already documents the nested body fields and idempotency key reasonably well. The description only adds path context for the required id via '/accounts/{id}/'; it does not clarify the body object or compensate for the boilerplate serializer description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('updates'), a concrete resource ('Accounts'), the HTTP method and path ('PATCH /accounts/{id}/'), and the exact scope ('partially updating'). This clearly distinguishes the tool from retrieve, full update, and destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for modifying selected fields of an existing account rather than replacing the whole record, but it does not explicitly say when to choose wafeq_accounts_update instead, nor does it provide prerequisites or when-not-to-use guidance. It is adequate but leaves comparison to alternatives implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_statement_transactions_destroyA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true and readOnlyHint=false, and the description reinforces this with '🔴 DESTRUCTIVE' and adds the important irreversible consequence: 'Permanently removes the record.' This goes slightly beyond the structured annotations, though it does not cover other behaviors like cascading effects or response details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The destructive warning is front-loaded, which is good, but the text is repetitive: 'deletes', 'Delete bank statement transaction', and 'Endpoint for deleting an existing bank statement transaction' all say essentially the same thing. The redundancy reduces clarity and wastes space that could have been used for more useful behavioral context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward destroy operation, the description plus annotations are mostly adequate: it is marked destructive, irreversible, and idempotent, and the required parameters are clear. However, there is no output schema and the description does not mention expected response behavior, prerequisites, or cascading consequences, leaving some ambiguity for an agent invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%: id and bank_account_id are bare strings with no descriptions, while idempotency_key is fully documented. The URL pattern in the description helps clarify that bank_account_id scopes the parent bank account and id identifies the specific statement transaction, but no format or additional constraints are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as deleting a bank statement transaction, using concrete verbs like 'deletes' and 'removes' along with the exact resource and endpoint. It is unambiguous and distinguishable from sibling tools that list, retrieve, or update the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool should be used when a bank statement transaction needs to be permanently deleted, but it does not explicitly contrast it with alternatives such as retrieve, update, or partial_update for the same resource. No exclusions, prerequisites, or cautionary conditions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_branches_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP GET endpoint and reinforces the read-only nature, but does not disclose additional behavioral details such as authentication requirements, error behavior, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the read-only badge and endpoint, which is good. However, 'Retrieve branch' and 'Endpoint for retrieving a single branch' are redundant restatements of the same idea, and the READ-ONLY label duplicates the annotation. It could be tightened to a single informative sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieve operation with only one required parameter, the description is largely sufficient. It clearly identifies the resource, the HTTP method, and the single-entity scope. The lack of an output schema is mitigated by the straightforward nature of a retrieve endpoint, though a note about the response shape would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate, and it does partially by showing 'id' as a path parameter in 'GET /branches/{id}/'. However, it does not explain what the ID represents, where to find it, or what format it should take, leaving the agent with minimal added meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Retrieve branch'), the resource ('branch'), and the exact endpoint ('GET /branches/{id}/'), making it obvious that this tool fetches a single branch by ID. It also distinguishes itself from sibling tools like wafeq_branches_list, wafeq_branches_create, and wafeq_branches_update through the phrase 'retrieving a single branch.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'single branch' implies this tool is for retrieving one specific branch rather than listing all branches, but no explicit guidance is given about when to use this versus wafeq_branches_list or other branch-related tools. The usage context is present but not fully articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_line_items_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the HTTP endpoint and resource scope, but no additional behavioral context beyond what annotations already provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the key endpoint, but the final two sentences ('Retrieve credit note line item' and 'Endpoint for retrieving a single credit note line item') are redundant. It could be trimmed to one clear statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-by-identifier endpoint, the description is functionally complete: it names the resource, gives the endpoint pattern, and annotations cover the safe/idempotent behavior. The absence of an output schema and low complexity reduce the need for deeper return-value documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description carries the burden. The endpoint template shows that credit_note_id identifies the parent credit note and id identifies the line item, which adds relational meaning beyond bare schema. Still, it provides no further parameter detail or examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Retrieve') and resource ('credit note line item'), and reinforces it with the endpoint pattern. The word 'single' distinguishes this from list, create, update, and destroy siblings in the same credit-note line-item family.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by 'retrieving a single credit note line item,' so an agent can infer this is for targeted reads rather than listing or modifying. However, it does not explicitly mention alternatives such as the line-items list endpoint or any exclusions/prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_custom_fields_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds the endpoint and READ-ONLY marker. It does not add deeper behavioral context such as 404 behavior, auth requirements, or response shape, but for a read-only retrieval tool the annotation coverage makes this acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but contains redundant restatement: 'Retrieve custom field' and 'Endpoint for retrieving a single custom field' say essentially the same thing. The useful endpoint and READ-ONLY prefix are front-loaded, but the duplication keeps it from being tightly structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only retrieval tool with rich annotations and no output schema, the description is nearly sufficient. It gives the HTTP method and resource path and clarifies the singleness of the operation, though it could briefly mention that the response is the custom field representation or that the id comes from a list/create response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the single required parameter id already has a clear description. The tool description adds no additional meaning about the id format or where to obtain it, which is fine because the schema covers the semantics fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('retrieve'), a resource ('custom field'), and explicitly says 'single custom field', which distinguishes it from sibling tools like custom_fields_list, custom_fields_create, and custom_fields_destroy. The endpoint line also pins the operation to GET /custom-fields/{id}/.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for fetching one custom field by ID, but it does not state when to prefer it over the list sibling or mention any exclusions. There is no explicit routing to alternatives, so usage guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_employees_destroyA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true and idempotentHint=true. The description adds the useful detail that the record is permanently removed, but it does not disclose cascading effects, authorization requirements, or response behavior. No contradiction with 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the destructive nature and endpoint path, but it repeats the same idea multiple times: 'deletes · Employees', 'Delete employee', and 'Endpoint for deleting an existing employee'. The only substantially additive sentence is 'Permanently removes the record.'

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete-by-id operation, the description, annotations, and idempotency_key schema provide enough context to select and invoke the tool correctly. Missing details such as cascading deletion behavior or return status are not critical for this operation, especially since no output schema exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The idempotency_key parameter is fully explained in the schema, including header behavior and UUID fallback. The required id parameter has no schema description, though its role is made obvious by the endpoint template /employees/{id}/ and the delete action. The description itself adds little explicit parameter meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the exact verb and resource: 'deletes · Employees', 'Delete employee', and 'Endpoint for deleting an existing employee'. It also includes the HTTP endpoint DELETE /employees/{id}/ and the consequence 'Permanently removes the record', making the tool's purpose unambiguous relative to employee retrieve/update siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended usage is implied: call this tool when an existing employee must be permanently deleted. However, it does not explicitly contrast with wafeq_employees_retrieve, wafeq_employees_update, or wafeq_employees_partial_update, nor does it provide any exclusions or precautions beyond the record needing to exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear without the description. The description adds the HTTP method and URL pattern and restates READ-ONLY, but does not disclose response shape or invalid-id behavior; this is acceptable given the annotation coverage but not a strong value-add beyond it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY and endpoint markers, but 'Retrieve expense' and 'Endpoint for retrieving a single expense' are redundant restatements. A single concise sentence would have equal utility.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, single-object GET endpoint with annotations covering the safety profile, the description is nearly complete: it identifies the resource, the HTTP path, and the singleness of the result. It does not explicitly describe the return value or error cases, but 'retrieve expense' strongly implies the returned object, so the remaining gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description bears the burden of explaining the id parameter. It only indirectly clarifies id through the URL template /expenses/{id}/ and the phrase 'single expense'; it does not explain the id format or that id is the unique expense identifier, though the single required parameter makes the gap small.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a precise operation—retrieving a single expense via GET /expenses/{id}/—and the word 'single' distinguishes it from wafeq_expenses_list and the create/update/destroy variants. This gives an agent enough specificity to select it among the many retrieve endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when an agent needs one expense and already has its id, but it never explicitly says when to prefer this over wafeq_expenses_list or mentions that the id is required. No alternatives or exclusions are stated, so usage guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payment_requests_destroyA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation as destructive and non-read-only, but the description adds the important behavioral detail that the record is permanently removed, reinforcing irreversibility. It also clearly identifies the target resource. No contradiction with annotations was found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The key information is front-loaded with the DESTRUCTIVE label and endpoint, but the description is repetitive: 'Delete payment request', 'Endpoint for deleting an existing payment request', and 'Permanently removes the record' overlap. It could be tightened to two clear sentences without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with strong annotations, the description covers the essential facts: target resource, HTTP endpoint, permanence, and the required id through the schema. The idempotency behavior is handled by the schema's idempotency_key description and the idempotentHint annotation. No output schema exists, but a delete confirmation response is not critical for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 50%: the required 'id' parameter has no schema description. The description partially compensates through the endpoint path showing '{id}' and the phrase 'existing payment request', which implies id refers to the payment request to delete. The idempotency_key parameter is fully explained in the schema, so no additional description is needed there.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes'), a specific resource ('Payment Requests'), and the exact HTTP endpoint ('DELETE /payment_requests/{id}/'). This clearly distinguishes it from sibling actions like retrieve, update, or partial_update on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains what the tool does but provides no guidance on when to choose it over alternatives, nor any exclusions or prerequisites. It never explicitly says 'use this when you need to permanently remove a payment request' or points to retrieve/update as safer alternatives for non-destructive needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_destroyA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds a useful permanence warning with 'Permanently removes the record' and identifies the HTTP DELETE method, but it does not disclose potential side effects, required permissions, or restrictions on when deletion is allowed. The annotation burden is largely already covered, so this is adequate but not exceptional.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line compactly front-loads the destructive action and endpoint, which is helpful. However, 'Delete quote' and 'Endpoint for deleting an existing quote' are redundant repetitions of the same idea, so not every sentence earns its place. The description is short but could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple destructive endpoint with one required parameter, and the annotations already provide the critical safety profile. The description's 'Permanently removes the record' adds the key consequence, and the schema explains idempotency behavior. Missing response/error details like 204 versus 404 are lower-value gaps for an invocation decision.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents idempotency_key with strong retry semantics, leaving only the required id parameter undocumented. The description supplies some path context via '/quotes/{id}/' but does not explicitly explain that id is the quote identifier or add meaning beyond the schema. At 50% schema coverage, the description only partially compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation with 'Delete quote' and 'Endpoint for deleting an existing quote,' and exposes the exact endpoint 'DELETE /quotes/{id}/'. The verb and resource are unambiguous, and the destructive nature is front-loaded, distinguishing it from sibling quote tools like wafeq_quotes_update and wafeq_quotes_partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: an agent should use this when an existing quote needs to be deleted. However, the description gives no explicit when-to-use versus when-not-to-use guidance, such as 'use update to modify a quote instead' or 'only delete quotes in certain states.' The intent is clear, but exclusion conditions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_line_items_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint, idempotentHint, and destructiveHint=false. The description repeats READ-ONLY and adds the GET method and path, but it does not add new behavioral context such as error behavior, authentication needs, or response shape. This is adequate because the annotations carry the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a compact READ-ONLY and endpoint header. However, the two sentences after the header—'Retrieve quote line item' and 'Endpoint for retrieving a single quote line item'—are redundant and could be merged into one sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter read-only retrieval tool with strong annotations, the description is mostly complete: it names the resource, the single-object scope, and the full path. It does not describe the return object, but with no output schema and a simple retrieve operation, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the burden. The endpoint path clarifies that quote_id is the parent quote and id is the line item identifier, and the parameter names are self-explanatory. However, no formats, constraints, or additional semantics are provided, leaving only minimal compensation for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Retrieve') and the resource ('quote line item'), and the explicit endpoint path reinforces the scope. The word 'single' distinguishes it from wafeq_quotes_line_items_list, and the retrieve verb separates it from create/update/destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the appropriate use case: fetching one specific quote line item by quote_id and id. However, it does not explicitly mention alternatives such as the list endpoint for retrieving all line items or update/destroy for mutations, so the guidance remains implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_retrieveA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the READ-ONLY prefix adds no new behavioral information. The description does not disclose response shape, error behavior, authentication needs, or other side effects beyond what annotations cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The route and resource line is front-loaded and compact, but 'Retrieve quote' and 'Endpoint for retrieving a single quote' are redundant restatements of the same action. The description is short but contains repeat filler instead of earning each sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only endpoint, the route and single-quote wording give enough context, and the annotations fully cover the safety profile. The lack of explicit output or error details is a minor gap for an operation whose return value is self-evident.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description compensates by showing the id in the route template GET /quotes/{id}/, so the agent knows the parameter is a path variable. For a single self-evident id parameter, this is sufficient semantic guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Retrieve quote' and 'Endpoint for retrieving a single quote.' Including the explicit route GET /quotes/{id}/ and the word 'single' distinguishes it from wafeq_quotes_list, create, update, and destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is only implied: 'retrieving a single quote' suggests use when an ID is known. The description names no alternatives and gives no explicit when-not-to-use guidance versus other quote-related endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_reports_balance_sheet_listA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with a READ-ONLY label and GET endpoint. It adds useful constraints (no date range, required params) but no new behavioral side-effect information beyond what annotations already carry.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured, front-loading the READ-ONLY status and endpoint before the parameter explanation. There is minor redundancy: 'Balance Sheet' appears both as a heading and in the opening sentence, but overall each section serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters and full schema coverage, the description covers the key invocation details: required parameters, no date range, and grouping behavior. It does not mention the optional branch/contact/project filters or currency defaults, but those are fully documented in the schema, making the description sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining period_count as '0-11 extra comparison periods', clarifying that group_by sets the period size, and explicitly defining date as the 'as of' date while ruling out date-range parameters. This goes beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it generates a balance sheet report with specific parameters, and the resource is unambiguous via the /reports/balance-sheet/ endpoint. However, it does not explicitly contrast with sibling report tools such as cash_flow, profit_and_loss, or trial_balance, leaving differentiation largely to the tool name and title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit input guidance, noting that date and period_count are required and that no date range is accepted. It does not explain when to choose this tool over the alternative report tools, so the 'vs alternatives' aspect is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces these with a READ-ONLY marker. It adds the endpoint method/path but provides no additional behavioral context such as authentication requirements, rate limits, or response shape. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but it is redundant: 'Retrieve simplified invoice' and 'Endpoint for retrieving a single simplified invoice' essentially restate the same thing. The same content could be conveyed in one sentence without losing clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only retrieve operation with strong annotations, the description is nearly complete. It provides the endpoint, the resource type, and the fact that it returns a single invoice. The lack of an output schema is acceptable given the tool name and purpose, though it could mention where to find the ID.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required 'id' parameter with 0% description coverage, so the description must compensate. It does so minimally by showing '{id}' in the endpoint path, indicating the parameter is a path parameter. However, it does not explain the format, source, or expected values of the ID.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Retrieve'), the resource ('simplified invoice'), and the exact endpoint (GET /simplified-invoices/{id}/). It distinguishes this tool from sibling list, create, update, and destroy operations for the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the verb 'retrieve' and the endpoint, making it obvious the tool fetches a single simplified invoice by ID. However, it does not explicitly mention alternatives like simplified_invoices_list or regular invoices_retrieve, nor does it provide when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_warehouses_destroyA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds useful behavioral context beyond that by stating the deletion is permanent and that the endpoint acts on an existing warehouse, ruling out soft-delete ambiguity. It does not cover cascading effects or permissions, but it does not contradict 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The destructive warning and endpoint are front-loaded, but the description repeats the same idea three times: 'deletes · Warehouses', 'Delete warehouse', and 'Endpoint for deleting an existing warehouse.' Only 'Permanently removes the record' adds a distinct nuance. The redundancy makes the description less crisp than it should be.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter delete tool with no output schema, the description provides the essential target and permanence, and annotations cover the destructive and idempotent nature. However, it omits response behavior, error conditions, or any restrictions on deletion. This is a minor gap given the tool's simplicity, but the description is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema richly documents idempotency_key, while id is only typed as a string. The description's endpoint line '/warehouses/{id}/' clarifies that id is the path identifier, adding a little semantic value. Still, the description does not explain the id's format or provenance, and with 50% schema coverage, parameter guidance is adequate but not complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'deletes', 'Delete warehouse', and 'Permanently removes the record.' It identifies the exact resource (Warehouses), the HTTP method and endpoint, and distinguishes it from sibling tools like wafeq_warehouses_retrieve, wafeq_warehouses_update, and wafeq_warehouses_partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied—call this when an existing warehouse should be deleted. However, the description does not explicitly say when not to use it or mention alternatives such as update/partial_update for modifying a warehouse instead of removing it. The routing guidance is inferable but not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_warehouses_retrieveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the READ-ONLY label adds no new behavioral information beyond the structured data. The GET endpoint and 'single warehouse' scope add minor context, but no auth, rate-limit, or error behavior is disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, but redundant: 'Retrieve warehouse' and 'Endpoint for retrieving a single warehouse' restate the same purpose, and the READ-ONLY marker duplicates the annotation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only endpoint with rich annotations, the description covers the essential purpose and resource scope. It lacks an explicit return-value description, but the tool name and 'retrieve warehouse' make the expected output sufficiently clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and one required id parameter, the description's URL pattern /warehouses/{id}/ helps map id to a warehouse identifier. However, it does not explicitly define the parameter type, format, or source of the id, leaving some inference to the agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Retrieve warehouse' and 'Endpoint for retrieving a single warehouse', with a specific verb, resource, and singular scope. This clearly distinguishes it from sibling tools like wafeq_warehouses_list and wafeq_warehouses_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by 'retrieving a single warehouse' and the required id parameter, but there is no explicit guidance on when to choose this over wafeq_warehouses_list or other warehouse endpoints. No alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_ledger_transactions_destroyA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the explicit warning 'Permanently removes the record' and the 🔴 DESTRUCTIVE marker, making irreversibility clear. It does not mention cascade effects or authorization requirements, but the annotation-provided safety profile is strong and the description adds useful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the danger warning and endpoint path, which is good. However, 'Delete bank ledger transaction' and 'Endpoint for deleting an existing bank ledger transaction' are near-duplicate statements, adding redundancy without new information. It is short but not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with annotations covering destructiveness and idempotency, and the schema covering idempotency_key behavior, the description supplies the essential permanence warning. It does not describe response format or deletion constraints, but nothing critical is missing for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%, with bank_account_id and id lacking descriptions. The endpoint path reveals the hierarchy, but the description does little beyond the schema's field names to explain the parameters. The idempotency_key semantics are already covered by the schema, not the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes'), the resource ('Bank Ledger Transactions'), the exact endpoint path, and the consequence ('Permanently removes the record'). This clearly identifies the operation and distinguishes it from retrieve/update/list siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for the delete operation, but it does not explicitly state when to use this tool over alternatives, nor does it mention any conditions or prerequisites. The intent is inferable from the name and destructive semantics, but no proactive routing guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_createA
  3.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark this as non-read-only and non-idempotent, and the description adds concrete behavioral context: calling twice creates two records, and passing an idempotency_key or letting the server generate one makes retries safe. This meaningfully helps an agent understand the write semantics and avoid accidental duplication.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a clear write label, endpoint, and the most important behavioral caveat. However, 'Create bill' and 'Endpoint for creating a new bill' are redundant, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex create operation with a large nested body schema and no output schema, yet the description does not mention what the API returns (e.g., created bill ID or object) or any prerequisites such as referenced contacts/accounts needing to exist. The idempotency note is useful, but the description remains incomplete for safe invocation of a complex write tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 tool description's idempotency_key note largely restates what the schema already explains, and it adds no new parameter-level meaning beyond the schema's detailed descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states a specific verb ('creates'), resource ('Bills'), and endpoint ('POST /bills/'), making it unmistakable that this tool creates new bills. It also reinforces the create semantics by warning that calling twice creates two records, which clearly distinguishes it from read/update/delete bill operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives such as wafeq_bills_update, wafeq_bills_partial_update, or wafeq_purchase_orders_bill_create. Usage is only implied by the verb 'create', with no mention of when not to use it or what differentiates it from related bill operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_line_items_createA
  3.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description clearly discloses non-idempotency ('Not idempotent — calling twice creates two records') and explains how idempotency_key makes retries safe, adding useful context beyond the idempotentHint=false annotation. It also leads with 'WRITE · creates data', consistent with readOnlyHint=false.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The front-loaded banner and idempotency warning are useful, but 'Create debit note line item' and 'Endpoint for creating a new debit note line item' repeat the same information. Several segments are redundant rather than earning their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a nested create call, the description gives the route and retry semantics but no description of the expected response or any guidance on the body contract; the schema must carry that weight. With no output schema and a poorly described body parameter, some context is missing, though the annotations cover the safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds no new detail about the body fields or debit_note_id; the path template is the only parameter hint it provides. The schema already documents most fields, but the required body shape is left entirely to the schema, whose body description is an unrelated output note.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Create') and resource ('debit note line item'), and provides an exact POST path with debit_note_id. It is clearly distinguishable from sibling tools targeting line items on other document types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage by labeling itself as the endpoint for creating a new debit note line item and warns against duplicate calls. However, it does not mention alternatives such as update, partial_update, or destroy, nor does it state explicit when-not-to-use conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_line_items_destroyA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation as destructive, and the description adds value by explicitly saying 'Permanently removes the record' and stating exactly what gets destroyed: the debit note line item. This reinforces irreversibility without contradicting 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but it repeats the same idea: '🔴 DESTRUCTIVE · deletes', 'Delete debit note line item', and 'Endpoint for deleting an existing debit note line item' all say essentially the same thing. It could be tightened to a single clear sentence plus the permanence warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter destructive operation with no output schema, the description covers the resource, endpoint, permanence, and idempotency semantics. It does not mention response behavior, prerequisites, or error conditions, but the annotations carry the destructive safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema leaves debit_note_id and id undocumented, but the endpoint path in the description clarifies that debit_note_id is the parent debit note ID and id is the line item ID. The optional idempotency_key is already thoroughly explained in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Delete debit note line item') and the exact resource ('Debit Note Line Items'), reinforced by the endpoint path. It is clearly distinguishable from sibling line-item retrieve, update, and partial_update tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The agent must infer usage from the verb 'delete' and the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_createA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry readOnlyHint=false and idempotentHint=false, but the description adds genuine value beyond them: it explains the concrete consequence of non-idempotency ("calling twice creates two records") and prescribes the mitigation (pass idempotency_key or let the server generate one for safe retries). The WRITE warning is consistent with readOnlyHint=false. This is meaningful behavioral context, though it stops short of covering auth or rate-limit behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and the idempotency warning is genuinely useful, but it contains redundancy: "Create invoice", "Endpoint for creating a new invoice", and the header's "Invoices · POST /invoices/" all say essentially the same thing. The emoji-prefixed header also duplicates what the annotation title already provides. Tightening to the endpoint line plus the non-idempotency note would earn a higher score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity — a large nested body with roughly 25 fields and nested line_items with revenue_recognition — the description is brief, but the 100%-coverage schema compensates heavily. There is no output schema and the description says nothing about the success response or what the created invoice object contains, which is a real gap for a creation endpoint. Core purpose and the key behavioral caveat are covered, making it adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 thoroughly documents every body field and the idempotency_key parameter, including the X-Wafeq-Idempotency-Key header and auto-generated UUID behavior. The description's mention of idempotency_key largely restates the schema's richer explanation rather than adding new parameter semantics. It neither harms nor meaningfully extends the schema's documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: "Create invoice" with endpoint "POST /invoices/", and the header line "WRITE · creates data · Invoices" reinforces this. It is readily distinguishable from the update/retrieve/list/destroy invoice siblings, though it never names a sibling explicitly. Close cousins like wafeq_simplified_invoices_create and wafeq_quotes_invoice_create exist and are not explicitly differentiated, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: this is the endpoint for creating a new invoice, and the non-idempotency warning implies it is for fresh creation rather than updating an existing record. No exclusions or alternative-tool routing are provided, but for a straightforward create endpoint the usage context is self-evident from "Create invoice" and the POST path.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_manual_journals_retrieveA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the GET endpoint and the 'single' scope, but largely repeats what the annotations and title already convey. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the READ-ONLY badge and endpoint, which is good. However, 'Retrieve manual journal' and 'Endpoint for retrieving a single manual journal' are essentially redundant, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-resource retrieval with a one-parameter schema and strong read-only/idempotent annotations, the description is mostly complete. It tells the agent what is retrieved and via which endpoint, though it could have added a bit more detail about the response or the id parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description needed to explain the meaning or format of 'id'. It only shows the URL path placeholder {id}, leaving the agent to infer that id is the manual journal's identifier. No additional semantics such as ID type, format, or source are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'retrieve' with the resource 'manual journal' and explicitly says 'single manual journal', which clearly distinguishes it from sibling operations like manual_journals_list, manual_journals_create, and manual_journals_update. The HTTP endpoint GET /manual-journals/{id}/ reinforces the exact scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes clear that this tool is for retrieving one manual journal by ID, which is sufficient context for the common case. It does not explicitly name alternative tools or state when not to use it, but 'single manual journal' implies the contrast with list/create/update operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_organization_retrieveA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method and path, but does not go beyond annotations with details like auth requirements, response behavior, or any limitations. This is consistent with the annotations, so no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, but it is redundant: 'Retrieve organization' and 'Endpoint for retrieving a single organization' say essentially the same thing. The first line packs useful metadata, but the duplicate sentences could be compressed without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only retrieve endpoint, the description is mostly adequate. However, it does not explicitly state that no ID is needed and that the current organization is returned, nor does it describe the response shape despite there being no output schema. These gaps are minor but prevent full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters and the schema has full coverage (100%), so there is no parameter documentation burden on the description. The baseline of 4 applies; the description does not need to explain parameters that do not exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the verb ('Retrieve') and resource ('organization'), and reinforces it with 'Endpoint for retrieving a single organization.' The endpoint path GET /organization/ also makes the target explicit, and it is naturally distinguishable from the many sibling *_retrieve tools by resource name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: the agent should use this tool when it needs to retrieve an organization. However, there is no explicit guidance about when not to use it, no alternative tool is mentioned, and it does not clarify that the organization is resolved from the current auth context despite having no parameters.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payment_requests_createA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly warns that the operation is not idempotent and that calling twice creates two records, which adds meaningful behavioral context beyond the annotations. It also explains how idempotency_key makes retries safe, including server-generated UUID behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the operation type, resource, and endpoint. There is minor redundancy between the title, 'Create payment request', and 'Endpoint for creating a new payment request', but no wasted sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a rich input schema, annotations, and no output schema, the description provides endpoint context, a write indicator, and a critical idempotency warning. It does not describe the response payload, but for a create endpoint the created resource is reasonably inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents the body and idempotency_key fields thoroughly. The description mentions idempotency_key behavior, but this largely repeats schema details rather than adding new parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states the specific action ('creating a new payment request') and includes the exact endpoint ('POST /payment_requests/'). It is clear but does not explicitly distinguish this create tool from sibling payment-request operations like update, retrieve, or partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by 'Create payment request' and the endpoint, but no explicit guidance is given for when to choose this over sibling tools (e.g., list/update/retrieve). The idempotency note provides useful retry guidance, but not tool-selection context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payment_requests_partial_updateA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey write behavior, non-destructiveness, and idempotency. The description adds the PATCH method and the 'existing' qualifier, but it does not disclose deeper behavioral details such as whether omitted fields remain unchanged, authentication requirements, or side effects. There is no contradiction with 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the HTTP method and resource path. However, 'Partial update payment request' and 'Endpoint for partially updating an existing payment request' are redundant, and the opening metadata line partly repeats the annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a nested request body and no output schema, but the input schema and annotations are rich enough to support basic invocation. The description omits explicit guidance on PATCH semantics like 'only supplied fields are updated' and does not reference the full-update alternative, leaving some ambiguity for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description itself provides no parameter-level guidance, but the input schema covers most parameters: body fields have rich descriptions and idempotency_key has a detailed explanation. The undocumented 'id' is obvious from the path. Schema coverage is 67%, so the description does not need to carry the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('partially updating'), the resource ('payment request'), and the target state ('existing payment request'). It also includes the HTTP verb and path (PATCH /payment_requests/{id}/), which distinguishes it from create, retrieve, full update, and delete siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this endpoint when you need to partially update an existing payment request. It does not explicitly name alternatives or state when not to use it, but the 'partial update' language naturally separates it from the full-update sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_pay_items_destroyA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly states 'Permanently removes the record,' reinforcing the destructiveHint annotation. It does not contradict the annotations, but it adds little beyond what the annotations already signal and does not discuss effects on the parent payslip or other side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The text is short and front-loads the destructive warning and endpoint. There is some redundancy between 'Delete pay item' and 'Endpoint for deleting an existing pay item,' but overall the description is compact and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, well-annotated destructive endpoint, the description covers the operation, the resource, the route, and permanence. It does not explain cascade effects or what happens to the associated payslip totals, which prevents a perfect score, but the core calling context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%, but the endpoint template supplies meaning for `payslip_id` and `id`: the former identifies the parent payslip and the latter the pay item. The `idempotency_key` parameter is already well described in the schema itself, so the description adds partial but not complete parameter clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes'), a specific resource ('Pay Items'), and the exact endpoint path (`DELETE /payslips/{payslip_id}/pay-items/{id}/`). It clearly distinguishes this tool from sibling tools like `wafeq_payslips_destroy` or pay-item retrieve/create tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: it is for deleting an existing pay item. However, it gives no explicit guidance about when to prefer this tool over related alternatives, nor any when-not-to-use conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_line_items_createA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal non-idempotent and readOnlyHint=false, but the description adds meaningful behavioral context: calling twice creates two records, and idempotency_key (or server-generated UUID) makes retries safe. This is useful beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the WRITE marker and endpoint, but it contains redundancy: 'Create purchase order line item' is repeated as a heading and again in the sentence 'Endpoint for creating a new purchase order line item.' The idempotency note is valuable, but the duplicate-purpose lines could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a nested body and no output schema, the description is only moderately complete. It explains the endpoint and idempotency well, but it does not mention what happens on success, what response to expect, or that purchase_order_id must reference an existing purchase order. Required body fields are left entirely to the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, and the schema itself documents most body fields. The description adds some value by explaining idempotency_key behavior, but it does not clarify purchase_order_id or the overall body structure beyond what the schema already provides. This is adequate but not strongly compensating.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action and resource: 'Create purchase order line item' with the explicit POST endpoint. The verb 'create' and resource 'purchase order line item' distinguish it from sibling list/retrieve/update/destroy tools without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the endpoint and phrasing: this is the tool for adding a new line item to a purchase order. However, it does not explicitly contrast with sibling tools like update, list, or destroy, nor does it state when one should prefer another line-item operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_line_items_destroyA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this with the '🔴 DESTRUCTIVE' warning and 'Permanently removes the record.' That adds irreversibility context beyond the annotation flags. It does not contradict the idempotentHint or openWorldHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the danger signal and endpoint, but 'Delete quote line item' and 'Endpoint for deleting an existing quote line item' are redundant restatements. Combining these into one sentence would make the description tighter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete call with robust annotations and no output schema, the description gives the essential behavior and permanence. It remains incomplete in not describing when to use it versus the many other line-item destroy tools or what response or errors to expect after deletion.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%, but the endpoint template explicitly shows {quote_id} and {id} as the parent quote and line item identifiers, adding meaning that the bare schema property names lack. The only schema-described parameter, idempotency_key, already has a thorough schema description, so no additional detail is required there.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes'/'Delete') and object ('Quote Line Items'), and includes the endpoint template 'DELETE /quotes/{quote_id}/line-items/{id}/'. This makes the target resource unambiguous and distinguishes it from the many sibling line-item destroy tools such as bills, purchase orders, and credit notes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool instead of the many sibling destroy endpoints or what preconditions apply. The description only restates the operation ('delete an existing quote line item') without exclusions, alternatives, or contextual cues such as 'only for quote line items'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_units_of_measure_destroyA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds that the record is permanently removed, clarifying this is a hard delete rather than a soft-delete or deactivation. This is useful behavioral context beyond the structured annotations, and there is no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the destructive warning and endpoint, but it repeats the same idea in 'Delete unit of measure,' 'Endpoint for deleting an existing unit of measure,' and 'Permanently removes the record.' The permanence sentence is valuable; the duplicate phrasing is redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destroy operation with no output schema, the description, annotations, and schema together provide the essential facts: the resource, the endpoint, idempotency safety, and permanent removal. It lacks caveats about potential failures or business constraints, but those are not critical for a straightforward delete call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The idempotency_key parameter is thoroughly documented in the schema, and the endpoint path in the description makes it clear that id is the unit-of-measure identifier. However, the description itself adds little direct parameter-level explanation, and the required id parameter has no dedicated description in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action — deleting a Unit of Measure — and gives the exact endpoint DELETE /units-of-measure/{id}/. This differentiates it from sibling create, update, retrieve, and list tools, and no other destroy tool targets the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied: call this when you need to delete an existing unit of measure. However, the description provides no explicit when-not-to-use guidance, no alternative tools to consider, and no mention of prerequisites such as ensuring the unit is not referenced elsewhere.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true and readOnlyHint=false, and the description adds 'Permanently removes the record' plus a red DESTRUCTIVE warning, clarifying irreversibility and scope. It does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the destructive warning, but it repeats the same information three times ('deletes · Amortizations', 'Delete amortization', 'Endpoint for deleting an existing amortization'). The redundancy earns a middle score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destroy operation with two parameters and no output schema, the description conveys the essential facts: target resource, action, and permanent deletion. Annotations cover idempotency and destructiveness, so nothing critical is missing for invoking the tool safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents idempotency_key well but leaves id undescribed, and the description compensates only partially by showing 'DELETE /amortizations/{id}/', which identifies id as the amortization path parameter. The meaning of id as the amortization identifier is left to inference from the resource name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the action: 'Delete amortization' and 'Endpoint for deleting an existing amortization'. It names the resource (amortizations) and the HTTP verb (DELETE), so an agent can unambiguously distinguish it from retrieve, list, and end_early siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the basic use case explicit (delete an existing amortization) but provides no guidance about when to choose destroy over the closely related amortizations_end_early_create, nor does it mention any prerequisites or exclusions. Usage is implied rather than contrasted with alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_download_retrieveA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety bar is partially met by structured data. The description adds genuine value beyond this by disclosing the return format ('base64-encoded PDF bytes plus its size and content type') and reaffirming 'Nothing is modified.' This tells the agent exactly what to expect in the response and that the call is side-effect-free.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the most important signals (READ-ONLY, returns a PDF, Bills, endpoint). However, there is redundancy: 'Download bill PDF' and 'Endpoint for downloading a PDF of the bill' convey nearly identical information, and the READ-ONLY prefix duplicates the annotation. It could be tightened without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool, the description is essentially complete: it covers purpose, endpoint, return shape (base64 PDF bytes, size, content type), and side-effect guarantees, with annotations covering safety and idempotency. Minor omissions are error conditions (e.g., bill not found) and how to source a valid `id`, but neither is critical at this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. The endpoint template 'GET /bills/{id}/download/' implies that `id` is the bill's identifier used in the URL path, which adds meaning beyond the bare string schema. However, it doesn't state where to obtain the id (e.g., from wafeq_bills_list) or any format/validity constraints, leaving partial but not full compensation for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Download bill PDF' and 'Endpoint for downloading a PDF of the bill.' The header line ('Bills · GET /bills/{id}/download/') and the 'Bills' label clearly differentiate this from the many sibling *_download_retrieve tools (invoices, payslips, quotes, etc.), so an agent can tell them apart without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied but not explicit. The 'Bills' prefix and the endpoint /bills/{id}/download/ signal that this tool is for downloading bill PDFs, and the READ-ONLY marker plus 'Nothing is modified' imply a safe retrieval operation. However, the description never explicitly states when to use this over alternatives like wafeq_bills_retrieve or names the sibling download tools it should be preferred to.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_contacts_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds the explicitly irreversible nature with 'Permanently removes the record.' This goes beyond the annotations and gives the agent important context that the action cannot be undone. It does not mention cascading effects or response format, but the core behavioral disclosure is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the danger indicator, HTTP method, and resource, which is good. However, it repeats the same idea multiple times: 'deletes', 'Delete contact', and 'Endpoint for deleting an existing contact' all convey the same basic purpose. It could be tightened without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation, the description is largely complete: it identifies the resource, specifies the endpoint, confirms permanence, and the schema provides idempotency guidance. No output schema exists, but none is required for a delete operation. It could mention what happens on a non-existent ID or whether related data is affected, but this is not essential.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The required 'id' parameter has no description in the schema, but the endpoint path '/contacts/{id}/' and the phrase 'existing contact' make its meaning clear. The 'idempotency_key' parameter is already thoroughly documented in the schema. The description itself adds little parameter-level detail, but the available context is sufficient for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action ('deletes', 'Delete contact'), the resource ('Contacts'), and the endpoint ('DELETE /contacts/{id}/'). It is unambiguous about what the tool does and clearly differentiates from sibling contact tools like retrieve, update, or create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting an existing contact, but it does not explicitly discuss when to use it versus alternatives or mention any prerequisites or exclusions. The usage context is clear enough from the verb and resource, but no direct comparison to siblings is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_cost_centers_destroyA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the emphatic 'Permanently removes the record' and the destructive warning, which reinforces irreversibility. It does not reveal additional behavioral details such as cascading effects, auth requirements, or error conditions, but the annotation coverage lowers the burden and the description adds some value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the destructive warning and endpoint, but it contains redundancy: 'Delete cost center' and 'Endpoint for deleting an existing cost center' express the same idea. The first metadata line also somewhat duplicates the annotations. It is concise but could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward delete operation with one required parameter, the description covers the action, the target resource, and the permanent consequence. Annotations already supply idempotency and destructive hints. No output schema exists, but the description is adequate for an agent to invoke the endpoint correctly, though it does not mention return codes or behavior when the cost center is in use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema describes idempotency_key fully but leaves 'id' without any description, giving 50% schema coverage. The description compensates somewhat by showing 'DELETE /cost-centers/{id}/' and referring to 'an existing cost center,' making it clear that id is the path identifier of the record to delete. It does not explain the ID format beyond the schema's string type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('deletes', 'Delete cost center') and resource ('Cost Centers'), even embedding the HTTP endpoint 'DELETE /cost-centers/{id}/'. It unambiguously differentiates this destroy operation from sibling cost center tools like list, retrieve, update, create, and partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by saying 'Endpoint for deleting an existing cost center' and 'Permanently removes the record,' which implies the appropriate scenario for usage. However, it does not explicitly name alternatives or give when-not-to-use conditions relative to other cost center operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_line_items_createA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly warns 'Not idempotent — calling twice creates two records' and explains that passing idempotency_key makes retries safe, going beyond the idempotentHint=false annotation. It does not mention other side effects such as validation failures or response shape, so it stops short of a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is dense and front-loaded with the WRITE indicator, resource, and endpoint, but the description then repeats the same fact three times: 'Create credit note line item', 'Endpoint for creating a new credit note line item', and the opening line. The redundancy wastes tokens and makes the structure less crisp than it could be.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential mutation behavior and idempotency concern, and the schema handles required fields. However, with no output schema, the description does not mention what the endpoint returns, and it does not note prerequisites such as the credit note existing, making it adequate but not fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool description adds little parameter-level meaning beyond the schema; the idempotency_key advice essentially repeats the schema description. Schema coverage is 67% and the nested body fields are individually documented, so the agent can infer required inputs, but the body parameter's own schema description is confusingly about output augmentation and the tool description does not correct it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear WRITE label, names the exact resource 'Credit Note Line Items', and gives the POST endpoint '/credit-notes/{credit_note_id}/line-items/'. It unambiguously identifies this as the creation tool among the many line-item siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that this endpoint 'creates a new credit note line item', so an agent can clearly select it when adding a line item to a credit note. It does not explicitly contrast it with update/destroy/list alternatives, so guidance is clear but not fully exclusive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_custom_fields_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces and extends this by adding 'Permanently removes the record' to emphasize irreversibility, a red 🔴 DESTRUCTIVE warning banner, and the meaningful precondition about documents. No contradiction with annotations; the added context goes beyond what the structured fields convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a warning banner, but it is redundant: 'Delete custom field' and 'Endpoint for deleting an existing custom field' both restate what the banner already says. The unique content — the in-use precondition and permanence — earns its place, but roughly half the prose repeats the same idea.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with strong schema coverage (100%) and rich annotations (destructive, idempotent, open-world), the description covers the core purpose, the key precondition, and the permanence of the operation. The main gap is that failure behavior when the field is in use is not described, but nothing critical is missing for invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both id and idempotency_key already documented in detail (the idempotency key's header behavior and auto-generation are fully explained in the schema). The description adds only marginal parameter-relevant context by implying that only non-in-use custom field ids are valid targets.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes' / 'Delete custom field') and a specific resource ('Custom Fields' with the exact DELETE /custom-fields/{id}/ endpoint). This unambiguously distinguishes the tool from its custom_fields siblings (list, create, retrieve, update, partial_update), so an agent can identify it 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear precondition — 'The custom field must not be in use on any documents' — which tells the agent when deletion is even valid. However, it does not explicitly name alternatives or contrast with related tools such as wafeq_custom_fields_update for modifying an in-use field, leaving the when-to-use reasoning mostly implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_createA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag write and non-idempotent behavior, and the description reinforces this by stating 'Not idempotent — calling twice creates two records.' It adds explicit guidance on idempotency_key behavior, which is valuable beyond the annotations. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the write indicator, endpoint, and non-idempotency warning. It wastes minimal space and communicates key information efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with no output schema, the description covers the core action, endpoint, and idempotency. However, it doesn't mention required fields beyond what the schema states, and doesn't clarify the distinction between debit notes and credit notes, which could confuse an agent selecting among siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds little about parameter semantics, but the schema itself thoroughly covers each field. The description mentions idempotency_key behavior, which supplements the schema, but otherwise does not go beyond it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates a debit note via POST /debit-notes/, with a specific verb and resource. It doesn't explicitly distinguish from sibling tools like wafeq_credit_notes_create, but the resource name and endpoint make the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description identifies the endpoint and notes non-idempotency, guiding the agent to use idempotency_key for safe retries. It doesn't explicitly compare against alternatives, but the context of creating vs updating/retrieving debit notes is implied by the endpoint and resource.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the bar is lower. The description adds value beyond those flags by stating 'Permanently removes the record,' which clarifies this is a hard delete rather than a soft delete or reversible action. The idempotency_key schema description further explains retry-safe behavior, which aligns with idempotentHint=true.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The front-loaded banner line ('🔴 DESTRUCTIVE · deletes · Debit Notes · DELETE /debit-notes/{id}/') is an efficient, attention-grabbing summary. However, 'Delete debit note' and 'Endpoint for deleting an existing debit note' are near-duplicate restatements of the same idea, and the only unique behavioral detail (permanence) is buried at the end. Two of the four sentences are redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter, 1-required-parameter delete with no output schema, the combination of annotations, description, and schema covers what an agent needs: destructive and permanent nature, idempotency behavior, the endpoint, and the required id. It would be more complete with notes on failure preconditions (e.g., whether posted or linked debit notes can be deleted) or cascading effects on line items, but nothing essential to invoking the tool is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50%. The idempotency_key parameter is richly documented in the schema (header mapping, auto-generated UUID v4, retry-safety semantics), but the required 'id' parameter has no description in either the schema or the tool description. The id's meaning is self-evident from context, so the description need not elaborate, but it adds zero param-level value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('deletes'), the resource ('Debit Notes'), the exact endpoint ('DELETE /debit-notes/{id}/'), and the consequence ('Permanently removes the record'). This is unambiguous and clearly distinguishes the tool from siblings like wafeq_debit_notes_list, wafeq_debit_notes_update, and wafeq_debit_notes_partial_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied rather than explicit: the destructive banner and 'deletes' make it clear this is the tool for removing a debit note, and 'Permanently removes' warns against casual use. However, the description never names alternatives or states when not to use it (e.g., 'use update for reversible changes'), leaving the agent to infer the selection logic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_line_items_retrieveA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description's READ-ONLY and GET markers align with these but add no new behavioral context such as error cases, authentication needs, or response shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the safety badge and endpoint path. But 'Retrieve debit note line item' and 'Endpoint for retrieving a single debit note line item' are redundant, and the READ-ONLY badge repeats annotation data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval with two string parameters, the description plus annotations cover the essential selection and invocation needs. The lack of an output schema is not critical because the purpose makes the return value evident.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only exposes two string IDs with no descriptions, while the path template /debit-notes/{debit_note_id}/line-items/{id}/ clarifies the hierarchy and role of each parameter. However, the description does not explain how to obtain these IDs or what formats they expect.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Retrieve debit note line item' with an explicit GET path, so the verb and resource are unambiguous. The word 'single' distinguishes it from list, create, update, and destroy siblings for the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description positions this as the endpoint for retrieving one debit note line item, giving clear selection context. It does not explicitly name alternatives or state exclusions, but the 'single' qualifier implies it is not for listing or modifying.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_items_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description adds that the operation 'permanently removes the record' and labels it 'DESTRUCTIVE', clarifying irreversibility. It does not mention cascading effects or authorization, but the annotations already cover readOnly/destructive/idempotent traits, so the additional behavioral detail is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the endpoint and destructive marker, but it repeats the same idea multiple times ('Delete item', 'Endpoint for deleting an existing item'). The redundancy reduces the value of otherwise compact text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive action with no output schema, this is complete enough: it states the operation, endpoint, permanence, and the idempotency behavior is covered by the schema. Missing details such as consequences for related records are not critical at this level of complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents `idempotency_key` well, while `id` has no schema description; the description's DELETE /items/{id}/ path only implicitly conveys that `id` identifies the item to delete. This is adequate but not a rich parameter explanation, and the description adds no explicit parameter guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specific verb ('deletes'), resource ('Items'), and effect ('Permanently removes the record'), and includes the endpoint DELETE /items/{id}/. This distinguishes it from sibling item tools like retrieve/update/partial_update, which do not remove the record.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The intended usage is implied by 'Endpoint for deleting an existing item', which is sufficient for a simple destroy operation but does not discuss exclusions or fallback tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_retrieveA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the READ-ONLY label mostly repeats structured data. The description adds the GET endpoint pattern but no deeper behavioral context such as permissions, rate limits, errors, or response behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with a useful READ-ONLY and endpoint label. There is minor redundancy between 'Retrieve payslip' and 'Endpoint for retrieving a single payslip', but overall it is well-structured and not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter retrieve operation with safety annotations, the description is basically usable. However, it does not distinguish itself from wafeq_payslips_list or wafeq_payslips_download_retrieve, and with no output schema it leaves the response shape implicit. A bit more context would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the endpoint path /payslips/{id}/ adds meaning by showing that id is the path identifier of the payslip to retrieve. It still does not explain the id's format or where to find a valid id, but for a single self-evident required parameter this is minimally adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the verb 'Retrieve', the resource 'payslip', and the endpoint GET /payslips/{id}/, making clear it retrieves a single payslip. This distinguishes it from list, create, update, destroy, and download siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'retrieving a single payslip' gives clear context for when to use this tool: when one specific payslip is needed by ID. It does not explicitly name alternatives or when-not-to-use cases, but the intent is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_projects_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry destructiveHint=true and idempotentHint=true, and the description adds the explicit fact that the record is 'Permanently removed', which reinforces irreversibility. It identifies the affected resource and endpoint, adding modest context beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the destructive warning, but it repeats itself: 'Delete project' and 'Endpoint for deleting an existing project' convey the same fact as the leading 'deletes · Projects'. Some redundancy prevents a higher score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destroy operation, the description provides the resource, endpoint, required id, and permanent consequence, while the schema covers idempotency and annotations cover safety. It does not describe response behavior or side effects on linked records, but those are not essential to select and invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The idempotency_key parameter is fully explained in the schema, and the URL template '/projects/{id}/' clarifies that id is the project identifier. However, the required id property has no dedicated schema description and the description text itself adds no parameter-level detail, making this adequate but not strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description gives a precise action and resource: 'deletes · Projects · DELETE /projects/{id}/' and explicitly says 'Delete project' and 'Endpoint for deleting an existing project'. This clearly distinguishes it from the sibling project retrieve/update/list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: call this when an existing project must be deleted. However, it does not state conditions for use, consequences relative to alternatives, or when the update/partial_update siblings should be preferred, so the guidance is mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this by saying 'DESTRUCTIVE' and 'Permanently removes the record,' which adds the irreversibility dimension. It does not discuss cascading effects or failure conditions, but it does not contradict the annotations and gives adequate warning for the operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and opens with a clear DESTRUCTIVE warning, but it repeats the same idea several times: 'deletes · Purchase Orders', 'Delete purchase order', and 'Endpoint for deleting an existing purchase order.' Only 'Permanently removes the record' adds meaningful new information, so the text is somewhat redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with a destructive annotation, one required id parameter, and an idempotency_key already documented in the schema, the description covers the core invocation signals: what is deleted and that the deletion is permanent. It does not describe the response shape or side effects, but those are lower-risk gaps for this kind of endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The path template /purchase-orders/{id}/ adds context to the bare string id parameter by showing it is the purchase order identifier in the URL. The idempotency_key parameter is already well explained in the schema, so the description does not need to repeat it. Overall, the description adds modest but useful parameter context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is explicit and unambiguous: it names the resource (Purchase Orders), the verb (deletes), and the HTTP endpoint (DELETE /purchase-orders/{id}/). It clearly distinguishes this from sibling operations like create, update, retrieve, or list on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the intended use: call this tool when an existing purchase order must be permanently removed. However, it does not provide explicit when-not guidance or mention alternative operations such as partial_update or update, so an agent receives no direct routing help beyond the obvious deletion purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_download_retrieveA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description's 'READ-ONLY' and 'Nothing is modified' reinforce without contradicting. The description adds genuinely useful behavior beyond annotations by disclosing the return payload: base64-encoded PDF bytes plus size and content type — valuable since there is no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The leading summary line is well-structured and front-loaded, but the description is redundant: 'Download purchase order PDF' appears both in the header and in the body, and 'Endpoint for downloading a PDF of the purchase order' is a third restatement of the same idea. The final sentence about base64 PDF bytes is the only non-repetitive content and earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only download tool, the definition is nearly complete: safety traits are covered by annotations, the response format is described (base64 PDF bytes, size, content type), and the endpoint clarifies the operation. Minor gaps remain — the provenance of 'id' is only implied, and error behavior (e.g., nonexistent purchase order) is not mentioned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% — the schema only shows 'id' as a required string with no explanation. The description's endpoint template '/purchase-orders/{id}/download/' partially compensates by implying that 'id' is the purchase order identifier. However, it doesn't state where to obtain valid IDs (e.g., from the list/retrieve endpoints) or any format expectations. The tool only has one simple parameter, so the gap is limited in impact.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Download purchase order PDF' and 'Endpoint for downloading a PDF of the purchase order.' The HTTP endpoint 'GET /purchase-orders/{id}/download/' further pins down the operation. Among the many download_retrieve siblings (invoices, bills, payslips, quotes, etc.), this one is unambiguously differentiated by the resource name 'purchase orders'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied rather than explicit: the '🟢 READ-ONLY · returns a PDF' header signals that this tool is for PDF retrieval rather than JSON retrieval, which distinguishes it from wafeq_purchase_orders_retrieve. However, no alternative tools are named, and there is no explicit when-to-use versus when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_line_items_retrieveA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces the READ-ONLY/GET nature and shows the endpoint path. It adds no additional behavioral context such as authentication requirements, error behavior, or response characteristics, but it does not contradict 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, but 'Retrieve purchase order line item' and 'Endpoint for retrieving a single purchase order line item' are redundant restatements. The header line plus the repeated sentence could be merged without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval tool with two path parameters, the description and annotations provide enough information to call it correctly. It lacks explicit guidance about choosing this over sibling endpoints, but the 'single' qualifier and clear endpoint path make the primary calling intent clear despite no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides parameter names with no descriptions, so the endpoint path 'GET /purchase-orders/{purchase_order_id}/line-items/{id}/' adds meaning by showing that purchase_order_id identifies the parent purchase order and id identifies the specific line item. This compensates for the 0% schema description coverage, though it leaves value formats unspecified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'retrieve purchase order line item' and explicitly says 'single', which distinguishes it from list/create/update/destroy siblings. The endpoint path clarifies it targets one line item nested under a purchase order.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies it should be used when fetching a single purchase order line item by ID, but it never names sibling alternatives like the list endpoint or explains when not to use it. No explicit when-to-use or when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_createA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry idempotentHint=false and readOnlyHint=false, and the description is consistent with them. Beyond the flags, it adds concrete behavioral context: 'calling twice creates two records' and explains the retry-safety mechanism via idempotency_key or a server-generated UUID. This tells the agent what actually happens at the API level and how to mitigate it, which is valuable disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with the WRITE marker, resource, and endpoint in the first line and the critical non-idempotency warning placed prominently. Minor redundancy exists — 'Create quote' appears in the header line, as a standalone heading, and again as 'Endpoint for creating a new quote' — but the overall length is appropriate and every substantive point earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a complex nested body (line_items with ten sub-fields) and no output schema, the description covers the most important non-obvious behavior (non-idempotency and retry safety) but does not mention the response shape, whether the created quote is returned, or any validation prerequisites. The schema carries the field-level burden well, so this is adequate but with a visible gap around what the caller gets back.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all parameters and nested fields (contact, currency, line_items, quote_date, quote_number, and the rest). The description does not add new parameter meaning; its idempotency_key mention merely summarizes what the schema already states in detail about the X-Wafeq-Idempotency-Key header and automatic UUID generation. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Create quote', 'Endpoint for creating a new quote') and reinforces it with the `POST /quotes/` endpoint and the 'Quotes' resource marker. Within a large sibling set containing quote list/retrieve/update/destroy/download/invoice actions, this unambiguously identifies the create operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the core use case clear — you use this when creating a new quote — but it never explicitly routes away from alternatives such as wafeq_quotes_update, wafeq_quotes_invoice_create, or wafeq_quotes_line_items_create. The only direct usage guidance is about passing idempotency_key for safe retries, which is parameter-level rather than tool-selection guidance. Usage context 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.

• wafeq_quotes_invoice_createA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare non-idempotence, but the description adds concrete consequences: calling twice creates two records/invoices, and suggests passing an idempotency_key for safe retries. This is useful behavioral context beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is repetitive: 'Convert quote to invoice', 'This endpoint can be used to convert a quote to an invoice', and 'Creates a NEW invoice from the quote' all say the same thing. The non-idempotency warning is also stated twice, making the text longer than necessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool, the description provides enough to understand the operation and key retry risk. However, it is incomplete around the 'id' parameter semantics and the idempotency_key guidance is not backed by the schema, which could prevent an agent from invoking it exactly as described.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one undocumented 'id' parameter and 0% description coverage. The description implies via the endpoint path that 'id' is the quote ID, but it never explicitly states this or explains format/constraints. It also mentions idempotency_key, which is not present in the input schema, adding minor confusion.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'Convert quote to invoice' and 'Creates a NEW invoice from the quote', backed by the endpoint path POST /quotes/{id}/invoice/. This clearly differentiates from generic quote CRUD or invoice creation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: converting a quote into an invoice. It does not explicitly discuss alternatives or exclusions, but the intended use case is unambiguous enough for an agent to select it correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_line_items_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description only repeats 'READ-ONLY' and adds an HTTP/path detail; it doesn't disclose pagination behavior, error cases, permissions, or response format. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first line is compact and informative, but the description contains redundancy: 'List quote line items' and 'Endpoint for retrieving a list of quote line items' say the same thing. The trailing restatement adds no new information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only list operation, the necessary identifying information is present: resource, method, path, required quote_id, and pagination parameters. The lack of an output schema means the agent won't know the returned fields, but the description is otherwise adequate and annotations fill in the safety context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The endpoint pattern /quotes/{quote_id}/line-items/ reveals that quote_id is a path parameter, which is useful since the schema gives it no description. page and page_size are already described in the schema, so the description's added value is mainly for the required parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific operation ('List') on a specific resource ('quote line items') and gives the endpoint path. The verb and resource make it distinguishable from the create/retrieve/update/destroy sibling tools for quote line items.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving all line items belonging to a quote, but it never states when to choose it over wafeq_quotes_line_items_retrieve, wafeq_invoices_line_items_list, or similar siblings. No exclusions or alternative routing are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_revenue_recognitions_destroyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds value by explicitly warning '🔴 DESTRUCTIVE' and stating 'Permanently removes the record,' which communicates irreversibility. This does not contradict any annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the destructive warning and endpoint, but it is redundant: '🔴 DESTRUCTIVE · deletes', 'Delete revenue recognition', and 'Endpoint for deleting an existing revenue recognition' all convey nearly the same information. It is compact yet repetitive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with one required parameter, the description, schema, and annotations together are sufficient: the resource is identified, idempotency is documented in the schema, and permanence is stated. No output schema is present, but a delete operation's return value is not essential for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The required 'id' parameter has no schema description, but the endpoint path '/revenue-recognitions/{id}/' and the phrase 'existing revenue recognition' imply it is the resource identifier. The 'idempotency_key' parameter is already fully described in the schema, so the description does not need to repeat it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is explicit: it begins with '🔴 DESTRUCTIVE · deletes · Revenue Recognitions · DELETE /revenue-recognitions/{id}/' and further states 'Delete revenue recognition' and 'Permanently removes the record.' The verb, resource, endpoint, and hard-delete semantics are all clear, making it easy to distinguish from retrieve/update siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Endpoint for deleting an existing revenue recognition' implies the tool is meant for deleting a record that already exists, but it does not name alternatives, exclusion conditions, or when not to use it. Usage is implied rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the idempotentHint=false annotation, the description explains that 'calling twice creates two records' and explains how passing an idempotency_key makes retries safe. This adds useful practical behavior context without contradicting any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the WRITE badge, resource path, and purpose. There is mild redundancy between 'Create bank account' and 'Endpoint for creating a new bank account,' but the overall structure is efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with two parameters and detailed schema descriptions, the definition covers the key endpoint, write behavior, and non-idempotency caveat. It does not explain response shape or prerequisites, but no output schema exists and the annotations plus schema already supply most necessary context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the idempotency_key parameter is already thoroughly documented in the schema. The main description does not add meaningful information about the body parameters; it mostly restates idempotency behavior already covered by the parameter schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Create bank account' and 'Endpoint for creating a new bank account,' and the header specifies 'Bank Accounts · POST /bank-accounts/'. This clearly identifies both the operation and the resource, making it easy to distinguish from sibling bank-account tools like retrieve, update, or destroy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool ('creating a new bank account') but does not give explicit usage conditions or alternatives. It lacks guidance on when not to use it or when to prefer a different bank-account operation, though the WRITE marker and endpoint provide some contextual direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_ledger_transactions_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a write operation and non-idempotence, but the description adds the concrete consequence that 'calling twice creates two records' and explains how idempotency_key makes retries safe. This is valuable behavioral context beyond the boolean hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the HTTP method and endpoint. Minor redundancy exists between 'Create bank ledger transaction' and 'Endpoint for creating a new bank ledger transaction,' but the overall structure is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a write operation with a nested body schema and no output schema, the description covers the key invocation concerns: endpoint, side effects, and retry safety. The body requirements are adequately delegated to the input schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67%, and the schema already documents idempotency_key and the body fields. The description's idempotency_key guidance mostly restates the schema parameter description rather than adding new semantic meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the action 'creating' and the resource 'bank ledger transaction,' and front-loads the exact endpoint POST /bank-accounts/{bank_account_id}/ledger-transactions/. This clearly distinguishes it from sibling tools like statement_transactions_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when creating a bank ledger transaction, and the idempotency note provides practical guidance for retries. However, it does not explicitly contrast this tool with related alternatives such as statement_transactions_create or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_statement_transactions_retrieveA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method (GET) and the endpoint path, which is mild behavioral context, but it does not disclose response shape, error conditions, or any side effects. This is acceptable but not exceptional given the low-risk operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the key READ-ONLY and resource information. Slight redundancy exists between 'Retrieve bank statement transaction' and 'Endpoint for retrieving a single bank statement transaction,' but the overall structure is efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieve with two required path parameters and strong annotations, the description is nearly complete. The endpoint path and the word 'single' give the agent enough context to invoke it correctly. The only notable gap is not distinguishing statement transactions from the closely related ledger transactions sibling, but the tool name itself makes this reasonably clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema description coverage is 0%, the description's inclusion of the full URL template 'GET /bank-accounts/{bank_account_id}/statement-transactions/{id}/' clarifies that both parameters are path parameters and conveys their roles. This adds meaning beyond the bare schema, though it still does not explain value formats or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Retrieve bank statement transaction' and 'Endpoint for retrieving a single bank statement transaction.' The word 'single' distinguishes it from the list sibling, and the resource path specifies the exact object being retrieved. It is unambiguous and immediately actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the retrieve semantics and the word 'single,' but the description does not explicitly state when to choose this tool over alternatives such as the list endpoint or the ledger transactions retrieve endpoint. With a large sibling set, a brief when-to-use/when-not-to-use note would strengthen this dimension.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_cost_centers_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag this as a write operation (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds value beyond those flags by spelling out the concrete consequence ('calling twice creates two records') and explaining the idempotency_key retry-safety mechanism. There is no contradiction with 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The opening marker line ('🟡 WRITE · creates data · Cost Centers · POST /cost-centers/') is an efficient, front-loaded summary that conveys classification and endpoint in one glance. However, 'Create cost center' and 'Endpoint for creating a new cost center' redundantly restate the same idea, adding minor waste to an otherwise compact definition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with full schema coverage and annotations covering the safety profile, the description covers the most important behavioral detail — non-idempotency and retry safety. It does not describe the response format (no output schema exists) or auth requirements, but those gaps are minor for this straightforward POST endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 both parameters, including the idempotency_key header behavior and the required body fields. The description adds only a brief framing of idempotency_key for retry safety, which is helpful but largely redundant with the schema's detailed parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the exact operation (create), the resource (cost center), and the HTTP endpoint (POST /cost-centers/), making it clearly distinguishable from sibling cost center operations like list, retrieve, update, and destroy. The write classification and endpoint path add specificity beyond what the tool name alone conveys; it is not a mere tautology.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use case — creating a new cost center — and gives retry guidance via idempotency_key, but it never explicitly states when to create versus update an existing cost center or names any alternative. No exclusions or when-not-to-use conditions are provided, leaving the decision to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral context beyond the annotations: it explains the real-world consequence of idempotentHint=false ('calling twice creates two records') and gives the mitigation ('Pass idempotency_key ... to make a retry safe'). This frames the write behavior in terms an agent can act on, going beyond the raw hint flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the WRITE flag, resource type, and endpoint before the prose. The only waste is mild redundancy between 'Create credit note' and 'Endpoint for creating a new credit note', which say the same thing. Otherwise every sentence earns its place, especially the non-idempotency warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex create tool with nested line_items, a large currency enum, and a UAE-specific place_of_supply constraint, the schema covers the parameter details thoroughly. The description supplies the essential behavioral layer (write operation, non-idempotency, retry safety). There is no output schema, so return-value behavior is left unspecified, but the core of what an agent needs to call it correctly is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 both parameters and all nested body properties in detail. The description's mention of idempotency_key retry safety echoes what the schema's idempotency_key description already states, adding no new parameter-level meaning. Baseline 3 is appropriate since the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource — 'Create credit note' / 'Endpoint for creating a new credit note' — and reinforces it with the explicit endpoint 'POST /credit-notes/'. This makes the operation unambiguous and distinguishes it from sibling tools like wafeq_credit_notes_update, wafeq_credit_notes_destroy, and wafeq_credit_notes_retrieve without needing to open their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is only implied by the verb 'create' and the endpoint; there is no explicit guidance on when to choose this over alternatives (e.g., wafeq_credit_notes_update for modifying an existing note, wafeq_credit_notes_list for reading). With well over a hundred siblings, some routing guidance would help, but the create-vs-read/vs-update distinction is reasonably self-evident from the name and endpoint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_custom_fields_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by explicitly warning that the operation is not idempotent and that calling twice creates two records. It also explains how to use idempotency_key to make retries safe, which is valuable behavioral context beyond the readOnly and idempotent hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the WRITE signal, but it repeats itself: 'Create custom field' and 'Endpoint for creating a new custom field.' say essentially the same thing. The idempotency warning earns its place, but the redundant phrasing costs it a higher score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a complex config schema, the description is adequate but sparse: it does not mention response shape, error conditions, or what happens after successful creation. The annotations cover idempotency and write-safety, and the schema covers parameters, so this is still callable, but an agent lacks some operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the schema already thoroughly documents body parameters, the config oneOf structure, and idempotency_key semantics. The description adds no meaningful parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'creating a new custom field' via 'POST /custom-fields/'. It names the specific resource and verb, and this inherently distinguishes it from sibling custom field tools for listing, retrieving, updating, and deleting.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this endpoint when creating a new custom field. It does not explicitly mention alternatives such as update or retrieve, but the idempotency guidance adds practical usage context around retries and duplicate creation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_employees_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral detail beyond annotations: it explains that calling twice creates two records and that the idempotency_key makes retries safe. This goes beyond the boolean idempotentHint=false and is genuinely useful for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The opening badge and endpoint line are efficient, and the idempotency note is high-value. However, 'Create employee' and 'Endpoint for creating a new employee' are redundant, so the description is not maximally tight.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a write operation with a nested body and no output schema, the description covers key invocation context: the endpoint, the create semantics, and the non-idempotent behavior. Combined with the detailed schema, this is sufficient for an agent to call the tool correctly, though response/return behavior is not mentioned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents the required body and fields. The description emphasizes idempotency_key, but the schema provides the richer detail about automatic UUID generation and header usage, so the prose adds little new semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: it creates data for the Employees resource, and provides the exact endpoint POST /employees/. 'Create employee' unambiguously distinguishes it from sibling retrieve/update/destroy tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool is used when creating a new employee, but it does not explicitly compare against alternatives like wafeq_employees_update or wafeq_employees_retrieve, nor does it state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_mark_as_posted_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds useful context beyond these annotations: the state change affects ledger status, generates the expense's journal, and is reversible. No contradiction with the annotations was found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is repetitive: 'Posts a draft expense to the ledger (generates its journal)' and 'Generates the expense's journal and posts it to the ledger' say the same thing. The reversibility point is also stated twice. The header 'moves a document in or out of the ledger' adds ambiguity. A single clear paragraph would be more effective for such a simple one-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (one required parameter, no output schema) and the presence of annotations, the description covers the essential behavioral context: it posts a draft expense, generates a journal entry, and is reversible. The main gap is the lack of explicit id parameter semantics, but the endpoint path mitigates this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has only an 'id' string parameter with 0% description coverage. The description does not explicitly explain what 'id' refers to, though the endpoint '/expenses/{id}/mark-as-posted/' and the phrase 'Posts a draft expense' imply it is the expense identifier. This is helpful but not sufficient compensation for the lack of explicit parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'Mark expense as posted' and 'Posts a draft expense to the ledger.' It identifies the specific endpoint and distinguishes itself from the sibling tool by naming the opposite operation: 'Undo with `mark expense as draft`.' Despite the slightly ambiguous 'moves a document in or out of the ledger' header, the body resolves this by specifying the actual action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description communicates when to use the tool: when a draft expense needs to be posted to the ledger. It also gives an explicit alternative for the reverse operation: 'Undo with `mark expense as draft`.' However, it does not explicitly say 'do not use this for marking as draft' — the alternative is implied rather than stated as an exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_projects_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as non-read-only and non-idempotent, but the description adds valuable behavior: 'calling twice creates two records' and explains how idempotency_key prevents duplicate retries. This goes beyond the structured annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the key write signal and endpoint. There is minor redundancy between 'Create project' and 'Endpoint for creating a new project,' but the overall structure is efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With simple parameters, full schema coverage, and annotations covering write/idempotency hints, the description is largely complete for invoking the tool. It includes the essential non-idempotence warning, though it does not describe the response format or error behavior in the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters well. The description adds no significant parameter meaning beyond what the schema provides; the idempotency_key note slightly reinforces the schema's explanation but is not new information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the verb and resource: 'Create project' and 'Endpoint for creating a new project.' This clearly distinguishes it from the sibling project tools like wafeq_projects_retrieve, wafeq_projects_update, and wafeq_projects_destroy, which operate on existing projects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used when creating a new project, and the non-idempotence warning gives important usage context. However, it does not explicitly state when not to use it or name alternatives such as wafeq_projects_update for existing projects.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_line_items_destroyA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds concrete context by stating the record is 'permanently removed.' The prefixed '🔴 DESTRUCTIVE' warning and explicit deletion target go beyond the bare annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The phrase 'delete purchase order line item' appears in essentially three places: the prefixed summary line, the title-like sentence, and the endpoint sentence. Only 'Permanently removes the record' adds new information, making the description redundant despite being short.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter delete operation with strong annotations (destructive, idempotent) and a detailed idempotency-key schema description, the definition is nearly complete. It identifies the resource, the exact path, and the permanence of deletion; only a return-value note is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 33%, but the route template /purchase-orders/{purchase_order_id}/line-items/{id}/ clarifies that purchase_order_id is the parent PO and id is the line-item ID. The idempotency_key parameter is thoroughly described in the schema, and the path placeholders compensate for the undocumented required IDs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'deletes · Purchase Order Line Items' and provides the exact DELETE path. 'Permanently removes the record' makes clear this is a hard delete, and the resource scope distinguishes it from the many other destroy siblings in the tool list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied rather than explicitly guided: an agent should call this when it wants to delete an existing purchase order line item. There is no comparison to alternatives like the line-item update or partial_update tools, and no when-not-to-use guidance, so it is adequate but not strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_reports_cash_flow_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details beyond the schema: it emphasizes that date_after/date_before are both required, that there is no date_from/date_to, and that a whole-period rule is validated before sending.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The text is compact and front-loads the read-only tag and endpoint, but the standalone 'Cash Flow' heading duplicates the title and the emoji decoration adds little. The remaining sentences are purposeful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only report tool, the description plus fully documented schema covers required parameters, date-range rules, optional grouping, and filters. It is slightly incomplete in not spelling out the whole-period rule itself or what the returned report contains, but it is otherwise sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the baseline is 3, but the description adds extra meaning by calling out required range bounds and explicitly ruling out date_from/date_to. It also confirms how currency and group_by shape the report, which helps an agent select values correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('Generate') and resource ('cash flow report'), and names the exact endpoint GET /reports/cash-flow/. It is clearly distinct from sibling report tools like wafeq_reports_balance_sheet_list and wafeq_reports_profit_and_loss_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance about when to choose cash flow over the other report list tools. It only references the profit-and-loss rule for date handling, not a comparison of use cases or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_line_items_destroyA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide destructiveHint and idempotentHint, and the description adds the meaningful context that the operation 'permanently removes the record,' clarifying irreversibility. It also names the exact resource being destroyed. No mention of auth or rate limits, but the annotation coverage lowers the bar and the description does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly redundant: 'deletes', 'Delete simplified invoice line item', 'Endpoint for deleting an existing simplified invoice line item', and 'Permanently removes the record' all repeat essentially the same message. While the first line efficiently front-loads the key information, the subsequent sentences add little and do not earn their place, making the overall description less concise than it should be.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion tool with 3 parameters, no output schema, and annotations covering destructive and idempotent behavior, the description adequately covers what the tool does, the resource it targets, and the permanent effect. It omits potential business-rule caveats, but none are strongly indicated for this tool's low complexity, so it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%, so the description must compensate for the undocumented invoice_id and id parameters. It does this by including the endpoint template '/simplified-invoices/{invoice_id}/line-items/{id}/', which reveals that invoice_id identifies a simplified invoice and id identifies a line item. The idempotency_key parameter already has a thorough description in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'deletes · Simplified Invoice Line Items' and the endpoint 'DELETE /simplified-invoices/{invoice_id}/line-items/{id}/', giving a specific verb and resource. This clearly separates the tool from sibling update, retrieve, and list operations, and the repetition of 'Delete simplified invoice line item' reinforces the exact action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the destructive purpose clear through 'deletes' and 'Permanently removes the record,' so an agent can infer this tool is for removal. However, it never explicitly says when to choose this over alternatives such as wafeq_simplified_invoices_line_items_partial_update or destroys for other resources, and no exclusions or prerequisites are mentioned. Usage is implied rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_upload_fileA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-idempotent write, and the description enriches this with concrete consequences: 'calling twice creates two records' and the idempotency_key retry mechanism. It also discloses that the server builds the multipart/form-data body itself. This exceeds the annotation baseline without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the write indicator, resource, and endpoint before moving into behavioral and parameter guidance. Minor redundancy exists between 'Create file' and 'Endpoint for creating a new file', but overall every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a four-parameter tool with no output schema, the description covers the invocation essentials: required filename, either file_base64 or file_path, optional content_type, and non-idempotency behavior. It could mention the raw upload sibling or return value, but those are secondary for a correct call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds useful meaning about choosing between file_base64 and file_path and content_type being optional. However, it mentions passing an idempotency_key that is not present in the input schema, and it doesn't restate the WAFEQ_ALLOW_LOCAL_FILE_UPLOAD restriction on file_path, which keeps this at adequate rather than strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Endpoint for creating a new file' and 'Upload a file using multipart/form-data', with the resource and HTTP verb visible in the banner. It does not explicitly distinguish itself from the sibling tool wafeq_upload_file_raw, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: create a file, prefer file_base64 plus filename when content is already held, and use file_path for a file on the server machine. It doesn't mention wafeq_upload_file_raw or state when to choose this tool over that sibling alternative, which prevents a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_accounts_createA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description adds a valuable warning: 'Not idempotent — calling twice creates two records' and explains how to use idempotency_key for safe retries. This gives actionable behavioral context that is not present in the annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured. The header line conveys key metadata (write operation, resource, endpoint) at a glance, followed by a one-sentence purpose and a focused non-idempotency caveat. No unnecessary words exist.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward create operation with a nested body; all required field semantics are fully documented in the schema. The description covers the critical behavioral edge case (non-idempotency). The absence of an output schema means a small gap regarding the response format, but this is minor given that the created account can be retrieved via sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds a practical note about idempotency_key for retry safety, but does not elaborate on body fields beyond what the schema already provides. This is a modest increment over the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Create account' and 'Endpoint for creating a new account', with a clear verb and resource. The structured header 'POST /accounts/' and 'creates data' differentiate this from sibling operations like update, retrieve, or destroy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for creating a new account, which implies its primary use case. However, it does not explicitly mention alternatives like update or destroy, nor does it include exclusions or prerequisites. The usage is inferred from the purpose rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_end_early_createA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations' destructiveHint=true, the description adds concrete behavioral detail: there is no API undo, the remaining balance is posted to the ledger immediately, and the amount recognized is the whole remaining balance. It also front-loads an IRREVERSIBLE warning. This goes beyond what the structured annotations convey, though it could further describe the resulting schedule state or response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The most critical information (IRREVERSIBLE, ledger posting, endpoint) is front-loaded effectively. However, the core purpose is stated redundantly three times: 'End amortization early', 'Endpoint for terminating an amortization early', and 'Terminates a schedule early.' The first line's 'posts the remaining balance to the ledger' also repeats the later 'recognizes its whole remaining balance immediately.' Tighter editing would make this definition stronger.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive mutation tool with a nested body and no output schema, the description covers the critical unknowns: the accounting effect, irreversibility, and the preview-first workflow. The lack of response/return expectations is a minor gap, but the preview tool reference compensates by telling the agent where to get the exact posting details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With only 50% schema description coverage, the description partially compensates by clarifying the relationship between the amount and the 'whole remaining balance' and between the account and 'the provided account.' However, it does not systematically explain the id parameter or add format/value constraints beyond the schema, leaving the coverage gap only partially filled.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource: 'End amortization early', 'terminating an amortization early', and 'Terminates a schedule early and recognizes its whole remaining balance immediately.' It names the exact accounting effect (posting the remaining balance to the ledger) and distinguishes itself from sibling amortization tools (list, retrieve, destroy, preview) by describing the actual terminating/posting action rather than a preview or read.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs the agent to 'Run the matching `preview_...` tool first to see exactly what would be posted,' naming the alternative tool and the sequencing condition. The IRREVERSIBLE warning implicitly signals this tool should only be invoked after verification. It lacks an explicit statement of when NOT to use it, but the preview-first directive provides strong practical guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bills_line_items_createA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read, non-idempotent write operation. The description goes beyond that by explicitly stating that calling twice creates two records and explaining how the idempotency_key makes retries safe. This adds concrete behavioral safety context without contradicting any annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the endpoint, but it repeats itself: 'Create bill line item' and 'Endpoint for creating a new bill line item' say the same thing. The idempotency paragraph is valuable, but the opening could be trimmed without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a nested body object and no output schema, the description provides the essential endpoint, verb, and non-idempotency warning, while the schema covers parameter details. It does not explain why to choose this over update or list siblings, but the create-focused purpose and schema richness are largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents most parameters, including idempotency_key behavior, and the required body fields are clear. The description adds little beyond what the schema provides; the idempotency_key note is useful but largely duplicates the schema's own parameter description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly identifies the operation ('Create bill line item'), the resource ('Bill Line Items'), and the exact endpoint (POST /bills/{bill_id}/line-items/). This clearly separates it from other line-item tools for invoices, purchase orders, or credit notes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames the tool as the endpoint for creating a new bill line item, making the primary use case obvious. It does not name sibling update/retrieve/destroy tools as alternatives, but the create-vs-manage distinction is clear enough from the stated purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_download_retrieveA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation read-only, idempotent, and non-destructive, and the description reinforces this with 'Nothing is modified.' It adds useful behavioral detail beyond the annotations by specifying the response format: base64-encoded PDF bytes with size and content type.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The core information is presented early and the description is short, but it repeats the same point multiple times: the first header line, the sentence 'Download credit note PDF', and 'Endpoint for downloading a PDF of the credit note' all convey the same meaning. The unique return-format detail is helpful, but redundancy reduces efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description covers the essential aspects: what it does, the endpoint path, the response format, and the non-mutating nature. It is complete enough for an agent to call it correctly, though it could slightly improve by explicitly defining the 'id' parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only defines 'id' as a string with no description, and the description does not explicitly explain that 'id' is the credit note identifier. However, the endpoint path '/credit-notes/{id}/download/' and the tool name make the meaning inferable, so the description partially compensates for the 0% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('download'), resource ('credit note'), and output ('PDF'), and includes the exact endpoint path. This clearly distinguishes it from retrieval endpoints like wafeq_credit_notes_retrieve and from other document-download siblings such as wafeq_invoices_download_retrieve.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly signals that this tool is for downloading a PDF version of a credit note, which gives an agent the context needed to choose it when a PDF document is required. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_item_units_of_measure_destroyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the important behavioral detail that the record is 'permanently removed.' This goes beyond a generic destructive flag by clarifying irreversibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but repetitive: 'deletes', 'Delete item unit of measure', and 'Endpoint for deleting an existing item unit of measure' all say the same thing. The destructive indicator is front-loaded, but the redundancy could be reduced to a single clear sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion operation, the description, schema, and annotations together cover what the tool does, the required id, idempotency behavior, and permanence of the action. A response format is not described, but this is a low-complexity destroy endpoint where it is not critical for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description does not explain the parameters, but the endpoint pattern '/item-units-of-measure/{id}/' clarifies that 'id' is a path identifier. The idempotency_key is already richly documented in the schema, so the description adds only modest meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('deletes', 'Delete item unit of measure') and resource ('Item Unit Of Measures') with the exact endpoint. It clearly matches the tool name and can be distinguished from sibling retrieve/create/update/list operations on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is clear: call this tool when you need to permanently delete an item unit of measure. It does not explicitly name alternatives or exclusions, but the destructive framing and endpoint make the when-to-use context obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_journal_line_items_retrieveA
  4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds a valuable non-obvious behavioral warning: the record carries created_ts (write time), not a transaction date, and the transaction date lives on the parent journal via the journal field. This goes beyond the annotations and prevents a likely misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, scannable, and front-loaded with the READ-ONLY label, endpoint, and a clearly separated critical warning. It loses a point because 'Retrieve journal line item' and 'Endpoint for retrieving a single journal line item' are essentially redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only retrieval, the description gives the endpoint, scope, and a crucial caveat about date semantics. It does not describe the response shape or explicitly route to the list sibling, but the essential information needed to call it correctly is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only echoes the id in the URL path without explaining its format, origin, or constraints. The parameter is simple and self-evident from the schema, but the description does not compensate for the lack of schema-level documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action and resource: 'Retrieve journal line item' with the endpoint 'GET /journal-line-items/{id}/'. It explicitly says 'single journal line item', which distinguishes it from the list sibling and other line-item retrieve tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving one journal line item by id, but it does not explicitly state when to use this tool over alternatives, mention the list sibling, or provide any exclusion guidance. Usage is inferable but not directly instructed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_manual_journals_destroyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already set destructiveHint=true and readOnlyHint=false, but the description adds meaningful behavioral context by stating 'Permanently removes the record' and exposing the raw DELETE endpoint. This goes beyond the boolean hints and properly warns an agent that the deletion is irreversible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the destructive warning and endpoint, but it repeats the same idea several times: 'deletes', 'Delete manual journal', 'Endpoint for deleting', and 'Permanently removes the record.' The core message is clear, but the redundancy could be trimmed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with one required parameter, the description provides the essential context: the resource, the HTTP method, the endpoint pattern, and irreversibility. The idempotency behavior is covered by the schema, and no output schema exists, so nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description does not directly explain the 'id' parameter, though the endpoint path '/manual-journals/{id}/' makes its purpose clear. The 'idempotency_key' parameter is well documented in the schema, including its header mapping and automatic UUID generation, so the description does not need to compensate for that parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Delete manual journal') on a specific resource ('Manual Journals') and reinforces it with the HTTP endpoint 'DELETE /manual-journals/{id}/'. It also uses the explicit '🔴 DESTRUCTIVE' warning and 'Permanently removes the record,' making the destructive intent unmistakable and distinct from the sibling retrieve/update tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames the tool's context: it is for deleting an existing manual journal and only requires the journal's id. It does not explicitly name alternatives or when not to use it, but the destructive framing and endpoint make the intended use unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_quotes_download_retrieveA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by specifying the response format: base64-encoded PDF bytes, size, and content type, and confirms 'Nothing is modified.' Error behavior and authentication requirements are not mentioned, but the annotation coverage lowers the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but it is redundant: 'Download quote PDF' and 'Endpoint for downloading a PDF of the quote' convey the same information. The first summary line also partially repeats the endpoint and action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only download tool with rich annotations and no output schema, the description adequately covers response format and safe behavior. It does not mention failure cases or file size limits, but these are not essential for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only defines 'id' as a required string, and schema description coverage is 0%. The description compensates by placing id in the URL path template /quotes/{id}/download/, making it clear that id identifies the quote whose PDF should be downloaded.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Download quote PDF'), the resource (Quotes), and the endpoint (GET /quotes/{id}/download/). It also states the output is a PDF, which differentiates it from quote retrieval and other document-download sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It is clear this is for downloading a quote PDF, but it does not explicitly say when to use this tool versus alternatives such as wafeq_quotes_retrieve or the other download_retrieve endpoints. The 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.

• wafeq_warehouses_createA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal write and non-idempotent behavior (readOnlyHint=false, idempotentHint=false), and the description adds valuable context beyond them: calling twice creates two records, and idempotency_key (with server-generated UUID v4) makes retries safe. This consequence-level disclosure genuinely helps an agent reason about safe invocation. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with purpose, then behavior. Minor redundancy exists: '🟡 WRITE · creates data', 'Create warehouse', and 'Endpoint for creating a new warehouse' repeat the same idea three times. Still, each section earns its place overall, and the critical idempotency guidance is concise and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a rich 100%-covered schema and annotations, the description covers the core of what an agent needs: what is created, the endpoint, and non-idempotency behavior. However, there is no output schema and the description does not set expectations for the success response or error cases (e.g., duplicate unique code, validation failures), which would help an agent verify the outcome of the call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema carries the parameter-documentation burden. Every body field (name, address, city, district, code, etc.) has a description, and idempotency_key is richly explained including the X-Wafeq-Idempotency-Key header and auto-generation. The tool description itself adds no parameter-level detail, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('creates data · Warehouses', 'Create warehouse') plus the exact endpoint (POST /warehouses/). Among the warehouse sibling family (list, retrieve, update, destroy, partial_update), it is immediately distinguishable as the creation operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly establishes that this tool is for creating a new warehouse, so the use context is unambiguous. It stops short of explicitly naming alternatives (e.g., 'to modify an existing warehouse use wafeq_warehouses_update/partial_update'), but the resource-scoped create intent is clear enough for an agent to select it correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_preview_createA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the readOnlyHint annotation by explicitly explaining that this is a POST endpoint but a simulation, that it returns events that WOULD be generated, and that it 'writes nothing to the ledger.' This removes ambiguity around POST semantics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the key purpose and read-only nature. The emoji header slightly overlaps with the following sentences, but the additional note about the POST being a simulation adds useful non-obvious context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a preview/simulation tool, the description adequately conveys the behavior and return concept. It could be more complete by describing the response payload shape or clarifying the unusual top-level filter parameters, but the core call intent and safety profile are well covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 25%, and the description does not compensate by explaining any parameters beyond referring to 'the given schedule.' The nested body schema documents amount, dates, duration, and recognition_type, but the bare top-level filter parameters are left unexplained, and the description adds almost no parameter-level guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific action and resource: 'Preview amortization schedule' and 'previewing the amortization events that would be generated.' It clearly distinguishes this tool from an actual amortization creation by stating it does so 'without creating an amortization.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: when a preview or simulation of the amortization schedule is needed and no ledger write should happen. It implies the alternative is the real creation endpoint ('without creating an amortization'), though it does not explicitly name the sibling create tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_amortizations_preview_end_early_createA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuine value beyond these: it explains the method/semantics mismatch ('This is a POST, but Wafeq documents it as a simulation') and clarifies the side-effect profile ('writes nothing to the ledger'). This is useful context that annotations alone do not convey. It does not contradict 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the key discriminator ('READ-ONLY · preview / simulation'). There is minor redundancy: the title line 'Preview early termination' duplicates the header badge, and the endpoint line repeats the resource context. Overall, each paragraph earns its place, but the title repetition is unnecessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description adequately conveys return value ('remaining balance and the posted events that would be reversed') and the no-side-effect guarantee. The schema covers the nested body parameters. The main completeness gap is the absence of explicit routing to the actual-termination sibling, which would help agents choose the correct tool when the goal is to execute rather than preview.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50%: date and start_date have schema descriptions, but id has none. The description adds only marginal parameter meaning by referencing 'the given date,' and id semantics are merely implied through the endpoint path '/amortizations/{id}/'. It does not adequately compensate for the undocumented id parameter beyond what the path suggests.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'previewing the remaining balance and the posted events that would be reversed by terminating the amortization early.' The header line 'preview / simulation' and endpoint path 'preview-end-early' clearly distinguish it from the actual-termination sibling wafeq_amortizations_end_early_create and the creation-preview sibling wafeq_amortizations_preview_create. An agent can tell what this tool does 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it is a simulation that 'returns the events that WOULD be generated and writes nothing to the ledger,' signaling when to use it (when a non-committal preview is needed). However, it never explicitly names the alternative for actually executing the termination (wafeq_amortizations_end_early_create), so the when-not-to-use guidance is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_branches_createA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal readOnly=false and idempotent=false, and the description adds valuable practical context: calling twice creates two records, and idempotency_key can make a retry safe. This goes beyond the structured annotations by explaining the real consequence of non-idempotence. It does not contradict 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the write badge, resource, and endpoint. It has some redundancy ('Create branch' followed by 'Endpoint for creating a new branch'), but it is still compact and every major behavioral point is included without excessive verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the detailed input schema, the description adds the essential missing context: the operation is a non-idempotent create with retry guidance. There is no output schema, but this is a simple create endpoint and the key behavioral risk is disclosed. It is complete enough for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 tool description mentions idempotency_key in the context of retry safety, but the input schema already fully explains the header behavior, UUID generation, and how to use it. No additional parameter meaning is added beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create branch' and 'Endpoint for creating a new branch.' It also includes the HTTP method and path (POST /branches/), making the operation unmistakable. This clearly distinguishes it from branch update, retrieve, list, and destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the intended use clear: use this tool when creating a new branch. It does not explicitly name alternatives or say when not to use it, but the create-versus-update/destroy distinction is evident from the verb and endpoint. No misleading exclusions are present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_debit_notes_download_retrieveA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds value by describing the response shape: base64-encoded PDF bytes, size, and content type. The explicit statement 'Nothing is modified' reinforces the safe profile without contradicting 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the READ-ONLY label, resource, HTTP method, and endpoint. There is minor redundancy between 'Download debit note PDF' and 'Endpoint for downloading a PDF of the debit note,' but the extra return-value detail earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter, read-only download endpoint, the description is sufficiently complete: it names the resource, the endpoint, the required identifier, and the return format. No output schema exists, so the explicit description of base64-encoded PDF bytes plus size and content type is valuable. Error conditions and id-format details are absent but not critical here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not directly document the `id` parameter. However, the endpoint path '/debit-notes/{id}/download/' makes clear that `id` identifies the debit note to download, adding some meaning beyond the bare schema. With only one required parameter, this is adequate, though format and source of the id are not explained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Download debit note PDF'), names the resource ('Debit Notes'), and gives the exact endpoint GET /debit-notes/{id}/download/. This clearly separates it from sibling download tools for invoices, bills, payslips, and other documents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly establishes that this tool is for downloading a PDF of a debit note, which is the key context an agent needs to select it over wafeq_debit_notes_retrieve or other document endpoints. It does not explicitly name alternatives or state when not to use it, but the download purpose is unambiguous and no exclusions are needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_item_units_of_measure_createA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations' idempotentHint=false, the description explicitly warns that calling twice creates two records and explains how idempotency_key makes retries safe. It also flags the operation as WRITE/creates data, giving an agent a concrete behavioral model. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, with a useful header line containing the operation type and endpoint. However, 'Create item unit of measure' and 'Endpoint for creating a new item unit of measure' are redundant, so it is not perfectly polished.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create endpoint with a fully described schema and good annotations, the description provides the needed core context: what is created, via which endpoint, and how to handle retries safely. It does not describe relationships to existing items/units, but the schema fields cover the data contract.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents the body and idempotency_key thoroughly. The description's idempotency note restates what the idempotency_key parameter description already says, adding no new parameter semantics. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Create') and resource ('Item Unit Of Measures'), backed by the exact POST endpoint. This clearly differentiates the create operation from sibling list/retrieve/update/destroy tools on the same resource, even if it does not explicitly contrast with units_of_measure_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the tool's purpose obvious ('Endpoint for creating a new item unit of measure') but does not explicitly state when to choose it over alternatives or exclude other operations. The idempotency guidance is useful for retries, but it is parameter-level guidance rather than tool-selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_revenue_recognitions_preview_createA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses a subtle behavioral trait: despite being a POST, it is a simulation that 'returns the events that WOULD be generated and writes nothing to the ledger.' This preempts the natural confusion an agent would have about a POST being read-only, and states the no-side-effects guarantee explicitly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The structure is strong: a front-loaded badge line with the endpoint, a one-line summary, then a fuller explanation. However, the third and fourth paragraphs are somewhat redundant — both state that it previews events that 'WOULD be generated' without creating a recognition — so the description could be tightened by one sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The core behavior, side-effect safety, and required body input are adequately conveyed, but with no output schema the return shape is only vaguely hinted as 'events that WOULD be generated.' The unexplained top-level filter parameters and lack of distinction from the sibling wafeq_revenue_recognitions_preview_end_early_create leave moderate gaps for an agent deciding how to call this correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 25%, so the description carries a burden it does not meet — it contains zero parameter-level guidance. The required nested 'body' fields are mostly documented in the schema, but the top-level filter parameters (status__in, start_date_before, end_date_after, etc.) are undocumented and confusing for a preview endpoint; the description neither clarifies nor warns that they look like list filters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource combination ('previewing the revenue recognition events') and explicitly contrasts with actual creation ('without creating a revenue recognition', 'writes nothing to the ledger'). The leading '🟢 READ-ONLY · preview / simulation' badge plus the endpoint path immediately distinguishes this from sibling write tools like wafeq_revenue_recognitions_end_early_create and read tools like wafeq_revenue_recognitions_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys when to use the tool: when the agent wants to simulate what recognition events would be generated before committing. The repeated emphasis on 'simulation' and 'writes nothing to the ledger' implicitly tells the agent not to use this when actual ledger effects are desired, but it never names an explicit alternative tool or a when-not-to-use condition.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_credit_notes_tax_authority_report_createA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by stating the operation is IRREVERSIBLE, submits the document outside the organization to a tax authority, and cannot be recalled or undone through this API. It also advises user confirmation and content verification, which is critical behavioral context beyond destructiveHint=true.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The critical irreversibility warning is effectively front-loaded, but the description is redundant: 'Report credit note to tax authority' appears three times in slightly different forms. The overall length is acceptable, but not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive single-resource submission action, the description covers the essential operational context: external filing, irreversibility, user confirmation, and content checking. It omits post-submission behavior or expected response, but there is no output schema and the core requirements are well addressed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents idempotency_key in detail, but id has no schema description beyond 'string'. The description's endpoint 'POST /credit-notes/{id}/tax-authority/report/' implies id is the credit note ID, providing some compensation, but no additional parameter-level guidance or constraints are given.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Report') and resource ('credit note') and includes the explicit endpoint 'POST /credit-notes/{id}/tax-authority/report/'. It clearly distinguishes from sibling tax-authority report tools for invoices and simplified invoices by naming Credit Notes as the target document.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives actionable usage context: confirm with the user before calling and check the document's contents first. It doesn't explicitly contrast with sibling report tools, but the resource-specific endpoint makes the intended use obvious enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_tax_authority_report_createA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description strongly discloses that the action is IRREVERSIBLE, submits the document outside the organization, and cannot be recalled or undone through this API. This goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by explaining the real-world consequence and adding a confirm-with-user directive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The warning is effectively front-loaded with the emoji and 'IRREVERSIBLE' label, but the phrase 'Report invoice to tax authority' is repeated in slightly different forms across the description, adding redundancy. It is still readable and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter mutation tool with no output schema, the description covers the critical context: external submission, irreversibility, need for user confirmation, and the danger of the action. It does not discuss when to prefer this over sibling tools, but the resource-specific naming and endpoints make that a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%, with idempotency_key already well-documented in the schema. The description adds no explicit prose for the 'id' parameter, though the endpoint '/invoices/{id}/...' implies it is the invoice identifier. This is modest compensation but leaves the parameter semantics mostly to the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Report') and resource ('invoice'), and explicitly identifies the endpoint 'POST /invoices/{id}/tax-authority/report/'. The 'Invoices' marker distinguishes this from sibling tax-authority-report tools for credit notes and simplified invoices.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly instructs to 'Confirm with the user before calling' and to check the document's contents first, which is essential guidance for an irreversible external action. It does not explicitly name sibling alternatives, but the resource scope ('Invoices') and endpoint make the selection obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_manual_journals_createA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by explaining the concrete consequence of non-idempotency: 'calling twice creates two records.' It also tells the agent how to mitigate this with an idempotency_key, which is actionable behavioral context that the annotations alone do not provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, but it repeats the same core idea three times: '🟡 WRITE · creates data', 'Create manual journal', and 'Endpoint for creating a new manual journal.' The idempotency guidance is valuable, but the redundancy means not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description, combined with a highly detailed input schema, gives an agent enough to select and invoke the tool correctly. It lacks an explicit statement about what the response contains, but no output schema is provided and the core invocation details are covered elsewhere. The non-idempotency warning is important context that is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with detailed descriptions, including the nested body and idempotency_key semantics. The description adds only a brief reminder about idempotency safety, which is useful but largely redundant with the schema's own explanation. Baseline of 3 is appropriate because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create manual journal' with the exact endpoint 'POST /manual-journals/'. The '🟡 WRITE · creates data' prefix makes the operation type unmistakable, and the presence of sibling create/update/destroy tools for the same resource makes this unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly identifies the tool as the creation endpoint for manual journals, so the intended use is clear. It does not explicitly list alternatives such as update or partial_update, but the create-vs-modify distinction is strongly implied by the resource and action. It also adds practical guidance about idempotency for retries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_createA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation as non-idempotent, and the description goes further by explaining the consequence ('calling twice creates two records') and how idempotency_key makes retries safe. This adds useful operational context beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with a write indicator and endpoint, but it repeats the same idea three times: '🟡 WRITE · creates data · Payslips', 'Create payslip', and 'Endpoint for creating a new payslip'. The idempotency warning earns its place; the redundant 'Endpoint for...' sentence does not.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema thoroughly documents the nested body and its required fields, and the description adds the essential non-idempotency and retry-safety context. The lack of any description of the return payload is a minor gap given there is no output schema, but it does not prevent correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is met. The description adds meaningful semantics for idempotency_key by explaining the X-Wafeq-Idempotency-Key header, automatic UUID v4 generation, and retry safety. Body parameters are left to the schema, which is appropriate given their thorough descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource ('Create payslip', 'POST /payslips/') and clearly identifies the operation as creating a new payslip. This is immediately distinguishable from sibling retrieve, update, destroy, and partial_update operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly establishes that this endpoint is for creating a new payslip, giving an agent enough context to select it over the many payslip-related siblings. It does not explicitly list when-not-to-use alternatives, but the create-vs-modify distinction is implicit and unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_upload_file_rawA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by spelling out the concrete consequence of non-idempotency ('calling twice creates two records') and how to make retries safe via `idempotency_key`. It also reveals the Content-Disposition header requirement. This is useful behavioral context, though slightly undermined by the confusing raw-body vs base64 phrasing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the most important information, but it contains noticeable redundancy: 'Create file (advance)' appears twice, and the raw-body mechanism is explained twice. It is compact overall, but not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage routing, payload construction, required headers, and retry behavior, which is enough for an agent to invoke it correctly. No output schema exists, but the return value is not essential for correct invocation. The slight ambiguity between 'raw binary content' and 'file_base64' keeps it from a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters thoroughly. The description adds a useful selection heuristic ('Provide `file_base64` + `filename`, or `file_path`'), but it largely restates what the schema already communicates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action ('Create file in advance mode'), the resource ('Files'), and the technical mode ('sending raw binary file content directly in the request body'). It also explicitly differentiates from the sibling `wafeq_upload_file` by saying raw mode is the distinguishing factor.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells the agent to prefer `upload_file` unless raw mode is specifically needed, which is clear routing guidance relative to the sibling. It also states the payload requirement (`file_base64` + `filename`, or `file_path`) and the Content-Disposition header requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_bank_accounts_statement_transactions_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description goes further by explicitly stating 'Not idempotent — calling twice creates two records' and explaining that the server can generate an idempotency key to make retries safe. This adds meaningful behavioral detail beyond the annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the endpoint, write semantics, and idempotency warning. However, 'Create bank statement transaction' and 'Endpoint for creating a new bank statement transaction' are redundant, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with no output schema, the description provides the essential invocation context: endpoint, resource type, write behavior, non-idempotence, and idempotency-key usage. The input schema covers required fields. It does not describe the return value or compare against ledger_transactions_create, but the overall definition is complete enough for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%, and the schema already documents idempotency_key, amount, statement_balance, and other body fields in detail. The tool description adds only a brief restatement of idempotency behavior and does not clarify bank_account_id or the nested body structure beyond what the schema provides. This meets the baseline but adds limited semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Create bank statement transaction' and the endpoint POST /bank-accounts/{bank_account_id}/statement-transactions/. This clearly distinguishes it from sibling list/retrieve/update/destroy tools for the same resource, and from the separate ledger-transactions create sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames when to use the tool: to create a new bank statement transaction. It also provides practical guidance on idempotency — explaining that duplicate calls create duplicate records and that idempotency_key should be passed for safe retries. It does not explicitly name alternatives or exclusion criteria, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_beneficiaries_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses important behavioral details: the operation is a write, it is not idempotent, calling twice creates two records, and passing an idempotency_key makes retries safe. This adds practical operational context that annotations alone do not fully convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the WRITE indicator and endpoint, and includes essential idempotency guidance. There is minor redundancy between 'Create beneficiary' and 'Endpoint for creating a new beneficiary,' but it remains appropriately sized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Together with the fully documented input schema, the description covers what the tool does, its side effects, and idempotency handling, which is sufficient for an agent to invoke it correctly. It does not describe the response shape, but no output schema is provided and a create operation's return value is generally implied.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents the body fields and the idempotency_key parameter. The description adds no new parameter-level meaning, though it does reinforce the idempotency_key usage guidance already present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Create beneficiary' and 'Endpoint for creating a new beneficiary,' clearly identifying the verb, resource, and action. It is easily distinguished from sibling tools like wafeq_beneficiaries_update and wafeq_beneficiaries_destroy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is clear: create a new beneficiary rather than updating or listing existing ones. It does not explicitly name alternatives or list exclusions, but the 'new beneficiary' language and the POST endpoint provide enough context for an agent to select this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_contacts_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate write/non-idempotent/non-destructive behavior, and the description adds valuable detail: calling twice creates two records, idempotency_key is sent as X-Wafeq-Idempotency-Key, and an auto-generated UUID protects retries. This goes beyond the structured annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The header line is a compact summary, and the idempotency note is essential and well placed. There is minor redundancy between 'Create contact' and 'Endpoint for creating a new contact', but overall the description is tight and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a rich body schema, clear annotations, and a well-explained idempotency mechanism, the description is sufficient for correct invocation. It does not describe return values, but no output schema exists and the endpoint/fields are fully specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema fully documents the body fields and idempotency_key. The description reinforces idempotency_key usage but does not add significant semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'creating a new contact' and 'POST /contacts/'. This distinguishes it from sibling tools like wafeq_contacts_update, wafeq_contacts_list, and wafeq_contacts_destroy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is explicit: use this tool to create a new contact rather than to retrieve, update, list, or delete one. It does not name alternatives explicitly, but the create-vs-alternative context is unambiguous from the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_expenses_mark_as_draft_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, it discloses the material side effect: the expense's journal is removed from the ledger, and it states the operation is reversible. This is exactly the kind of behavioral context an agent needs for a state-change tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The content is front-loaded with the action and endpoint, but the same fact—removes journal and returns to draft—is repeated three times. It should have been a single sentence plus the reversal note, so the redundancy hurts the score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter state-change tool with annotations, the description covers the action, the ledger side effect, reversibility, and the inverse tool. Minor gaps (e.g., explicit id format or behavior if already draft) do not prevent correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema has no property descriptions, the endpoint pattern /expenses/{id}/mark-as-draft/ and the repeated 'expense' context make clear the only parameter is the expense identifier. For a single obvious id parameter, the description sufficiently compensates for the 0% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the specific action ('Moves a posted expense back to draft') and identifies the resource and endpoint, and the phrase 'Undo with mark expense as posted' distinguishes it from the sibling posting tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly signals the intended use case: a posted expense should be returned to draft, and it explicitly names the inverse operation. It doesn't list formal exclusions, but no real ambiguity exists for such a targeted status-change tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_purchase_orders_createA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description goes beyond annotations by explicitly stating 'Not idempotent — calling twice creates two records' and explaining the idempotency_key header mechanism. This adds meaningful behavioral context about retry safety and duplicate creation. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the emoji marker, action type, endpoint, and one-line summary appear first. The idempotency clarification follows as important behavioral context. It is slightly redundant with the title and annotations ('write', 'creates data'), but the endpoint and idempotency notes earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex creation tool with nested objects and no output schema. The description covers the essential creation semantics and idempotency behavior, which are the most critical operational concerns. It does not describe required fields (currency, line_items) or response format, but those are adequately documented in the input schema, and the annotations cover the write intent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all parameters and nested line_items fields. The description adds value by explaining the idempotency_key parameter's behavior beyond the schema, including the header name and the automatic UUID v4 generation, which is genuinely useful for an agent deciding whether to pass it. The description also confirms the body's role as the purchase order payload.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('creates data'), resource ('Purchase Orders'), and endpoint (POST /purchase-orders/). It explicitly differentiates this creation tool from siblings like wafeq_purchase_orders_update, wafeq_purchase_orders_line_items_create, and wafeq_purchase_orders_bill_create by focusing on creating a top-level purchase order.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description identifies this as the endpoint for creating a new purchase order, which implies the primary use case, but does not explicitly contrast with wafeq_purchase_orders_bill_create or wafeq_purchase_orders_line_items_create. It does provide guidance on idempotency usage for retries, which helps an agent decide how to safely invoke the tool. Missing explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_reports_profit_and_loss_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that by stating the server validates the date range before sending and tells the caller the nearest valid range. This helps the agent anticipate error handling without contradicting 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured with the operation front-loaded, followed by key parameter constraints. The 'Profit and Loss' line is somewhat redundant with the resource name, but the rest of the explanation earns its place and avoids unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich annotations and fully described schema, the description covers the critical non-obvious behavior: date-range validation, period alignment, and the group_by interaction. It does not describe the response format, but for a report generation tool the purpose and constraints are sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing descriptions for all parameters. The description adds extra meaning by clarifying that date_after/date_before are required range bounds, that date_from/date_to do not exist, and that the range must align with whole periods depending on group_by. This is valuable interaction-level semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Generate profit and loss report' and identifies the endpoint 'GET /reports/profit-and-loss/'. This clearly distinguishes it from sibling report tools such as balance sheet, cash flow, and trial balance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage context, including required date range bounds, the absence of date_from/date_to, and the rule that partial periods are rejected with group_by=year. It also advises using group_by=month for year-to-date figures. It does not explicitly name alternative report tools, so it falls just short of full alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_revenue_recognitions_preview_end_early_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint/idempotentHint/destructiveHint, and the description complements them by explaining the semantic oddity of a POST that performs no writes. It explicitly states it returns the events that WOULD be generated and writes nothing to the ledger, which is exactly the kind of behavioral context an agent needs. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Front-loaded with a READ-ONLY/preview/simulation badge and endpoint, followed by a short explanation and a clarifying note about the POST semantics. Each sentence adds useful signal, though 'Preview early termination' duplicates the annotations/title slightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only preview with no output schema, the description covers what the agent needs: it previews the remaining balance, shows events that would be reversed, and does not mutate state. It does not detail the exact response shape, but the conceptual return is described well enough for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents `body`, `date`, and `start_date`, and the endpoint path in the description implies `id` is the revenue recognition identifier. The description adds little parameter-level meaning beyond tying the date to the early termination. With 50% coverage, the missing `id` is trivially inferable, so this is adequate but not enriched.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: previewing early termination of a revenue recognition, and describes what it returns (remaining balance and posted events that would be reversed). The 'preview / simulation' label and the explicit 'writes nothing to the ledger' distinguish it from the actual end-early sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description sets clear context: this is a read-only simulation for previewing the effects of terminating a revenue recognition early. It does not explicitly name `end_early_create` as the alternative or state when not to use it, so it falls short of fully explicit routing. Still, the simulation/writes-nothing framing makes the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_line_items_createA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly discloses that the operation is not idempotent, explains the consequence of calling twice, and gives actionable retry guidance with idempotency_key. This goes well beyond the annotations, which only state idempotentHint=false, by explaining why and how to mitigate it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the resource, endpoint, and write-status. There is minor redundancy between 'Create simplified invoice line item' and 'Endpoint for creating a new simplified invoice line item', but the overall structure is tight and every other sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core creation purpose, the non-idempotent behavior, and the retry-safety mechanism. The schema handles the body fields, and no output schema exists, so return-value details are not expected. It is slightly incomplete in not clarifying the distinction between simplified and regular invoices, but this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents most body fields well, so the description's added value is its clear guidance on idempotency_key: pass it for safe retries or let the server generate one. This is meaningful parameter-level context beyond the raw schema. The invoice_id parameter is not described, but its role is obvious from the endpoint path and tool name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create simplified invoice line item' and includes the exact POST endpoint. It is unambiguous and distinguishes this tool from the many sibling line-item creation tools by naming the 'simplified invoice' resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this tool is for creating simplified invoice line items, but it does not explicitly state when to use it over alternatives such as wafeq_invoices_line_items_create. There are no exclusions or alternative tool references, so the usage guidance is present but implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payslips_download_retrieveA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Nothing is modified.' It goes beyond annotations by specifying the return shape: base64-encoded PDF bytes, size, and content type. It does not discuss auth or rate limits, but those are not necessary for a straightforward read-only download.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, front-loaded with a keyword summary, and puts the return behavior last. The middle sentence 'Endpoint for downloading a PDF of the payslip' is redundant with the first line and title, preventing a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only PDF download with no output schema, the description is complete: it states the resource, endpoint, required id, return format, and non-mutating behavior. An agent has everything needed to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has a single string `id` with no description and 0% coverage, but the endpoint line 'GET /payslips/{id}/download/' supplies the missing semantics: `id` is the payslip identifier and is used as a URL path parameter. It could be more explicit about the id's source/format, but the meaning is recoverable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource ('Download payslip PDF'), states the REST endpoint, and specifies the response is a PDF. This distinguishes it from sibling payslip operations like wafeq_payslips_retrieve, update, and destroy, and from other PDF download endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The endpoint and 'Download payslip PDF' make it clear when to use the tool: whenever the PDF version of a payslip is needed. It does not explicitly contrast with wafeq_payslips_retrieve or state when not to use it, but the context is clear and the lack of exclusions is minor for such a specialized endpoint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_download_retrieveA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations. It discloses the exact response format ('base64-encoded PDF bytes plus its size and content type'), explicitly states 'Nothing is modified,' and reveals the HTTP method (GET). This complements the readOnlyHint, idempotentHint, and destructiveHint annotations with concrete behavioral details the agent needs to understand the call's effect and output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the key facts in a summary line (READ-ONLY, returns a PDF, resource, endpoint). It is slightly redundant, repeating 'Download simplified invoice PDF' and 'Endpoint for downloading a PDF of the simplified invoice,' but the overall structure is clear and beats verbose alternatives.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter download tool, the description is complete. It tells the agent the endpoint, the resource, the required id, the response format, and that nothing is modified. Annotations cover safety traits, and the input schema covers the required parameter. No critical information is missing for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required `id` parameter with 0% schema description coverage, so the description must compensate. It partially does by showing the URL template `/simplified-invoices/{id}/download/`, which implies `id` is the simplified invoice identifier. However, it never explicitly defines `id` or its format, leaving the agent to infer the parameter's meaning from the endpoint rather than from a direct description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Download simplified invoice PDF' and 'Endpoint for downloading a PDF of the simplified invoice.' It identifies the specific verb (download), the resource (simplified invoice PDF), and even includes the exact endpoint path. It distinguishes itself from sibling download tools (e.g., invoices, bills, quotes) by explicitly naming 'Simplified Invoices' as the resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it obvious when to use this tool: when a PDF of a simplified invoice is needed. It provides clear context by labeling the resource 'Simplified Invoices' and showing the GET endpoint, which implicitly separates it from other download_retrieve siblings. However, it does not explicitly mention alternatives or state when not to use it, so it stops short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_items_createA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the operation is a non-idempotent write, explains the effect of calling twice, and documents the idempotency_key behavior and auto-generated UUID. Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description adds meaningful behavioral context beyond those flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the endpoint, resource, and safety warning. The line breaks and emojis make it scannable, though the '🟡 WRITE' prefix and 'Create item' title add a bit of redundancy with the annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the key behavioral concern (non-idempotency and retry safety) and confirms the endpoint. There is no output schema, but for a create endpoint the response is reasonably inferable; it could mention that a created item object is returned, but this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides detailed descriptions for all parameters (100% coverage), including nested units of measure and idempotency_key header behavior. The description adds value by explicitly mentioning idempotency_key and the automatic retry safety mechanism, but most parameter semantics are already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates data via POST /items/, specifies the resource (Items), and identifies it as a write operation. The title 'Create item' and the explicit 'creates data · Items · POST /items/' line distinguish it from retrieval, update, and destroy siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states this is the endpoint for creating a new item and explicitly warns it is not idempotent, advising use of idempotency_key for safe retries. It doesn't explicitly name alternative tools for creating items (e.g., why not use item_units_of_measure_create), but the resource and action are unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_payments_download_retrieveA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it read-only/idempotent, and the description adds concrete behavioral detail: the response is base64-encoded PDF bytes plus size and content type, and 'Nothing is modified.' This goes beyond the structured hints and gives the agent a realistic picture of side effects and return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Key facts (read-only, PDF, resource, endpoint) are front-loaded in the first line. However, 'Download payment PDF' and 'Endpoint for downloading a PDF of the payment' restate the same idea, so not every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only download tool, the definition covers purpose, endpoint, safety, and response shape, so an agent has enough to select and invoke it correctly. No output schema exists, so the explicit mention of base64-encoded content, size, and content type fills that gap. The lack of explicit routing to sibling alternatives is minor given the clear resource path.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter 'id' has no schema description (0% coverage), but the path template GET /payments/{id}/download/ and 'payment PDF' make it clear id refers to the payment identifier. The description compensates for the schema gap by grounding the parameter in the resource context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States an explicit verb ('Download'), a specific resource ('payment PDF'), and the exact endpoint path. The 'Payments' qualifier distinguishes it from sibling download tools for payslips, invoices, bills, etc. No ambiguity about what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes clear it is the endpoint for obtaining a payment's PDF via GET /payments/{id}/download/, so an agent can route payment-PDF requests here. It does not explicitly name alternatives or exclusions, but the resource-specific context is sufficient for selection among the sibling download tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_reports_trial_balance_listA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral disclosures: dates are optional and default to the current financial year, misspelled query parameters are silently ignored, and the behavior was verified on a specific date. This goes well beyond what annotations alone convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear READ-ONLY label, endpoint, and a focused parameter note. There is minor redundancy with the title 'Trial Balance' appearing both as a header and in the first sentence, but the overall length is appropriate and the critical warning is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 100% schema coverage, no required parameters, and annotations already describing the safety profile, the description is nearly complete. It covers the important parameter pitfalls and default behavior. The only minor gap is that there is no output schema and the description does not describe the response shape, but for a report tool this is not a critical omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all 8 parameters, so the baseline is 3. The description adds meaningful semantic value by clarifying that from_date/to_date are optional and control the report period, that omission returns the current financial year, and that alternate common parameter names should not be used. This goes beyond the schema's descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Generate trial balance report'), the exact resource ('GET /reports/trial-balance/'), and the key inputs (from_date, to_date, with_pnl_openings, include_zero_balances). It also identifies the report type as 'Trial Balance', which distinguishes it from sibling report tools like balance_sheet, cash_flow, and profit_and_loss.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives excellent usage context: it specifies the correct parameter names, explicitly warns against alternative date parameter names, and explains the default behavior when dates are omitted. It does not explicitly say when to prefer this tool over other report tools, but it provides enough context for correct invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_revenue_recognitions_end_early_createA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint annotation, the description adds critical behavior: posting to the ledger, irreversibility, no API undo, and whole remaining balance recognition. This gives the agent a full safety picture before invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the irreversible warning, and every sentence contributes either safety context, endpoint clarification, or a preview recommendation. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive, irreversible action with no output schema, the description provides the essential context: what the tool does, the ledger impact, the absence of undo, and the required preview step. Combined with the schema, an agent has enough to invoke it correctly and safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents amount, end_early_date, end_early_account, notes, and start_date. The description adds context by mentioning the 'provided account' and 'remaining balance', but it doesn't fully compensate for the remaining 50% schema coverage gap, especially around id and the body object semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: it terminates a revenue recognition early and recognizes the remaining balance immediately. This clearly distinguishes it from the preview sibling tool by framing it as the actual posting action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent to run the matching preview_... tool first to see what would be posted, which is strong usage guidance. It also warns that there is no API undo. It doesn't enumerate every alternative or exclusion, but the preview-before-execute instruction is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_invoices_download_retrieveA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already establish read-only, idempotent, non-destructive behavior, and the description reinforces this with 'Nothing is modified.' It also adds valuable detail about the response: base64-encoded PDF bytes, size, and content type, which goes beyond structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with safety and format signals. There is some redundancy ('Download invoice PDF' appears in the title, first line, and endpoint sentence), but it remains compact and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only download tool, the description covers everything essential: what it does, how the resource is identified, what the response contains, and that no data is modified. No output schema exists, so the explicit return-format detail is especially valuable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only defines a bare string `id` with zero description coverage, but the endpoint path /invoices/{id}/download/ and the phrase 'Download invoice PDF' make it clear that `id` is the invoice identifier. This gives the parameter enough meaning for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: downloading invoice PDFs, reinforced by the explicit endpoint GET /invoices/{id}/download/. It clearly separates this from other invoice operations and from similar download tools for other document types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It conveys a clear purpose: use this endpoint when you need a PDF of a specific invoice. It does not explicitly name alternatives like wafeq_invoices_retrieve for JSON retrieval, nor does it state when not to use it, but the usage context is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_simplified_invoices_tax_authority_report_createA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and non-idempotent, but the description adds meaningful context beyond those hints: the action is irreversible, the document is submitted outside the organization, it cannot be recalled or undone through this API, and user confirmation plus content review are required before invoking. This is exactly the kind of behavioral disclosure an agent needs for a consequential external filing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The most important information—irreversibility, external filing, and the endpoint—is front-loaded in a compact first line. However, 'Report the simplified invoice to the tax authority for processing and validation' largely repeats the first line, so not every sentence earns its place. Overall length is still reasonable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description fully covers what the operation does, where it submits the document, the irreversible consequences, and the required user-safety precautions. There is no output schema, but for a destructive external-filing action, the consequences and prerequisites matter more than return-value details, and those are thoroughly disclosed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents `idempotency_key` thoroughly, and the description's endpoint line ties the bare `id` parameter to a simplified-invoice document, adding meaning the schema's plain `string` type does not provide. With only 50% schema coverage, the description partially compensates for the undocumented `id`, though it could still be more explicit about required id semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs like 'files' and 'Report' and names the exact resource: a simplified invoice being submitted to an external tax authority. It also includes the precise endpoint `POST /simplified-invoices/{id}/tax-authority/report/`, making it clearly distinguishable from sibling tax-authority report tools for regular invoices and credit notes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use the tool: to report a simplified invoice for external tax processing and validation. It also provides an important prerequisite—confirm with the user and check the document's contents before calling. It does not explicitly mention sibling alternatives or exclusions, so it falls just 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.

• wafeq_journal_line_items_listA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses behavioral traits well beyond the annotations: rows carry no transaction-date field, created_ts is write-time only and frequently falls in a different month, and the endpoint is cursor-paginated unlike the rest of the API. These are high-value facts an agent cannot infer from readOnlyHint, openWorldHint, or idempotentHint. The READ-ONLY marker is consistent with readOnlyHint=true, so no contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the endpoint header and the critical NO DATE FIELD caveat before any optional detail. Minor redundancy: 'List journal line items' appears twice within the body and is repeated as the title, so one sentence could be dropped without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 16-parameter, no-output-schema list endpoint, it covers the two riskiest invocation details — date semantics and pagination style — and routes to the correct sibling for dated data. It leaves unspecified how multiple filters combine and what the response shape is, but the schema already documents each filter and no output schema exists to elaborate, so the description is complete enough for safe selection and correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, setting the baseline at 3, and the description adds meaning above that baseline by clarifying that date_after/date_before operate on the real transaction date while created_ts/modified_ts are write-time stamps, and that cursor+page_size are the pagination pair. This prevents the agent from treating the schema's terse 'Date' entries as interchangeable with timestamp filters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource — 'List journal line items' — backed by the explicit API path GET /journal-line-items/ and a READ-ONLY marker. It differentiates from siblings by naming wafeq_account_ledger as the alternative for rows that carry their date, so an agent can tell this list endpoint apart without opening other schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit when-to guidance: 'To work by transaction date, filter with date_after/date_before, which DO operate on the real transaction date.' It also names an exclusion condition and alternative ('For rows that come back already carrying their date, use the wafeq_account_ledger tool instead') and warns against a misuse pattern (reporting created_ts as the transaction date).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_account_ledgerA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark the operation as read-only and idempotent, and the description adds non-obvious behavior: the 92-day window limit for date resolution, the fallback for wider ranges returning rows without `date`, the request-cost model, and the `requests_made` result field. There is no contradiction with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and the key scoping rule, then provides constraints and cost behavior. Every sentence carries operational value, and the emoji/type line is a compact readable marker rather than filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description clarifies what rows contain (`date` vs `created_ts`), what constraints apply, what the result reports (`requests_made`), and when to prefer this tool over the raw alternative. Combined with the full schema coverage and annotations, the agent has enough context to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all 12 parameters with 100% coverage, so the baseline is 3. The description adds meaningful parameter-level meaning by requiring both dates and stating the 92-day constraint for date resolution, plus the behavior when the window is wider. It does not repeat every schema field but adds value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('journal line items') and highlights the distinguishing trait: the real transaction date is attached as `date`. It also contrasts itself with the raw journal-line-items tool by warning about `created_ts`, so an agent can tell them apart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'Use this instead of the raw journal-line-items tool whenever the date matters', names the alternative, and gives concrete use cases such as tracing an account's history, reconciling a period, or explaining a balance. It also warns not to report `created_ts` as the transaction date.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wafeq_requestA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explains why the tool is destructive, noting the same call can 'read a report or delete an invoice.' It adds critical runtime behavior beyond annotations: automatic X-Wafeq-Idempotency-Key injection on writes unless overridden, and Authorization always being set from server credentials and non-overridable. This is valuable disclosure for a high-risk arbitrary API tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the destructive warning and escape-hatch positioning, followed by concrete usage rules and header behavior. Every sentence carries operational weight; the slight redundancy between the header line and first sentence is acceptable as a scannable summary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an arbitrary-endpoint tool with no output schema, the description provides the essential context an agent needs: when to use it, safety categorization and rationale, user-confirmation requirement, idempotency behavior, and authentication constraints. It is appropriately complete for a deliberately open-ended escape hatch.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3; the schema already documents method, path, query, body, and headers. The description adds meaning by clarifying the idempotency-key auto-injection behavior and that Authorization cannot be overridden through the headers parameter, which goes beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Call any Wafeq endpoint directly, with full control over method, path, query, body AND headers.' It also explicitly differentiates itself from the documented sibling tools by presenting itself as the fallback escape hatch for endpoints not covered by the bundled spec.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use guidance: use only for 'something the bundled spec does not cover,' while documented endpoints have their own generated tools. It also prescribes a safety rule: 'Confirm with the user before any non-GET call.' This clearly routes the agent away from primary tools and into this fallback only when appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.