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

Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful context by specifying the exact environment variables checked and that the tool provides instructions when not configured. This goes beyond the annotations.

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

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

The description is a single succinct sentence that conveys all necessary information with no unnecessary words. Every part is valuable.

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

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

Given zero parameters, present annotations, and an output schema, the description fully covers what the agent needs to know: it will report configuration status and optionally provide setup instructions.

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

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

No parameters exist, so schema coverage is effectively 100%. The description does not need to elaborate on parameters; the baseline score of 4 applies.

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

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

The description clearly states the tool's purpose: to report whether MERIT_API_ID and MERIT_API_KEY are configured and provide setup instructions. This distinctively sets it apart from sibling tools which focus on data operations.

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

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

The description implicitly indicates when to use this tool (to check configuration status and get setup instructions). While it doesn't explicitly state when not to use it or list alternatives, the sibling tools are so different that usage context is clear.

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

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

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description's 'Read-only tool' is consistent with annotations but adds no additional behavioral context (e.g., rate limits, auth requirements). This is adequate given annotation coverage.

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

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

The description is front-loaded with 'Read-only tool' and lists actions succinctly. However, the repetitive 'List ...' structure could be condensed, and the inclusion of periods and semicolons makes it slightly verbose. Adequate but not exemplary.

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

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

For a tool with 9 parameters, no output schema, and extensive sibling tools, the description is incomplete. It fails to explain parameter mechanics, filter usage, or return behavior, leaving significant gaps for an agent to select and invoke correctly.

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

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

With 0% schema description coverage, the description must compensate but does not. It only lists possible values for the 'action' parameter, leaving id, filters, payload, etc. unexplained. The agent cannot infer correct parameter usage beyond action selection.

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

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

The description clearly states it is a read-only tool for payments, banks, and GL information, distinguishing it from write siblings. However, the purpose is presented as a list of actions rather than a concise single statement, slightly reducing clarity.

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

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

The description includes 'Read-only tool,' which implies it should not be used for writes, but it does not explicitly mention alternatives like merit_write_financial or specify when to use this vs. other read tools such as merit_read_purchases. Some guidance is present but incomplete.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds 'Read-only tool' but does not elaborate on permissions, rate limits, or side effects beyond what annotations convey.

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

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

The description is relatively short but uses a run-on list with semicolons. It could be better structured (e.g., bullet points) and still concise.

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

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

Given the tool's complexity (9 parameters, no output schema, no enums), the description is insufficient. It does not cover parameter interactions, default behaviors, or the full scope of actions and their constraints.

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

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

With 0% schema description coverage and 9 parameters, the description fails to explain the meaning of key parameters (e.g., action, id, filters, payload). Only action is mentioned via a list of sub-actions, but no enum or format details are provided.

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

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

The description clearly states it is a read-only tool for inventory, fixed asset, and pricing data with a list of actions. However, it does not explicitly differentiate from sibling tools like merit_read_financial or merit_read_master_data, which may have overlapping scope.

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

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

While it identifies the tool as read-only, there is no guidance on when to use it versus alternative tools, nor does it explain which action to use in different scenarios. The description lacks context-specific usage recommendations.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reiterates 'Read-only tool' and lists actions, adding moderate value by specifying the type of data (master/reference), but does not disclose behaviors like rate limits, permissions, 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.

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

The description is moderately concise; the action list is structured but somewhat lengthy. It front-loads the read-only nature, but a more compact grouping could improve readability without losing information.

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

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

Given no output schema and 0% parameter coverage, the description should explain what each action returns and how to use optional parameters. It fails to do so, leaving significant gaps for an agent to understand tool usage correctly.

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

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

Schema description coverage is 0%, so the description must compensate. Only the 'action' parameter is implicitly explained via the list of action values. Other critical parameters (id, filters, payload, etc.) are not described at all, leaving the agent to guess their purpose and format.

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

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

The description clearly states the tool is for reading master and reference data from Merit, and lists 18 specific actions (e.g., customers_list, accounts_list). The purpose is clear but does not differentiate from sibling read tools like merit_read_financial which may also list accounts or other overlapping actions.

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

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

No guidance is provided on when to use this tool versus the many other read tools (e.g., merit_read_financial, merit_read_inventory). The description simply enumerates actions without contextualizing scope or alternatives.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Read-only tool' adds no new safety context. It lists actions but lacks details on pagination, error behavior, or output structure, though not required given annotations.

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

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

