POHODA MCP Server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools are clearly distinct by resource type (e.g., address, invoice, stock) and action (create, list, delete, update), but some Czech document types like převodka, příjemka, prodejka, výdejka, výroba may be ambiguous to non-Czech speakers without clearer descriptions of their specific purposes within the ERP system.
Naming Consistency5/5
All tools follow a consistent 'pohoda_verb_noun' pattern with snake_case, using clear verbs like create, list, delete, update, and download. This predictability makes it easy for agents to understand and navigate the toolset.
Tool Count2/5
With 48 tools, the count is excessive for typical MCP server purposes, likely overwhelming agents and indicating poor scoping. While POHODA is a comprehensive ERP system, many tools could be consolidated or omitted to reduce complexity and improve usability.
Completeness4/5
The toolset provides broad coverage for POHODA's ERP domain, including CRUD operations for key resources like addresses, invoices, orders, and stock, plus listing exports and status checks. Minor gaps exist, such as missing update tools for some document types (e.g., invoices, offers) and limited delete operations, but core workflows are well-supported.
Average 3.2/5 across 48 of 48 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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

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 of behavioral disclosure. While 'Create' implies a write operation, the description omits whether this generates an ID, handles duplicates, requires specific permissions, or what success/failure looks like. No mention of side effects or idempotency.
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?
At only 6 words, this is under-specified rather than appropriately concise. Every sentence should earn its place, but this single sentence merely restates the function without adding value. No front-loaded critical information or structure.
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?
Given this is a mutation tool with 4 parameters, no annotations, no output schema, and integration with an external ERP system (POHODA), the description is grossly incomplete. It lacks behavioral details, return value information, and parameter explanations necessary for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (date and text have descriptions; partnerName and note do not). The description fails to compensate for these gaps by explaining the semantics of partnerName (is this a customer? supplier? internal code?) or the purpose of the note field. It adds zero parameter context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a service record in POHODA' is tautological, essentially restating the tool name (create_service). While it identifies the target system (POHODA), it fails to define what constitutes a 'service' record in this context or distinguish it from sibling tools like create_contract, create_order, or create_invoice.
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 provided on when to use this tool versus alternatives. Given the extensive list of sibling creation tools (create_invoice, create_order, create_contract, etc.), the description offers no criteria for selecting this specific tool or prerequisites for invocation.
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 burden but discloses almost nothing about safety, idempotency, pagination, return format, or whether 'Export' implies file generation. It does not clarify if the operation is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (5 words), which avoids verbosity, but it is under-structured—presenting as a fragment rather than front-loaded sentences. Every word earns its place, but there is insufficient content to guide usage.
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 4 filter parameters and no output schema, the description is incomplete. It fails to explain parameter interaction logic (AND vs OR), expected return structure, or filtering behavior when no parameters are provided (all records?).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (all 4 parameters have basic descriptions), so the description meets the baseline. However, it adds no semantic context about date formats, ID uniqueness, or the relationship between dateFrom/dateTill and lastChanges parameters.
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 provides a verb ('Export') and resource ('service records from POHODA'), but 'Export' is ambiguous compared to the tool name 'list_service'—it is unclear whether this retrieves data or generates a file export. It distinguishes the resource (services vs siblings like invoices/orders) but does not clarify the operation's nature.
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 provided on when to use ID filtering versus date ranges, or how to combine the optional parameters. No mention of sibling alternatives like pohoda_create_service or when to use pohoda_download_file instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Create' implies a write operation, there's no disclosure of side effects (stock movements?), idempotency, error handling, or return values. The presence of 'stockCode' in items suggests inventory impact that isn't mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence contains no waste, but for a 9-parameter financial document creation tool with nested line items, it is underspecified rather than appropriately concise. Front-loading is moot given the minimal length.
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?
Inadequate for the complexity: creating a sales document with partner data and line items requires explanation of the document lifecycle, VAT handling (rateVAT enum), stock integration, and return format. No output schema exists to compensate for the terse description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 44% (low), with partner fields (partnerName, partnerStreet, partnerCity, partnerZip, partnerIco) lacking descriptions. The description adds no semantic context for these undocumented fields nor explains the relationship between 'text' and 'note' parameters or required business logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create'), resource ('sales document/prodejka'), and target system ('POHODA'). It identifies the specific document type 'prodejka' distinguishing it from sibling tools like pohoda_create_invoice, though it doesn't explain what differentiates a prodejka from other sales documents.
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 provided on when to use this tool versus alternatives like pohoda_create_invoice, pohoda_create_offer, or pohoda_create_voucher. No prerequisites mentioned (e.g., whether partner data creates new records or references existing ones).
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 burden for behavioral disclosure. It states 'Create' implying mutation, but provides no details about side effects (stock level changes), reversibility, error handling, or return values. The agent cannot determine if this performs an immediate stock write-off or creates a draft document.
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 single sentence is efficient and front-loaded, but undersized for the tool's complexity (9 parameters including nested line items). While not wasteful, it lacks the necessary depth for a document creation tool with business logic implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex business document creation tool with nested line items and partner data, the description is inadequate. Missing critical context includes: VAT handling behavior, stock movement implications, required vs optional fields beyond the schema, and success/failure response patterns. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% (partner fields and most item fields undocumented). The description lists no parameters and provides no semantic guidance to compensate—such as explaining that partner fields identify the recipient, or that stockCode links to inventory items. Baseline 3 reduced due to failure to compensate for low 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 provides a clear verb ('Create'), specific resource ('dispatch document/výdejka'), and system context ('POHODA'). The parenthetical Czech term helps distinguish it from siblings like create_prodejka or create_invoice, though it doesn't explain the business distinction between these similar 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 provided on when to use this tool versus similar siblings (create_prodejka, create_invoice, create_prevodka). Given the extensive list of document creation tools in this ERP system, explicit differentiation would be necessary for correct agent selection.
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 fails to mention mutation effects (stock level changes), idempotency, error handling, or whether the operation is atomic. The description only implies a write operation through the word 'Create' without detailing 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 extremely concise with zero redundancy. However, given the tool's complexity (9 parameters including nested financial items), it is arguably undersized rather than appropriately concise. Every word earns its place, but there aren't enough of them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial document creation tool with nested line items (quantity, unitPrice, rateVAT) and no output schema or annotations, the single-sentence description is inadequate. It misses critical context: document numbering, warehouse selection, currency handling, and confirmation of successful creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% (low), with critical parameters like partnerName, partnerIco, and most item sub-properties lacking descriptions. The description adds no parameter context, failing to compensate for the schema gaps. It doesn't explain the relationship between items, stockCode, or the VAT rate enum values.
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 (Create) and the specific document type (transfer document/převodka). It distinguishes from siblings by explicitly naming the Czech document type 'převodka', which differentiates it from similar warehouse tools like create_prijemka or create_vydejka. However, it fails to explain what a převodka actually represents (e.g., internal warehouse transfer).
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 provided on when to use this tool versus similar warehouse document tools (create_prijemka, create_vydejka, create_vyroba). No mention of prerequisites, required setup, or business rules (e.g., whether both source and target warehouses must be specified).
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 full burden. While 'Create' implies a write operation, the description fails to disclose whether this affects stock levels, generates accounting entries, requires existing partners, or handles duplicates/idempotency.
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 efficient sentence with no redundancy. However, given the tool's complexity (9 parameters, nested objects, financial document creation), it is underspecified rather than optimally 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 complex mutation tool involving inventory documents with line items and partner data, the description is inadequate. It lacks output schema, annotations, and any explanation of side effects, return values, or error conditions necessary for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 44% (low), with partner fields and most item fields undocumented. The description adds no compensatory context for these parameters, nor does it explain the expected format for nested items or the relationship between partner fields and the document.
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 (Create), resource (receiving document/příjemka), and system (POHODA). It translates the Czech term 'příjemka' which aids understanding. However, it does not explain how this differs from sibling creation tools like pohoda_create_vydejka or pohoda_create_prodejka.
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 (e.g., pohoda_create_prevodka for transfers or pohoda_create_prodejka for sales). It mentions no prerequisites, business logic (inventory receipt), or conditions for use.
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 states the mutation intent ('Create') but fails to disclose idempotency behavior (what happens if code already exists), error handling, side effects, or whether the operation is atomic. Only the basic action type is conveyed.
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 consists of a single efficient sentence with no redundancy. However, for a 12-parameter mutation tool with no annotations, this brevity results in underspecification rather than effective conciseness—critical context is omitted due to excessive terseness.
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's complexity (12 parameters, mutation operation, no output schema, no annotations), the description is insufficient. It lacks error behavior documentation, return value description, and business logic constraints necessary for safe invocation of a data-modification operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions no parameters specifically, nor does it add semantic context about validation rules, parameter relationships (e.g., sellingPrice vs sellingPriceVAT exclusivity), or business logic. It relies entirely on the schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create) and resource (stock/inventory item) with domain context (POHODA). It distinguishes from siblings like pohoda_delete_stock and pohoda_list_stock through the specific action/resource combination, though it doesn't differentiate from other create_* tools beyond naming the resource type.
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 provided on when to use this tool versus alternatives like pohoda_update_stock (for existing items) or prerequisites such as whether the store must exist beforehand. The description offers no 'when-not-to-use' or prerequisite information.
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 bears full responsibility for behavioral disclosure. It states 'Create' implying mutation, but fails to disclose idempotency characteristics, validation rules (e.g., uniqueness constraints on contract numbers), error handling, or what the tool returns on success (e.g., the created contract ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with two front-loaded sentences. The first establishes purpose; the second lists optional fields. While efficient, the second sentence partially duplicates schema information that is already fully documented.
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 9 optional parameters with no required fields, the description should clarify what constitutes a minimal valid contract. It lacks explanation of return values (critical since no output schema exists) and omits business logic context such as whether duplicate contract numbers are rejected or if partners are auto-created.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, establishing a baseline of 3. The description adds minimal semantic value by grouping partner fields as 'partner details' and noting they are optional, but does not explain parameter formats beyond what the schema already provides (e.g., date formats are in the schema descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('contract') within the POHODA system. It distinguishes from sibling tools like pohoda_create_invoice or pohoda_create_order by specifying 'contract', though it could further clarify what type of contract (e.g., sales, purchase) to be a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions which fields are optional but provides no guidance on when to use this tool versus pohoda_create_order or pohoda_create_offer, nor does it specify prerequisites (e.g., whether the partner must exist beforehand or if this creates a draft vs. finalized contract).
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 but offers minimal information. It does not mention idempotency, error handling, whether the operation is reversible (noting the absence of a delete_internal_doc sibling), or what success/failure returns.
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?
Extremely efficient two-sentence structure: first sentence establishes purpose, second summarizes parameters. No filler words or redundant information; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with nested line-item objects and no output schema, the description is insufficient. It lacks explanation of return values, document lifecycle, or the business purpose of internal documents within POHODA accounting workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, establishing a baseline of 3. The description adds value by grouping optional fields in prose, but does not expand on parameter semantics beyond what the schema already documents (e.g., no examples, format constraints, or business logic for 'variable symbol').
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 core action ('Create') and resource ('internal document') with system context ('POHODA'). However, it fails to differentiate what constitutes an 'internal document' versus other creatable entities like invoices or vouchers in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it distinguishes required versus optional parameters, it provides no guidance on when to use this tool versus the numerous sibling creation tools (create_invoice, create_voucher, create_order, etc.). No prerequisites, conditions, or workflow context is provided.
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 of behavioral disclosure. While 'Create' implies a write operation, the description fails to disclose idempotency behavior, validation rules (e.g., duplicate order numbers), return values, or side effects. For a mutation tool with 12 parameters including nested line items, this is insufficient behavioral 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 a single, efficient sentence that front-loads the primary action. It avoids redundancy with the schema while conveying essential parameter categorization. However, the dense string of optional fields could benefit from formatting or grouping for improved readability.
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's complexity—12 parameters including a nested items array with 6 sub-properties, and no output schema or annotations—the description is inadequate. It lacks explanation of return values, error scenarios (e.g., invalid VAT rates), business logic constraints, or the distinction between issuedOrder and receivedOrder business contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is appropriately 3. The description adds value by categorizing parameters as required versus optional, which aids agent decision-making. However, it groups specific schema fields under vague terms like 'partner details' and 'line items' without elaborating on the nested structure that the schema reveals.
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 'Create a new order in POHODA' with specific verb (create) and resource (order). It distinguishes from sibling tools like create_invoice or create_offer by explicitly naming 'order' as the target entity, though it could better clarify the business distinction between orders and similar documents like offers or enquiries.
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 identifies required fields (orderType, date) and optional fields, but provides no guidance on when to use this tool versus similar creation tools like pohoda_create_offer or pohoda_create_enquiry. It also omits prerequisites such as whether the partner must exist beforehand or if order numbers must be unique.
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 but only states 'Create' without explaining side effects (e.g., immediate accounting impact, cash balance updates), reversibility (notably, no delete_voucher exists in siblings), or error conditions. Critical gaps for a financial mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is optimally concise with two efficiently structured sentences: the first establishes purpose, the second outlines required vs. optional parameters. No redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial tool with 13 parameters, nested line item objects, no output schema, and no annotations, the description is insufficient. It lacks critical context such as whether items are required for valid accounting, if the operation posts immediately or creates drafts, and how to handle the returned result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds minimal semantic grouping by clustering 'symbols' and 'partner details,' but provides no additional format guidance, examples, or validation rules beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'cash voucher (receipt or expense)' with specific document types, distinguishing it from sibling tools like create_invoice or create_order. However, it assumes familiarity with POHODA without explanation and doesn't clarify the business distinction between cash vouchers and similar transaction documents like prodejka/prijemka.
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 lists required fields (voucherType, date) and optional ones but provides no guidance on when to use this tool versus alternatives (e.g., when to use a cash voucher vs. an invoice) or workflow prerequisites such as whether the cash register must exist beforehand.
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 bears full responsibility for disclosing behavior but only states the basic creation action. It fails to clarify side effects (e.g., whether this automatically updates stock levels), idempotency, error handling, or what determines a successful creation given the lack of output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is maximally efficient with zero redundancy, front-loading the essential verb and object immediately.
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's complexity (4 parameters including nested item objects), absence of annotations, and lack of output schema, the description is insufficient. It omits return value documentation, error scenarios, and POHODA-specific business logic that would help an agent handle failures or confirm successful creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the structured schema already documents most parameters (date, text, items). The description adds no supplemental parameter guidance (e.g., format examples, business rules for items array), meeting the baseline expectation for medium-high schema coverage but not compensating for the undocumented 'note' parameter or nested item fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and resource ('production document'/'výroba') within the POHODA system, distinguishing it from sibling list operations (pohoda_list_vyroba) and other document types like invoices or orders. However, it lacks specificity about the business context (e.g., whether this records manufacturing output, material consumption, or assembly).
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 similar creation tools like pohoda_create_prevodka (transfer) or pohoda_create_vydejka (issue), nor does it mention prerequisites such as existing stock items or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'Delete' implies destruction, the description fails to disclose that this operation is permanent, irreversible, or whether it has cascading effects on related records. For a destructive operation, this omission is significant.
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?
Appropriately brief with two short sentences. However, the second sentence ('Requires the contract ID') wastes space by repeating information already explicit in the schema's required field list and parameter description. Front-loading is adequate with the action stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with zero annotations and no output schema, the description is dangerously incomplete. It lacks critical safety information (irreversibility warnings), return value description (success/failure indicators), or relationship context to list_contracts (how to find the ID).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds 'Requires the contract ID,' which is redundant with the schema's 'required' constraint and the parameter description 'Contract ID to delete (required)'. No additional semantic context (e.g., ID format, where to find the ID) is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (Delete), resource (contract from POHODA), and scope (by ID). Distinguishes from siblings like pohoda_create_contract or pohoda_delete_invoice by specifying the 'contract' resource type. Falls short of 5 because it lacks scope qualifiers (e.g., 'permanently removes') or workflow context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives (e.g., when to delete vs. update a contract). No mention of prerequisites, state requirements (e.g., 'only drafts can be deleted'), or warnings about irreversibility. The second sentence merely restates the required parameter.
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 but fails to clarify whether this is a read-only operation, what data structure is returned, or whether there are pagination limits. The term 'Export' implies data retrieval but doesn't specify if this is destructive or has 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 a single, efficient sentence that front-loads the verb and resource. While appropriately brief, it lacks a second sentence that could have clarified output format or key behavioral constraints without sacrificing 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?
Given the absence of both annotations and output schema, the description should explain what the tool returns (structured data vs. file) and provide basic usage patterns for the four optional parameters. As an ERP integration tool with complex sibling operations, the current single-sentence description is insufficient for reliable agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear explanations for each parameter (id, dateFrom, dateTill, lastChanges). The description adds no additional semantic context about parameter interactions (e.g., whether dateFrom requires dateTill), meeting the baseline expectation when the schema is self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Export') and resource ('receiving documents/příjemky') and specifies the POHODA system context. However, the use of 'Export' rather than 'List' (used in the function name) creates slight ambiguity about whether this generates a file or returns data, and it doesn't explicitly differentiate from other list operations beyond naming the document type.
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 (e.g., pohoda_list_stock for inventory), nor does it explain the filtering strategy given that all four parameters are optional. There is no mention of prerequisites or required 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?
No annotations provided, so description carries full burden, yet discloses nothing about read-only safety, return format, pagination, or whether 'Export' implies file generation or data retrieval. Fails to mention all parameters are optional.
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?
Extremely concise at 6 words with no filler. However, the brevity comes at the cost of missing critical context given zero annotations and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 filter parameters, no output schema, and no annotations, the description is inadequate. It fails to describe the return structure, pagination behavior, or filtering logic (AND/OR between parameters).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 fully documented in the schema. The description adds no parameter-specific guidance (e.g., date formats, ID uniqueness), earning the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Export' and resource 'sales documents (prodejky) from POHODA', distinguishing from sibling create/delete operations. However, uses 'Export' while tool name uses 'list', and doesn't explicitly differentiate from other list_* siblings (e.g., pohoda_list_invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like pohoda_list_invoices or pohoda_create_prodejka. No explanation of when to filter by id vs date ranges vs lastChanges.
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 but fails to mention critical traits such as pagination behavior, default result limits, date format expectations for the 'lastChanges' parameter, or whether 'Export' implies a file download or structured data return. The description only implies a read-only operation through the word 'Export'.
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, efficient sentence of nine words that places the primary action ('Export') at the beginning. While appropriately front-loaded and free of verbosity, its extreme brevity contributes to underspecification in other dimensions, though it does not contain wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 5 optional parameters, zero required parameters, no output schema, and no annotations, the description is insufficiently complete. It fails to specify the output format, pagination controls, or the behavior when invoked without parameters (e.g., whether it returns all stock items or requires at least one filter).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its 5 parameters, establishing a baseline of 3. The description adds marginal value by contextualizing the parameters collectively as 'optional filters,' but does not augment the schema with additional semantic details like date formats, wildcard usage examples, or the relationship between 'id' and other filter fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Export'), the resource ('stock/inventory items'), and the source system ('POHODA'). However, it does not explicitly differentiate from the sibling tool 'pohoda_list_movements' or clarify that this is a data retrieval operation as opposed to file generation, which would help distinguish it from potential export-to-file utilities.
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 phrase 'with optional filters' provides minimal implicit guidance about the parameters, but there is no explicit guidance on when to use this tool versus 'pohoda_list_movements', when to apply specific filters versus fetching all items, or prerequisites like required permissions.
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 but fails to deliver. It does not clarify whether this is a read-only operation, what data structure is returned (critical given the lack of output schema), pagination behavior, or error handling conditions.
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 single sentence is efficient with no wasted words, front-loading the key action and resource. Every element serves a purpose, though given the complexity (four parameters, no output schema, no annotations), the description is arguably undersized rather than optimally 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?
Given the absence of output schema and annotations, the description is insufficient for an agent to fully understand the tool's behavior. It lacks explanation of return values, filtering logic (AND/OR), and whether the operation is safe to invoke, leaving significant gaps for a tool interfacing with an accounting 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% description coverage, documenting all four parameters (id, dateFrom, dateTill, lastChanges) including date formats. Since the schema is self-documenting, the baseline score applies, though the description adds no additional semantic context about parameter relationships or optional usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Export') and the specific resource ('dispatch documents' with the Czech term 'výdejky') from the POHODA system. However, it does not explicitly differentiate this tool from similar listing tools like pohoda_list_prijemky or pohoda_list_prodejky, nor does it clarify the exact nature of the 'export' 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?
The description provides no guidance on when to use this tool versus alternatives, or how to effectively use the optional filtering parameters. It fails to mention that all four parameters are optional or explain the interaction between date range and ID filtering.
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 but provides minimal information. While 'export' implies a read operation, the description does not specify the output format, pagination behavior, what happens when no documents match, or whether the operation is idempotent.
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 extremely concise at nine words. It is front-loaded with the verb 'Export' and wastes no text. However, the brevity contributes to the lack of behavioral and usage context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of four optional filtering parameters, the description is incomplete. It fails to explain the return value format, the relationship between the date filters (AND/OR logic), or date string format expectations (ISO 8601, etc.).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% description coverage for all four parameters, documenting them as 'Document ID', 'Date from', 'Date to', and 'Only changed after this date'. The description adds no additional parameter semantics, but with high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Export') and resource ('production documents/výroba') from the POHODA system. It distinguishes this tool from siblings operating on different document types (invoices, orders, etc.) by specifying 'production documents'. However, it does not explicitly differentiate from the sibling 'pohoda_create_vyroba' beyond the implicit 'export' versus 'create' semantics.
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 provided on when to use this tool versus alternatives, or how to combine the optional filtering parameters (id, date range, lastChanges). There is no mention of prerequisites, permissions, or whether this retrieves current or historical production data.
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 of behavioral disclosure. It states the mutation intent ('Update') but fails to clarify whether partial updates are supported (fields omitted are preserved vs cleared), whether the operation is idempotent, or what response to expect. No safety warnings or permission requirements are mentioned.
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 efficient sentence with no redundant words. However, given the tool's complexity (8 parameters, no annotations, mutation behavior), it may be overly brief to the point of under-specification, though it avoids the tautology of simply restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It omits critical operational context such as the dual identification mechanism (id vs code), partial update behavior, and success/failure indicators. The mention of 'POHODA' provides system context but insufficient operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents all 8 parameters. The description adds no semantic information beyond the schema (e.g., explaining that 'id' and 'code' are alternative identifiers, or detailing the VAT rate enum values), warranting the baseline score 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 uses a specific verb ('Update') and resource ('stock/inventory item') and includes the context 'existing' which implicitly distinguishes it from sibling pohoda_create_stock. However, it does not explicitly differentiate from other siblings like pohoda_delete_stock or mention the POHODA system context beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., create vs update), nor does it explain the prerequisite that either 'id' or 'code' must be provided to identify the target item, or that these are mutually exclusive identification methods.
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 fails to mention whether the operation is idempotent, what side effects occur (e.g., accounting entry creation), error handling behavior, or the format of return values for this write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two efficient sentences. The first states purpose; the second summarizes requirements and options. Every word earns its place with no redundancy or filler 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?
For a complex creation tool with 15 parameters and nested line items, the description covers the essential parameter groupings but omits critical context expected for a write operation: error scenarios, idempotency guarantees, or confirmation of what constitutes a successful creation (especially given no output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, establishing a baseline of 3. The description adds value by grouping related parameters ('symbols', 'partner details', 'line items') and explicitly calling out required fields, but does not add semantic depth beyond what the schema already provides (e.g., business context for 'rateVAT' values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and resource ('bank document'), specifying the two sub-types ('receipt or expense'). However, it does not explicitly differentiate from sibling tools like pohoda_create_voucher or pohoda_create_invoice, leaving some ambiguity about when to select this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required and optional parameters but provides no guidance on when to use this tool versus alternatives (e.g., when to use bank documents vs. invoices or vouchers). It states 'Requires bankType and date' which is parameter-level usage, not tool-selection logic.
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. While it indicates a create operation, it fails to disclose what the tool returns, error handling behavior, idempotency characteristics, or POHODA-specific side effects. The mutation risk is implied but not explicit.
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?
Extremely efficient two-sentence structure. The first sentence establishes the core action and resource, while the second logically groups required versus optional parameters. No redundant or wasted language.
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 10-parameter creation tool with no annotations or output schema, the description covers the minimum viable information (action, required fields, optional fields). However, it lacks POHODA-specific context (e.g., what distinguishes an enquiry from other documents) and return value documentation, leaving significant gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, establishing a baseline of 3. The description adds semantic grouping by categorizing 'partner details' (covering 5 separate fields) and 'line items' as optional groups, which aids comprehension beyond the flat schema structure, though it doesn't explain parameter formats or validation rules beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new enquiry in POHODA' with a specific verb and resource. However, it does not differentiate from sibling creation tools like pohoda_create_offer or pohoda_create_order, which could help an agent understand when to use an enquiry versus other document types in the POHODA system.
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 (e.g., pohoda_create_offer for formal price quotes). It only lists parameter requirements without explaining use cases, prerequisites, or exclusion criteria.
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 provided, so description carries full burden. States 'Create' implying mutation, but lacks details on side effects (e.g., accounting period locking), error states, idempotency, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes purpose, second documents requirements. Front-loaded and efficiently 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?
Adequate for 18 parameters with full schema coverage, but gaps remain: no output schema means return values are undocumented, and lacking annotations, the description should mention success indicators or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. Description groups parameters ('partner details, symbols') but adds minimal semantic value beyond the schema's own field 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?
States specific action ('Create a new invoice') and target system ('POHODA'). However, it implies only invoices are created, while the invoiceType enum includes credit notes, receivables, and commitments—narrower than actual capability.
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?
Lists required fields ('Requires invoiceType and date') but provides no guidance on when to use this tool versus siblings like pohoda_create_offer or pohoda_create_order, nor when to select specific invoiceType values like issuedCreditNote versus issuedInvoice.
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 provided, so description carries full burden. States 'Delete' but fails to disclose irreversibility, side effects (impact on inventory/accounting), or business rules (e.g., cannot delete invoiced orders). Minimal safety disclosure for a destructive ERP 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?
Two short sentences, front-loaded with action. Second sentence is slightly redundant with schema's 'required' field, but overall efficient and readable.
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?
Inadequate for an ERP delete operation. No output schema handling, no mention of POHODA-specific constraints (e.g., deletion only allowed for draft orders), success/failure behavior, or idempotency. Missing critical business context for financial data deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has 100% coverage with 'Order ID to delete (required)'. Description adds 'Requires the order ID' which is redundant with schema constraints. Baseline score appropriate since schema fully documents the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Delete) + resource (order) + system context (POHODA). Explicitly distinguishes from sibling delete tools (delete_invoice, delete_stock, etc.) by specifying 'order'.
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?
Only states the obvious parameter requirement ('Requires the order ID'). No guidance on when to use vs. alternatives, prerequisites (e.g., order status checks), or warnings about deletion constraints typical in ERP systems.
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 of behavioral disclosure. While 'Export' implies a read-only operation, the description does not confirm this, nor does it disclose side effects, rate limits, authentication requirements, pagination behavior, or the format of returned 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 consists of a single, efficient sentence with no redundant words. Every element serves to identify the tool's function, making it appropriately front-loaded and 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 100% input schema coverage, the input side is adequately documented. However, there is no output schema, no annotations, and the description does not explain what data structure is returned or how filtering logic works (e.g., whether filters are AND/OR combined). This leaves significant gaps for a data retrieval 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?
With 100% schema description coverage, the input parameters (id, dateFrom, dateTill, lastChanges) are fully documented in the schema itself. The description does not add additional semantic context about parameter interactions or date formats beyond what the schema provides, warranting the baseline score 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 uses a specific verb 'Export' and resource 'transfer documents (převodky)', clearly indicating it retrieves transfer documents from the POHODA system. It implicitly distinguishes from sibling 'pohoda_create_prevodka' by using 'Export' (read) versus the implied write operation of 'create'.
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 'pohoda_create_prevodka' or other list operations like 'pohoda_list_stock'. There are no explicit when-to-use conditions, prerequisites, or exclusions stated.
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. While 'Export' implies a read operation, the description does not confirm read-only safety, disclose pagination behavior, explain return format, or mention any rate limits or permission requirements for accessing these configuration lists.
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 efficiently front-loaded with the core action ('Export settings/lists') followed by the specific type enumeration. No filler words or redundant explanations are present; every element serves a 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 single-parameter tool, the description adequately covers the input domain. However, given the absence of output schema and annotations, the description lacks completeness regarding what data structure is returned and how this 'export' differs from other list operations in terms of data freshness or 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?
The input schema has 100% description coverage ('Type of settings to export') and the description redundantly lists the enum values. This provides clarity but adds no semantic meaning beyond the schema itself (e.g., no examples of what 'numericalSeries' or 'centre' represent in the POHODA 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 uses a specific verb ('Export') and resource ('settings/lists from POHODA') and enumerates the exact configuration types supported (numericalSeries, cashRegister, etc.). This distinguishes it from siblings that handle transactional entities (invoices, orders) rather than master configuration data.
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?
While the description lists the available settings types, it fails to clarify when to use this tool versus overlapping siblings like 'pohoda_list_bank' (which could conflict with 'bankAccount' type) or 'pohoda_list_stores' (which could conflict with 'store' type). No prerequisites or exclusion criteria are provided.
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 provided, so description carries full burden. Mentions partial update capability ('any fields to update') but fails to disclose mutation risks, idempotency, error behavior (e.g., invalid ID), or side effects expected for an update 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?
Two efficient sentences with no redundancy. First sentence establishes purpose and key constraint; second enumerates parameters. 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?
Adequate for a basic update operation with comprehensive schema coverage, but lacking given the complexity of 11 parameters and mutation semantics. Absence of annotations and output schema leaves gaps regarding success indicators and failure modes that the description doesn't fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has 100% description coverage, establishing baseline 3. Description adds value by explicitly grouping parameters as 'fields to update' and emphasizing the partial update pattern, though it mostly repeats schema information without adding format constraints or examples.
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?
Clear verb ('Update') and resource ('address in POHODA addressbook') with specific constraint ('by ID'). Implicitly distinguishes from sibling pohoda_create_address by specifying 'existing' and ID-based lookup, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lacks explicit when-to-use guidance versus alternatives (e.g., when to update vs. create a new address). Only contains implicit usage hints ('existing', 'by ID') but no explicit prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It implies mutation via 'Create' but discloses no side effects, idempotency characteristics, rate limits, or return value format. For a 10-parameter creation tool with nested line items, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient at two sentences. Front-loads the core action, follows with requirement constraints, and efficiently bundles optional parameters. No redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a creation tool with good schema coverage: mentions required/optional split and captures all parameter categories. However, lacks return value description (critical since no output schema exists) and POHODA-specific behavioral context expected when annotations are absent.
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 schema has 100% description coverage, the description adds value by grouping the five partner-related fields (partnerName, partnerStreet, etc.) under the conceptual label 'partner details' and explicitly highlighting the two required fields. This semantic grouping aids agent comprehension beyond raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Create' and resource 'offer' in system 'POHODA'. However, it fails to differentiate from siblings like 'pohoda_create_enquiry' or 'pohoda_create_order' which are similar pre-sale documents, leaving the agent to guess which creation tool 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like create_enquiry or create_order. No prerequisites (authentication, permissions) or error conditions are mentioned. Only lists required vs optional fields, which is parameter documentation, not usage 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 provided, so description carries full burden. While 'Delete' implies destruction, it lacks critical safety context: irreversibility warnings, what happens if the item is referenced by other records, cascading effects, or success/failure behavior. For a destructive operation, this is a significant 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?
Single sentence, seven words. Action-oriented, front-loaded with the verb, zero waste. Appropriate length for the information provided.
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?
Inadequate for a destructive operation with optional identifiers. No output schema exists, yet the description omits return value indicators, prerequisite checks (item existence), and the identifier selection logic. Should specify if deletion is permanent and whether id or code is preferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for both 'id' and 'code'. Description adds no explicit parameter guidance, meeting the baseline for high schema coverage. However, it fails to explain the unusual case where both identifier parameters are optional (required: 0).
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?
Specific verb 'Delete' with clear resource 'stock/inventory item' and system context 'POHODA'. Clearly distinguishes from sibling create/update/list stock tools and other delete operations (address, contract, etc.) through the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives, nor does it clarify the critical parameter relationship: both 'id' and 'code' are optional in the schema, but the description doesn't explain whether one is sufficient, both are required, or which takes precedence.
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?
Without annotations, the description carries the full disclosure burden. It successfully indicates the read-only nature and return format (JSON array), but omits pagination behavior, rate limits, maximum date ranges, or authorization requirements that would be necessary for robust agent 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 efficiently structured in four short sentences with the action verb front-loaded. No words are wasted, though the content is minimalistic rather than richly informative.
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 absence of annotations and output schema, the description adequately covers the basic contract by mentioning the JSON array return type. However, it lacks detail on what constitutes a 'movement record' (fields, structure) or default behaviors when filtering isn't provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description confirms date range filtering is supported, but adds no additional semantic value regarding parameter interactions, date format preferences, or default behavior when parameters are omitted (both are optional per schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'movement records' from POHODA, using a specific verb and resource. It distinguishes from siblings like pohoda_list_stock and pohoda_list_invoices by specifying 'movements', though it could clarify whether these are stock movements or financial transactions for perfect clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Read-only export' implying safe data retrieval usage, but provides no explicit guidance on when to select this tool over similar siblings (e.g., pohoda_list_stock vs pohoda_list_movements) or prerequisites like date range requirements.
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 provided, yet description fails to clarify if 'Export' creates a persistent file (hinted by pohoda_download_file sibling) or returns data directly, nor mentions idempotency, rate limits, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 7-word sentence with zero redundancy. Front-loaded with verb and target resource, immediately conveying the operation without extraneous 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?
Adequate for a zero-parameter tool in identifying the target domain, but lacks critical context regarding output format, pagination behavior, or the specific meaning of 'Export' in the POHODA system.
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?
Tool accepts zero parameters, meeting the baseline expectation for this dimension. With 100% schema coverage (trivially true for empty schema), no additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Export' and resource 'stores (warehouses)', distinguishing from siblings like pohoda_list_invoices or pohoda_list_stock. Minor ambiguity whether 'Export' implies file creation or simple data 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?
Provides no guidance on when to use this tool versus alternatives (e.g., pohoda_list_stock) or prerequisites for invocation. No filtering constraints mentioned despite zero parameters implying a full export.
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 provided, so description carries full burden. It discloses the return format ('JSON array of matching records'), which compensates somewhat for the missing output schema. However, it lacks critical safety context (read-only assurance, idempotency), pagination behavior, or rate limiting details expected for a data retrieval tool without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste: first establishes purpose, second covers capabilities and return format. Every sentence earns its place; appropriately 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?
Adequate for a simple 4-parameter retrieval tool with complete schema documentation. Mentioning the JSON array return partially compensates for missing output schema. However, lacks completeness regarding result limits, pagination, or what constitutes a 'matching record' structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, establishing baseline 3. The description summarizes available filters ('ID, date range, or last changes') but adds no syntax details, format examples, or semantic relationships beyond what the schema already provides (e.g., does not clarify date format precedence between DD.MM.YYYY and YYYY-MM-DD).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (List) and resource (internal documents from POHODA), matching the tool name. However, it does not differentiate from sibling list tools (e.g., pohoda_list_invoices, pohoda_list_contracts) by explaining what constitutes an 'internal document' in this context.
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?
Lists filtering capabilities but provides no guidance on when to use this tool versus alternatives. Does not mention relationship to pohoda_create_internal_doc or other document-listing siblings, nor prerequisites like authentication or date format preferences.
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 must carry full behavioral burden. It successfully discloses the return format ('Returns JSON array'), but omits critical operational details like read-only safety status, pagination behavior, rate limits, or error handling patterns.
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 consists of two efficient sentences with zero waste. It is appropriately front-loaded with the core action ('List invoices') followed by filter capabilities and return format, earning its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description partially compensates by specifying the JSON array return type. However, it lacks detail on the structure/content of invoice records and omits safety/permission context that annotations would typically provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% description coverage, establishing a baseline of 3. The description adds value by summarizing the filter categories (invoice type, ID, date range, etc.), but does not extend beyond the schema's existing documentation to provide format examples or dependency relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List) and resource (invoices from POHODA), making the core purpose unambiguous. However, it does not explicitly differentiate from sibling list tools (e.g., pohoda_list_accountancy or pohoda_list_orders) or contrast with pohoda_create_invoice/delete_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?
While the description enumerates available filters, it provides no guidance on when to use this tool versus alternatives like pohoda_list_accountancy, nor does it clarify prerequisites or indicate that all parameters are optional (0 required params).
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 full disclosure burden. It states the creation action but omits critical behavioral details: whether it returns the created record ID, how it handles duplicates, error conditions, or whether the operation is idempotent.
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, front-loaded sentence that immediately states the action. The semicolon-separated list of optional fields is slightly dense but efficiently presented without extraneous 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?
For a 10-parameter creation tool with no output schema or annotations, the description covers the basic operation and parameter enumeration but lacks completeness regarding return values, success/failure behaviors, and integration with the broader address lifecycle (create vs update workflows).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all fields. The description lists optional fields but adds minimal semantic value beyond the schema (e.g., no format guidance for IČO/DIČ, no validation rules, no examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create') and target resource ('new address/contact in POHODA addressbook'), distinguishing it from siblings like pohoda_update_address and pohoda_list_addresses through the 'Create' verb.
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?
While it notes the required parameter ('Requires name'), it lacks explicit guidance on when to use this tool versus pohoda_update_address or whether duplicate checking occurs. Usage relative to alternatives is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. While 'Delete' implies destruction, the description fails to disclose critical behavioral traits: whether the deletion is permanent/irreversible, what happens to related records (invoices, orders referencing this address), or error conditions (e.g., fails if address doesn't exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two short sentences. The first sentence front-loads the core purpose. The second sentence ('Requires the address ID.') is slightly redundant given the schema already marks the field as required and the first sentence mentions 'by ID', but overall 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's low complexity (single parameter) and complete schema coverage, the description adequately covers the basic invocation pattern. However, for a destructive operation within an ERP system (evidenced by sibling tools like pohoda_create_invoice), it lacks important safety context about irreversibility or referential integrity constraints, leaving gaps in contextual 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?
With 100% schema description coverage, the schema already fully documents the 'id' parameter as 'Address ID to delete (required)'. The description adds minimal semantic value beyond stating 'Requires the address ID', which essentially duplicates the schema information. Baseline score appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Delete), resource (address from POHODA addressbook), and identification method (by ID). It effectively distinguishes from sibling tools like pohoda_create_address, pohoda_update_address, and pohoda_list_addresses through precise verb selection.
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 the verb 'Delete' and mentions the ID requirement, but provides no explicit guidance on when to use this versus pohoda_update_address or prerequisites such as verifying the address exists. It lacks 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.
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. While 'Delete' implies a destructive operation, the description fails to disclose whether this is permanent/hard deletion versus soft deletion, whether it triggers cascading deletions of related records, or what authorization level is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is appropriately concise and front-loaded with the primary action. However, the second sentence ('Requires the invoice ID') is redundant given the schema's required field constraint and parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool with 100% schema coverage and no output schema, the description provides the minimum viable context. However, it omits behavioral details (success indicators, error conditions for non-existent IDs, concurrency implications) that would be expected given the destructive nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter already documented as 'Invoice ID to delete (required)'. The description adds minimal semantic value beyond the schema, merely restating that the ID is required, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action (Delete), resource (invoice), and system (POHODA). The tool name and description together clearly distinguish this from sibling operations like pohoda_create_invoice, pohoda_list_invoices, and pohoda_delete_address.
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?
While the resource (invoice) is clearly identified, the description provides no explicit guidance on when to use this versus alternatives, nor does it mention prerequisites (e.g., whether the invoice must be in a specific state to be deleted) or exclude cases where deletion might fail.
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?
Discloses return format ('Returns JSON array of matching records'), which is necessary given the lack of output schema. However, with no annotations provided, the description fails to indicate the safety profile (read-only vs destructive), pagination behavior, or rate limits that the agent needs to know.
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?
Three sentences with clear structure: purpose first, filters second, return format third. No redundant or wasted language. Appropriately terse 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?
Adequate for a simple 5-parameter list operation with 100% schema coverage. The description compensates for missing output schema by stating the return type. However, given zero annotations, it should explicitly state the read-only/safe nature of the operation to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. The description summarizes the filtering capabilities ('Supports filtering by...') but adds no semantic detail beyond the schema (e.g., date format precedence, exact semantics of lastChanges).
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?
Clear verb ('List') and specific resource ('cash vouchers' with parenthetical clarification 'receipts and expenses'). The 'from POHODA' scope is present. Distinguishes from siblings like pohoda_list_invoices or pohoda_create_voucher by specifying the voucher type, though it could explicitly contrast with the create_voucher sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists available filters (ID, date range, company name, last changes) which provides implied context for when to use the tool. However, lacks explicit 'when to use vs alternatives' guidance (e.g., when to use this instead of pohoda_list_accountancy or pohoda_create_voucher).
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 successfully discloses the return format ('Returns JSON array of matching records'), but omits other behavioral traits like pagination limits, maximum results, or explicit confirmation that this is a read-only/safe 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 consists of two efficient sentences with zero waste: the first establishes purpose and scope, while the second covers filtering capabilities and return format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately compensates by specifying the return type ('JSON array'). For a 5-parameter listing tool with 100% schema coverage and no annotations, the description provides adequate context, though it could be improved with pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though it does synthesize the dateFrom/dateTill parameters into the concept of 'date range' which provides slight grouping context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List bank documents (receipts and expenses) from POHODA', providing a specific verb (List) and resource. It distinguishes from siblings like pohoda_list_invoices or pohoda_list_accountancy by specifying 'bank documents' and clarifying these include 'receipts and expenses'.
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 the specific entity type ('bank documents'), but provides no explicit guidance on when to use this versus pohoda_list_accountancy or other financial listing tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the authentication requirement and enumerates the specific data fields retrieved, which is helpful. However, it omits other behavioral traits like read-only safety, error conditions, or the response structure/format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with no wasted words. It is front-loaded with the action verb ('Get') and immediately specifies the resource and returned fields, followed by the authentication prerequisite.
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 (zero parameters, no nested objects) and lack of an output schema, the description adequately compensates by enumerating the specific data fields returned (company name, database, period, year). It provides sufficient context for a straightforward metadata retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per the scoring guidelines, a parameterless tool receives a baseline score of 4, as there are no parameter semantics to clarify beyond the schema itself.
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 ('Get') and clearly identifies the resource (POHODA company/accounting unit info). It distinguishes itself from sibling CRUD and list operations by targeting the specific company configuration metadata and explicitly listing the returned fields (company name, database name, accounting period, year).
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 states a prerequisite ('Requires authenticated connection') but does not explicitly define when to use this tool versus similar siblings like 'pohoda_status' or 'pohoda_list_settings'. Usage is implied by the specific fields listed (use when you need company metadata), falling short of explicit 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?
No annotations provided, so description carries full burden. It discloses 'Read-only export' (safety) and 'Returns JSON array' (return format), but lacks pagination details, volume limits, or field structure of the returned records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, zero waste. Front-loaded with action verb, followed by safety profile, capabilities, and return type. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter list tool without output schema, the description covers purpose, safety, filters, and return type adequately. Minor gap: does not mention pagination behavior or whether parameters are optional (though schema shows this).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with date formats already specified. Description mentions filtering capabilities align with parameters but adds no additional semantic value (e.g., whether dateFrom/dateTill are inclusive, or lastChanges format details). Baseline 3 appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' with clear resource 'accountancy records from POHODA'. The term 'accountancy' effectively distinguishes this tool from 20+ sibling list tools (e.g., list_invoices, list_orders) by specifying the exact record type being queried.
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?
Mentions 'Supports filtering by date range or last changes' which implies usage patterns, but lacks explicit when-to-use guidance or differentiation from related list tools. No mention of what happens when no filters are provided (full export vs error).
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 successfully discloses the return format ('JSON array of matching address records'), but fails to explicitly state the read-only/safe nature of the operation or mention pagination behavior/limits given the optional filtering.
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 well-structured sentences with zero waste: first establishes purpose and filtering capability, second specifies return format. Information is front-loaded and appropriately sized for the tool's complexity.
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 no output schema exists, the description appropriately specifies the return type ('JSON array'). For a simple filtered list operation with 5 optional parameters, it covers the essential operational context, though it could explicitly note that all parameters are optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, establishing a baseline of 3. The description lists the available filter fields, which mirrors the schema content but doesn't add additional semantic context (e.g., explaining IČO format, date syntax details beyond what the schema shows).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (List) and resource (addresses from POHODA addressbook), distinguishing it from siblings like pohoda_list_invoices or pohoda_create_address. The scope is immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' implies read/search usage, but there is no explicit guidance on when to use this versus pohoda_create_address or pohoda_update_address, nor any mention of prerequisite steps like 'use this to check for existing addresses before creating'.
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 full burden. It discloses the return format ('Returns JSON array'), which is valuable since no output schema exists. However, it omits other behavioral traits like pagination behavior, result limits, or explicit confirmation that this is read-only (though 'List' implies it).
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 three-sentence structure is efficiently front-loaded: purpose (sentence 1), filtering capabilities (sentence 2), and return format (sentence 3). Every sentence earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple flat schema (5 optional parameters, no nesting) and absence of annotations/output schema, the description adequately covers the essential information: operation type, filterable fields, and return structure. Minor gap regarding result limits or pagination keeps it from 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%, establishing a baseline of 3. The description summarizes the filtering capabilities ('ID, date range, company name, or last changes'), which maps to the schema parameters, but does not add significant semantic depth or usage examples 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 'List contracts from POHODA', providing a specific verb (List), resource (contracts), and system context (POHODA). It effectively distinguishes from siblings like pohoda_create_contract or pohoda_delete_contract through the specific verb choice.
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 the 'List' operation type, distinguishing it from mutation siblings (create/delete/update). However, it lacks explicit guidance on when to use this versus other list operations or specific prerequisites like authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds crucial information about the return format ('JSON array'), but omits important behavioral details like pagination behavior, record limits, or explicit confirmation that this 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 consists of two efficiently structured sentences with zero waste. The first sentence front-loads the core purpose, while the second covers capabilities and return type without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately discloses the return type ('JSON array of matching enquiry records'). With 100% parameter coverage and 6 optional parameters, it adequately covers the filtering interface, though it could mention pagination or default limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% description coverage, establishing a baseline of 3. The description enumerates the available filters but adds no semantic value beyond what the schema already provides (e.g., no examples, format guidance beyond the schema, or cross-parameter relationships).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('List') and resource ('enquiries from POHODA'), distinguishing it from sibling tools like 'pohoda_create_enquiry' (create vs list) and other list operations targeting different document types (invoices, orders, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by detailing available filters (enquiry type, date range, company name), but provides no explicit guidance on when to use this tool versus alternatives like 'pohoda_create_enquiry' or when to prefer specific filters over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It compensates partially by disclosing the return format ('Returns JSON array') which is necessary given the lack of output schema. However, it omits safety profile (read-only status), pagination behavior, or rate limiting details that would help an agent understand operational constraints.
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 efficiently structured: first establishes the core operation and domain, second details capabilities and return format. No redundant text or tautology; every word contributes to agent understanding of the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 7 optional parameters and no output schema, the description adequately covers the return type and available filters. It could be improved by noting that all filters are optional (enabling full list retrieval) or mentioning pagination/result limits, but it provides sufficient context for basic invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description enumerates the available filters ('order type, ID, date range, company name, order number, or last changes') but adds minimal semantic value beyond what the schema already documents. It does not clarify the date format expectations or the semantics of 'last changes' beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'List' with resource 'orders' from system 'POHODA'. It effectively distinguishes from sibling tools like pohoda_create_order and pohoda_delete_order, and differentiates from other list operations (invoices, addresses, etc.) by specifying the domain.
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 filtering capabilities ('Supports filtering by...') but provides no explicit guidance on when to use this tool versus alternatives like pohoda_list_invoices or pohoda_list_offers. It also fails to note that all parameters are optional, which would be valuable context for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: the dual-mode return behavior (base64 content for <100KB files, size-only for larger) and the path relativization requirement. It misses explicit safety classification (though 'Download' implies read-only) and error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states purpose, sentence 2 discloses the critical 100KB behavioral threshold, sentence 3 clarifies the path parameter constraint. Information is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description appropriately compensates by detailing return value structures (base64 vs size info). For a single-parameter tool, it covers the essential complexity (size limits) but could benefit from mentioning error cases (e.g., file not found) or authentication requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already adequately documents the filePath parameter. The description echoes this with 'Path is relative to documents root,' which reinforces but doesn't significantly extend the schema's semantic meaning. Baseline score appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear specific verb ('Download') and resource ('file from POHODA documents storage'). It effectively distinguishes itself from the numerous sibling CRUD tools (create_invoice, list_orders, etc.) by specifying this is for file retrieval from document storage rather than business entity operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance through the 100KB threshold disclosure, which informs users when they'll receive full content vs. metadata only. However, it lacks explicit 'when to use' guidance comparing it to document export features that might exist in other tools, and doesn't specify prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature and return format ('JSON array'). Missing pagination details or error behavior, but covers basic safety and output expectations for a simple export 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?
Four sentences, each earning its place: purpose declaration, safety hint, parameter scope, and return format. Front-loaded with the core action and no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a 2-parameter list tool. Compensates for missing output schema by stating return type. Could improve by clarifying what constitutes a 'balance record' in POHODA (accounting vs inventory context).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed date format descriptions. Description mentions 'Supports filtering by date range' which semantically connects to the two parameters. Baseline 3 appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('List') + resource ('balance records from POHODA'). Distinguishes from write-oriented siblings (create/delete/update variants) by identifying the specific entity type being queried.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'Read-only export' which signals safe querying vs mutation tools, but lacks explicit guidance on when to use this versus sibling list operations like pohoda_list_accountancy or pohoda_list_bank.
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 discloses return format ('JSON array of matching offer records') but omits safety characteristics, pagination behavior, rate limits, or error conditions. It implies read-only behavior but does not confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose front-loaded in sentence one, capabilities in sentence two, and return format in sentence three. No redundant phrases or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately compensates for missing output schema by specifying the JSON array return type. With 100% schema parameter coverage, it appropriately focuses on high-level functionality rather than parameter repetition, though it could note that all filters are optional.
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?
Given 100% schema coverage, the description adds semantic value by framing parameters as 'filtering' criteria and mapping enum values ('issued/received' vs schema's 'issuedOffer/receivedOffer'), clarifying their interactive purpose beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear resource 'offers from POHODA', distinguishing it from sibling creation tools like pohoda_create_offer and other list operations such as pohoda_list_orders or pohoda_list_invoices.
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?
While the description implies retrieval usage through 'List' and 'filtering', it lacks explicit guidance on when to prefer this over pohoda_create_offer or whether offers must exist first. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Successfully discloses read-only safety profile and return format ('Returns JSON array'). Could improve by mentioning pagination behavior or specific contents of VAT records, but covers essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, zero waste. Front-loaded with primary action, followed by safety hint, filtering capability, and return format. Every sentence earns its place with high information density.
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?
Appropriately complete for a simple list operation. Compensates for missing output schema by stating return format (JSON array). Mentions optional filtering capability. Does not explicitly note that both parameters are optional (0 required), but this is discoverable in 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 has 100% description coverage with detailed date format strings (DD.MM.YYYY or YYYY-MM-DD). Description mentions 'Supports filtering by date range' but adds minimal semantic value beyond the self-explanatory schema. Baseline 3 appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'List' + resource 'VAT classification records' + system 'POHODA'. Clearly distinguishes from sibling list tools (e.g., pohoda_list_invoices, pohoda_list_addresses) by specifying the exact record type being retrieved.
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 implied usage context through 'Read-only export' statement, distinguishing it from create/delete siblings. However, lacks explicit when-to-use guidance or named alternatives among the numerous other list_* 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?
No annotations provided, so description carries full burden. It discloses what specific information is returned (queue count, idle/working state, address) and implies read-only behavior via 'Get'. However, it omits explicit safety guarantees, idempotency, or error states that would be helpful for a server status 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?
Two well-structured sentences: first defines the operation and return payload, second defines usage context. No redundant words or unnecessary verbosity. Information is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without output schema, the description adequately compensates by enumerating the three specific status fields returned (queue, state, address). Sufficient for tool selection, though an output schema would provide better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters with 100% schema coverage (trivially). Per rubric, 0 params = baseline 4. Description appropriately does not invent parameters, focusing instead on return value semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'POHODA mServer status' and distinguishes from siblings by focusing on server health rather than business data (unlike the many create/list/update tools). It further clarifies by listing specific returned data points (queue count, state, address).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use to check if the server is ready to accept requests.' This clearly positions it as a prerequisite health-check tool. Lacks explicit 'when-not-to-use' or named alternatives, but effectively conveys its role as a readiness probe.
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:

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

Score Badge

Copy to your README.md:

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

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