merit-aktiva-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly organized around distinct resources and actions, and descriptions clearly identify endpoints and GUIDs. A few pairs require close reading—sales invoices by number/customer vs. period list, purchase invoices vs. purchase orders, and list_prices/get_price/send_prices—but the descriptions sufficiently disambiguish them.
Naming Consistency5/5
All tools follow the merit_<verb>_<noun> snake_case pattern, using predictable list/get/create/update/delete/send verbs. Even compound nouns and pluralizations remain consistent, with no camelCase or mixed conventions.
Tool Count1/5
77 tools is an extreme number for a single MCP server, far beyond even a heavy 25+ threshold. While Merit Aktiva is a broad ERP platform, this surface is too large to navigate effectively and would benefit from being split into focused domain servers.
Completeness3/5
Core workflows—customers/vendors, items, sales and purchase invoicing, payments, GL batches, reports, inventory, fixed assets, and pricing—have substantial coverage. However, many entities have list/get/create but no update or delete, the purchase-order approval flow is list-only, and several resources lack write operations, leaving notable gaps.
Average 3.9/5 across 77 of 77 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It signals a read operation through 'Get' and notes date-dependent validity, but it does not describe response format, error behavior, authentication needs, or what happens when customer identification is omitted.
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 and front-loaded: the purpose appears first, followed by the endpoint in parentheses and the key required/alternate parameter guidance. Every sentence earns its place without 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 tool with no annotations and no output schema, the description is under-specified. It does not explain what the response contains, how currency and UOM are handled, or how this tool differs from the related price list/send tools in the sibling set. An agent would lack complete guidance for a 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 43%, so the description must compensate. It adds some meaning by clarifying that customerId, custName, or custRegNo are alternatives for identifying a customer. However, it leaves uomName and currencyCode completely unexplained, and the schema itself also lacks descriptions for them.
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: 'Get the valid sales price for a customer on a date.' It does not explicitly contrast with sibling tools like merit_list_prices or merit_send_prices, but the scope is specific enough to make the purpose largely self-evident.
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 price-related sibling tools. The only usage instruction is parameter-level ('itemCode and docDate are required; provide customerId, or custName / custRegNo'), which does not help an agent choose among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry behavioral transparency, but it only states the endpoint and date format. It does not say whether the call is read-only, what response shape to expect, how filters affect output, or whether special permissions are required.
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 identifying endpoint, and contains no filler. It is concise, though it achieves brevity by omitting behavioral context that other dimensions penalize.
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 complete schema coverage, the description lacks enough context for an agent to understand the report's semantics, filtering behavior, or output format. With no output schema and no annotations, key operational details 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?
All five parameters already have schema descriptions with 100% coverage, so the description is not required to document them. It adds only the ISO date format clarification, which largely duplicates the schema's 'YYYY-MM-DD' note.
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?
Identifies the resource as an inventory report and provides the exact endpoint, which separates it from the many other merit_* report tools. It lacks an explicit verb and does not describe report contents beyond the name, so it is clear but not maximally descriptive.
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 call this report instead of alternatives such as merit_list_inventory_movements or merit_get_sales_report. The agent must infer usage from the tool name and endpoint, making selection largely a guessing exercise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavior disclosure. It only reveals the HTTP method (POST) and the reportType codes; it does not state whether the call modifies data, whether it is safe to invoke repeatedly, what authentication or permissions are needed, or what the response looks like. This leaves significant behavioral uncertainty for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the resource, the endpoint, and the core reportType mapping with no wasted words. The format is easy to scan and the most important identifying information appears first.
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 no output schema and no annotations, yet the description does not explain return values, pagination, date-range semantics, or how the report content is structured. For a report tool, an agent would likely need more context about what the response contains and how it relates to other purchase-related tools. The description covers only the request mechanics and reportType meaning, leaving several practical 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 is 3. The description repeats the reportType enum meanings that are already in the schema and adds no new semantic detail about startDate or endDate beyond their format. It provides a small amount of redundancy but no substantive additional parameter clarification.
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 resource ('Purchase report') and the endpoint, and the reportType mapping distinguishes the four report flavors. The tool's name reinforces that it retrieves a purchase report, so an agent can tell it apart from sales-report siblings by the 'purchase' qualifier. It stops short of an explicit verb like 'retrieves' or 'generates', but it is not vague.
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 instead of closely related siblings such as merit_list_purchase_invoices, merit_get_purchase_invoice, or other report tools like merit_get_sales_report. There are no alternatives mentioned, no context about typical use cases, and no exclusions. The reportType mapping is a parameter explanation, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description bears the full burden of explaining side effects, response behavior, and prerequisites. It only gives an endpoint and enum mapping, without stating whether the POST is effectively read-only, what the response contains, or whether any permissions or data constraints apply.
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 resource name, with no filler words. It is telegraphic and could be better structured as sentences, but it wastes no 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 no annotations, an agent needs at least an indication of what the report response looks like and when this endpoint is appropriate. The description covers the type selector but leaves the return format, date range behavior, and relationship to other reports unexplained.
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 startDate, endDate, and reportType are already documented structurally. The description adds only a redundant restatement of the reportType enum and does not clarify date range semantics or any relationships between 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 identifies the resource ('Sales report') and the exact POST endpoint, and the reportType enum clarifies the five report variants. It lacks an explicit verb, relying on the tool name 'get', and it does not explicitly distinguish this from sibling report tools beyond the 'sales' qualifier.
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 many sibling reporting tools such as merit_get_customer_debts_report or merit_get_profit_report. The reportType mapping hints at scope, but no decision criteria or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the endpoint and required fields, but the endpoint name 'sendoffer' strongly hints that the offer may be sent to the customer, and the description neither confirms nor denies this side effect. It also omits idempotency, authorization, and what happens on success — material gaps for a write operation.
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?
Three dense sentences with zero filler: the action and endpoint are front-loaded, followed by the required-field set and a global date convention. Every sentence carries information an agent would otherwise need to extract from the schema.
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 18-parameter creation tool with nested objects and no output schema, this is under-specified. The 7-value docStatus enum is unexplained, the ten undocumented parameters are left to guesswork, the likely 'send' behavior is unaddressed, and the response/return shape is never mentioned.
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 genuine value with 'totalAmount (ex-VAT)' and a compact required-field summary, but schema coverage is only 44% and 10 parameters (docStatus, refNo, currencyCode, departmentCode, roundingAmount, etc.) are undocumented in both schema and description. The docType and taxAmount notes largely restate the schema's own enum and property descriptions, so compensation for the coverage gap is insufficient.
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 — 'Create a Merit Aktiva sales offer' — with the HTTP endpoint (POST /api/v2/sendoffer), making the operation and resource unambiguous. The verb 'create' implicitly distinguishes it from siblings like merit_update_sales_offer, merit_set_sales_offer_status, and merit_create_invoice_from_sales_offer, though no sibling 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the tool for producing a new sales offer, and the docType guidance (1=quote, 2=order, 3=prepayment) adds task-level context. However, there is no explicit when-to-use versus when-not guidance or mention of alternatives such as merit_update_sales_offer or merit_create_invoice_from_sales_offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the endpoint and date/dateType constraints, but it does not mention authentication requirements, output format, pagination, or any side effects. Listing does imply a read operation, but the description adds limited behavioral context beyond the endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose and endpoint, followed by only the essential constraints and dateType semantics. No filler or redundant material.
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 operation with three parameters and no output schema, the description covers the required inputs and their constraints. It lacks guidance on results format and sibling-tool selection, but the core calling contract 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 even without parameter detail in the description the baseline is 3. The description restates the ISO date format, the 3-month maximum interval, and the dateType meaning, adding little 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 identifies the operation as listing Merit Aktiva general-ledger batches and includes the explicit API endpoint. However, it does not explicitly distinguish this from sibling tools such as merit_list_gl_batches_full or merit_get_gl_batch, so it falls 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 choose this tool over alternatives such as merit_list_gl_batches_full or merit_get_gl_batch. The parameter constraints are stated, but there is no context for selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it mostly spends its words on enum codes and date formats rather than behavior. It does not explain what invoking this tool actually does — whether an invoice is immediately generated, scheduled, or sent to the customer (the endpoint name 'sendperinvoice' hints at sending but is never explained) — nor does it disclose side effects, idempotency, or authorization needs. For a creation tool with zero annotation coverage, this is a significant transparency gap.
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?
Compact and front-loaded: the core purpose leads, followed by compact enum tables and a date-format note. No filler words. Minor deduction because the cycle enum and ISO date format duplicate what the schema already states, and that space could have been used to describe required nested object shapes, but overall the structure is tight and scannable.
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 high-complexity tool — 12 parameters, 8 required, 4 nested object parameters, no annotations, and no output schema — and the description is not nearly complete enough for this context. It omits the structure of the required customer, invoiceRows, and taxAmount objects, the meaning of totalAmount, the purpose of optional parameters, the behavior of the POST call, and the response shape. An agent could not reliably construct a valid request from this definition 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 coverage is low (42%), so the description must compensate for the 7 undocumented parameters (payer, endDate, invoiceNo, taxAmount, invoiceRows, totalAmount, currencyCode) — and it does not. It does add genuine value for the period enum, decoding cryptic values like '6 = current less cycles' that the schema leaves as 'relative to the cycle', but it merely repeats the cycle enum and date formats already present in the schema. It partially compensates for low coverage but leaves the required nested objects (customer, invoiceRows, taxAmount) completely opaque.
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 ('Create a Merit Aktiva recurring invoice') and includes the exact API endpoint (POST /api/v2/sendperinvoice). The term 'recurring invoice' cleanly differentiates this from siblings like merit_create_sales_invoice (one-off) and merit_list_recurring_invoices / merit_get_recurring_invoice (read 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?
Usage context is implied: the 'recurring invoice' phrasing tells an agent this is for scheduled invoices rather than one-off sales invoices, and the endpoint positions it as the create operation among the recurring-invoice siblings. However, there is no explicit when/when-not guidance, no mention of prerequisites (e.g., existing customer), and no named alternatives telling the agent which sibling to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the HTTP method and endpoint, but it does not state whether the operation is read-only, what the response format is, or any side effects or permission requirements. This leaves the agent without explicit expectations beyond the basic resource identification.
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 a single compact sentence with no filler. It efficiently front-loads the report type and then packs the endpoint and both parameter clarifications into minimal space. Every part 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?
The tool has only two required parameters and no output schema, so the core invocation details are present. However, the lack of annotations and behavioral details means the agent gets no safety profile, return-value expectations, or guidance on how this report relates to sibling reports. For a straightforward report call it is minimally complete but not fully self-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 100%, so the schema already documents both parameters. The description's restatement of 'endDate is ISO YYYY-MM-DD' and 'periodCount is the number of months' adds only marginal clarification over the schema fields. It provides no extra value such as examples, ranges, or edge-case guidance.
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 as a balance sheet / statement of financial position and gives the endpoint, which makes the tool's function recognizable. However, it uses a noun phrase rather than an explicit verb like 'retrieves' or 'generates', and it does not explicitly contrast with sibling report tools. The report type is specific enough to distinguish it from profit, inventory, and sales reports.
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 obtaining a balance sheet report, but it does not state when to use this tool over sibling report tools such as profit or inventory reports. There are no explicit conditions, exclusions, or references to alternatives. The usage context must be inferred entirely from the named report type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the HTTP method is POST, states that entries are included, and explains the addAttachment flag triggers base64 attachment content. However, it does not mention whether the operation is read-only, what happens when the id is not found, or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary purpose is front-loaded, and the parameter clarifications are brief and relevant.
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 get-by-id tool, this is adequate: it covers the required id, the optional attachment behavior, and the endpoint. However, with no output schema and no annotations, it could better explain what 'entries' means, how the response is shaped, and how this tool relates to the nearby list_gl_batches and list_gl_batches_full 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 coverage is 100%, so the baseline is 3. The description mostly repeats the schema: id is the batch GUID/GLBId, and addAttachment includes a file as base64. It does not add meaningful semantics beyond what the input schema already provides.
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 ('Get') and resource ('one Merit Aktiva GL batch with entries'), and includes the endpoint. It is distinct from listing tools by emphasizing 'one' batch, but it does not explicitly differentiate itself from siblings like merit_list_gl_batches or merit_list_gl_batches_full.
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 the alternative list tools or other GL batch tools. It gives operational instructions for id and addAttachment, but no context around 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the HTTP endpoint and names the writable fields, but it does not explain whether unspecified fields are preserved, whether permissions are required, what side effects occur, or what the response looks like. For a mutation tool this is a meaningful gap.
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 a single sentence that front-loads the action, names the endpoint, identifies the key parameter, and lists the writable fields. Every part contributes useful information with no repetition or filler.
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 update tool with four flat parameters, the description covers the core action and field scope. However, because there are no annotations and no output schema, it would benefit from stating the mutation semantics (e.g., partial update behavior) or typical success/error response. It is 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must compensate, especially for fComment and hComment, which have no schema descriptions. The description says these are writable but does not explain what they mean or how they behave when omitted. It adds little 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 uses a specific verb and resource: 'Update a Merit Aktiva sales offer', and further distinguishes the operation by naming the writable fields (deliveryDate, hComment, fComment). This clearly differentiates it from sibling tools like merit_set_sales_offer_status or merit_create_invoice_from_sales_offer.
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 updating the listed sales-offer fields, but it does not explicitly say when not to use it or point to alternatives such as merit_set_sales_offer_status for status changes. The guidance is adequate by implication rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the HTTP method (POST), endpoint, uniqueness constraint and max length for name, required fields, and the return shape { Id, Name }. This goes beyond what the schema provides, though it omits error behavior and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, then packs constraints and return information into a compact, readable format. 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 17 parameters, 29% schema coverage, no annotations, and no output schema, the description is too sparse to be complete. It identifies required fields and return shape, but leaves the purpose and constraints of most optional parameters unexplained, which could lead an agent to generate invalid or semantically wrong requests.
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 29%, so the description must compensate for 14 undocumented parameters. It adds value for 'name' by specifying uniqueness and max 150, and it restates required fields, but it does not clarify the meaning or acceptable values for fields like vendorType, paymentDeadLine, overDueCharge, or bankAccount. The compensation is minimal relative to the number of undocumented parameters.
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 ('Create') and the resource ('Merit Aktiva vendor'), and includes the exact endpoint for disambiguation. This distinguishes it from sibling tools like merit_update_vendor, merit_list_vendors, and merit_create_vendor_group without requiring the agent to inspect 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?
The description states the create operation and required fields, but gives no explicit guidance on when to choose this tool over alternatives such as merit_update_vendor or merit_list_vendors. There are no when-to-use or when-not-to-use conditions, so the agent must infer usage from the tool name and the word 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose useful behaviors: debtDate defaults to today when omitted, empty customerName selects all customers, and the underlying call is a POST. But it says nothing about return shape, pagination, or whether repeated calls are safe, which matters given the POST verb for a 'get' report.
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?
Two sentences pack in the resource, endpoint, filter semantics, sentinel behavior, and a default, all front-loaded and without filler. Only minor redundancy exists where 'overDueDays filters exceeded days' overlaps with the schema's 'Minimum overdue days'.
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 report tool with no annotations and no output schema, the description covers the parameter side well but omits what the report actually returns and whether at least one of customerName/customerId is expected. The agent can call it correctly on inputs, but not on interpreting the result or knowing the required call shape.
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 baseline is 3. The description adds genuine value beyond the schema: it exposes the mutually-inclusive relationship between customerName and customerId, the special meaning of an empty customerName string, and the debtDate default — none of which the schema states.
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 ('Customer debts report') and the exact endpoint (POST /api/v1/getcustdebtrep), and the tool name supplies the action 'get'. It is distinct from sibling report tools like merit_get_customer_payments_report or merit_get_sales_report by the specific 'debts' resource, but it does not explicitly call out 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives solid invocation guidance: which parameter to provide (customerName or customerId), the empty-string-all-customers sentinel, the overDueDays filter, and the debtDate default. However, it never states when to choose this tool over sibling report tools or any exclusions, leaving tool-selection context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that this is a POST operation and that fields beyond id are optional patches, which conveys partial-update semantics. However, it does not disclose permissions needed, error behavior for invalid or missing customers, idempotency, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and resource, then immediately provides the critical invocation detail (id required, others optional patches). Every word earns its place; there is no filler or 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?
This tool has 13 parameters, no output schema, and no annotations, yet the description only covers the update action and patch semantics. It omits return values, error conditions, authorization expectations, and guidance on choosing between customer-related sibling tools. The description is too sparse to fully support correct invocation in an unfamiliar workflow.
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 8%: only 'id' has a description in the schema, while the other 12 parameters are undocumented. The description adds the generic 'other fields are optional patches' rule, but does not explain the meaning or accepted format of any individual field, so it fails to compensate for the low 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 clearly states a specific action ('Update') and resource ('Merit Aktiva customer'), and names the exact endpoint. It is immediately distinguishable from sibling tools like merit_create_customer and merit_list_customers because the verb and resource are explicit.
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 update an existing customer and notes that id is required, but it does not explicitly say when to use this tool instead of create_customer or list_customers, nor does it mention any exclusions or prerequisites beyond the required id. Usage context is present but left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the HTTP method/endpoint and the date format conversion (ISO to yyyyMMddHHmm), which is useful behavioral context. However, it does not mention potential side effects, reversibility, permission requirements, or what happens on success or failure.
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 two tightly packed sentences with no filler. The core action leads, followed by the identification method and the critical date-format note. Every sentence adds distinct 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?
For a 9-parameter creation tool with no annotations and no output schema, the description is too sparse. It omits response/return behavior, error conditions, and guidance on the optional fields (iban, refNo, bankId, currencyRate). The identifier and date-format details are helpful, but an agent would still be uncertain about side effects and how to verify the result.
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 56%, so the description is expected to compensate. It adds meaningful semantics by explaining that customerName + offerNo are used together to identify the offer, and it clarifies that paymentDate is converted to yyyyMMddHHmm. Yet optional parameters like iban, refNo, bankId, and currencyRate remain undocumented 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 a specific verb and resource: 'Record a payment against a sales offer.' It also states the exact endpoint and the identifying fields (customerName + offerNo), which makes the tool's function unambiguous and distinguishes it from invoice or purchase payment tools among the 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 use case is implied by 'Record a payment against a sales offer,' and the identifier logic provides clear context. However, the description does not explicitly state when to prefer this over sibling tools like merit_create_sales_invoice_payment or merit_delete_payment, nor does it mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose the most critical behavioral trait—irreversibility ('There is no undo')—and flags destructiveness upfront. However, it omits side effects (e.g., impact on linked payments or e-invoices) and any preconditions on which invoices may be deleted, so coverage is partial.
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?
One tightly packed sentence with the safety warning front-loaded, followed by the operation, endpoint, parameter meaning, and irreversibility. Every element earns its place with zero 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 one-parameter destructive tool with no output schema, the description covers the essential call contract: what it does, the endpoint, the parameter, and the no-undo consequence. The only gaps are response shape and any restrictions on deletable invoices, which are minor for 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% (id is described as 'Invoice GUID / SIHId (required)'), so baseline is 3. The description restates nearly the same information ('id is the invoice GUID (SIHId)') without adding new nuance, meeting but not exceeding the schema's already-documented 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 states a specific verb+resource ('delete a Merit Aktiva sales invoice') plus the exact endpoint (POST /api/v1/deleteinvoice). This clearly distinguishes it from sibling tools like merit_get_sales_invoice, merit_list_sales_invoices, and merit_delete_purchase_invoice, so an agent can identify the operation 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?
The description gives no guidance on when to use this tool versus alternatives—no mention of prerequisites (e.g., invoice state), no suggestion to verify with merit_get_sales_invoice first, and no exclusions. The DESTRUCTIVE warning conveys caution but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the mutating nature ('create or replace') and the POST method. However, 'replace' is ambiguous — it is not disclosed whether an existing discount set is fully overwritten or upserted per row, which matters for a potentially destructive write. The targetGroup/groupType enum meanings are a useful behavioral addition.
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?
Two dense sentences with zero filler: the action and endpoint are front-loaded, and the field guides follow. Every clause earns its place, especially given how little the schema reveals about discount row contents.
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 tool with no output schema, the description covers the operation and two key row fields, which is a reasonable start. But it leaves the rest of the discount row structure unspecified, so an agent cannot reliably construct a valid discounts array, and the ambiguity of 'replace' is unresolved. Complexity is low enough that this is only a moderate 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 only describes discounts as 'Discount rows (required)' with opaque object items, so the description's documentation of targetGroup (1 = customer, 2 = customer group) and groupType (1 = item, 2 = item group) adds real meaning absent from the schema. With 100% schema description coverage the baseline is 3, and this extra field-level semantics lifts it to 4. Fields beyond these two remain undocumented.
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 opens with a specific action, 'Create or replace Merit Aktiva sales discounts,' and pins the operation to a concrete endpoint (POST /api/v2/senddiscounts). This makes the tool's function unmistakable and implicitly separates it from the read-only sibling merit_list_discounts, though no sibling 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 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: 'Create or replace' signals a write operation, and the targetGroup/groupType field explanations hint at the two targeting modes. The description never says when to choose this over alternatives like merit_send_prices or merit_list_discounts, nor does it state any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does identify the operation as an HTTP POST and lists required inputs, but it omits response behavior, error/validation semantics, permission requirements, and what side effects occur beyond creation.
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 a single front-loaded sentence that conveys the action, endpoint, and required parameter constraints with no filler or redundancy. It is efficient and scannable.
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 invocation details are present: endpoint, required parameters, and length constraints. However, with no output schema and no annotations, the description gives no indication of what the tool returns or how to interpret the result, leaving the agent guessing after 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 100% and the input schema already documents each parameter with the same constraints (GUID, max 20, max 64). The description repeats these facts without adding new meaning, 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 states a precise action ('Create') and resource ('Merit Aktiva customer group') and includes the exact API endpoint. The customer-group scope clearly distinguishes this from sibling tools like merit_create_customer and merit_create_vendor_group.
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 verb 'Create' and the resource name make it clear this tool is for creating customer groups, but there is no explicit when-to-use guidance, no alternatives mentioned, and no exclusion of listing or vendor-group tools. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates item groups and mentions the endpoint, but it does not describe response behavior, error cases, permissions, idempotency, or side effects beyond creation.
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?
Two concise sentences with no filler. The main purpose is front-loaded, the endpoint is included as useful context, and the key requirement is stated clearly.
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 create tool, it covers the action and the required fields. However, with no annotations and no output schema, it leaves out response/error behavior and any prerequisites. This is adequate but has clear gaps.
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 describes itemGroups as an array of generic objects. The description adds essential semantic detail by specifying that each group needs code and name, which the schema does not provide.
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 specific action 'Create', the resource 'Merit Aktiva item groups', and the endpoint 'POST /api/v2/senditemgroups'. This clearly distinguishes it from sibling tools like merit_list_item_groups and merit_create_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?
Implies the tool should be used when creating item groups, and the required fields give practical context. However, it does not explicitly contrast with alternatives or mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It accurately states the side effect (sends an email) and the endpoint, but does not disclose prerequisites (e.g., customer email address, invoice state) or subsequent effects (e.g., marking the invoice as sent). The behavior is clear enough for a simple send action, but depth 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the most important information front-loaded ('SENDS EMAIL'). The endpoint and parameter usage are included without redundancy or filler.
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 two-parameter send action, the description covers the mechanics and both parameters. However, without an output schema or annotations it omits the expected response/status and any preconditions, and it does not explain how this tool relates to the e-invoice sibling. 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 100%: id has 'Invoice GUID / SIHId (required)' and delivNote has 'If true, send a delivery note without prices'. The description essentially restates these, adding no new meaning. Baseline 3 is appropriate when the schema already documents both parameters.
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?
Clearly identifies the action (emailing) and the resource (Merit Aktiva sales invoice) plus the recipient (customer), and names the underlying endpoint. This distinguishes it from sibling tools like get_sales_invoice or send_sales_invoice_einvoice.
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's use — after obtaining an invoice id, email it to the customer — but it never explicitly contrasts with alternatives such as merit_send_sales_invoice_einvoice or merit_get_sales_invoice_pdf. There is no when-to-use/when-not-to-use guidance, so the agent must infer selection from the verb 'email'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states 'List' and 'No filters', with no disclosure of return format, pagination, performance characteristics, or authentication requirements. For a tool with zero annotation coverage, this is significantly lacking.
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 a single sentence, front-loaded with the action and resource, and the 'No filters' note is succinct. No wasted words, perfectly concise for a trivial tool.
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 simplicity (no parameters, no output schema, no annotations), the description is minimal but arguably sufficient for an agent to call the tool. However, it does not specify what the response contains (e.g., all price lists, pagination hints) or any constraints, and with siblings present, a bit more context could aid selection. It is adequate but not thorough.
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 zero parameters, the baseline is 4. The description adds 'No filters' which reinforces the schema (empty object) but provides no new semantic value since the schema already conveys there are no parameters. The baseline score 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 a specific verb 'List', the resource 'Merit Aktiva sales prices', and the HTTP endpoint. It distinguishes itself from siblings like 'merit_get_price' (singular) and 'merit_send_prices' by specifying it returns a list with no filters, making it 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 says 'No filters' which implies it returns all prices, but it does not explicitly mention when to use this tool over alternatives such as 'merit_get_price' (presumably for a single price) or 'merit_send_prices'. Usage context is implied 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does disclose the endpoint and detailed filter semantics (DocType, DocStatus), which is useful. However, it never explicitly states that the operation is read-only or describes the response shape, and naming a POST endpoint without safety clarification leaves some ambiguity.
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 a compact single paragraph that front-loads the purpose and then enumerates parameter semantics without fluff. It could be improved with line breaks or bullets for readability, but every clause carries meaningful 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 operation with no output schema, the description omits the return payload structure, pagination, or any sample response. It also introduces DocType/DocStatus parameters not present in the schema without clarifying whether they are optional or how to pass them. An agent is left guessing about essential call results.
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 value by introducing DocType and DocStatus enums that are absent from the input schema, and it reinforces the 3-month period constraint. This goes beyond what the schema alone 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 clear verb-resource pair ('List Merit Aktiva sales offers') and names the underlying endpoint (POST /api/v2/getoffers), making the operation unmistakable. The plural 'offers' also distinguishes it from the sibling merit_get_sales_offer, which fetches a single offer.
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 parameter constraints and enum meanings, but no explicit guidance on when to choose this tool over alternatives like merit_get_sales_offer or merit_list_sales_invoices. Usage is implied by the verb 'List' and the resource name, but there are no when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It usefully discloses that this is an update operation, that it targets an existing item by id, and that fields are patched rather than fully replaced. However, it does not mention potential side effects, authorization needs, response behavior, or idempotency, leaving meaningful gaps for a mutation 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 one compact sentence that front-loads the operation and endpoint, then immediately states the key constraint. There is no filler, repetition, or unnecessary 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?
This is a mutation tool with no annotations and no output schema, and 7 of 8 parameters are undocumented. The description gives only the minimal call shape. An agent still lacks information about return values, error behavior, permissions, or the full semantics of the update, which is too incomplete 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 13%, with only id documented. The description adds that other fields are optional patches, which is helpful, but it does not explain the meaning or expected format of fields like taxId, itemGrCode, discountPct, or salesPrice. With such low schema coverage, the description should compensate much more than it does.
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 ('Update') and resource ('Merit Aktiva item'), and includes the exact endpoint. This clearly distinguishes it from sibling tools like merit_create_items and merit_list_items, so an agent knows exactly what operation this tool performs.
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 states that id is required and other fields are optional patches, which gives an agent clear instructions on how to call it. It does not explicitly name alternatives such as 'use merit_create_items to create new items', but the update semantics and id requirement provide enough context to avoid obvious misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the HTTP method (POST) despite the tool name starting with 'get', and it notes the result includes rows. But it does not state read-only behavior, error conditions, or any special request requirements beyond the GUID.
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 two short sentences with no fluff. The main purpose is front-loaded, and the endpoint and parameter explanation each earn their place without unnecessary detail.
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 get-by-GUID tool, this is largely complete: it states the resource, the required identifier, and that rows are included. There is no output schema, so a bit more detail about the returned structure could be helpful, but the description is adequate given the low 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 description coverage is 100%, and the description largely repeats the schema's 'Recurring invoice GUID (required)' by saying 'id is the recurring-invoice GUID'. It adds no meaningful semantics beyond what the schema already 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 a specific verb ('Get') and resource ('one Merit Aktiva recurring invoice with rows'), and the word 'one' distinguishes it from list-type siblings like merit_list_recurring_invoices. Including the endpoint further disambiguates the exact API 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 implies usage by GUID: 'id is the recurring-invoice GUID' and says 'Get one', so an agent can infer this is for fetching a single known recurring invoice. However, it does not explicitly name alternatives or say when not to use this tool, such as pointing to merit_list_recurring_invoices for retrieving all recurring invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It indicates a retrieval operation and that the response includes rows, and it discloses the endpoint and method. However, it does not explicitly state that this is read-only with no side effects, nor does mention authorization or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and resource, followed by the parameter clarification. Every word contributes meaning and nothing is 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 single-parameter retrieval tool with no output schema, the description is nearly complete: it names the resource, endpoint, and says the result includes rows. It leaves the exact response shape and error handling unspecified, but those are minor gaps given the tool's simplicity.
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 describes id as 'Offer GUID (required)' with 100% coverage. The description's 'id is the offer GUID' essentially repeats the schema rather than adding new semantic depth, so it stays at the high-coverage 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?
States a specific verb ('Get'), a precise resource ('one Merit Aktiva sales offer'), and a distinguishing detail ('with rows'), plus the endpoint. This clearly differentiates it from sibling tools like merit_list_sales_offers and merit_create_sales_offer.
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 'Get one' implies this is for retrieving a single offer by GUID rather than listing or creating offers, but the description never names alternatives or states when not to use it. There is clear implied context, but no explicit exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates a read-only list operation and the required type restriction, but it does not mention response format, error behavior, or authentication requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the resource and endpoint, then adds the only necessary parameter mapping. No filler words.
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 list tool with no output schema, the description contains enough to invoke it correctly: endpoint, required parameter, and enum meanings. It could mention return shape or explicitly note that it is read-only, but the low complexity makes the omission 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?
The schema already covers the single 'type' parameter with enum values and descriptions (100% coverage). The description repeats that mapping but adds no new semantics, so it earns the baseline for high 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 names the specific resource ('Merit Aktiva payment types'), uses the verb 'List', and includes the exact endpoint. This clearly distinguishes it from sibling tools like merit_list_payments, which lists payments rather than payment 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?
It implies when to use the tool—when payment types for purchases, expense reports, or sales are needed—and states the required type parameter. However, it does not explicitly contrast it with alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does add useful context: the HTTP verb and endpoint, the meaning of the id parameter, the delivNote behavior, and an expected error code. However, it does not disclose side effects, permissions, or whether sending is irreversible, which would be especially relevant for an action that transmits an invoice externally.
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 compact: a front-loaded purpose statement, the endpoint, the required parameter, and a concise note about the optional parameter and error case. Every sentence adds value, with no filler or repetition. It is efficiently structured for quick agent parsing.
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 action with no output schema, the description provides enough to invoke the tool correctly: required id, optional delivNote, and the principal failure mode. It does not describe the response format, but that is acceptable given the absence of an output schema and the simplicity of a send action. Slightly more detail on outcomes would push it to 5.
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 description largely restates what the schema already provides: id is the invoice GUID/SIHId, and delivNote controls sending without prices. It adds the error-code context for a receiver incapable scenario, but this is not parameter-level semantics beyond the schema. The baseline of 3 is appropriate given high 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 opens with 'SENDS E-INVOICE' and explicitly states the action: send a Merit Aktiva sales invoice as an e-invoice. It includes the specific endpoint and identifies the exact resource (invoice GUID/SIHId), making the tool's purpose unambiguous and distinct from siblings like merit_email_sales_invoice or merit_get_sales_invoice_pdf.
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 e-invoice sending, but it does not explicitly distinguish it from alternatives or state when not to use it. The 'Receiver not capable' note is a failure condition, not usage routing guidance. An agent could infer the use case from the tool name and context, but explicit sibling differentiation is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully reveals the endpoint, uniqueness constraint, max name length, required-field conditions, and the return shape. However, it does not disclose error behavior, duplicate handling, permissions, or side effects beyond the obvious creation.
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 three sentences long, front-loads the core action and endpoint, and packs in the most critical constraints without any filler. Every sentence adds operational 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 17-parameter creation tool with no annotations and no output schema, this is workable but not complete. It captures required fields and the response, and the schema covers many optional fields, but it omits conditional rules like the city requirement and does not provide guidance on optional fields or 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 coverage is 59%, so the description should compensate for undocumented parameters. It does add value by explaining the uniqueness/max-length rule for name and clarifying required-field semantics beyond the schema. Yet it leaves the remaining seven undocumented parameters unaddressed, so the compensation is incomplete.
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 ('Create a Merit Aktiva customer') with an explicit endpoint, and adds distinctive constraints (unique name, required fields). This distinguishes it from siblings like merit_update_customer or merit_create_customer_group without needing to inspect schemas.
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 by specifying required fields and their business meaning (notTDCustomer for physical persons/foreign companies, countryCode format). It could be stronger by explicitly naming when to choose this over merit_update_customer, but the create-versus-update distinction is reasonably implied by the tool name and action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose a mutation ('Record a payment'), the endpoint, and the paymentDate format conversion. However, it omits any detail about response behavior, permissions, or whether the payment can be reversed.
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?
Two tightly written sentences. The purpose is front-loaded, followed by the identification rule and the key format transformation, with no redundant wording.
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 enough to invoke the tool with required parameters and understand the date conversion, but it lacks guidance for optional parameters and doesn't specify expected behavior/response. Given no output schema or annotations, this is a moderate gap rather than a fatal one.
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 meaning beyond the schema by explaining that vendorName and billNo identify the target bill and that paymentDate is converted to yyyyMMddHHmm. But the four optional parameters (iban, refNo, bankId, currencyCode) remain unexplained, and schema coverage is only 50%.
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 action 'Record a payment' and the exact resource 'purchase invoice', with the API endpoint in parentheses. This clearly separates it from the sales invoice and sales offer payment 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 for when to use it: recording a payment against a purchase invoice, identified by vendorName and billNo. It does not explicitly name alternative tools or when-not conditions, but the purchase-invoice framing is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does communicate that the call takes no filters and identifies the endpoint, but it does not mention read-only status, pagination, response shape, or authentication requirements. For a simple list operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that conveys the resource, endpoint, and filtering behavior with no redundant words. Every element 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 zero-parameter list operation with no output schema, the description contains enough information to invoke the tool correctly: the action, the resource, and the endpoint. The lack of filters is explicitly stated, so an agent will not look for missing parameters. No additional context is necessary for this level of complexity.
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 already reflects this with an empty object. The description's 'No filters' reinforces the schema and adds a small behavioral cue, matching the baseline for no-parameter tools.
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: 'List Merit Aktiva customer groups', and specifies the exact endpoint. The phrase 'No filters' further defines the scope, and the resource type clearly separates it from sibling tools like merit_list_vendor_groups or merit_list_customers.
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 over alternatives, such as merit_list_customers or merit_create_customer_group. The description does not state exclusions, prerequisites, or conditions that would route an agent to a different sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose the endpoint, date constraints, and enum values, but it does not describe response shape, pagination, defaults, or authentication. The unmodeled 'Type' parameter also adds ambiguity about how filtering is expressed.
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?
Three concise sentences front-load the purpose and endpoint before enumerating parameter constraints. There is no redundant prose; every sentence adds actionable detail.
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 listing tool with no output schema and no annotations, the description covers the critical call details: endpoint, required date range, dateType semantics, and the intended Type semantics. It is missing only minor behavioral context such as response format and defaults.
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 100%, so the baseline is 3. The description mostly repeats schema information and adds a 'Type' mapping, but 'Type' is not present in the input schema, which could lead an agent to pass an unsupported or named-mismatched parameter. This ambiguity prevents the baseline from holding.
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 ('List'), a specific resource ('Merit Aktiva inventory movements'), and the exact HTTP endpoint (POST /api/v2/getinvmovements). This clearly distinguishes it from sibling tools such as merit_create_inventory_movement and merit_get_inventory_report without requiring schema inspection.
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 gives clear context: use this tool when the need is to list inventory movements, with explicit constraints on periodStart/periodEnd (ISO format, max 3 months apart). It does not explicitly name alternatives or exclusions, so it misses the top score, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It communicates a read-style list operation and the filter modes, but does not explicitly state side-effect-free behavior, return shape, pagination, or authentication requirements.
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?
Three short sentences with no filler; the core action and endpoint are first, the sibling distinction second, and filter semantics last. Every sentence carries 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 list tool with no output schema, the description covers the resource, scope, and filter options but omits the response format and any operational constraints. With no annotations to fill safety gaps, 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 100%, so the description is not required to document parameters. It does restate dateFilter and statusFilter semantics, which matches the schema, but adds no new syntactic meaning. 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?
States a specific verb and resource: 'List Merit Aktiva purchase orders waiting approval' with the underlying POST endpoint. Explicitly distinguishes from booked purchase invoices, so an agent can separate it from sibling merit_list_purchase_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?
Gives a clear use case ('waiting approval') and warns that it is not for booked purchase invoices (getpurchorders). It doesn't enumerate alternative tools by exact sibling name, but the exclusion is enough to route a simple choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful non-obvious behavior: each value may set endValue or quantity, quantity takes precedence, and address or customerId is also allowed. However, it does not disclose write side effects, whether the operation is idempotent, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the action and target resource, then packs in the API endpoint and the most important parameter semantics. There is no filler or repetition of schema details.
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 useful but not fully complete for a mutation tool with no annotations and no output schema. It explains the main value fields, but does not specify required combinations inside each value object, the meaning of address vs customerId, validation constraints, or what the response contains.
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?
Even though schema description coverage is 100%, the schema only says 'Article code' and 'Indication readings (required)'. The description adds real meaning by clarifying that artCode is the article, and by exposing the inner fields of each value object (endValue, quantity, address, customerId) and the precedence rule between quantity and endValue.
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 ('Send') and resource ('meter / indication values for recurring invoices'), and includes the direct API endpoint. This distinguishes it from sibling tools that list, get, or create recurring invoices, and from other 'send' tools like merit_send_prices or merit_send_discounts.
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: use this when you need to submit meter/indication values for recurring invoices. However, it does not explicitly state when not to use it or name alternative tools for viewing/creating recurring invoices, so an agent must infer the selection rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose the POST endpoint and the conditional rule that a comment is required for status 5, which goes beyond the schema. However, it does not disclose whether transitions are restricted or reversible, what side effects a status change may have, or how errors surface.
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 one front-loaded sentence stating purpose and endpoint, followed by a compact enumeration of status codes. Every element earns its place; there is no filler and no repetition of details already present in the schema.
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, 3-parameter tool with 100% schema coverage, the description covers the essentials: purpose, endpoint, enum semantics, and the conditional comment parameter. But because it is a mutating status-change tool with no annotations and no output schema, the absence of transition-validity, reversibility, and error-behavior information leaves a visible 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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine value by mapping each numeric enum value to a human-meaningful state (1 = unsent, 2 = sent, 3 = confirmed, 4 = rejected, 5 = commented, 7 = canceled) and restating the comment-required condition. This semantic mapping is absent from the schema, which only says '1–5 or 7'.
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 specific verb and resource — 'Change a Merit Aktiva sales offer status' — and reinforces it with the API endpoint (POST /api/v2/setofferstatus). The status-code semantics make the tool clearly distinct from siblings like merit_update_sales_offer and merit_create_sales_offer, even though no sibling 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 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 you need to move an existing sales offer to one of the enumerated statuses. However, there is no explicit when-to-use/when-not-to-use statement, no mention of alternatives such as merit_update_sales_offer for editing other offer fields, and no guidance on which status transitions are valid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It discloses the HTTP method (POST), the partial-update semantics ('other fields are optional patches'), and version capability ('v2 supports Dimensions'). It does not cover authentication, error behavior, or return values, but the key mutation semantics are transparent.
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?
Three short sentences with no wasted words. The primary purpose and required parameter are front-loaded, and the remaining details are compact and relevant.
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 13-parameter mutation tool with no annotations and no output schema, the description is adequate for basic invocation but incomplete. It lacks return value expectations, error conditions, authorization requirements, and explicit guidance on how it differs from related vendor 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 description adds meaningful patch semantics beyond the schema: fields besides id are optional and can be patched individually. However, schema description coverage is only 8%, so the description does not explain the meaning or format of the 12 undocumented fields, making the compensation partial.
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 updates a Merit Aktiva vendor, includes the exact endpoint, and explains that id is required while other fields are optional patches. This distinguishes it from create/list sibling tools and leaves no ambiguity about its core function.
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 verb 'Update' and the vendor context imply it should be used for modifying existing vendors, and sibling names like merit_create_vendor and merit_list_vendors suggest alternatives. However, the description never explicitly states when to use this tool instead of others or mentions exclusions or prerequisites beyond id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals the HTTP method, date format, and type-dependent requirements, but does not mention side effects, authorization needs, response behavior, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and endpoint, then packs the type-specific rules without filler. Every clause contributes.
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 mutation tool with no annotations and no output schema, yet the description omits the required structure of the 'rows' array objects (e.g., item code, quantity, cost). An agent cannot reliably construct a valid request body for all types from the provided information.
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 description adds meaningful conditional semantics beyond the schema, such as itemUnitCost being required on rows for type 1 and location2Code being the destination for type 3. However, the required 'rows' array item structure remains undocumented, preventing a perfect score.
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 a Merit Aktiva inventory movement') and includes the POST endpoint, making the operation unambiguous. It clearly distinguishes this creation tool from read-oriented siblings like merit_list_inventory_movements.
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 type semantics ('1 = in, 2 = out, 3 = between stocks') give clear contextual guidance for when each variant applies. There are no explicit exclusions or named alternatives, but the create vs. list distinction in sibling names makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It clearly states this is a creation operation and cites the POST endpoint, which implies a mutation. It also specifies the return fields. However, it does not disclose side effects such as whether the original offer is marked as invoiced, whether conversion can be repeated, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences convey the operation, endpoint, parameter meaning, and return value without any filler. Every sentence earns its place, and the most important information 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?
For a single-parameter conversion tool with no output schema, the description covers the input, operation, and return fields. It is nearly complete, though a note about the expected state of the offer or failure conditions would have made it 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?
Schema description coverage is 100%, so the schema already documents the required id parameter. The description adds minimal extra value by confirming 'id is the offer GUID', which is helpful for disambiguation but does not substantially go beyond the schema's 'Offer GUID (required)'.
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: 'Create a sales invoice from a Merit Aktiva sales offer', with the exact endpoint and input. This clearly differentiates it from sibling tools like merit_create_sales_invoice, which creates an invoice directly rather than converting an offer.
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 this tool is for converting an existing sales offer into an invoice, which is distinct from the many invoice- and offer-related siblings. It does not explicitly name alternatives or state when not to use it, but the offer-to-invoice transformation 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses immediate document creation, GL entry, booked state, and approval-flow bypass. It does not cover response shape, reversibility, or auth requirements, but the essential side effects are clearly stated.
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?
Three sentences, front-loaded with the action and endpoint, no filler. It efficiently packs purpose, behavioral caveats, and critical parameter semantics.
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 financial mutation with 13 parameters, nested objects, no annotations, and no output schema. The description covers the high-level workflow but omits essential structure for invoiceRows and taxAmount, which an agent must understand to invoke the tool correctly. More detail on required row fields and response behavior is needed.
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 31%, and the description adds some meaning by noting vendor can be an existing Id or new record and that totalAmount is ex-VAT. However, it provides no structure for the required invoiceRows and taxAmount arrays, which are opaque objects in the schema, and it leaves several auxiliary fields unexplained.
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 a booked Merit Aktiva purchase invoice' via a named endpoint. It also distinguishes the tool by emphasizing immediate GL entry and booked state, which separates it from sales invoice or purchase invoice payment 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 explicitly says this tool bypasses the approval flow and names sendpurchorder as the alternative for approval-based workflows. It also clarifies vendor handling (existing Id or new record). It lacks direct contrast with sibling purchase-invoice tools like listing or payment tools, but the core 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the mutating nature via 'Create' and POST, and hints that the client supplies the GUID. However, it does not cover response format, idempotency when re-sending the same GUID, or error behavior — meaningful gaps for an operation with zero annotation support.
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?
A single sentence front-loads the action and endpoint, followed by a compact summary of required fields with constraints. Every word earns its place and there is no filler.
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 3-parameter create tool with no output schema and no nested objects, the description covers the purpose, endpoint, and required fields completely. Minor gaps around response/error behavior remain, but nothing an agent needs to invoke the tool successfully 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 100%, so the schema already documents all three parameters. The description restates constraints (GUID, max 64, max 20) that are already present in the schema property descriptions, adding no genuinely new semantic information. 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 names the specific verb ('Create'), the resource ('Merit Aktiva vendor group'), and the exact endpoint (POST /api/v2/sendvendorgroup). This clearly differentiates it from sibling create tools like merit_create_customer_group and merit_create_vendor 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement gives clear context: an agent can tell this is the tool for creating vendor groups in Merit Aktiva. However, it names no sibling alternatives (e.g., merit_list_vendor_groups for listing, merit_create_customer_group for customer groups) or when-not-to-use conditions, so it stops short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it explicitly flags the two most critical behavioral traits: DESTRUCTIVE and irreversible ('There is no undo'). It does not speculate about cascading side effects on linked accounting records, but for a single-parameter delete tool this is above-average disclosure.
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?
Two tight sentences with zero filler; the DESTRUCTIVE warning is front-loaded, followed by the action, the parameter clarification, and the irreversibility note. Every element 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 low-complexity tool (one required param, no output schema, no annotations), the description covers what it does, the endpoint, the identifier semantics, and the irreversible nature. It is complete enough for an agent to call it correctly; only speculative failure-mode detail (e.g., conflict with registered payments) could add more.
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 schema already documents id as 'Purchase invoice GUID / PIHId (required)'. The description reinforces this by restating that id is the PIHId, which adds only marginal value, so the baseline 3 for high schema coverage 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?
States a specific verb and resource ('delete a Merit Aktiva purchase invoice') plus the exact endpoint. It is plainly distinguishable from every sibling: no other tool deletes purchase invoices, and merit_delete_sales_invoice/merit_delete_payment are clearly separate resources.
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 'no undo' warning conveys that this should only be invoked when deletion is certain, which is implied usage guidance rather than explicit when-to-use advice. It does not name alternatives such as merit_get_purchase_invoice or merit_list_purchase_invoices for first locating the target, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It reveals the HTTP method and parameter formats, but it does not state whether the operation is read-only, what the response contains, or any data-scope limitations. Since the name and 'income statement' imply retrieval, it is not misleading, just incomplete on return behavior.
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?
Three short sentences with no filler: the first identifies the resource, the second defines the two required parameters, and the third notes the optional filter. Information is front-loaded and every sentence contributes.
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 report endpoint, all request parameters and their semantics are covered, and no output schema exists to shift that burden. The main gap is not describing the response shape or content, but the tool name and 'P&L' label provide enough context for an agent 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.
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 ISO date format and clarifies periodCount as months back, but the schema descriptions already convey these meanings; 'Optional departmentFilter' adds only minor value beyond the schema's optional field.
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 tool as an income statement / P&L report and provides the concrete endpoint, making the resource and operation clear. This differentiates it from sibling report tools such as sales, purchase, inventory, and balance reports by financial statement type.
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 opening phrase 'Income statement / P&L' provides clear context for when to use the tool: when a profit-and-loss or income statement report is requested. It does not explicitly list alternatives or say when not to use sibling report tools, but the unique P&L label makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the response includes rows and payments, and that skipAttachment omits the PDF for a smaller response, which is useful. It does not mention side effects, error behavior, or permissions, but the verb 'Get' strongly implies a read-only operation.
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 a concise two-sentence definition with no filler. Key details are front-loaded: the operation, resource, and response contents appear first, followed by the endpoint and parameter clarifications.
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 get-by-id tool with two parameters and no output schema, the description covers the essential semantics: what is returned and how to shrink the response. It could mention behavior for missing/invalid IDs or authentication needs, but these are less critical given the tool's simplicity.
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 coverage is 100% and the baseline is 3, the description adds value by specifying that skipAttachment omits the PDF and produces a smaller response. It also reinforces that id is the PIHId GUID, which helps the agent map the parameter to the intended API field.
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 clear, specific action: 'Get one Merit Aktiva purchase invoice with rows and payments'. It distinguishes itself from sibling listing tools by emphasizing 'one' invoice and from the sales invoice getter by specifying 'purchase'. The endpoint reference adds further precision.
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 this tool: when you need a single purchase invoice and its rows/payments. However, it does not explicitly name alternatives or state conditions for choosing this over merit_list_purchase_invoices or merit_get_purchase_invoice PDF-related tools. Usage guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the HTTP endpoint and the filter behavior, and 'List' implies a read-only operation. However, since no annotations are provided, the description carries the full burden for behavioral transparency and does not explicitly state whether the operation has side effects, requires authentication, or returns a particular shape.
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 one focused sentence followed by a compact parameter explanation. Every element is useful, and the core purpose 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?
For a simple read-only listing tool with one optional enum parameter, the description covers the purpose and the only parameter's possible values. It does not describe response contents in detail, but no output schema exists and the operation is straightforward enough that 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 100%, and the description essentially restates the same usageFilter semantics already present in the schema. It adds no meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a precise resource ('Merit Aktiva chart of accounts'), and the exact API endpoint. This clearly identifies what the tool does and distinguishes it from the many other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's use context clear: it is for listing chart-of-accounts data, and it explains how to filter via usageFilter. It does not explicitly name alternatives, but none of the sibling tools target the same resource, so selection ambiguity is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it adds useful wire-level context: the HTTP method/endpoint (POST /api/v1/getcostcenters) and the unrestricted scope ('No filters'). However, it does not explicitly state that the operation is read-only or describe the response shape, though 'List' strongly implies a non-destructive fetch.
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?
A single 12-word sentence with the verb and resource front-loaded, followed by the endpoint and the scope note. Every word earns its place; there is no filler or 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 zero-parameter tool with no output schema and no annotations, the description covers the essential facts: what is listed, the endpoint, and the lack of filters. The only minor gap is no explicit mention of the return payload format, but 'List cost centers' and the tool name make the expected result predictable.
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 tool has 0 parameters with 100% schema coverage, so the rubric baseline is 4. 'No filters' reinforces that no arguments are accepted, which is consistent with the empty input schema, and there are no undocumented parameters for the description to compensate for.
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 ('List') and resource ('Merit Aktiva cost centers') and adds the exact endpoint (POST /api/v1/getcostcenters). The resource is unique among the extensive sibling list, so an agent can distinguish it from tools like merit_list_locations or merit_list_departments 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?
No explicit when-to-use guidance is provided; the description does not name alternatives or contexts where this tool should or should not be chosen. 'No filters' is an invocation detail rather than usage guidance, so when to select it is only implied by its resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. 'List' and 'No filters' imply a non-destructive, complete read operation, but pagination, return shape, and authentication expectations are not addressed. Acceptable for a simple 0-parameter list tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire definition is one sentence with the action, endpoint, and a scope constraint. No filler or redundant phrasing.
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 zero-parameter list operation, the description provides the action, resource, endpoint, and filter behavior, which is enough to make the call. It does not describe the response structure, but the simplicity of the tool makes this 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?
There are zero parameters and the schema coverage is 100%, so the description has nothing to add. 'No filters' usefully confirms that an empty call is intended, matching the baseline for a parameterless tool.
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 specific verb 'List' and a clear resource ('Merit Aktiva sales discounts'), reinforced by the exact endpoint. This is enough to distinguish it from write-oriented siblings such as merit_send_discounts.
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 'No filters' clause conveys when this broad list is appropriate, but the description gives no explicit guidance about alternatives or when not to use it. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the POST endpoint and the no-filter behavior, which is genuinely useful. It does not, however, describe pagination, ordering, response shape, or whether results are cached — minor gaps for a zero-parameter list tool, but gaps nonetheless.
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?
Two terse, information-dense sentences with zero filler. The core purpose is front-loaded, the endpoint is parenthetically supplied, and the 'No filters' qualifier is a single unobtrusive sentence. Every word 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 zero-parameter, no-output-schema tool, the description covers what an agent needs to invoke it correctly: the action, the resource, the endpoint, and the absence of filters. It stops short of describing the returned data structure, but for a self-evident 'list employees' call that omission is minor.
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 zero parameters, the baseline is 4. The description adds the endpoint URL, which the empty input schema cannot convey, and confirms through 'No filters' that no query or filter parameters exist. This fully compensates for the schema's emptiness.
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: 'List Merit Aktiva fixed-asset responsible employees'. This clearly distinguishes it from sibling tools like merit_list_fixed_assets and merit_list_fixed_asset_locations, and the endpoint (POST /api/v2/getfaresppersons) removes all ambiguity about which operation is invoked.
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 'No filters' note gives useful context that this returns the full unqualified list, implying an agent that needs filtering must look elsewhere. However, it does not explicitly name any alternative tool or provide when-to-use/when-not-to-use guidance, so the agent must infer routing from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It correctly notes 'No filters', which is useful for a zero-parameter list operation, but it does not mention pagination, return format, authentication needs, or system-specific behavior.
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 a single sentence that wastes no words. It includes the endpoint, the resource type, and the key behavioral constraint ('No filters'), all front-loaded 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?
For a simple no-parameter list tool, the description is largely sufficient: it names the resource, provides the endpoint, and notes the absence of filters. It could be slightly more complete by indicating what the response contains, but the low complexity keeps the gap minor.
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 tool has zero parameters, so the baseline for parameter semantics is 4. The description adds value by stating 'No filters', confirming that the endpoint accepts no filter inputs and that all locations are returned.
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: 'List Merit Aktiva fixed-asset locations', and includes the endpoint. It clearly identifies what the tool does and distinguishes it from related siblings like merit_list_locations by specifying 'fixed-asset locations'.
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 the action 'List ... fixed-asset locations', but the description does not explicitly state when to prefer this over alternatives such as merit_list_locations or merit_list_fixed_assets. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly implies a read-only operation via 'List', but it does not disclose output format, pagination, or any side effects. For a simple zero-parameter list tool, this is adequate but minimal.
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?
A single, front-loaded sentence that contains exactly the needed information: what the tool lists, the endpoint, and the key limitation. No wasted words.
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 parameters, no output schema, and no annotations, the description is nearly complete. It gives the resource, endpoint, and filtering constraint. The only minor omission is explicit mention of return structure or pagination behavior, but these are less critical for such a simple list operation.
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 0 parameters and the schema is an empty object, so the baseline is 4. The description adds meaningful clarity by explicitly stating 'No filters', which prevents the agent from assuming query parameters are supported.
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 ('List'), a clear resource ('Merit Aktiva item groups'), and the underlying endpoint. It is easily distinguished from sibling tools like merit_list_customer_groups, merit_list_vendor_groups, and merit_create_item_groups.
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 'No filters' gives a clear constraint: use this tool when you need all item groups without filtering. However, it does not explicitly mention alternatives or provide when-not-to-use guidance, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the HTTP endpoint, precedence of id over other filters, partial matching behavior, numeric code meanings, and the effect of locationCode on returned quantity. It omits pagination and response format details, but the core behavioral quirks are well covered.
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 purpose, and organized by filter behavior. It contains some redundancy with the input schema, but the prose remains efficient and each sentence conveys relevant usage 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 description sufficiently explains how to construct a request and what filter semantics apply. However, with no output schema and no annotations, it does not describe the response shape, pagination, or result limits, leaving some ambiguity for an agent about what to expect after calling 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 parameter descriptions already document the codes, partial matching, and id precedence. The tool description mostly restates this information rather than adding new meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List/search Merit Aktiva items' with a specific verb and resource, and includes the exact endpoint. This clearly distinguishes it from sibling tools that list other entities like item groups, customers, or projects.
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 that this tool is for retrieving or searching items, with filter behavior explained. It does not explicitly name alternatives or exclusions, but the list/search purpose is unmistakable given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It conveys a read-only listing operation via 'List' and getpayments, and it adds useful behavioral constraints: period length cap and the meaning of dateType and Direction values. It does not cover pagination, response shape, or permissions, but for a simple list endpoint the key 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences deliver the verb, resource, endpoint, date constraints, and key enum meanings with no filler. The most important invocation constraints are front-loaded before the response-direction note.
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 flat 5-parameter list tool with no output schema, the description gives the essential call information: endpoint, required period format, maximum range, dateType semantics, and a key response field. It does not describe pagination or the full response shape, but an agent has enough context to invoke the tool correctly and interpret Direction values.
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 documents the parameters. The description adds small clarifications like 'ISO YYYY-MM-DD' and 'max 3 months apart,' but those are largely present in the schema. The Direction mapping is useful for interpreting responses, not for selecting input parameters, so it does not meaningfully raise this dimension.
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: 'List Merit Aktiva payments for a period.' It also gives the exact underlying endpoint, POST /api/v2/getpayments, which makes the operation unmistakable. Among the large sibling list, this is clearly distinct from list_payment_types, delete_payment, and payment-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The period-bound listing context is clear, and the required periodStart/periodEnd plus the 3-month constraint tell the agent how to frame a call. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions, such as 'for deleting payments use merit_delete_payment.' Usage is more implied than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds non-obvious context: the Merit API rejects periods longer than 3 months, and dateType 0 is the default. It does not mention pagination or response shape, but for a list read operation this is a minor gap.
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 and front-loaded with the core purpose, followed only by essential operational constraints. Every sentence earns its place, and there is no redundant or promotional language.
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 5-parameter list tool with no output schema, the description plus the fully documented schema gives an agent enough to invoke it correctly: required period fields, date format, range limit, and default dateType. It lacks explicit output/pagination details, but the core calling context is 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 input schema already covers all 5 parameters with 100% coverage, so the baseline is 3. The description adds a small amount of value by calling out the 3-month limit, the enforced rejection, and the default for dateType, but it largely restates schema 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 clearly states a specific action ('List') and resource ('Merit Aktiva sales invoices') scoped to a period, and includes the exact API endpoint. This distinguishes it from siblings like merit_list_sales_invoices_by_number_or_customer and merit_get_sales_invoice.
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 when a period-based invoice list is needed, and names no alternative. It does not explicitly state when not to use this tool or point to more specific siblings, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It adds the endpoint and 'No filters' behavior, and 'List' signals a read operation, but it does not describe response format, pagination, or any rate limits. Some transparency is present, but full behavioral context is missing.
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 a single, front-loaded sentence with no wasted words. The endpoint is parenthetical and the 'No filters' clarification is useful and direct.
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 zero-parameter listing tool, the description covers what is needed to invoke it: the endpoint and the absence of filters. It does not describe the return shape, but the low complexity and clear 'List' semantics make the definition reasonably 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?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description reinforces this by explicitly saying 'No filters,' leaving no ambiguity that no arguments are accepted.
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 ('vendor groups'), and includes the exact API endpoint. This clearly distinguishes it from sibling tools like merit_list_customer_groups or merit_list_vendors.
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 'No filters' implies the tool returns all vendor groups with no narrowing, which provides some usage context. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden. It does add useful context — 'create or replace' signals upsert semantics, and the targetGroup value mapping (0=campaign, 1=customer, 2=customer group) gives operational meaning. However, it does not disclose auth requirements, what identifies an existing row for replacement, failure behavior, or any destructive impact details.
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?
Two sentences, both load-bearing: the first states the operation and endpoint, the second the targetGroup enumeration. No filler words, and the core action is front-loaded ahead of the supporting detail.
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 write tool with no output schema and no annotations, the description covers the operation, endpoint, and the single most important semantic nuance (targetGroup values). The main gaps are that the array items are otherwise unspecified bare objects and the tool does not state how 'replace' matches existing rows, but the description addresses the highest-risk ambiguity.
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, prices, is already described in the schema ('Price rows (required)'), so the baseline is 3. The description adds real value by revealing the targetGroup field semantics inside price rows — 0 = campaign, 1 = customer, 2 = customer group — knowledge the schema (items typed as bare objects) does not provide.
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 specific verb phrase — 'Create or replace Merit Aktiva sales prices' — that identifies the exact resource and action, and pins it to the POST /api/v2/sendprices endpoint. This clearly distinguishes it from read-only sibling tools like merit_list_prices and merit_get_price.
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 sibling tool is named as an alternative. The verb 'Create or replace' implies this is the write path for price data while merit_list_prices and merit_get_price are the read paths, but that routing is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the mutation action and key constraints (entryRows structure, date format), but it does not mention the response, side effects, or permissions. This is more transparent than a bare 'create' but still leaves significant behavioral gaps.
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?
Three short sentences, no fluff. The purpose and endpoint are front-loaded, followed by the two most important usage details. 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 moderate-complexity creation tool with no output schema, the description covers required parameters and formats well. However, it does not explain what the API returns (e.g., batch ID) or what happens on success or failure, which is a notable completeness 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?
Schema coverage is 75%, and the description adds critical meaning to the most complex parameter: entryRows need accountCode plus debit and/or credit. This goes well beyond the vague schema description 'GL lines (required).' It also reinforces the ISO date format for batchDate.
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: 'Create a Merit Aktiva general-ledger batch,' plus the exact API endpoint. This clearly distinguishes it from sibling tools like merit_list_gl_batches and merit_get_gl_batch by focusing on creation.
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 this as the tool for creating GL batches and gives the mandatory input shape (entryRows with accountCode and debit/credit). It doesn't explicitly name alternatives, but the create-versus-read distinction among siblings is implicit and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the operation creates items and returns an array of {ItemId, Code}. However, it does not mention potential side effects like idempotency, validation errors, authentication requirements, or whether existing items can be overwritten. The return format is useful but the behavioral disclosure is only partial.
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: two sentences that cover the operation, endpoint, required fields, conditional requirement, and return value. Information is front-loaded and there is no redundant 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?
For a tool with a nested object array and no schema detail, the description provides the essential fields and return format, making it actionable. It lacks enumeration of optional fields and error handling, but is sufficient for basic item creation. The output schema is absent, but the return shape is described, reducing ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single array parameter with a generic description ('Items to create (required)'). The tool description enriches this dramatically by specifying required fields (type, usage, code, description), enum values for type and usage, and the conditional requirement (uomName for stock items). This is essential for constructing valid input and goes well 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 clearly states the tool creates Merit Aktiva items, including the exact POST endpoint. The verb 'Create' and resource 'items' are specific, and it naturally distinguishes from siblings like merit_update_item and merit_create_item_groups by the action and target.
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 create items but does not explicitly state when to use it versus other item-related tools (e.g., merit_update_item for changes). It provides field requirements but no context on when to select this tool over alternatives, such as prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It adds valuable context by disclosing the API endpoint, the required fields, the numeric mapping for deprCalcMethod, and the non-obvious wire-format spellings 'InventaryNo' and 'FAFroupName'. It does not disclose response behavior, idempotency, or error handling, which would strengthen a mutation tool, but it goes well beyond a bare 'Create fixed assets' statement.
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 three tight sentences with no filler. Each sentence serves a distinct purpose: stating the operation and endpoint, listing required fields, and documenting enum values plus the spelling caveat. Information is front-loaded and 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?
The description covers core input guidance and a critical quirk, but the tool has no output schema and no annotations, so more context is needed about return values, error behavior, or partial failure handling. Optional fields beyond inventoryNo, name, and deprCalcMethod are not mentioned, leaving uncertainty about whether additional properties are accepted. For a single-parameter create tool the essential payload guidance is present, but the operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says 'fixedAssets' is an array of objects, leaving the item structure entirely undefined. The description compensates by specifying that each asset needs inventoryNo and name, explaining the deprCalcMethod enum values, and calling out the exact wire spellings. This is essential meaning that the schema alone cannot convey.
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 operation 'Create Merit Aktiva fixed assets' and includes the exact endpoint, making the action and target resource unambiguous. It names required fields, which clearly distinguishes this creation tool from sibling read-only tools like merit_list_fixed_assets. The specificity leaves no doubt about what the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
When to use this tool is implied by the name and 'Create' verb, but there is no explicit comparison to alternatives such as merit_list_fixed_assets or merit_list_fixed_asset_locations. The description focuses on how to build the payload rather than when to select this tool over siblings. An agent could infer usage, but the tool would benefit from an explicit 'use this when creating fixed assets' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does it well: immutability, negative quantities for credit invoices, inline customer creation, and required payload semantics. It does not cover permissions or whether the endpoint triggers any sending side effect, so not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with no filler. The endpoint, core constraints, and required fields are front-loaded, and 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?
The description never explains the internal structure of invoiceRows or taxAmount items, whose schemas are empty objects, so an agent cannot reliably construct them. There is also no output schema or response information, which is a significant gap for a 13-parameter mutation tool.
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?
Adds meaning beyond the schema: negative quantity/totalAmount for credit invoices, existing Id vs new-customer record shape, totalAmount as ex-VAT, and ISO date format. Schema coverage is only 62%, and nested taxAmount/invoiceRows items are untyped, so this added context is valuable, though several parameters remain undocumented.
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?
Opens with the specific action 'Create' and names the exact resource: 'Merit Aktiva sales invoice', also giving the endpoint POST /api/v2/sendinvoice. This clearly separates it from list/get/delete/email invoice 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?
Explicitly says invoices cannot be updated and prescribes delete-and-recreate, which is a strong when-not-to-use signal. It also gives credit-invoice guidance and required fields, though it does not name sibling alternatives like creating from a sales offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it does a good job: it explicitly labels the operation 'DESTRUCTIVE' and states 'There is no undo', disclosing the irreversible nature. It does not mention permissions or side effects on related data, but for a single-parameter delete operation the core behavioral risk is well covered.
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?
Three short sentences with no filler: a destructive warning, the action and endpoint, the parameter identity, and an irreversibility note. Every word earns its place and the most important information 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?
For a tool with one required parameter, no output schema, and no annotations, the description covers the essential knowledge needed to select and invoke it: what it deletes, the endpoint, the id, and the irreversible consequence. It doesn't specify error behavior or preconditions, but those are minor for such a simple 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 already documents the only parameter as 'Payment GUID (required)' with 100% coverage, so the description's restatement 'id is the payment GUID' adds no new meaning. The baseline of 3 applies because the schema does all the heavy lifting and the description merely echoes 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 states a specific action ('delete a Merit Aktiva payment') with the resource and the exact endpoint, making it unmistakably distinct from sibling payment tools like list or create. The leading 'DESTRUCTIVE' flag plus 'There is no undo' reinforces the intent. No ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use this tool when you need to permanently delete an existing payment, and the warning 'There is no undo' advises caution. It does not explicitly name alternative tools or when not to use it, so it falls short of a 5, but the context is clear and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return shape ('FileName + FileContent'), base64 encoding, and the delivNote behavior. The use of 'Get' and 'Returns' strongly implies a read-only operation, though it does not explicitly state safety or error behavior. This is adequate for a simple retrieval 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?
Three short sentences convey the core action, return format, and parameter variant with no filler. The most important information (get PDF as base64) is front-loaded, and each sentence adds necessary detail.
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?
Despite having no output schema and no annotations, the description covers the essential return values ('FileName + FileContent') and the effect of the optional parameter. It could be more explicit about read-only behavior and potential errors, but for a two-parameter retrieval tool with 100% schema coverage, the description is sufficiently 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 100%, so the baseline is 3. The description adds minimal meaning beyond the schema: 'Set delivNote for a delivery note without prices' essentially repeats the schema parameter description, and 'id' is not elaborated beyond being required. No significant extra value is 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 states a specific verb ('Get'), a specific resource ('sales invoice PDF'), and the output format ('base64'), plus the exact endpoint. It clearly distinguishes itself from sibling 'merit_get_sales_invoice' by emphasizing PDF and base64, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for retrieving invoice PDFs, and the delivNote line explains a key usage variant. It does not explicitly name alternatives or state when not to use it, but the PDF/base64 emphasis provides enough contextual routing among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals the HTTP verb (POST) and that there are no filters, but it does not describe response format, pagination, authentication requirements, or whether banks and payment methods are returned together. For a simple read-only list operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the resource, endpoint, and filtering behavior with no wasted words. Every element 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 zero-parameter list operation, the description provides the essential details: the resource, endpoint, and lack of filters. It is slightly thin on return-value details, but given the tool's simplicity and the absence of an output schema, nothing critical 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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter ambiguities. The description reinforces this with 'No filters,' which adds practical confirmation that no input is needed.
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 ('List'), a clear resource ('Merit Aktiva banks / payment methods'), and includes the exact API endpoint (POST /api/v1/getbanks). It also notes 'No filters,' making the scope explicit and distinguishing it from filtered list 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 implies when to use this tool: whenever an unfiltered list of Merit Aktiva banks or payment methods is needed. It does not explicitly name alternatives or exclusion conditions, but the zero-parameter, no-filters context makes usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses that the call takes no filters and identifies the endpoint, which implies a read-only listing operation. However, it does not mention permissions, response shape, pagination, or any rate-limit expectations. For a simple list tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and resource, then adds the endpoint and the key behavioral constraint. Every word earns its place with no 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 zero-parameter list tool with no output schema, the description covers the essential facts: what it returns conceptually, the endpoint, and the absence of filtering. It could additionally describe the response structure or pagination, but such omissions are minor given the tool's simplicity.
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 tool has zero parameters and the schema is empty, so parameter documentation is inherently unnecessary. The description reinforces this with 'No filters,' making it clear that no input is required. This matches the baseline for zero-parameter tools.
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 exact action ('List'), the resource ('departments'), and the product context ('Merit Aktiva'), and even includes the endpoint. This clearly distinguishes it from the many sibling list tools that target different resources like locations, banks, projects, and customers.
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 usage context clear: call this when you need the full list of Merit Aktiva departments, with no filters. It does not explicitly name alternatives, but the resource name is unique among siblings and there is no competing department-list variant, so the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. It reveals the endpoint, the read-style list nature, and the absence of filters, but does not mention ordering, pagination, whether inactive periods are included, or any response-level behavior. For a zero-parameter list operation this is workable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence conveys the resource, endpoint, and filtering behavior without unnecessary detail. The most useful information 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?
For a no-argument list tool, the description covers what the tool lists and the key constraint of no filters. It does not detail output fields, ordering, or pagination, but the absence of an output schema and the trivial invocation make this 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 has zero parameters and 100% schema coverage, so there is little for the description to add. The explicit 'No filters' statement usefully confirms that the tool accepts no invocation arguments.
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 ('List') and a specific resource ('Merit Aktiva accounting periods / financial years'), and adds the endpoint. This distinguishes it from the many sibling list tools, each of which targets a different 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?
It clearly indicates this tool is for enumerating financial years/accounting periods and notes that no filters apply. It does not explicitly name alternatives or exclusions, but no sibling covers the same resource, so the usage context is effectively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the operation type and explicitly says 'No filters,' which is helpful, but it does not mention pagination, response format, authentication requirements, or the potential size of the returned dataset. For a simple read-only list this is minimally adequate but not fully transparent.
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 a single, front-loaded sentence that states the action, resource, endpoint, and a key constraint. Every word earns its place, and there is no redundancy or wasted 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 zero-parameter list tool with no output schema, the description is nearly complete: it names the resource, gives the endpoint, and explicitly states the lack of filters. It could add a note about response shape or pagination, but the absence of those details is a minor gap given how simple this tool is.
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 is empty, and the description reinforces this by stating 'No filters,' which explains why no parameters are accepted. With zero parameters there is little semantic work to do, and the description adds just enough meaning beyond the empty 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 a clear resource ('Merit Aktiva fixed assets'), and also includes the exact endpoint ('POST /api/v2/getfixassets'). It is immediately distinguishable from sibling tools like merit_list_fixed_asset_locations and merit_create_fixed_assets.
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 'No filters' clearly tells the agent that this tool returns the full, unfiltered set of fixed assets, which is useful context for when to call it. It does not explicitly name alternatives or state when not to use it, but the resource-specific naming and clear scope make the usage context fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context about the API endpoint, the fact that there are no filters, and the exact return fields. However, it does not explicitly state whether the operation is read-only, whether pagination is involved, or whether any authentication or permissions are required. For a zero-parameter list tool this is a moderate gap, but the word 'List' implies a read operation.
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 whole description is one tight, front-loaded sentence. It immediately states the action and resource, then adds the endpoint, a filter guarantee, and the return summary. Every clause 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 zero-parameter, no-output-schema list tool, the description gives the agent enough to call it correctly: no filters, endpoint, and return fields. Minor omissions like explicit read-only confirmation or pagination behavior exist, but they do not block correct usage for a straightforward list operation.
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 tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds value by explicitly stating 'No filters', which reinforces that the agent should not attempt to pass filtering arguments. Nothing further is needed.
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 ('List'), a concrete resource ('Merit Aktiva stock locations'), and the HTTP endpoint, which unambiguously identifies the operation. It also states 'No filters', distinguishing this from more complex list tools and making it easy to differentiate from sibling tools such as merit_list_fixed_asset_locations.
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 that this tool is for retrieving stock locations with no filtering, and the return fields are specified. It does not explicitly name alternative tools or define exclusion criteria, but the resource type is distinctive enough that an agent can infer when to use this versus other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly signals a read-only listing operation, names the underlying POST endpoint, and discloses the important max-3-months constraint and dateType behavior. It does not mention pagination, response shape, or authentication needs, but these are minor gaps for a list operation.
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 and well-structured: purpose first, then constraints, then sibling disambiguation. Every sentence carries useful information, with no filler or redundancy beyond acceptable reinforcement of schema details.
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 provides the endpoint, required period constraints, dateType meanings, and a sibling distinction. With no output schema, return shape and pagination are not described, but for a straightforward filtered list operation the description plus full parameter schema coverage is enough for an agent to select and 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?
Schema description coverage is 100%, so the schema already documents every parameter. The description repeats periodStart/periodEnd format and dateType meaning but adds no new semantic value beyond the schema. The unPaid parameter is only explained in the schema, not in the description, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('Merit Aktiva purchase invoices'), and a scope ('for a period'). It also names the endpoint and explicitly distinguishes itself from merit_list_purchase_orders, so an agent can differentiate it from the most confusable sibling 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 explicitly identifies the key alternative, merit_list_purchase_orders, and the condition that separates them ('waiting-approval'). It also provides practical usage constraints like the 3-month maximum period and dateType semantics. It does not give exclusion guidance for single-invoice retrieval, but that is reasonably inferable from the sibling name merit_get_purchase_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It transparently exposes the HTTP method/endpoint, the meaning of dateType, and the 180-day maximum period. The word 'List' also implies a read-only operation, though pagination and output format are not described.
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 two sentences with no filler. It front-loads the action and resource, then gives the key constraints and dateType definitions. Every sentence adds useful 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 list operation with three well-documented parameters, the description is largely complete: it names the endpoint, required date semantics, and the critical 180-day bound. An output schema is absent, so a brief note on the return shape or pagination would improve completeness, but it is not essential for making a correct call.
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 schema already documents each parameter. The description adds value by clarifying that the period refers to the next-invoice date and by restating the dateType semantics in prose, which helps an agent interpret periodStart and periodEnd 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?
The description clearly states the tool's function: 'List Merit Aktiva recurring invoices'. It also includes the exact API endpoint, making the operation unambiguous. The verb 'List' distinguishes it from sibling tools like merit_get_recurring_invoice or merit_create_recurring_invoice.
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 listing recurring invoices over a period, but it does not explicitly mention alternatives or when to prefer this over merit_get_recurring_invoice. The 180-day limit and dateType options provide useful boundary conditions, but there is no explicit when-to-use/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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It conveys a read-only listing operation, states that no filters are supported, and provides the underlying HTTP endpoint. It does not mention pagination, ordering, or authentication, but for a simple parameterless list the behavior is sufficiently clear.
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 a single front-loaded sentence that includes the resource, operation, endpoint, and a key limitation with no wasted words. Every element 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?
For a zero-parameter, simple list tool, the description is largely complete: it names the resource, the verb, the endpoint, and the lack of filters. It could optionally describe the expected return shape, but no output schema exists and the absence of parameters lowers the complexity enough that this is not a major 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 tool has zero parameters and the schema already covers them, matching the baseline of 4 for parameterless tools. The description reinforces this with 'No filters,' confirming there is nothing to configure or pass in.
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 operation: listing Merit Aktiva units of measure, and even includes the exact endpoint. This clearly differentiates it from the many sibling merit_* list tools, none of which target units of measure. The resource 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for listing units of measure and notes that there are no filters, which gives basic context for when to use it. However, it does not explicitly discuss alternatives or say when not to use this tool, leaving usage guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It adds meaningful detail: the endpoint, invoice identification via customerName + invoiceNo, the bankId-or-IBAN requirement, the ISO date format, and that partial payments are allowed. It does not describe response behavior or error cases, but the core mutation semantics are well disclosed.
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 and front-loaded: it opens with the core action and endpoint, then gives only the essential constraints in short sentences. Every sentence adds useful information with no filler or repetition of schema content.
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 mutation tool with no annotations and no output schema, the description covers the key invocation details: endpoint, identification, payment method constraints, date format, and partial payments. The main gap is the absence of any indication of what a successful response looks like, but the provided guidance is sufficient for selecting and calling the tool 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?
Schema coverage is high at 88%, so the schema already documents most parameters. The description adds valuable relational context beyond the schema: bankId or IBAN are alternatives, IBAN must match a known payment method, and customerName + invoiceNo together identify the invoice. This helps the agent understand how the parameters relate.
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: 'Record a payment against a sales invoice', reinforced by the endpoint POST /api/v2/sendpayment. It clearly identifies the target as a sales invoice payment, distinguishing it from siblings like merit_create_purchase_invoice_payment and merit_create_sales_offer_payment.
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 clear this is for recording payments against sales invoices specifically, and the sibling names help disambiguate it from purchase-invoice and sales-offer payment tools. It does not explicitly state when not to use it, but the context is clear enough that an agent can select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses automatic pagination following getmoredata, the required date range, and flags a wire typo (CurrncyCode). This is meaningful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: identify the endpoint, describe pagination and automation, and state requirements plus a gotcha. No wasted words.
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 report tool with 100% schema coverage and no output schema, the description conveys the call surface, required inputs, pagination behavior, and a field-name quirk. It could mention the response structure, but that is not required given the absence of an output schema emphasizes the unknown return shape.
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 describes all parameters with 100% coverage. The description adds value by clarifying the typo in the wire field name, emphasizing that periodStart/periodEnd are required, and noting the pagination parameter behavior. This is more than the schema alone would provide.
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 it is a customer payments report via a specific endpoint (POST /api/v2/getcustpaymrep), and distinguishes it through pagination behavior. The tool name itself is descriptive, and the description confirms the resource and 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?
It states the required parameters (periodStart/periodEnd) and describes pagination behavior explicitly (HasMore/Id4More, automatic getmoredata). It doesn't explicitly say when to choose this over sibling report tools, but the uniqueness of the endpoint and pagination note provide enough usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it discloses useful behavior: endpoint (POST /api/v2/getinvoice), returned content (rows and payments), and the base64 PDF payload with a 'large' warning. It doesn't discuss auth or error cases, but 'Get' plus these details make behavior predictable enough.
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?
Two tight sentences, with the main purpose first and parameter guidance second. No redundant words; the endpoint and size warning 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 simple 2-parameter read tool, the description covers what is returned, the id source, and the optional heavy attachment. It is missing an explicit cross-reference to get_sales_invoice_pdf for PDF-only needs, which would make it fully 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 coverage is 100%, so baseline is 3, but the description adds value by explaining id as the SIHId GUID from list tools and specifying that addAttachment returns the invoice PDF as base64 and may be large. This is more than the schema's generic 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 'Get one Merit Aktiva sales invoice with rows and payments' – a specific verb, resource, and content scope. 'One' explicitly distinguishes it from list siblings, and including rows/payments sets it apart from PDF-only retrieval.
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?
Tells the agent where the id comes from ('SIHId from the list tools') and how to request the PDF ('Set addAttachment'), giving clear invocation context. It does not explicitly name the alternative get_sales_invoice_pdf or state when not to use this tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the safety burden. It uses a read-only verb ('List') and a get-style endpoint, and it discloses that setting allValues includes inactive/ended values. It does not mention authentication, rate limits, or output shape, but for a simple read-only enumeration this is reasonably transparent.
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?
Two concise sentences: the first front-loads the purpose and endpoint, the second explains the only parameter behavior. There is no redundant or filler wording.
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 list operation with no output schema, the description says what is returned (dimensions and their values), how to include inactive/ended values, and the endpoint. It does not state the default value of allValues or pagination behavior, but those are minor gaps for this simple tool.
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 describes allValues at 100% coverage, so the baseline is 3. The description adds meaningful semantics by explaining that 'all values' specifically means including inactive/ended values, which goes beyond the schema's generic 'Include all dimension 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 action ('List'), the resource ('Merit Aktiva dimensions and their values'), and the exact endpoint (POST /api/v2/getdimensions). None of the many sibling list tools target dimensions, so the tool 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is plain: retrieve Merit Aktiva dimensions and their values. The allValues note adds the one conditional behavior. It does not explicitly name alternatives or when-not conditions, but there is no overlapping sibling tool, so this is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries a heavier burden, and it does disclose key behaviors: it is a one-call endpoint that can include entries and cost allocations, and the default-off behavior for optional flags. It does not disclose pagination, output shape, or side effects, but it is a list operation and the 'max 31 days' constraint adds concrete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose, then adds the endpoint path and the two most important operational details (31-day limit, default flags). Every sentence contributes useful information and nothing is wasted.
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 list operation with no output schema and no annotations, the description explains the essentials: what it returns (batches with entries/cost allocations), the one-call value, the date limit, and default flag behavior. It could mention response shape or error behavior, but the tool is relatively simple and the key calling decisions are covered.
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 value by clarifying that the period constraint is max 31 days and that withLines/withCostAlloc default off when omitted, which maps directly to parameter behavior. It does not add a usage example, but it exceeds the baseline by interpreting the parameter options.
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 ('List Merit Aktiva GL batches with entries and cost allocations in one call') and identifies the endpoint (POST /api/v1/GetGLBatchesFull). It distinguishes itself from sibling tools by emphasizing the 'full' one-call behavior and the optional includes, which sets it apart from merit_list_gl_batches and merit_get_gl_batch.
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 states the period constraint ('Period max 31 days') and notes that withLines/withCostAlloc default off when omitted, which helps an agent decide input values. It does not explicitly name alternatives or say 'use X instead', but the context makes the intended use clear relative to the sibling GL batch tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates this is a read-only list operation, explicitly says there are no filters, and reveals the edge-case behavior: 'Empty when none are open.' It also exposes the REST endpoint. It doesn't mention response format or side effects, but the simple list semantics are adequately conveyed.
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?
Two sentences with zero wasted words. The main purpose is front-loaded, followed by the endpoint and the empty-case behavior. No redundant phrasing or unnecessary detail.
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 zero-parameter, no-output-schema list tool, the description covers the operation, endpoint, and empty behavior. It does not detail the fields of the returned addresses, but given the tool's simplicity and the self-explanatory name, this is a minor gap rather than 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 tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description reinforces the empty schema with 'No filters,' explaining why no arguments are needed. This adds a small but meaningful confirmation beyond the schema itself.
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: 'List client addresses for open Merit Aktiva recurring invoices'. It also names the underlying endpoint, making the tool's function unmistakable. This clearly distinguishes it from sibling tools like merit_list_recurring_invoices, which list the invoices themselves rather than their addresses.
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 tool when you need client addresses tied to open recurring invoices. It also states 'No filters,' signaling that this is an unfiltered bulk retrieval. It does not explicitly name alternatives or exclusions, but the narrow scope and unique resource make the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does reasonable work: it discloses the HTTP method (POST), that filtering is by number and/or customer, that a period is not required, and that the output serves to locate an invoice's GUID. For a simple read-style list tool this is solid behavioral disclosure; it does not address pagination or full response shape, but the core 'what happens when called' behavior is transparent.
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?
Two tight sentences with zero filler. The first is front-loaded with the verb, resource, filter, and endpoint; the second adds parameter guidance and the tool's purpose. Every clause 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 low-complexity tool (3 optional string params, no nested objects, no output schema, no annotations), the description covers the essentials: what it lists, how to filter, what not to provide, and why to call it. The only gap is that the full response shape is not described beyond the SIHId/GUID purpose, but that is minor given the tool's simple lookup nature.
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% with each parameter already described (including wire field mappings InvNo, CustId, CustName), so the baseline is 3. The description adds value beyond the schema by clarifying the 'or' relationship among the three parameters — any one can be provided and no period is needed — which the schema's independent property descriptions do not convey.
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 ('List'), a clear resource ('Merit Aktiva sales invoices'), and a precise filtering scope ('by invoice number and/or customer'), plus the exact HTTP endpoint. It distinguishes itself from the plain merit_list_sales_invoices sibling by emphasizing the filter basis, and from merit_get_sales_invoice by framing its purpose as finding an invoice's GUID (SIHId) rather than retrieving an already-known invoice.
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: supply any of invoiceNo, customerName, or customerId, and notes that no period is needed — a useful exclusion that prevents an agent from passing a date range common to other list tools. It also states the use case (finding a specific invoice's GUID), but does not explicitly name alternative tools or say when NOT to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the HTTP method and endpoint, confirms no filters, and tells the agent exactly which fields are returned ('Code, Name, EndDate'). This gives a clear read-only listing behavior without requiring the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler. The action and resource appear first, followed by the endpoint, the filtering constraint, and the return fields. Every element 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 zero-parameter list tool with no output schema, the description fully covers what the agent needs: what it does, how it is invoked, what constraints apply, and what the response contains. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with no parameters, and the description reinforces that by saying 'No filters'. This prevents an agent from inventing or expecting unsupported parameters, adding meaningful semantic clarity beyond the empty 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 ('List'), a specific resource ('Merit Aktiva projects'), and the exact endpoint ('POST /api/v1/getprojects'). 'No filters' further defines scope, and no sibling tool targets projects, so 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool to use when a project listing is needed and explicitly states that no filters are supported. It does not name alternatives or exclusion conditions, but the resource is unique among the large sibling set, so little ambiguity exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the operation lists all rates, takes no filters, uses a specific POST endpoint, and returns a defined set of fields with the important note that Id is the TaxId GUID used on invoice rows. This is sufficient for a simple read-only enumeration, though it does not mention auth or rate limits.
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?
Two sentences, front-loaded with the verb and resource, and every clause adds value: scope, filter behavior, endpoint, and return fields. No filler or repetition of the tool name beyond the opening phrase.
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 zero-parameter listing tool with no output schema, the description is complete: it names the resource, states there are no filters, and documents exactly what the response contains, including the semantic role of Id. An agent can call this tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is empty, so the baseline is already 4, and the description adds the explicit statement 'No filters'. This confirms the empty parameter list and prevents an agent from inventing filter parameters; it also adds the endpoint 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 states a specific action, 'List all Merit Aktiva tax (VAT) rates', names the endpoint, and lists the returned fields. This clearly distinguishes it from the many other merit_list_* siblings because it names the exact 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?
It gives clear context: the tool returns all tax rates with no filters, so an agent knows to choose it when it needs the complete VAT rate table. It does not explicitly name alternatives or state when not to use it, but the zero-parameter scope makes the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that unfiltered responses can be very large, defines filter precedence, and specifies exact/partial matching and ISO date formatting. It does not describe pagination or output shape, and omits whether the endpoint is read-only — but the description's stated behavior is clear and aligned with its list/search purpose.
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?
Three sentences with no filler. The core purpose is stated first, the large-result warning is front-loaded, and the most important matching semantics are packed into the final sentence. Every sentence contributes operational guidance.
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 list/search tool with 5 optional params and no required fields, the description covers the essential selection semantics, filter precedence, scale warning, and date format. It lacks only minor operational details like pagination, sorting, and returned fields, but those would typically belong to an output schema; without one, an agent still has enough to invoke the tool 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?
Schema coverage is already 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema: id wins over other filters, regNo/vatRegNo match exactly while name matches partially, and dates are ISO YYYY-MM-DD. This gives an agent matching semantics it could not infer from parameter names alone. It slightly overlaps with schema descriptions (e.g. partial/exact labels) but the precedence and date-format guidance are genuine additions.
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-resource pair (list/search Merit Aktiva vendors), cites the actual endpoint, and differentiates itself from other merit_* siblings that target invoices, customers, or accounts. The no-filters-returns-all caveat further sharpens what the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises preferring a filter when possible, states precedence rules (id wins over others), and distinguishes exact vs partial matching (regNo/vatRegNo exact, name partial). This gives an agent concrete criteria for selecting and tuning the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It warns that unfiltered calls may return very large lists or even fail to serialize, and it documents exact vs partial matching and ISO date formats. This meaningfully exceeds bare schema information.
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?
Four compact sentences, front-loaded with the tool's purpose and endpoint, followed only by high-value caveats and matching rules. There is no filler or redundant restating of the parameter schema.
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 read/list tool with no output schema and no annotations, the description covers the key operational concerns: default behavior, scale risks, filter precedence, matching semantics, and date formatting. The parameter descriptions fill in the remaining field-level details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantic value beyond the schema: id wins over all filters, regNo/vatRegNo are exact matches while name is partial, and date format is ISO. These interaction rules are not evident from the 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 uses a specific verb-resource pair ('List/search Merit Aktiva customers') and includes the exact endpoint. It is clearly distinct from sibling tools like create_customer or customer debt reports.
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 gives strong situational guidance: use filters to avoid huge result sets, and explains filter precedence and matching behavior. It does not explicitly contrast with alternative retrieval tools, but the filter guidance is clear enough for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![merit-aktiva-mcp MCP server](https://glama.ai/mcp/servers/werkstatt-jasper/merit-aktiva-mcp/badges/card.svg)](https://glama.ai/mcp/servers/werkstatt-jasper/merit-aktiva-mcp)

Score Badge

Copy to your README.md:

[![merit-aktiva-mcp MCP server](https://glama.ai/mcp/servers/werkstatt-jasper/merit-aktiva-mcp/badges/score.svg)](https://glama.ai/mcp/servers/werkstatt-jasper/merit-aktiva-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/werkstatt-jasper/merit-aktiva-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server