Description is short and front-loaded with 'Read-only tool,' then lists actions. No wasted words, though a list format could improve readability.

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

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

Description is incomplete given 9 parameters and no output schema. Only action parameter is explained; key details on filters, payload, and response are missing, making it insufficient for reliable invocation.

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

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

With 0% schema coverage, the description must compensate but only explains the 'action' parameter values. Other 8 parameters (id, filters, payload, etc.) receive no explanation, leaving ambiguity.

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

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

The description clearly states the tool reads purchase invoices and purchase orders, listing specific actions (invoices_list, invoice_get, orders_list), which distinguishes it from sibling read tools like merit_read_sales.

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

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

The description implies usage for purchase documents through naming and actions, but does not explicitly state when not to use it or compare with alternatives like merit_read_financial.

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

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

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds a list of actions but no additional behavioral details like pagination or error handling. 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.

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

The description is fairly concise but the list of actions is run-on and could be better formatted. It front-loads 'Read-only tool' but is not particularly well-structured.

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

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

No output schema and no explanation of return values or continuation mechanism. Given the complexity (8 reports, 9 parameters), the description is incomplete and does not cover how to use the tool effectively.

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

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

Schema description coverage is 0%. The description lists the valid action values, which is critical, but does not explain the other 8 parameters (id, filters, payload, etc.). For a tool with 9 parameters, this is insufficient.

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

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

The description clearly states the tool reads Merit reports and lists eight specific actions, making the purpose clear. However, it does not differentiate from sibling read tools like merit_read_financial or merit_read_sales, which could cause confusion.

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

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

No guidance on when to use this tool versus the specific read tools (e.g., merit_read_financial). The description only says 'Read-only tool' but lacks any when-to-use or when-not-to-use instructions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description reinforces read-only behavior but adds no additional behavioral context beyond listing actions. No contradictions.

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

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

Front-loaded with key purpose ('Read-only tool'). Actions listed in a structured format. Slightly long due to enumeration, but each line is concise. No unnecessary words.

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

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

While the action list is useful, the description fails to document parameter semantics, return values (no output schema), or provide examples. Given 9 parameters and zero schema descriptions, the tool definition is incomplete.

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

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

Schema coverage is 0%, so description must compensate. It enumerates valid action values in text, aiding the agent. However, it does not explain id, filters, payload, or other parameters, leaving significant gaps.

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

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

Clearly states it is a read-only tool for sales invoices, offers, and recurring invoices. Lists all available actions. Distinguishes from sibling write tools like merit_write_sales.

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

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

Explicitly states read-only nature, implying not for modifications. Does not provide explicit when-not-to-use or alternatives, but siblings are clearly write tools. Within the tool, actions list provides guidance on which action to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description usefully explains WHY that is true — it is a dry-run that returns intended operations plus a confirmation_code rather than mutating. It leaves a real gap, though: the schema contains a 'confirmed' boolean that could plausibly execute the change, and the description never explains whether this tool can ever commit or how idempotency works across repeated previews.

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

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

Three short sentences with the most decision-relevant fact (preview-only, no execution) placed first, which is exactly the right ordering. The final action gloss ('customer_upsert: Create or update a customer') restates the preceding sentence almost verbatim, so a small amount of text is not earning its place.

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

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

For a preview-write tool with 9 undocumented parameters and no output schema, the description covers the confirm workflow but omits the shape of the returned preview and the semantics of most inputs. It is enough to know which tool to call first, but not enough to call it correctly without opening the schema.

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

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

Schema description coverage is 0% across 9 parameters, so the description must carry parameter meaning and largely does not. Only 'action' (customer_upsert) and 'confirmation_code' are addressed; id, bank_id, filters, payload, confirmed, delivnote, and add_attachment are never explained, leaving an agent to guess what payload shape or filter syntax customer_upsert expects.

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

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

The description names a specific verb+resource ('Create or update customers') and front-loads the distinguishing property ('Preview-only write tool. Does not execute changes'), so an agent can tell it apart from merit_write_customers_confirm and the read_* siblings immediately. It also enumerates the single supported action, customer_upsert.

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

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

It makes the workflow condition explicit: this tool returns a confirmation_code that must be fed to merit_write_customers_confirm, implying you call this one first and only confirm afterwards. It never states when NOT to use it or what happens if the preview is skipped, so it stops short of full routing guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds the confirmation gating contract (requires confirmation_code plus confirmed=true) and the two-step preview/confirm nature, which is genuinely useful beyond the annotations. It stops short of saying what data is destroyed or that repeats are non-idempotent.

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

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

