Buchhaltungsbutler MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, e.g., between receipts_upload and receipts_add (both add receipts) and between multiple posting add tools. However, descriptions clarify differences, so confusion is minimal.
Naming Consistency3/5
Naming is mostly verb_noun with underscores, but there are inconsistencies like 'add' vs 'create' (e.g., transactions_add vs invoices_create) and 'batch' naming (transactions_addBatch vs settings_add_batch_creditors). Plural/singular also varies.
Tool Count2/5
With 48 tools, the server is overloaded. While the accounting domain has many entities, this count is higher than typical MCP servers and may overwhelm agents. Some tools could be merged (e.g., batch and single variants).
Completeness3/5
The tool set covers many CRUD operations for most entities, but notable gaps exist: no update or delete for transactions, no update for receipts, no delete for postings, accounts, or settings. This may force agent workarounds.
Average 3.6/5 across 48 of 48 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 6, 2026
- 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?
The description repeats the idempotentHint and mentions it creates data, but the claim that it creates receipts, transactions, etc. is inaccurate for an accounts_add tool, misrepresenting its behavior. This reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats 'Add a basic account' and includes a lengthy generic first sentence that is not specific to this tool, making it somewhat verbose and less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is insufficient. It does not explain what a basic account is, how it differs from other account types, or what the result looks like.
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 baseline is 3. The description adds no parameter-level details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a basic account' but the preceding generic statement 'Creates new records (receipts, transactions, postings, invoices, master data)' is overly broad and misleading, confusing the tool's actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'accounts_get' or other account-related tools. No prerequisites or business context 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?
Annotations already indicate non-idempotent and write. The description adds 'Not idempotent — calling twice may create duplicates', which is consistent and adds some value. However, no further behavioral traits beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a generic preamble about creating records, which is partially redundant with the tool-specific line. Could be streamlined into a single focused sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 29 parameters and the absence of an output schema, the description does not explain return values, side effects beyond duplicates, or parameter interactions. For a complex tool, this is insufficient.
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 provides full parameter information. The description does not add any additional parameter meaning beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'create invoice draft for the specified customer', which is a specific verb and resource. It distinguishes from sibling tools like invoices_create by mentioning 'draft', but does not explicitly differentiate from invoices_create_e_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like invoices_create or invoices_create_e_invoice. The idempotency warning is behavioral, not usage context.
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 adds the warning 'Not idempotent — calling twice may create duplicates' beyond the annotations, which declare idempotentHint false. However, it does not describe return values, error handling, or effects on other entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase 'add multiple free postings' is repeated verbatim, creating redundancy. The generic write warning at the start may not be specific to this tool, wasting 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?
No output schema is provided, and the description does not explain what the tool returns on success or failure. For a batch write operation, details on atomicity, partial success, or errors are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context that free_postings follow the same validation as the single-free-posting endpoint, but otherwise adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'add multiple free postings' which is a specific verb-resource pair. However, it does not distinguish from the sibling 'postings_add_free' which adds a single free posting, relying on the name to imply batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'postings_add_free' or other batch posting tools. The description does not mention prerequisites or context.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds minimal value by stating 'WRITE · updates data' and 'modifies existing master data in place', but it does not disclose error handling, authentication needs, or rate limits. The endpoint URL is provided but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses emoji/bold for emphasis. It includes the endpoint but repeats the tool name. It is concise and front-loaded with the purpose, though slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return value or success indicators, but it does not. It also lacks context about the tool's role among siblings (e.g., only for existing records). The description is too minimal to be considered 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 schema fully describes all three parameters. The description adds no additional details beyond what the schema provides, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a postingaccount' with a verb and resource. However, it does not explicitly distinguish from sibling tools like settings_add_postingaccount or settings_get_postingaccounts, though the verb 'update' inherently differentiates it from creation or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., settings_add_postingaccount for creation, settings_get_postingaccounts for listing). The description lacks any context about prerequisites or typical scenarios.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description repeats the read-only nature but adds minimal behavioral context beyond that (e.g., response returns an array of receipt data). It does not elaborate on rate limits, required permissions, or error conditions. The description adds little value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with repetitive elements (emoji, bold title, endpoint). It contains three sentences plus the endpoint line; some parts are unnecessary (e.g., repeating the tool name). Could be more concise and front-loaded.
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 output schema, the description mentions that the response includes an array of receipt data but lacks details about receipt fields or pagination. It also does not summarize parameter purposes beyond what the schema provides. Given the tool's simplicity, it is marginally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with both parameters (api_key and get_file) fully described. The description adds no additional meaning or syntax details for these parameters beyond what the schema provides. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('a single receipt for a specified customer account by id_by_customer'). It explains the need to first retrieve the identifier from another endpoint. However, the name and title are redundant and confusing ('id_by_customer' is awkward), and it does not explicitly contrast with siblings like receipts_get.
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 mentions how to obtain the required identifier ('using /receipts/get method first'), which provides a prerequisite. But it does not specify when to use this tool over alternatives (e.g., receipts_get) or when not to use it. No explicit when-to-use or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes.' and 'get all the accounts', which clarifies scope (all accounts) but adds no new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'get all the accounts' appears twice. The first line with emoji is unnecessary. It could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-all tool with one optional param and no output schema, the description covers the basic function. However, it omits details like return format, pagination, or filtering capabilities, which would help given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional parameter (api_key) with good detail. The tool description adds no parameter information, so it provides no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches data' and 'get all the accounts', indicating it retrieves all account records. However, it does not differentiate itself from other get tools like cost_locations_get or postings_get, relying solely on the tool name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., if only a subset of accounts is needed). The description only emphasizes read-only nature, which is already covered by annotations.
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?
Annotations already declare write (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description reinforces these by noting it creates data and is not idempotent, adding the explicit warning about duplicates. This adds some context but does not disclose additional behaviors beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise with two clear parts: a generic note and a specific statement. Uses emoji and bold for emphasis, but some redundancy exists (e.g., duplicates 'creates' and 'create'). Could be slightly trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 32 parameters, no output schema, and numerous sibling tools for invoice creation, the description lacks contextual completeness. It does not explain how this differs from draft or e-invoice tools, nor does it outline typical usage scenarios. The high schema coverage partially compensates, but the tool's role in the broader system is unclear.
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 baseline is 3. The description does not elaborate on any parameter meaning beyond the schema; it only says 'Add an invoice for the specified customer', which does not add semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates an invoice for a specified customer. The bold 'create invoice' and 'Add an invoice' specifically identify the resource and action. However, the generic preamble 'Creates new records (receipts, transactions, postings, invoices, master data)' broadens the scope, potentially causing confusion with sibling tools that create other record types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like invoices_create_draft or invoices_create_e_invoice. The description mentions idempotency but does not specify use cases, prerequisites, or exclusions. The endpoint is provided but not contextualized.
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?
Annotations already indicate readOnlyHint=false and idempotentHint=false. The description adds a warning about duplicates from repeated calls, which is useful. However, it does not disclose potential side effects, required permissions, or return values, missing opportunities to fully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes a generic boilerplate line ('🟡 WRITE · creates data') that does not add tool-specific value. The specific part is short, but the structure could be tighter by removing redundant 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?
With full schema coverage and a simple structure, the description adequately covers the purpose and non-idempotency. However, it lacks details on expected responses, error conditions, or typical usage patterns, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no additional parameter-level meaning beyond what is in the schema, so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a postingaccount' and mentions the endpoint, making the action clear. However, it does not differentiate from similar tools like settings_update_postingaccount, which might cause confusion about when to use create vs update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions non-idempotency but does not compare to sibling tools like settings_add_creditor or settings_update_postingaccount, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no additional behavioral context beyond stating it modifies data. No contradiction with annotations, but no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, containing only essential information. However, it redundantly repeats the title and endpoint. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 14 parameters and no output schema, the description lacks completeness. It does not specify that postingaccount_number is required to identify the debtor, nor does it explain the return value or update behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high description coverage (100%), and each parameter is well-documented with validation details. The description adds no additional meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a debtor account' and 'Modifies existing master data in place,' which specifies the verb and resource. The sibling tools include separate create and read operations, providing good differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like settings_add_debtor. The context implies it is for updating existing debtors, but no explicit when-to-use or when-not-to-use instructions are given.
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?
The description includes a warning that the tool creates data and is not idempotent, which is useful beyond the annotations. It aligns with the annotations (readOnlyHint=false, idempotentHint=false). However, it does not describe side effects like validation of cost_location fields or potential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a generic template line ('🟡 WRITE ...') that may be repeated across tools, adding noise. The title is effectively repeated in the description. It could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters (6 required) and many siblings, the description is too sparse. It does not explain what the tool returns, how to interpret results, or how it differs from similar posting tools. The absence of an output schema increases the need for descriptive completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with detailed descriptions (100% coverage). The tool description itself adds no parameter-specific information 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Postings: add free posting' and the description 'Add a free posting.' clearly state the action and resource. However, the description does not differentiate this tool from siblings like 'postings_add_batch_free' or 'postings_add_receipt', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its alternatives. There is no mention of prerequisites, contextual suggestions, or scenarios where other tools (e.g., 'postings_add_batch_free') would be more appropriate.
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 that the tool is a write operation ('WRITE'), can 'link/unlink records,' and is 'Reversible.' This adds context beyond annotations, but the description ambiguously mentions both creating and removing assignments while the tool name only suggests assignment. No additional details on permissions or side effects are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise but includes some repetition (e.g., the bold title line duplicates the purpose). It could be more streamlined by removing the general 'WRITE' note if it applies to a category, but overall it is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should at least hint at the return value or side effects of the assignment. It fails to explain what happens after assignment, error conditions, or any consequences, leaving the agent underinformed for a mutation 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 coverage is 100%, and the description does not add extra meaning beyond what the input schema already provides. The parameters are adequately described in the schema, so the description adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assign a receipt to a free posting.' It distinguishes from siblings like transactions_assign_receipt (which assigns to transactions) and postings_add_free (which creates a free posting). The verb 'assign' combined with the specific resource 'free posting' provides clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. Siblings such as transactions_assign_receipt and transactions_unassign_receipt exist, but the description does not explain that this tool is specifically for free postings or contrast it with other assignment tools.
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?
Annotations (readOnlyHint=false, idempotentHint=false) are consistent with the description's 'WRITE' and non-idempotency warning. The description adds context that it creates data, but includes a generic sentence listing other record types (receipts, transactions, etc.) which is inaccurate for this tool, slightly reducing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a generic template line that is irrelevant to this specific tool (listing other record types), which detracts from clarity. The bold header helps structure, but the generic part could cause confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should cover return values or response behavior, but it does not. It also lacks details on batch size limits, validation errors, or overall process flow. The generic sentence introduces ambiguity about the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description itself adds no additional parameter-specific information beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create multiple debtor accounts' (specific verb and resource) and opens with 'create debtors batch', clearly distinguishing from sibling tools like 'settings_add_debtor' (single debtor) and 'settings_add_batch_creditors' (batch creditors).
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 warns about non-idempotency but provides no explicit guidance on when to use this tool versus the single debtor creation sibling ('settings_add_debtor'), nor does it mention prerequisites or scenarios where batch creation is appropriate.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds 'READ-ONLY' and 'Makes no changes', which aligns but adds no new behavioral insights. There is a slight inconsistency: claiming 'Get all creditors' while supporting pagination, which is not explained. Beyond that, no additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, with key info front-loaded in the first line. However, it repeats 'get creditors' (title, description, inline code) and includes an endpoint line that may not be essential. Still, it's efficient and avoids verbosity.
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 3 optional params, no output schema. The description does not explain pagination behavior (limit/offset defaults, response structure). For a simple list tool, this might suffice, but it leaves gaps about how to retrieve all creditors and what the output contains. More detail on pagination and response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage: all three parameters have descriptions. The tool description adds no extra meaning to parameters; it merely restates the tool's purpose. Baseline is 3 because schema already provides sufficient semantic info.
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 tool as fetching creditors with the phrase 'get creditors' and 'Get all creditors'. The title and emoji reinforce the read-only nature. The sibling tools include distinct actions like add/update, so differentiation is clear. However, the term 'all' contradicts the pagination parameters (limit/offset), slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The name and sibling set imply it is for reading creditors, not adding or updating. Usage context is implied but not stated, leaving ambiguity for an AI agent that might need to choose between get_creditors and add_creditor.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds value by marking the action as WRITE, describing it as 'links/unlinks records,' and noting it is reversible. However, it does not elaborate on required permissions or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with key information front-loaded in the first line. However, it contains slight redundancy (e.g., repeating 'assign receipt to transaction' in two forms) and could be tightened without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters and no output schema, the description covers the basic behavior and endpoint. Lacking guidance on usage context and sibling differentiation, it is adequate but not fully complete for an agent to confidently select it over alternatives.
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 input schema already describes all parameters adequately. The description does not add any additional meaning or usage hints for the parameters, so it provides no extra value beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or removes an assignment between a receipt and transaction, using specific verbs (links/unlinks, assign). However, it lacks explicit differentiation from sibling tools like transactions_assign_batch_receipt and transactions_unassign_receipt, which could cause confusion about whether this tool handles both actions.
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 over alternatives such as transactions_unassign_receipt or transactions_assign_batch_receipt. The description implies it can both assign and unassign, but the existence of a dedicated unassign sibling suggests this is inaccurate, leaving the agent without clear usage rules.
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?
Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness. The description adds 'Reversible', which is useful context, but does not elaborate on side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and redundant (repeats 'unassign a specific receipt from a transaction' twice). The character emoji and generic 'links/unlinks' intro add unnecessary length without clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unassignment action, the description covers the core behavior. However, without an output schema, it fails to mention return values or confirmation of success, leaving a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'unassign a specific receipt from a transaction', using a specific verb and resource. The title reinforces this. It is easily distinguished from sibling tools like transactions_assign_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., transactions_assign_batch_receipt). No prerequisites or conditions for unassignment are mentioned.
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?
Annotations indicate readOnlyHint=false and idempotentHint=false. The description explicitly states 'WRITE · creates data' and warns 'Not idempotent — calling twice may create duplicates,' adding useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but includes a generic introductory line that is not specific to this tool, adding minor redundancy. The structure is acceptable but could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and non-idempotence, but lacks details on return value, uniqueness constraints for code or name, and does not leverage the absence of an output schema to explain expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description does not add any extra parameter information beyond what the schema provides, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new cost location.' The title also specifies the tool's function. However, it does not differentiate from sibling tools like cost_locations_update or cost_locations_delete, and a generic intro line about creating records is included but not specifically tied to cost locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only behavioral note mentions non-idempotence, but there is no context on prerequisites, conditional use, or when to avoid 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?
Annotations already declare idempotentHint=false and destructiveHint=false. The description adds 'Not idempotent — calling twice may create duplicates' and 'WRITE · creates data', which aligns with annotations but provides minor additional clarity. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key info (endpoint, purpose). The '🟡 WRITE' preamble is redundant but not harmful. Could be slightly tighter, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 34 parameters (16 required) and no output schema, the description is too brief. It lacks guidance on required fields, ordering, or common usage patterns. More context is needed for an AI agent to use it effectively.
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 description does not need to elaborate on parameters. The tool description includes no parameter-specific details, which is acceptable given the schema handles it. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an e-invoice for a customer, with a specific verb and resource. The presence of sibling tools like invoices_create and invoices_create_draft indicates a distinct purpose (e-invoice vs regular invoice).
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 does not provide any guidance on when to use this tool versus alternatives like invoices_create or invoices_create_draft. No exclusions or context are given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds some context beyond annotations: indicates write operation and non-idempotence, but annotations already convey these. Adds some more specific record types.
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?
Description is short but includes a generic header line that could be trimmed. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing context on batch processing constraints (size limits, validation), no mention of return values or typical use cases.
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 baseline 3. Description does not add extra meaning about parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create multiple creditor accounts' with specific verb and resource. Distinguishes from siblings like single creditor add and batch debtors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like settings_add_creditor or settings_update_creditor. Only mentions behavior, not usage context.
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 repeats the read-only nature already indicated by annotations (readOnlyHint=true) but adds no new behavioral traits. The endpoint method (POST) is a minor detail not found in annotations, but overall value is limited given annotation richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two lines plus an endpoint line. It front-loads the read-only nature and immediately states the action. Every sentence serves a purpose, with no extraneous content.
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 minimal and lacks context about returns (e.g., a list of debtors) or pagination behavior. For a simple read-only tool with no output schema, it is adequate but leaves gaps in understanding the full scope.
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 fully documents all three parameters. The description adds no additional meaning or explanation to parameters like limit, offset, or api_key, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('debitors'), making the tool's purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like settings_get_creditors, which limits contextual clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels it as a write operation (WRITE · creates data) and states it is not idempotent, which aligns with annotations and adds behavioral context. It also notes the prerequisite about activation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes an emoji and repeats the title in bold. The foreign currency note is useful but the structure could be tighter. Key information is front-loaded, but there is some 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?
The description lacks information about return values or error handling. For a write operation with nested objects, this omission leaves the agent uncertain about what to expect. Given no output schema, the description should compensate 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 description adds limited value beyond schema. It mentions that the 'receipts' array structure mirrors the 'postings/add/receipt' endpoint, which is helpful but not detailed. No additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool adds multiple receipt postings. The verb 'add' and resource 'postings' are specific. However, it does not explicitly distinguish this tool from the singular 'postings_add_receipt' or similar batch tools like 'postings_add_batch_transactions'.
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 important usage notes: only works if creditor/debtor posting is activated, and foreign currency handling requires pre-fetching the receipt. However, it does not guide when to use this tool versus alternatives (e.g., when to use batch vs singular).
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?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds value by stating 'WRITE · creates data' and 'Not idempotent — calling twice may create duplicates', but does not go beyond annotations significantly. No additional context on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus the endpoint, with a clear emoji and warning. No unnecessary 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?
Despite having 14 parameters and no output schema, the description does not explain return values, error handling, or the structure of the response. For a write operation, this is a significant 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?
Input schema has 100% coverage with descriptions for all 14 parameters. The tool description does not add any extra meaning beyond the schema; it only mentions the endpoint. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a transaction to a payment account of the specified customer' along with the endpoint. The title 'Transactions: add transaction' also reinforces the purpose. It distinguishes from siblings like 'transactions_addBatch' by focusing on a single transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'transactions_addBatch' for batch additions or other transaction-related tools. It does not mention preconditions or exclusion criteria.
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?
The description adds valuable context beyond annotations: it explicitly states the operation is a write ('WRITE'), reversible, and links/unlinks records. This complements the annotations (readOnlyHint=false, destructiveHint=false) and informs the agent about the non-destructive, reversible nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with key information front-loaded (action, reversibility, endpoint). It uses an emoji for quick visual categorization and avoids redundancy. A minor improvement could be removing the repeated 'Assign multiple receipts to transactions.' line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and reversibility but lacks some context: it doesn't mention the 50-element batch limit from the schema, nor does it describe return values (no output schema). For a batch tool, additional context like error handling or prerequisites would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters (api_key and transactions_to_receipts). The description does not add additional parameter semantics beyond what the schema provides, such as format or constraints. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assigns multiple receipts to transactions, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like transactions_assign_receipt (single) or transactions_unassign_receipt (removal), relying on the name 'batch' to imply the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention using this for batch operations and the single-assignment counterpart for individual operations, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description reinforces this with 'READ-ONLY' and adds response structure details (number of rows, array of transaction data) and the POST endpoint, providing useful extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with key points. A minor redundancy is repeating 'get transactions' in bold. Overall, every sentence adds 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?
Given the lack of output schema and 9 optional parameters, the description covers purpose and safety but omits that an account filter might be necessary despite being optional. The combination with schema is adequate but leaves some uncertainty.
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 carries minimal burden. It mentions 'specified customer account' which aligns with the account parameter but adds no further meaning to other parameters. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves transactions for a specified customer account. However, it does not explicitly differentiate from sibling tools like transactions_get_id_by_customer, making the distinction somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as transactions_add or transactions_get_id_by_customer. The description lacks context for decision-making.
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?
The description reinforces the readOnlyHint with a clear 'READ-ONLY' label and states 'Makes no changes to the accounting records.' It also mentions the response includes row count and array, adding context beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three short sentences) with a front-loaded READ-ONLY indicator and emoji for quick scanning. It efficiently conveys essential 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?
Given the complexity of 13 parameters including nested objects (order), the description is too sparse. It lacks details on pagination, ordering behavior, and response schema, leaving the agent under-informed for proper 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?
Input schema has 100% coverage with detailed parameter descriptions, so the description adds minimal value. It does not elaborate on how to specify the customer account (e.g., via api_key), but this is covered in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get receipts for a specified customer account' which is a specific verb and resource. It distinguishes from siblings like receipts_upload or receipts_addBatch, but does not explicitly differentiate from other retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching receipts but provides no explicit guidance on when to use this tool versus alternatives like receipts_get_id_by_customer or receipts_assigned_transactions_get.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces read-only behavior but adds minimal new insight beyond stating the method (POST) and the fact that no changes are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key action ('get postingaccounts') and read-only indicator. It includes an emoji for visual clarity but could be slightly more streamlined.
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 having 8 parameters and no output schema, the description does not explain return format, pagination behavior, or how the filter parameters (exclude_*) interact. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add any additional meaning or context for parameters beyond what the schema already 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 clearly states 'get postingaccounts' and 'Get all postingaccounts', making the verb and resource explicit. It distinguishes from sibling tools like settings_get_debtors and settings_get_creditors.
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 read-only usage but does not provide specific when-to-use or when-not-to-use guidance relative to alternatives. It lacks explicit exclusions or alternative tool references.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds '🟡 WRITE · updates data' and 'Modifies... in place', which aligns but doesn't provide additional behavioral context like authorization needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key info (WRITE label, verb, resource). However, the 'updates data' phrase is redundant with the WRITE label. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no output schema, the description lacks information about return values, confirmation of changes, or what happens after a successful update. This leaves the agent underinformed.
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% with detailed parameter descriptions. The description does not add extra meaning beyond the schema; it only mentions the endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'creditor account', and distinguishes it from add/get siblings by specifying 'Modifies existing master data in place'.
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?
Minimal guidance: it says 'Modifies existing master data in place' implying it's for existing creditors, but no explicit when-to-use, prerequisites, or alternatives compared to sibling tools like settings_add_creditor.
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?
Beyond annotations (destructiveHint=false, idempotentHint=false), description adds 'WRITE · creates data', explicit non-idempotency warning, and rate-limit constraint. This is valuable behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains some redundancy ('add batch transaction' then 'Add multiple transactions'), and includes the endpoint path which is not essential. Information is generally front-loaded but could be more streamlined.
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?
High schema coverage and parameter count low (2), but missing return value description (no output schema) and error handling details are vaguely referenced ('same applies for error messages'). 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?
Schema coverage is 100% so baseline is 3. Description adds the maximum batch size (50) and references the single-transaction endpoint for field details, which adds useful context beyond 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?
Clearly states it creates new records and adds multiple transactions, using a specific verb and resource. However, the description lists multiple record types (receipts, transactions, etc.) which is slightly broad and could confuse the exact scope. No explicit differentiation from sibling batch tools like receipts_addBatch.
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?
Provides some guidance: not idempotent (duplicate warning) and rate limit (5 seconds). However, it does not explicitly compare to alternative tools (e.g., transactions_add for single transactions) or specify when to choose this over others.
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?
Annotations indicate mutation (readOnlyHint=false) and idempotency. The description adds context: it reverts state, is reversible, and requires postings not fixed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly concise with emoji and bold for emphasis, but includes some redundancy (e.g., 'unconfirm receipt posting' appears twice). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and available annotations, the description provides sufficient context: it explains the operation, condition, and endpoint. Lacks return value info but that's not expected without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description references receipt_id_by_customer but adds no significant meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it unconfirms postings for a receipt, using specific verb and resource. It distinguishes from siblings like postings_unconfirm_free and postings_unconfirm_transaction by the resource type (receipt), but does not explicitly differentiate.
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 mentions a condition ('only work if postings are not fixed'), but does not provide explicit guidance on when to use this tool versus alternatives like postings_unconfirm_free or postings_unconfirm_transaction.
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?
Annotations already indicate non-idempotency and non-readOnly. The description explicitly states 'Not idempotent — calling twice may create duplicates' and marks the tool as 'WRITE · creates data', adding behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an initial broad statement 'Creates new records (receipts, transactions, postings, invoices, master data)' which is misleading as this tool only creates a creditor account. This fluff reduces conciseness and clarity. The important non-idempotency warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and no output schema, the description covers the action and non-idempotency but omits return value details (e.g., does it return created creditor ID?). The endpoint is provided. The initial overbroad statement slightly detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 14 parameters have detailed descriptions. The tool description adds no additional parameter meaning, so it meets the baseline. No need for extra elaboration.
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 creates a creditor account, distinguishing it from sibling create tools like settings_add_debtor or settings_add_postingaccount. The verb 'create' and resource 'creditor account' are specific, and the 'WRITE' label emphasizes mutation.
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 through its purpose but provides no explicit guidance on when to use this tool versus alternatives (e.g., settings_add_debtor). The non-idempotency warning is a caution but not a usage rule. No context of prerequisites or conflicting 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description reinforces. It also adds a key behavioral constraint: each request is limited to 1000 postings. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a front-loaded safety indicator. However, it includes minor redundancy (repeating 'get postings' and the endpoint) that could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the response structure (count and array) and the 1000 limit, but does not provide guidance on how to use pagination parameters (offset/limit) or specify which parameters correspond to 'customer account'. With 12 parameters and no output schema, more context would be helpful.
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 parameter descriptions in the schema are comprehensive. The description does not add new semantic meaning beyond what the schema provides, such as format or usage tips for individual 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 states the tool retrieves postings for a specified customer account, using the verb 'get' and specifying the resource 'postings'. It differentiates from siblings by emphasizing the read-only nature, distinguishing it from write operations like postings_add_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching postings based on the name and description, but it does not explicitly state when to use this tool over alternatives like transactions_get or receipts_get. No exclusions or prerequisites are mentioned.
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?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds context: 'WRITE', 'reverts state', 'reversible', and explains it restores a deleted receipt, aligning with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with redundant phrasing ('reverts state — Reverts a prior state change... Reversible'). It could be more concise while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restore tool with one optional parameter and no output schema, the description adequately covers the action, reversal nature, and how to obtain the identifier. Lacks discussion of error scenarios but is sufficiently complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only parameter (api_key). The description does not add parameter-specific information beyond what is in the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restore'), the resource ('deleted receipt'), and the identifier ('id_by_customer'). It distinguishes from the inverse sibling receipts_delete_id_by_customer by specifying it reverts a prior state change.
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 context ('Reverts a prior state change', 'Reversible') and tells how to get id_by_customer via /receipts/get, but does not explicitly state when to use this tool vs alternatives, nor when not to use it (e.g., if receipt is not deleted).
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?
Description adds context beyond annotations: it clearly states the tool is not idempotent (may create duplicates) and includes a rate limit. Annotations already indicate it's a write operation (readOnlyHint=false). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, with a clear opening line distinguishing the tool type. The inclusion of the endpoint and rate limit adds value, though some repetition of the purpose exists. Could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and no output schema, the description explains the general purpose and response (filename), but does not summarize parameter interactions (e.g., e-invoice ignoring certain params) or provide more detail on processing. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The tool description does not add extra parameter-specific meaning, but the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a receipt into a customer account, with a specific verb ('upload') and resource ('receipt'). It distinguishes from siblings like receipts_add by emphasizing file upload and processing by BuchhaltungsButler technology.
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 mentions a rate limit (10 requests per minute) and implies it is for file uploads, but does not explicitly state when to use this tool over alternatives like receipts_add or receipts_addBatch. No when-not or alternative names given.
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?
The description discloses that the tool is not idempotent and may create duplicates, which aligns with annotations (idempotentHint=false, readOnlyHint=false). It also indicates validation behavior for optional fields. This adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief generic header and two specific sentences. It is front-loaded with the write/duplicate warning, then the specific action. No unnecessary text.
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?
While the schema covers all parameters, the description lacks information about return values (no output schema) and any post-creation steps or prerequisites. For a creation tool with 14 parameters, more context would be helpful.
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% with detailed descriptions for all 14 parameters. The tool description does not add additional meaning to the parameters beyond what is in the schema, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a debtor account' and uses a specific verb-resource pair. The title and description clearly indicate this tool creates debtor records, distinguishing it from sibling tools like settings_update_debtor or settings_add_creditor.
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 no explicit guidance on when to use this tool versus alternatives such as settings_add_batch_debtors for bulk creation or settings_update_debtor for modifications. Usage is only implied by the name and description.
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?
The description adds context beyond annotations by stating 'Modifies existing master data in place' and including the endpoint. Annotations already provide idempotentHint=true and destructiveHint=false, and the description aligns with these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one emoji line, one bold statement, and one sentence of purpose. Every word adds value, and it is front-loaded with the action and resource.
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 lacks details about the response (e.g., no output schema) and error conditions. However, for a simple update tool, it provides the essential purpose and parameters. More context on behavior when code is missing would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what is already documented. It reiterates 'name/description,' which matches the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a cost location's name/description.' It uses the specific verb 'update' and identifies the resource (cost location), distinguishing it from siblings like cost_locations_add (create) and cost_locations_get.
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 for updating existing cost locations but does not explicitly state when to use this tool versus alternatives like cost_locations_add or cost_locations_delete. No guidance on exclusions or prerequisites is provided.
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?
Description states it creates data and is not idempotent, consistent with annotations (readOnlyHint=false, idempotentHint=false). Adds value beyond annotations by mentioning potential duplicate creation and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is longer than necessary, with redundant '🟡 WRITE' line and extensive VAT list that could be summarized. However, important notes are front-loaded and structured with bold headings.
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?
Lacks specification of return value/response shape. For a write tool with complex parameters, provides good usage context but not fully complete without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with thorough descriptions for each parameter, including usage examples. Description adds minimal extra meaning beyond what schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state 'Add postings for a specified receipt'. The verb+resource is specific. Does not explicitly differentiate from siblings like 'postings_add_batch_receipts', but the function is distinct due to the receipt parameter.
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?
Provides explicit prerequisites (creditor/debtor posting activation) and important condition for foreign currency. Lacks explicit alternatives but gives actionable context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds valuable context: it warns of destructiveness, requires user confirmation, and notes that receipt deletes are restorable while cost-location deletes are not. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, including a warning emoji, a one-sentence summary, and a note on prerequisite. It could be slightly tighter but is mostly efficient.
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 purpose, prerequisite, and destructive behavior, but lacks details on the missing id_by_customer parameter and what happens on success (no output schema). The missing param reduces completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists api_key, but the description implies an id_by_customer parameter, which is not present. This mismatch confuses parameter semantics despite 100% schema coverage for the listed param. The description does not clarify how id_by_customer 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 clearly states the tool deletes a receipt by id_by_customer for a specified customer account. The verb 'delete' and resource 'receipt' are specific, and it distinguishes from sibling restore 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 advises to get the id_by_customer via '/receipts/get method' first, providing a clear prerequisite. However, it does not explicitly compare with other delete tools or state when not to use.
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?
Annotations already provide readOnlyHint and destructiveHint; the description adds the POST endpoint and the 1000-limit, which are valuable behavioral details not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, uses emoji and bold for emphasis, and front-loads the read-only warning. No superfluous text, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the response includes row count and data array, but lacks detail about the fields in the array. Without an output schema, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description only reiterates the limit constraint, adding no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is read-only and fetches cost locations for a customer account, distinguishing it from write siblings like cost_locations_add/update/delete.
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 marks the tool as READ-ONLY and states its purpose, making it clear when to use it (to get cost locations without modification). However, it does not explicitly compare to alternatives.
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?
Description labels the tool as a WRITE operation and explicitly states it is not idempotent, which aligns with annotations (readOnlyHint=false, idempotentHint=false) and adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at three lines, with a clear header and action statement. The generic header line could be more tailored, but overall efficient.
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?
No output schema is provided, and the description does not explain return values or what the tool outputs upon success. For a creation tool with 9 parameters, complete guidance would include the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so parameters are already well-documented. The description adds no new semantic information beyond the schema, meeting baseline expectations.
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?
Title and description clearly state 'add postings for a specified transaction', distinguishing it from siblings like 'postings_add_free' or 'postings_add_receipt' by specifying the transaction context.
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?
Description warns about non-idempotency ('calling twice may create duplicates'), implying cautious use. However, it does not explicitly state when to use this tool versus alternatives, though context hints from sibling 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?
Annotations provide destructiveHint=false and idempotentHint=true. The description adds context: 'Reverts a prior state change,' 'Reversible,' and the condition about 'not fixed.' It explains the idempotency implication (reversibility) but does not detail side effects or permissions. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (write, reverts state) and ends with endpoint. Some redundancy with the emoji and bold formatting, but overall not verbose. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return value or error cases. For a simple write operation, the action is clear, but the lack of output description leaves a gap. 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 both parameters are already documented. The description implies the use of posting_id_by_customer ('specified free posting') but does not add new semantic information. Baseline 3 for high 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 the tool's action: 'Remove a specified free posting by unconfirming it.' It distinguishes from sibling tools like postings_unconfirm_receipt and postings_unconfirm_transaction by specifying 'free posting'. The verb+resource combination is specific and 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 provides a condition: 'This will only work if the posting is not fixed.' It implies usage for free postings but does not explicitly contrast with siblings. No when-not guidance, but the context of 'free posting' and sibling names makes it clear enough.
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?
Annotations indicate non-idempotent (idempotentHint=false) and non-destructive (destructiveHint=false). The description explicitly states 'Not idempotent — calling twice may create duplicates', which adds value beyond annotations. It also notes the write nature and rate limit.
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 front-loaded with a write warning and purpose. It is somewhat lengthy but structured logically: warning, title, purpose, rate limit. Could be more concise by removing the 'Endpoint' line, but overall efficient.
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?
No output schema is provided, and the description does not explain return values. It mentions error messages in the schema. The rate limit and non-idempotency are covered, but missing details on response format or success indicators.
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 detailed parameter descriptions. The description adds an extra constraint: 'maximum of 50 receipts are allowed', which is not in the schema. This fully compensates for the 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 'Creates new records' and 'add batch receipts / Add multiple receipts', specifying the verb (add) and resource (batch receipts). It distinguishes from sibling tools like 'receipts_add' (single) and 'receipts_upload'.
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 mentions a rate limit of one request per 5 seconds but does not provide guidance on when to use this tool vs alternatives (e.g., single receipt add or upload). No explicit when-to-use or when-not-to-use context.
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 reiterates read-only and non-destructive behavior, which is already provided via annotations (readOnlyHint, destructiveHint). It adds minimal behavioral context beyond stating the endpoint method (POST) and confirming it fetches data.
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 concise: one line with a visual indicator, a bold statement of purpose, a brief sentence, and a usage hint. Every sentence serves a purpose with 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?
Given the tool's simplicity, full schema coverage, and comprehensive annotations, the description is complete. It covers the main input, a prerequisite, and read-only nature. It could optionally describe the output (list of receipts) but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description mentions 'transaction_id_by_customer' but does not add extra meaning beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'get all receipts assigned to a specific transaction', specifying the verb 'get' and resource 'receipts assigned to a transaction'. It distinguishes from sibling tools like 'transactions_assign_receipt' and 'receipts_get'.
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 tells when to use this tool: after obtaining the transaction's id_by_customer via '/transactions/get method'. It provides a prerequisite but does not explicitly exclude use cases or mention alternatives for similar lookups.
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?
Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds that it reverts state and is reversible, which is consistent and provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose and key conditions. It includes an endpoint and is well-structured, though the emoji and formatting could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with a specific condition, the description adequately covers the core behavior and condition. Without an output schema, the return value is not explained, but the tool's purpose is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the input schema are complete (100% coverage), so the description does not need to add more. The tool description does not elaborate on parameters beyond what's in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverts a prior state change (unconfirms a posting) and specifies the resource (transaction postings). It distinguishes from siblings like postings_unconfirm_free and postings_unconfirm_receipt by focusing on transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a condition for use ('only work if the postings are not fixed') and states it is reversible. However, it does not explicitly compare to alternative tools or advise 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only and not idempotent. The description adds context: 'Not idempotent — calling twice may create duplicates' and the 🟡 WRITE marker, which reinforces the behavioral traits and provides practical guidance.
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 relatively concise, with a clear front-loaded warning about write operations and non-idempotency. The content is focused and efficiently conveys the necessary information, though the repetition of 'creates data' and 'not idempotent' could be slightly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema) and the presence of many siblings, the description provides adequate context: it specifies the action, distinguishes the tool from 'receipts_upload', and includes behavioral hints. It does not cover all edge cases but is sufficiently complete for a creation 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 coverage is 100%, so the schema already documents all 14 parameters. The description does not add additional meaning about parameters beyond the schema details, thus a 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 title 'Receipts: add a receipt' and description 'Add a receipt into the specified customer account' clearly state the verb (add) and resource (receipt). It distinguishes itself from sibling 'receipts_upload' by noting this endpoint is for adding without a file.
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 'Use this endpoint, to add a receipt without a file!', providing a clear condition for use relative to 'receipts_upload'. However, it does not address other scenarios or 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?
The description reinforces the READ-ONLY nature already declared in annotations, stating '🟢 READ-ONLY — Fetches data. Makes no changes.' No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, but includes some redundancy (e.g., repeating the tool title in bold). It front-loads the READ-ONLY indicator and effectively uses two short paragraphs.
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 tool with one optional parameter and no output schema, the description adequately explains the return: 'The response includes an array of transaction data.' However, it could clarify what 'id_by_customer' represents.
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% with a single parameter 'api_key' already well-described in the schema. The description adds no additional parameter insight beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a single transaction for a specified customer account by id_by_customer.' It distinguishes from the sibling 'transactions_get' which retrieves all transactions.
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 advises obtaining the 'id_by_customer' via another endpoint first: 'You can get the "id_by_customer" by using the "/transactions/get method".' This provides a prerequisite, though it doesn't explicitly cover when not to use the tool.
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?
The description complements annotations by stating 'Not idempotent — calling twice may create duplicates', which is consistent with idempotentHint=false. It also indicates a write operation (readOnlyHint=false, destructiveHint=false). No contradictions; it adds useful duplication warning beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the purpose after a brief generic note. Each sentence serves a purpose: write warning, core function, parameter constraint. The generic WRITE note could be considered redundant if common across tools, but overall it is concise.
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 4 parameters fully described in schema and no output schema, the description covers the key constraint. However, it lacks information on return values, error behavior, or expected response after adding a comment. While the tool is simple, an agent might benefit from knowing what to expect post-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?
While the input schema describes all 4 parameters (100% coverage), the description adds critical constraint: 'You have to submit either a transaction_id_by_customer or a receipt_id_by_customer.' This mutual exclusivity is not evident from individual parameter descriptions, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'add comment to transaction or receipt', providing a specific verb and resource. The note about needing either transaction_id_by_customer or receipt_id_by_customer further clarifies the scope. This clearly distinguishes it from sibling tools like accounts_add or receipts_add.
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 includes a clear note about the requirement to submit either a transaction_id_by_customer or a receipt_id_by_customer, providing necessary context for when to use this tool. However, it does not explicitly mention when not to use it or compare to alternatives, but the constraint is sufficient for an agent to decide.
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?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description discloses that deletes are irreversible and not restorable, adding critical behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a warning and is fairly concise, but contains slight redundancy in repeating 'delete cost location' in both the title and body. Still efficient.
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?
No output schema exists, and the description does not explain return values (e.g., success/error responses). For a destructive tool, more detail on outcomes would be beneficial, but basic usage is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and already describes both parameters adequately. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a cost location, using a specific verb and resource. It distinguishes from sibling tools like 'add' and 'update' by naming the delete action explicitly.
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 instructs to confirm with the user before calling and notes that cost-location deletes are not restorable, contrasting with receipt deletes. However, it does not explicitly state when not to use or mention alternative tools.
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?
Description includes write indicator, creation of new records, and idempotency warning ('calling twice may create duplicates'), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with write/behavioral warnings, but includes unnecessary formatting (emoji, bold) and endpoint URL, slightly impacting conciseness.
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?
Lacks output schema but covers key behavioral aspects (write, idempotency) and parameter structure via schema; no mention of error handling or partial success.
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%; description adds only a reference to another endpoint for validation details, not substantially enriching parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description explicitly state 'add multiple transaction postings' and 'add posting for specified transactions', distinguishing from single transaction and batch receipts 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?
Description indicates it's for adding multiple transaction postings in batch, but does not explicitly state when to prefer this over sibling tools like postings_add_transaction.
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?
The description explicitly states 'READ-ONLY — Fetches data. Makes no changes', which aligns with and expands on annotations (readOnlyHint, idempotentHint, destructiveHint). No contradictions; adds beyond annotations by emphasizing safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line read-only note, a purpose sentence, a prerequisite hint, and the endpoint. Every sentence is essential, with no filler. The read-only indicator is front-loaded for instant clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description could mention the structure of the returned transactions for completeness. However, the description adequately explains what the tool does and how to use it, with the prerequisite step. It's nearly complete but lacks a brief note on response format.
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 value by explaining how to get the key parameter (receipt_id_by_customer via /receipts/get) and briefly noting the confirmed_only filter's effect, going beyond the schema's dry descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all transactions assigned to a specific receipt, using the verb 'get' and specifying the resource. It distinguishes from sibling tools like 'transactions_assigned_receipts_get' by focusing on the receipt-to-transactions direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (obtaining receipt_id_by_customer via /receipts/get), offering clear context. However, it does not explicitly state when to use this tool versus alternatives like transactions_assigned_receipts_get.
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:

[![Buchhaltungsbutler-MCP MCP server](https://glama.ai/mcp/servers/ohneben/Buchhaltungsbutler-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ohneben/Buchhaltungsbutler-MCP)

Score Badge

Copy to your README.md:

[![Buchhaltungsbutler-MCP MCP server](https://glama.ai/mcp/servers/ohneben/Buchhaltungsbutler-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ohneben/Buchhaltungsbutler-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/ohneben/Buchhaltungsbutler-MCP'

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