BuchhaltungsButler MCP-Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes (receipts, transactions, postings, master data), but create_receipt and create_invoice heavily overlap (both create invoices/credit notes), and create_invoice_draft is nearly identical to create_invoice. This introduces ambiguity for agents selecting between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_, create_, get_, delete_, upload_, assign_, etc.). No mixed conventions or vague verbs are used.
Tool Count3/5
With 23 tools, the set is on the higher end of the typical range. While the breadth covers multiple accounting subdomains, the count feels slightly heavy and some tools (e.g., create_invoice vs. create_receipt) could be consolidated.
Completeness2/5
The lifecycle coverage is incomplete: receipts have create/get/list/delete/upload but no update; transactions, invoices, debtors, creditors, accounts, and cost locations generally lack update and delete operations. Several entities (debtors, creditors, accounts) have only list and create, missing get and modification endpoints, creating dead ends in workflows.
Average 3.4/5 across 20 of 23 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any side effects, permissions, reversibility, or other behavioral aspects. It only states the action without describing what happens beyond the removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and well-structured.
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 does not mention what happens after the action (e.g., return value, confirmation) and no output schema is provided. It could be more complete by explaining the expected result or any side effects, making it somewhat incomplete for a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no additional meaning to the parameters beyond the schema descriptions, which already provide 100% coverage (e.g., 'Die id_by_customer des Belegs'). Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Entfernt die Zuordnung eines Belegs von einer Banktransaktion' (removes the assignment of a receipt from a bank transaction). It uses a specific verb and specifies the resource, making it distinct from sibling tools like assign_receipt_to_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, nor any prerequisites or conditions. The description only states the action without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full blame for behavioral disclosure. While 'zuordnen (Matching)' implies a state-changing link operation, the description doesn't clarify whether the operation overwrites existing assignments, whether it's idempotent, whether it validates that the transaction is a bank transaction, or what happens on failure. The api_key parameter hints at auth requirements but this isn't disclosed as behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded German sentence that front-loads the action verb and communicates the core operation immediately. Zero wasted words. It loses one point because it borders on being terser than necessary — the parenthetical is the only added flourish.
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 state-changing pairing tool with no output schema and no annotations, the description fails to mention whether the operation errors on already-assigned receipts, what it returns (the transaction? the assignment?), or whether it's part of a two-step match/unmatch flow (though the sibling unassign tool implies this). The absence of behavioral notes on idempotency or error cases makes this underspecified for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 3 parameters (api_key, receipt_id_by_customer, transaction_id_by_customer) with German descriptions. The description's noun phrases map conceptually to the params (Beleg→receipt_id, Banktransaktion→transaction_id), but it doesn't add format or constraint details beyond the schema. Baseline of 3 is appropriate per the rubric 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 uses a specific verb+resource pairing ('Ordnet einen Beleg einer Banktransaktion zu') that clearly identifies the operation as assigning a receipt to a bank transaction. The parenthetical '(Matching)' adds domain context. While it doesn't name sibling tools, the operation is specific and distinguishable from alternatives like unassign_receipt_from_transaction, though one point is lost for not being fully specific about which entity receives the assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of when to prefer unassign_receipt_from_transaction, what prerequisite state the transaction or receipt should be in, or when matching is appropriate. The only implied usage context comes from the tool name and sibling list, not from the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'creates' but does not mention side effects, validation, API key requirements, or whether the creation is permanent. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero fluff. It is front-loaded with the key information (creates document types). No unnecessary words are used, making it highly efficient, though perhaps sparse for such a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 25 parameters, no output schema, and no annotations, a one-line description is grossly inadequate. It lacks critical context such as how to structure the item arrays, what the API expects, error scenarios, or any post-creation behavior. The description is not complete enough for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 25 parameters are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate given the complete 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 'Erstellt' (creates) and the resource types (Rechnung, Gutschrift, Angebot), which covers the core purpose. However, it does not differentiate from the sibling 'create_invoice_draft', and the scope is somewhat ambiguous given the multiple document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'create_invoice_draft'. There is no mention of prerequisites, when to choose invoice vs credit vs offer, or any contextual hints. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral transparency. It merely restates the tool's function without disclosing side effects, errors, idempotency, or posting behavior. There is no contradiction with annotations since none exist, but the description adds no behavioral insight beyond the tool's name.
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?
A single, well-formed German sentence that is readily parseable and front-loaded with the verb. No fluff or redundancy. However, it borders on under-specification since the description is nearly a restatement of the tool name.
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 rich 100% schema coverage and the relatively simple CREATE operation, the description suffices for basic use. However, it omits any mention of side effects, idempotency, or interaction with receipt assignment (siblings suggest a workflow), which would be valuable 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 description coverage is 100%, with all 11 parameters documented in German including the important sign convention for amount (positiv für Eingang, negativ für Ausgang) and format examples for dates. The baseline of 3 applies as the schema does the heavy lifting; the description adds no additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Erstellt eine neue Banktransaktion auf einem Zahlungskonto' uses a specific verb (Erstellt) and resource (Banktransaktion auf einem Zahlungskonto), clearly conveying the action. While it doesn't explicitly distinguish itself from sibling tools, the action type differs obviously from receipt/invoice tools by name and stated resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives like create_free_posting, create_receipt, or how it relates to existing transactions in a bank feed. The description is purely declarative with no context, exclusions, or alternative routing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing any behavioral details such as authentication requirements, side effects, error handling, or return values. The description adds no transparency beyond the basic create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in German with no superfluous information, making it appropriately 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?
Given the tool has 14 parameters and no annotations, the description is overly minimal. It does not convey the overall purpose beyond a simple create, nor does it mention that only 'name' is required or that an API key may be needed. While the schema provides parameter details, the description lacks higher-level context about usage and implications.
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 100% coverage for parameter descriptions, so the schema already explains each parameter. The tool description itself does not add additional semantic context beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates) and the resource (a new debtor/customer), effectively distinguishing it from sibling tools like create_creditor or create_invoice. It is concise 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 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 create_creditor or other creation tools. It does not mention prerequisites, conditions, or exclusions, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so per the rubric the description carries the full behavioral burden, but it adds nothing beyond a restatement of the tool name. For a write operation, there is no disclosure of side effects, duplicate-handling behavior, authentication requirements, or what happens on failure. The description neither contradicts annotations nor enriches the agent's mental model in any meaningful way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded, grammatical sentence with zero wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with no output schema and a well-documented parameter schema, the minimal description is mostly adequate. However, it misses the opportunity to mention return behavior, error semantics, or idempotency. The description is adequate for a task of this complexity but provides nothing beyond the bare minimum — a solid mid-tier performance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline of 3 applies. The description itself adds no parameter-level detail, but the schema does a decent job on its own: `api_key` clearly explains the env-var fallback (BUCHHALTUNGSBUTLER_API_KEY), and `name`/`number` are minimally described. The `number` parameter would benefit from format/constraint details, but that's a schema gap, not a description failure.
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?
"Erstellt eine neue Kostenstelle." is a clear, specific verb+resource formulation that unambiguously states a create-mutation on a cost center entity. It distinguishes well from its only same-resource sibling `list_cost_locations`, which is clearly a different operation type. A point is lost because the description essentially restates the tool's name in German without adding any scope, constraints, or distinguishing detail.
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 invoke this tool versus any alternative, nor any preconditions or context. There is no mention of how this relates to `list_cost_locations` or when a user might need to verify an api_key first. No misleading information, but effectively zero actionable guidance beyond what the tool name implies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that a comment is added, but does not mention side effects (e.g., whether the comment is appended, whether it modifies in place, any permission requirements, or reversibility). The implicit mutation is not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse. It is not verbose, but it lacks structural elements like bullet points or examples. It earns its place with minimal waste.
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 a clear schema and no output schema, the description is adequate but not rich. It does not explain the outcome of the operation or any constraints beyond the schema. Given its simplicity, this is acceptable but could be improved by mentioning the effect (e.g., 'adds a comment to the specified receipt or transaction.')
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning beyond the schema's parameter descriptions, which already clearly explain 'type', 'comment', 'id_by_customer', and 'api_key'. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds a comment to a receipt or a transaction, using a specific verb and resource. It is distinct from sibling tools, which focus on other operations like create, delete, or list, so it is easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does, without any guidance on when to use it or when not to. No alternatives are mentioned, but for a unique action like commenting, some context about appropriate scenarios would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'creates' without disclosing side effects, required permissions, reversibility, or whether it validates posting accounts and VAT keys. This is insufficient for a mutation tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in German, which is efficient. However, it lacks structure such as examples or sub-bullets, but for a simple purpose it is appropriately 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 the tool has 9 parameters, 6 required, no output schema, and no annotations, the description is minimal. It does not explain what a 'free posting' is, how VAT keys work, or what the response will be. For a potentially complex accounting operation, this is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a bit by naming 'Soll- und Habenkonto' which maps to postingaccount_debit and postingaccount_credit, but it does not explain semantics of 'freie Buchung' or VAT keys beyond schema. Slight enhancement over schema, but not substantial.
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 'Erstellt' (creates) and resource 'freie Buchung' (free posting) with Soll- und Habenkonto (debit and credit account). It is specific enough to distinguish from siblings like 'create_receipt' or 'create_invoice', though it could elaborate on 'free' meaning unlinked to existing documents.
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 creating a free posting with debit and credit accounts, but provides no explicit guidance on when to use this tool over alternatives like 'create_invoice' or 'create_transaction'. There is no mention of prerequisites or exclusions, but the context of posting accounts is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention that deletion is likely irreversible, might have cascading effects (e.g., on linked transactions), or requires specific permissions. This gap is significant for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. There is no fluff, and it efficiently conveys the core action, though it sacrifices detail for brevity.
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 lack of annotations and output schema, the description is incomplete for a destructive operation. It does not mention what happens on success (e.g., return value or confirmation), nor any side effects, making it insufficient for an agent to use confidently.
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 merely restates the id_by_customer parameter without adding new meaning. Baseline for high coverage is 3, and since the description adds no extra semantics beyond the schema, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (deletes) and the resource (Beleg/receipt) and the identifier (id_by_customer), which distinguishes it from sibling tools like get_receipt or create_receipt. It is specific and unambiguous about the operation's core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deletion but provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or side effects. Since it's a straightforward delete, the intended usage is somewhat obvious, but no exclusions or contextual cues are given, making it only minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It conveys that this is a read operation ('Ruft ... ab') and implies a complete result set ('alle Konten'), but it does not disclose pagination behavior, auth requirements, or any side-effect-free guarantee beyond the verb choice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to stating the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description captures the basic operation. However, it lacks sibling differentiation and any indication of return-value shape or usage context, which makes it minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter api_key has 100% schema description coverage, so the schema already fully documents its meaning and optionality. The description adds no additional parameter-level detail, which aligns with the high-coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Ruft alle Konten eines BuchhaltungsButler-Kunden ab' (retrieves all accounts of a customer). This clearly identifies the tool as a listing operation, but it does not distinguish it from siblings like list_posting_accounts or list_debtors, which share the list_* pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools such as list_posting_accounts and list_receipts could potentially overlap, but the description does not explain the differentiator or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'retrieves all debtors' and does not disclose pagination behavior (limit/offset, default 25), authentication via api_key, or expected response shape. This leaves important behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence that conveys the tool's purpose without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with fully documented optional parameters, the description is minimally adequate. However, with no output schema and no annotations, it lacks details about return format, pagination, and authentication behavior, making it incomplete for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit, offset, and api_key. The description adds no parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ruft ... ab') and clearly identifies the resource ('alle Debitoren (Kunden) eines BuchhaltungsButler-Kontos'). It also distinguishes the tool from the sibling list_creditors by explicitly naming debtors/customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_creditors or create_debtor. There are no usage conditions, exclusions, or context hints beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It adds value by disclosing the 1000-postings-per-call limit, but it leaves unstated what happens when that limit is reached (truncation, error, pagination), result ordering, and whether the operation is strictly read-only (only implied by 'abrufen').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a critical constraint. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters and no output schema, the description covers the essential operation and maximum result size. However, it omits guidance on filter combinations, default behavior when no filters are supplied, and the semantics of the 1000-item cap. It is adequate but minimal for a tool with this parameter count.
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 each of the 8 parameters having a descriptive comment. The tool description itself adds no parameter-level meaning, so the baseline score of 3 is appropriate: the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ruft ... ab') and resource ('Buchungen (Postings) für einen Kunden'), distinguishing it from list_receipts, list_accounts, and other sibling list tools. However, it does not differentiate list_postings from list_transactions, which may be semantically overlapping in accounting contexts.
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 the many sibling list tools, nor does it mention prerequisites or ideal use cases. The only usage-related detail is the maximum 1000 postings per call, which is a constraint rather than an applicability guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions retrieving transactions but does not clarify that this is a read-only operation, does not mention pagination behavior beyond schema, nor any side effects. There is no mention of authentication requirements or data scope, leaving the agent to infer 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 two concise sentences, front-loaded with the verb and resource. It efficiently communicates the core function and filtering options without any redundant or verbose language.
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 11 parameters and no output schema, the description offers minimal guidance on expected results, pagination handling, or return structure. It does not explain how filters combine or what response format to expect, making it incomplete for agents needing to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a summary of filter dimensions (account, time period, amount, counterparty) that maps loosely to the schema parameters, but it does not provide additional semantic meaning beyond what the schema already conveys.
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 ('Ruft ab' - retrieves) and the resource ('Banktransaktionen' - bank transactions) for a customer. It also highlights key filtering capabilities (account, time period, amount, counterparty), which distinguishes it from sibling tools like list_receipts or list_accounts.
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 a listing use case for transactions but does not explicitly state when to prefer this tool over alternatives like get_transaction (single) or create_transaction. It lacks explicit exclusion criteria or conditions, though the filtering context is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action of fetching a transaction, without mentioning whether it requires authentication, what it returns, error behavior, or any side effects. This is minimal and leaves the agent to infer that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the function and key identifier. There is no unnecessary elaboration or repetition, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is adequate but lacks guidance on usage versus sibling tools and any details about return values or error handling. It is complete enough for a basic get-by-ID operation but leaves gaps for an agent unfamiliar with the system.
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 100% coverage with descriptions for both parameters (api_key and id_by_customer). The description does not add new meaning beyond the schema; it merely restates the purpose of id_by_customer. Since the schema is self-explanatory, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching a single transaction by its id_by_customer. The verb 'Ruft ab' (fetches) and resource 'Transaktion' make the purpose specific, and it distinguishes from sibling tools like list_transactions (which lists multiple) and create_transaction (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single transaction needs to be retrieved by its id_by_customer, but it does not explicitly state when to use this tool versus alternatives like list_transactions. No exclusions or alternative suggestions are provided, leaving context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It states a read operation ('abruft') but says it retrieves 'all' creditors while the schema supports limit/offset pagination. This is potentially misleading. It does not describe default limits, ordering, or whether results are paginated.
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 sentence in German with clear verb and resource. It is front-loaded and contains no fluff, making it efficient for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, all documented in schema, no annotations, no output schema), the description is adequate but not rich. It omits key behavioral context like pagination despite the limit/offset parameters, and the word 'alle' conflicts with the existence of limits. This could lead to agent misunderstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no value to parameter meaning; it does not mention limit, offset, or api_key, all of which are clearly described in the schema. The description is neutral and does not conflict with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific purpose: 'Ruft alle Kreditoren (Lieferanten) eines BuchhaltungsButler-Kontos ab' (retrieves all creditors/suppliers of a BuchhaltungsButler account). It clearly distinguishes itself from siblings like list_debtors (debtors) by naming the resource (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 implies use when listing creditors but does not explicitly mention when to prefer this over alternatives or any exclusions. It lacks guidance on when not to use this tool (e.g., when filtering is needed or when using a different API key).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, but it offers no behavioral details beyond the basic listing capability—nothing about default pagination limits (despite limit/offset params), that filtering by date range is inclusive, how deleted receipts behave, or what happens when no filters are applied. Given this is a read-only list operation with 13 params, more context would be valuable and is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the core purpose and the second lists the available filters. The front-loading of the resource type (inbound/outbound) immediately orients the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with 13 optional parameters and only 1 required field, the description adequately covers the 'what' but not the 'defaults'—there's no mention of pagination behavior, maximum page size implications, or what a typical response looks like. Since there's no output schema, some note on return format could improve it, but the description is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so all 13 parameters are documented (max=500, date formats, enum values for list_direction and payment_status). The description's filter mentions (period, payment status, counterparty, invoice number) mirror existing schema params without adding new meaning, landing right at 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 verb ('Ruft...ab' = retrieves) and the specific resource (Belege/Eingangs- oder Ausgangsbelege), making the function immediately clear. It differentiates from siblings by explicitly scoping to both inbound and outbound receipt retrieval with filtering, which distinguishes it from get_receipt (single fetch) and create/delete/upload receipt variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool through its filter list (time period, payment status, counterparty, invoice number) but never explicitly contrasts it with sibling tools like get_receipt for single records or mentions when NOT to use it. There's no mention of alternatives, though the filter focus suggests a search/list use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that a new receipt is created; it does not mention authentication needs via api_key, what happens on creation, whether the operation is reversible, or what response to expect. For a mutating tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded German sentence that names the action, object, and key differentiator ('ohne Datei'). There is no redundant wording or filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 14 parameters and 6 required fields, no output schema, and no annotations, but the description only conveys the core create-without-file operation. It lacks usage context, alternative-tool differentiation, return behavior, and guidance for the many optional parameters. The schema covers parameter syntax, but the overall contextual picture is 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?
The input schema provides 100% description coverage for all 14 parameters, including formats, required vs. optional, and enum meanings. The description adds context like 'Beleg' and example types, but does not add parameter-level semantics beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Erstellt') and resource ('neuen Beleg'), and explicitly clarifies 'ohne Datei', which distinguishes it from upload_receipt. It also gives concrete examples (Eingangsrechnung, Ausgangsrechnung, Gutschrift) that map to the allowed type enum values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ohne Datei' gives clear context that this tool is for creating receipts without an uploaded file, implicitly contrasting with upload_receipt. However, it does not explicitly name that sibling as an alternative or state when not to use this tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state whether the operation is read-only or has side effects. It only mentions the optional file inclusion as Base64, but lacks details on error behavior, authentication requirements beyond the api_key parameter, or what happens if the receipt is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function without unnecessary words. It is well-structured and easy to understand.
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 action but lacks details on the return structure or expected output when get_file is not set. Given the simplicity of a get operation, this may be acceptable, but it leaves some ambiguity about what data is returned and under what conditions.
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 parameter descriptions in the schema already cover the meaning of id_by_customer and get_file. The tool description adds minimal extra context by linking id_by_customer to the receipt retrieval, but it does not significantly enhance understanding 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 that the tool retrieves a single receipt by its id_by_customer, which is a specific action distinct from sibling tools like list_receipts or delete_receipt. The verb 'Ruft ab' (retrieves) and the object 'einen einzelnen Beleg' (a single receipt) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one specific receipt by ID, and the phrase 'einen einzelnen Beleg' indicates it is for a single receipt, providing sufficient guidance. However, it does not explicitly contrast with alternatives like list_receipts, which might return multiple receipts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description does mention that the tool accesses accounts of a 'BuchhaltungsButler-Konto' and implies a read operation. However, it does not disclose details about pagination (beyond limit/offset parameters), potential authorization requirements, or what happens if no accounts exist. This is minimal but not fundamentally misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly conveys the tool's purpose. It is front-loaded and contains no unnecessary wording. Ideal for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no output schema, and high schema coverage, the description is adequate to inform an agent what the tool does. However, it does not mention any specifics about the response structure, potential errors, or whether authentication is always required. For a straightforward listing operation, this is acceptable but not outstanding.
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%, meaning each parameter has its own description in the schema. The tool description itself does not add additional parameter semantics beyond restating 'ruft alle Sachkonten ab', which might imply no parameters are typically needed. Given the high schema coverage, the description does not need to explain parameters further, hence a 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 retrieves all posting accounts ('Sachkonten') for a BookkeepingButler account. It uses a specific verb ('Ruft ab') and resource ('Sachkonten'), and the sibling tool 'list_accounts' likely refers to a different type of accounts, providing implicit differentiation based on the German terminology.
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 when to use the tool (to retrieve posting accounts), but does not explicitly specify when not to use it or mention alternatives. It doesn't reference sibling tools like 'list_accounts' or 'list_postings' to clarify distinctions, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the Base64 encoding requirement and that data:-URL prefixes are stripped. However, it doesn't mention error handling, authentication details, or what happens after upload (return value, ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both high-value. The first states the function and formats, the second provides the critical encoding requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters and no output schema. The description covers the core upload function and encoding, but lacks context on return values, error cases, or confirmation behavior. For a complex tool with no annotations and no output schema, it could do 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 description coverage is 100%, so parameters are well-documented in the schema. The description referencing Base64 encoding adds context, but most parameter semantics are already in the schema. The description adds file format info but no new parameter-level details beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it uploads a Beleg (receipt) with file (PDF, XML, image) to BuchhaltungsButler - specific verb, resource, and file formats. It doesn't explicitly distinguish from create_receipt sibling, but the focus on file upload helps differentiate it.
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 implies when to use it (uploading a receipt file) and mentions file format requirements. It doesn't explicitly state when not to use it or name alternatives like create_receipt, but the context of file-based upload is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description tells us it's a read-only operation ('Ruft... ab' indicates retrieval without side effects) and the scope (all cost centers for a customer). However, it doesn't describe any restrictions, such as potential large result sets, ordering, or whether the read is always consistent. For a simple list operation, this is adequate but not rich; the absence of a note about not requiring the API key if the environment variable is set is notable, as the schema provides that context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose without any waste. It doesn't repeat the tool name artificially or include filler. Every word serves a purpose. For such a simple tool, this is ideal 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?
Given that the tool is a simple list operation with 1 optional parameter and no output schema, the description is nearly complete. It covers what and for whom ('eines BuchhaltungsButler-Kunden'). The only minor gap is that it could mention that no API key means it uses the environment variable, but that's already in the schema's parameter description. The description doesn't need to describe return values as there's no output schema, and the operation is straightforward. Given the low complexity, the description is sufficiently complete, though a tiny bit more (e.g., 'in alphabetical order' or 'including archived cost centers') could lift it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'api_key' has a clear description explaining it's the customer's API key and is optional if an environment variable is set. The description 'Ruft alle Kostenstellen...' doesn't add parameter-specific information beyond the schema. Per the rubric, the baseline for 100% coverage is 3, and no additional meaning is added by the description, so a 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ruft alle Kostenstellen eines BuchhaltungsButler-Kunden ab' clearly states the action ('Ruft alle... ab' = retrieves all cost centers) and the resource ('Kostenstellen' = cost centers of a BuchhaltungsButler customer). It is specific and uses a clear verb+resource structure. It does not explicitly distinguish itself from the sibling 'create_cost_location', but the read vs. write distinction is easily inferable from the verb, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to list all cost centers for a customer) through the present tense 'Ruft... ab'. It does not explicitly state when not to use it or name alternatives, but the sibling context (create_cost_location) implies the read-versus-write boundary. Given the tool's simplicity, the implied usage is reasonably clear, though explicit exclusions are missing, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It mentions a critical behavioral detail: 'Wenn nicht angegeben, wird die nächste freie verwendet' regarding the posting account number, which is important for understanding how the system assigns accounts. This adds transparency beyond what the schema says. However, it does not disclose other potential side effects, like whether creating a creditor requires authentication or what happens in case of duplicate names, but given the simplicity, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that fully communicates the tool's purpose. It is front-loaded and contains no filler. Every word adds value. It does not repeat what the schema already says, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 14 parameters (mostly optional), a simple creation operation, and no output schema, the description is sufficient for understanding its function. It lacks detailed context about the API key environment variable (which is mentioned in the schema), but that is not the description's job. The description and schema together provide a complete picture for the agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% – every parameter has a description. The tool description itself adds minimal parameter info, but since the schema is already thorough, the description does not need to repeat it. The description adds the useful clarification about the posting account number auto-assignment, which supplements the schema. This justifies a score slightly above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Erstellt einen neuen Kreditor') and the resource type ('Kreditor (Lieferant)'). It distinguishes from siblings like 'create_debtor' and 'create_receipt' by specifying the business entity. The description is concise and in the same language as the parameters, which is appropriate.
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 creating a creditor but does not explicitly state when to use this tool versus alternatives like 'create_debtor' or 'list_creditors'. The sibling tools are not referenced, and there is no mention of prerequisites or the relationship to other accounting operations. Slight improvement could be made by noting that this is for supplier creation, not customer creation, but that is inferable from the term 'Kreditor'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions creating a draft without detailing side effects, permission requirements, or whether it is a mutating operation. It lacks disclosure of any behavioral aspects beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without unnecessary 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?
Given the tool's complexity (25 parameters), the description is brief and does not explain expected output or provide broader context (e.g., whether it returns a draft ID or requires further steps). It partially compensates by indicating it is a draft, but omits important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents all parameters, and the description only references that they are the same as create_invoice, adding minimal extra meaning. It does not clarify any parameter usage beyond the cross-reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an invoice draft in BuchhaltungsButler, distinguishing it from create_invoice through the 'Entwurf' (draft) wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions 'gleiche Parameter wie create_invoice', indicating that this tool is an alternative to create_invoice for draft creation, providing clear usage guidance.
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/milomymilo/buchhaltungsbutler-mcp/badges/card.svg)](https://glama.ai/mcp/servers/milomymilo/buchhaltungsbutler-mcp)

Score Badge

Copy to your README.md:

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

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