Front-loaded with the key fact that this is the confirmed/executing half of a preview-confirm pair, and the sentences are short. The final 'Create or update customers' sentence is redundant with the action line that follows it.

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

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

For a destructive, non-idempotent write tool with nine mostly-optional parameters and no output schema, the description leaves critical gaps: what payload/filters must carry, how confirmation_code is obtained, and what side effects occur. It covers the workflow contract but not enough to call it correctly.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It only explains confirmation_code and confirmed; id, bank_id, filters, payload, delivnote, and add_attachment are entirely undocumented anywhere, leaving the agent to guess what payload must contain.

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

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

States a specific operation ('Executes a previously previewed write operation from merit_write_customers') and names the action customer_upsert, which distinguishes it from merit_write_customers (preview) and merit_write_sales_confirm. The purpose is clear, though the trailing 'Create or update customers' restates the action rather than adding scope.

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

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

Gives the triggering condition explicitly ('when called with confirmation_code and confirmed=true') and ties this tool to a prior call to merit_write_customers. It communicates the preview-then-confirm workflow well but never states when NOT to use it (e.g., bypassing confirmation) or what happens if the code is stale.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: preview returns a confirmation_code, confirmation creates a real unsent accounting invoice affecting the ledger and reports, items are re-verified at confirmation, and unknown fields are rejected at every level. This goes well 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.

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

The description is long but front-loads the most important distinction (preview vs. confirmation) and each sentence carries operational constraints. There is some repetition around 'not an unposted draft' and the density could be better structured, but for the complexity involved it is reasonably efficient.

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

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

Given a 9-parameter write-preview tool with no output schema, the description is exceptionally complete: it covers the preview/confirm lifecycle, ledger impact, manual boundaries, payload shape, validation behavior, and field-level restrictions. Nothing essential for correct invocation appears missing.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it richly documents the payload structure, required field formats, singular InvoiceRow, TaxId resolution, and validation rules. However, several top-level parameters such as id, bank_id, filters, delivnote, and add_attachment are not explained, leaving gaps despite the strong payload coverage.

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

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

The description states a specific action and scope ('Preview-only write tool... returns intended operation details and a confirmation_code') and distinguishes this preview tool from the confirmation sibling. It further specifies that it creates unsent accounting invoices, not unposted drafts, making the resource and state unambiguous.

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

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

It explicitly says to use this tool for preview and then use merit_write_sales_confirm with the returned confirmation_code. It also names what is not exposed by this server (delivery, deletion, credit invoices) and clarifies that only the preview is non-writing, giving clear when-to-use and when-not-to-use guidance.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds the consequences the annotations cannot convey: the result is a real unsent accounting invoice that affects the ledger and reports before delivery, it is explicitly not an unposted draft, the server re-verifies items at confirmation and refuses missing/stock/unrecognized ones, and unknown fields are rejected at every level.

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

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

Front-loaded with the confirmation contract, but the body is dense and repeats the same point three times ('not unposted drafts', 'NOT an unposted draft', 'NOT an unposted draft'). A single statement of that constraint would free space for the undocumented top-level parameters.

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

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

For a destructive, 9-parameter write tool with no output schema, the description covers the mutation's real-world effect, the item re-validation behavior, and most payload constraints. It falls short only on the several top-level parameters left undocumented and the absence of any return/result expectation.

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

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

Schema coverage is 0%, so the description carries the full burden. It does heavy lifting on the payload shape (InvoiceRow singular, Item={Code,Description,UOMName}, Quantity>0, Price>=0, TaxId, TaxAmount, TotalAmount rules) and on confirmation_code/confirmed, but the top-level id, bank_id, filters, and delivnote parameters are never explained. Partial compensation, not full.

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

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

States a specific verb and resource ('executes a previously previewed write operation from merit_write_sales') and pins the trigger condition (confirmation_code plus confirmed=true). It explicitly separates itself from the sibling merit_write_sales, which only previews, so an agent can distinguish the two without opening either schema.

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

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

Gives explicit sequencing ('Read items_list first', 'Resolve company-specific TaxId GUIDs via taxes_list'), states the preview-vs-confirm relationship with merit_write_sales, and names what is out of scope (delivery, deletion, credit invoices handled manually in Merit). When-not-to-use guidance is effectively present via 'Review before confirming; send manually in Merit.'

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