AbraFlexi MCP Server

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation3/5
Some tools are clearly distinct, but there is meaningful overlap: evidence_get and the specific invoice_issued_get/contact_get/product_get wrappers cover the same ground, and invoice_issued_get_recipients vs invoice_issued_get_email as well as contact_get_cell_phone vs contact_get_any_phone are easily confused. The descriptions help, but an agent could reasonably select the wrong tool in several cases.
Naming Consistency4/5
The dominant verb_noun pattern is consistent and readable, e.g. evidence_create, contact_update, invoice_issued_delete, changes_enable. Minor deviations such as server_info, abraflexi_client_methods, and abraflexi_client_call, plus singular/plural label variants, keep it from being a perfect 5.
Tool Count2/5
68 tools is far above the 25+ threshold for a heavy toolset. While AbraFlexi is a broad ERP system, the surface is inflated by generic evidence_* tools coexisting with many specific wrappers and by numerous highly specialized invoice_issued_* actions that could reasonably be grouped or delegated to evidence_perform_action.
Completeness4/5
The toolset covers contact, product, invoice, bank, evidence, attachment, label, change-tracking, locking, storno, mass operations, reporting, QR codes, and user queries, which is quite thorough. Minor gaps like missing dedicated invoice_received_update/delete or bank_transaction_update/delete are workaroundable via the generic evidence_update/evidence_delete tools.
Average 3.5/5 across 68 of 68 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as required permissions, idempotency, side effects, or error handling. The description is a single line with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and directly states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention return values or side effects. Missing usage context, relationships between parameters (e.g., customer reference), and behavioral guarantees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain relationships or constraints 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 action (Create) and resource (issued invoice). It distinguishes from siblings like update/delete, though does not differentiate from other create tools like 'invoice_received_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?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'Delete a contact/company'. It does not disclose permissions, irreversibility, or side effects, making behavioral transparency minimal.
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 is concise and directly states the action and resource. However, it lacks structured information, such as usage notes or parameter details.
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 simplicity and lack of annotations, the description is incomplete. It omits behavioral details, return values (despite an output schema existing but not described), and any context about the effects or limitations of 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the two parameters (id and kod).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'contact/company from AbraFlexi'. It distinguishes from sibling tools like contact_create, contact_get, and contact_update by specifying the delete action.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself, but it only says 'update multiple records'. It does not mention all-or-nothing transactionality, independent commits via atomic, validation via dry_run, or partial-failure behavior; those live only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler and names the core action up front. It is appropriately concise, though the awkward domain phrasing 'in an evidence' costs a little clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents evidence, records, atomic, and dry_run, and an output schema exists, so the core invocation is covered. The main gaps are usage context and behavioral caveats, which matter for a mutation tool with no annotations and many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a meaningful description, so the tool description does not need to compensate. It adds no parameter-level detail beyond the schema, which sets the baseline at 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 names a specific action ('update') and resource ('multiple records in an evidence') and notes the batch/single-request nature, which separates it from single-record updates and from batch insert. It does not explicitly differentiate from evidence_mass_update or define 'evidence', so it stops short of 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?
No guidance is given about when to choose this tool over evidence_update, evidence_mass_update, or evidence_batch_insert, and no exclusions or alternatives are stated. 'Single request' faintly implies batch use but leaves the decision to inference.
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 only says content is downloaded to a local file; it does not mention whether existing files are overwritten, whether directories are created, whether authentication is required, or any side effects. This is minimal disclosure for a file-writing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the core meaning, and it is immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the relationship between id/kod, evidence, and attachment_id, leaving ambiguity about which identifier identifies the attachment versus the evidence record. It does not mention how the tool behaves when output_path already exists or what the output schema contains. For a 5-parameter tool with no annotations, this is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds little beyond connecting evidence/attachment_id to the attachment and output_path to the local destination, which is the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Download'), a specific resource ('an attachment's raw content'), and a destination ('a local file'). It is clear and reasonably distinct from siblings like evidence_get_attachment_thumbnail, though it does not explicitly differentiate itself from evidence_get_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as evidence_get_attachment or evidence_list_attachments. It does not state prerequisites, exclusions, or conditions that would help an agent choose between this tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, but it only states the read operation itself. It does not mention pagination behavior, default detail level, cross-company access, or any side effects or guarantees, even though the schema hints these 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 one-sentence description is compact and front-loads the main action ('Get records'). No filler or redundant wording is present; however, the brevity comes at the cost of usage context, so it is good but not excellent.
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 generic 11-parameter reader with a rich schema and an output schema, the description covers the primary purpose and lets the schema handle parameter meaning. It is still incomplete as a standalone guide because it gives no selection criteria against the many sibling tools and no behavioral context, so it is merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each of the 11 parameters, including evidence, ids, limit, detail, and company, already carries a meaningful description. The tool description adds nothing beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Get records from any AbraFlexi evidence,' making the tool's core function immediately understandable. It is appropriately broad for a generic evidence reader, but it does not name or distinguish specialized sibling tools such as evidence_get_sum or evidence_get_record_changes, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided beyond the single sentence; there is no statement of when to use evidence_get versus specialized alternatives like evidence_get_sum, evidence_get_labels, or evidence_get_record_changes. The agent must infer selection from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'lock' and 'for the accountant' without explaining what that lock means, whether it is reversible, or what side effects it has on the record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and scope, and the parenthetical adds the specific operation name efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves meaningful gaps: it does not explain the 'lock-for-ucetni' semantics, does not distinguish from evidence_lock, and does not warn that locking a record requires either id or kod despite schema marking both optional. The output schema reduces the need to explain return values, but the usage context is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are individually documented with names and examples. The description adds nothing beyond the schema, which gives a baseline of 3. It does not clarify that id or kod is the actual record identifier, even though both are optional 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 states a clear action ('Lock') and a specific resource ('a record in any AbraFlexi evidence'), and the parenthetical identifies the variant as 'lock-for-ucetni'. However, it does not differentiate this tool from the sibling evidence_lock, so an agent cannot tell when to choose one over the other.
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 evidence_lock or evidence_unlock. It neither states conditions for use nor mentions any exclusions, leaving the agent to infer the intended scenario.
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 disclose behavioral traits on its own. It reveals that the tool mutates state by cancelling a record, but does not mention irreversibility, required permissions, audit/accounting implications, or the effect of cancelling in different evidencies. 'Any evidence' broadens scope but adds no guardrails.
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?
One short sentence with no filler; the core action and object appear first. It is admirable concise, though the terseness contributes to missing usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to explain return values, but this is a mutating tool with no annotations and multiple was to identify a record (id vs kod). The description does not clarify whether id or kod is required/preferred, what preconditions apply to storno in AbraFlexi, or what success looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (evidence, id, kod) with descriptions and an example evidence name, so schema coverage is 100%. The description adds no additional meaning about how id and kod relate or which identifier should be suppiled.
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 ('Cancel (storno)') and a defined resource ('document record in any AbraFlexi evidence'), making the action clear. However, it does not explicitly differentiate itself from sibling tools like evidence_delete or evidence_perform_action, relying on the domain-specific term 'storno' to imply distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool vs evidence_delete, evidence_perform_action, or evidence_uplate. The description only states what the operation does, leaving the agent to infer its place among the siblings.
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. 'Update' correctly implies mutation, but the description does not state whether id and kod are mutually exclusive, what happens when neither is given, whether the write is partial or full-replacement, or whether write access is required. This is comparable to the minimal coverage seen in other bare mutation tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero wasted words; the core operation and scope appear immediately. It is efficient, but arguably under-sized given the tool's six parameters and ambiguous record selectors, so it falls just short of the top score for appropriate sizing.
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?
An output schema exists and the input schema covers all parameters, so return values and parameter semantics are handled elsewhere. However, with no annotations and a minimal description, essential context is missing: how to pick between id and kod, when to prefer this over the many sibling update tools, and what update semantics apply. The description does not compensate for the annotation gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented in the schema and the description adds no parameter-level meaning. Per the baseline rule, a 3 is appropriate when the schema does the heavy lifting; the description's silence on parameters costs nothing extra.
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 a specific verb and resource: 'Update a record in any AbraFlexi evidence.' The word 'any' signals universal evidence coverage, distinguishing it from per-evidence siblings like invoice_issued_update or contact_update, and the singular 'a record' separates it from evidence_mass_update and evidence_batch_update. However, it never names those siblings explicitly, so differentiation is implicit rather than stated.
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. With many update-like siblings (evidence_create, evidence_mass_update, evidence_batch_update, evidence_perform_action, plus per-evidence update tools), the agent gets no routing signal. The description also says nothing about how to choose between the id and kod record selectors.
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 explaining side effects. It only restates the high-level operation and does not disclose whether the deduction is permanent, what it changes on either invoice, or what authorization 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 description is a single compact sentence with the action front-loaded and no filler. The parenthetical Czech term is helpful for domain users but the unexplained 'ZDD' abbreviation slightly reduces standalone clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema cover the parameter mechanics, which lowers the burden on the prose. However, for a mutating accounting operation with no annotations, the description omits when to use it and how it differs from adjacent tools such as invoice_issued_deduct_zdd or invoice_issued_link_zdd.
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 parameter mechanics are already well documented. The description adds useful business context around advance_invoice_id and the target invoice, but does not meaningfully expand on what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Deduct an advance invoice') and the affected resource ('a tax document invoice'), which goes well beyond a tautology. It does not explicitly name a sibling like invoice_issued_deduct_zdd, so some overlap with related invoice actions remains, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when this tool should be used over alternatives, what prerequisites must hold, or what conditions make an advance invoice deductible. With many closely related invoice tools in the sibling list, the agent must rely on the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and does not mention side effects, prerequisites, reversibility, or what happens to the invoice, ZDD, or related records. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key action is front-loaded. The Czech parenthetical adds localization value without bloating the text. It is concise, though it is so brief that it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is fully described and an output schema exists, covering parameters and return shape. However, the description lacks behavioral context, usage guidance, and differentiation from similar tools. For a specialized financial operation, this is a minimal viable description, not a complete one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but the schema itself already documents id, kod, extra_fields, and zdd_invoice_id with meaningful descriptions. The description neither helps nor hinders here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Deduct an advance tax document (ZDD) from an issued invoice'. It names the resource (ZDD) and target (issued invoice), and the Czech parenthetical reinforces the domain term. However, it does not explicitly distinguish itself from the similar sibling invoice_issued_deduct_advance, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like invoice_issued_deduct_advance or invoice_issued_link_zdd is provided. The description only implies the use case by naming the operation, leaving the agent to infer selection criteria from sibling names.
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 disclose behavior itself. It states the linking action but not side effects on the documents, reversibility, or any validation/preconditions. 'Link' implies a mutation but leaves consequences unspecified.
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 one sentence and front-loads the core action, with no filler. The parenthetical 'Vazby ZDD' adds domain jargon that may obscure rather than clarify, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter semantics and an output schema exists, so invocation mechanics are mostly available. However, with no annotations and no guidance on the relationship to sibling link/unlink/deduct tools, an agent lacks behavioral and conditional context needed for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema, so schema coverage is 100% and the baseline is 3. The description adds no per-parameter semantics, but it does clarify that ZDD is an advance tax document, which helps map the invoice id/kod parameters to the operation.
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 names a specific verb ('link') and both resources ('advance tax document (ZDD)' and 'income payment'), making the operation identifiable. It does not explicitly contrast with similar siblings such as invoice_issued_deduct_zdd or invoice_issued_unlink_zdd, so it stops short of 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?
There is no statement of when to use this tool, what prerequisite state is required, or when to prefer invoice_issued_deduct_zdd or invoice_issued_unlink_zdd instead. The intended usage must be inferred from the verb 'link' and the sibling names, which is not sufficient 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without detailing side effects (e.g., whether the creation triggers validations, returns the object, or requires specific permissions).
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 with no wasted words. It is concise, though it could provide a bit more context without becoming too long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage and an output schema, the description lacks contextual completeness. It does not mention the return value (output schema exists) or provide any integration context, which is important for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds no additional meaning beyond the schema, making it adequate but not enhancing understanding.
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 the resource ('received invoice in AbraFlexi'). However, it does not differentiate from sibling tools like invoice_issued_create, making the purpose clear but not uniquely distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., invoice_issued_create or bank_transaction_create). The description does not mention any prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create a new bank transaction.' It does not mention mutation side effects, required permissions, validation behavior, reversibility, or that this creates an itemless document as hinted in the castka parameter description.
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, clear sentence with no filler or redundant phrasing. It is concise, though arguably undersized for a 9-parameter mutation tool; slightly more context could be added without hurting conciseness.
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 no annotations and a nontrivial 9-parameter schema, the description is too thin. It lacks usage guidance, behavioral context, and operational expectations; the output schema helps with return values but does not compensate for the missing usage and behavior information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter has a meaningful description, so the schema already carries the parameter semantics. The tool description adds no additional parameter meaning, which is acceptable under the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a specific resource ('bank transaction in AbraFlexi'), clearly identifying the operation. It also distinguishes itself from sibling tools like bank_transaction_get and generic evidence_create by naming the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as evidence_create or bank_transaction_get. The description does not state any exclusions, prerequisites, or routing criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it enables change tracking and returns a JSON-formatted string; it does not mention side effects, idempotency, permissions required, or what happens if change tracking is already enabled.
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 very brief and front-loaded with the action and resource. The return line is slightly redundant given the output schema exists, but it is not excessive and the overall structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, this is minimally viable, but it leaves gaps around behavioral expectations such as whether enabling is idempotent, whether it requires special permissions, and how it relates to querying or disabling change tracking. These gaps are more notable because no annotations are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms an empty properties object, so there are no parameter semantics to document. The baseline of 4 applies because the description is not required to compensate for any parameter-coverage gap.
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 specific action ('Enable') and resource ('change tracking for the current company'), and scopes it to the Changes API. It is clear enough to distinguish from siblings like changes_disable and changes_status by the verb, though it does not explicitly call out those 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?
There is no guidance about when to use this tool versus related Change API tools such as changes_disable, changes_status, or changes_get. The intended use is implied by the word 'Enable,' but no conditions, prerequisites, or exclusions 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 are provided, and the description does not disclose any behavioral details such as permissions, partial update behavior, or what happens if the contact does not 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 a single concise sentence with no unnecessary words. It directly states the tool's purpose, though it could be slightly more detailed.
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?
While the schema and output schema exist, the description lacks important context about update behavior (e.g., partial vs full replace) and usage scenarios, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add much. However, it provides no additional meaning beyond the schema's parameter descriptions, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing contact/company'), distinguishing it from sibling tools like contact_create, contact_get, and contact_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus contact_create or other alternatives. The description does not mention prerequisites, conditions, or limitations.
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 only says 'delete' without noting that deletion is destructive/irreversible, whether permissions are required, or any cascading effects. For a mutating tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter schema and output schema carry much of the needed operational detail, making the tool minimally usable. However, the complete absence of deletion semantics and usage guidance leaves an agent uncertain about important selection and safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all four parameters. The description adds only the 'any evidence' scope, which slightly reinforces the evidence parameter but provides no extra operational meaning such as id/kod precedence or company behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'delete a record from any AbraFlexi evidence.' This is clear and distinct from unrelated tools, but it does not differentiate the generic evidence_delete from specialized sibling deletes like contact_delete, invoice_issued_delete, or product_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic delete versus the specialized delete tools, nor are there any exclusions or alternative recommendations. The 'any evidence' phrasing implies broad applicability, but the agent is left to infer routing on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of behavioral disclosure. It only says 'Unlock a record' without explaining effects on locked records, error cases, permissions, or consequences of unlocking. This is minimal but not deceptive; it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the core action and resource, though it is so brief that it sacrifices useful behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema and complete parameter schema, the description omits usage context, behavioral side effects, and any relation to lock operations. For a state-change tool with no annotations, this leaves the agent without enough situational understanding.
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 like evidence, id, and kod are fully documented in the schema. The description adds no additional parameter nuance, such as how id and kod interact or whether one is preferred, keeping this at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Unlock') and resource ('a record in any AbraFlexi evidence'), which cleanly identifies the tool's function. The sibling evidence_lock reinforces the distinction, making it easy to recognize this as the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to unlock a record, how this relates to evidence_lock or evidence_lock_for_ucetni, or whether unlocking requires prior locking. The agent must infer usage context entirely from the name and sibling tools.
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 does tell the agent that other labels are preserved, which is useful, but it does not disclose permanence, required permissions, behavior with nonexistent labels, or potential side effects. For a mutation tool, 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?
The description is one short, front-loaded sentence with no filler. It communicates the action, object, and key behavior without wasting tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is sufficiently rich and an output schema exists, so an agent can assemble a valid call. However, the definition is not fully self-sufficient because it fails to disambiguate from evidence_unset_labels and lacks behavioral safety context in the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 100% of parameters, including the evidence name, record identifiers, and labels_to_remove array, so the baseline is 3. The description adds little beyond the schema's own wording, and that is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Remove', the resource 'specific label(s)', and the scope 'from a record, keeping the rest', which clearly conveys what the tool does. However, it does not differentiate this singular tool from the sibling evidence_unset_labels, which sounds like the same 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?
There is no guidance about when to use this tool versus alternatives such as evidence_set_label or evidence_unset_labels. The description implies a removal use case but never states conditions, exclusions, or when the plural sibling would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning potential side effects (e.g., irreversible deletion, impact on related records) or required permissions. This leaves the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded and efficient. However, it could be slightly improved by adding brief behavioral notes without increasing length significantly.
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 is a simple delete operation, the description omits crucial context: what happens on success/failure, error cases, and whether the action is reversible. An output schema exists but may not be visible; yet the description should still hint at return behavior. Minimal completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'id' and 'kod' described adequately. The description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate since the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('issued invoice'), and the system ('AbraFlexi'). It distinguishes this tool from siblings like 'invoice_issued_create' or 'invoice_issued_get' by specifying the delete 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 (e.g., 'evidence_delete' or 'product_delete'). It lacks explicit context about prerequisites, such as whether the invoice must exist or if deletion requires authorization.
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 only the result semantics and does not explain how 'best' is determined, what happens if no recipient email exists, whether id or kod takes precedence, or any error behavior. It adds little beyond the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It front-loads the core action and result, and every word contributes to understanding what the tool does.
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 low complexity, full schema coverage, and presence of an output schema, the description is minimally viable for calling the tool. However, it omits the meaning of 'best', parameter precedence, and any fallback or error behavior, leaving meaningful gaps for an agent deciding how to invoke it robustly.
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 both id and kod documented as 'Invoice ID' and 'Invoice code (alternative to id)' respectively. The description adds no additional meaning or guidance about parameter selection, precedence, or mutual exclusivity, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the best recipient email address for an issued invoice.' This clearly identifies what the tool returns and distinguishes it from the sibling invoice_issued_get_recipients, which likely returns all recipients rather than a single best email. The word 'best' is somewhat vague but the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as invoice_issued_get_recipients or contact_get_notification_email. The phrase 'for an issued invoice' provides some scope, but no explicit conditions, exclusions, or alternative-selection criteria are given.
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 explaining side effects. It implies a mutating 'match' operation but does not disclose whether the payment is consumed, how remainder/overpayment is handled, or what state changes occur on the invoice or payment document.
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 with no filler or redundant wording. It earns its place, though it is brief enough that some behavioral context is left for other dimensions.
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 six parameters, no annotations, and a nuanced matching workflow involving remainders and overpayments, the one-sentence description is not complete enough for an agent to invoke the tool safely. The output schema exists, so return values are not a gap, but mutation behavior and alternative routing are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters, including zbytek, overpay_to, payment_evidence, and payment_id. The description adds no extra parameter-level meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Match an issued invoice against a payment document') and identifies the exact resource pairing, with the Czech term 'Parovani plateb' reinforcing the domain. This clearly separates it from sibling tools like invoice_issued_cash_payment or invoice_issued_deduct_advance, which handle different payment-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives and does not state prerequisites or exclusions. An agent must infer use from the tool name alone, and there is no mention of related matching or remainder-handling flows.
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 the full burden of behavioral disclosure. It merely states 'update' without explaining whether the update is partial or full, what authentication is needed, or what the side effects are. The existence of an output schema is not 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 extremely concise and front-loaded, delivering the core purpose in a single sentence without any fluff. However, it may be overly minimal, sacrificing helpful details that would justify a higher score in other dimensions.
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 three parameters, an output schema, and no annotations, the description is insufficient. It does not explain how to identify the invoice, what fields can be updated, or what the response will contain, leaving the AI agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema provides; it does not clarify the relationship between 'id' and 'kod' or what fields 'data' should contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'existing issued invoice', making the tool's purpose unambiguous. It is specific enough to distinguish from sibling tools like create, delete, or get.
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 creating or deleting invoices. It lacks any context about prerequisites or when updates are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only repeats the creation action, omitting details about idempotency, side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence). It is front-loaded and to the point, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the need for usage guidance, the description is incomplete. It does not cover when to use or potential pitfalls, essential for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage). The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new product') and the target system ('AbraFlexi'). It is specific and distinguishes from sibling tools like product_update or product_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., product_update). The description does not specify prerequisites or context 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?
No annotations are provided, so the description bears full responsibility. It only states 'Update an existing product' without disclosing behavioral traits such as what happens if the product is not found, whether updates are partial or full, or any authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, efficient and to the point. However, it could include slightly more information without becoming verbose.
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 simplicity and the presence of an output schema, the description is too minimal. It does not clarify the relationship between id and kod, how the data parameter should be structured, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters (id, kod, data).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'existing product' in 'AbraFlexi', distinguishing it from sibling tools like product_create (create) and product_delete (delete). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like product_create or product_get. It does not mention prerequisites (e.g., the product must exist) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states the operation type without disclosing side effects, error conditions, authentication needs, or behavior on duplicate codes.
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, clear sentence with no wasted words. It is concise, though front-loading the resource type is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (not shown) and full schema coverage, the bare description may suffice for simple create operations. However, it omits important context like duplicate handling or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds no extra meaning beyond 'Create' and 'in AbraFlexi', making it neutral.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new contact/company in AbraFlexi'). It effectively distinguishes from sibling tools like contact_delete, contact_get, and contact_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., bank_transaction_create or invoice_issued_create) or any prerequisites. The agent receives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Get the change history' clearly implies a read-only retrieval, but it does not mention pagination, ordering, identifier resolution behavior, or whether an empty history yields an error. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The parenthetical translation adds minor value and does not harm clarity. It earns its place by communicating the action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema requires only 'evidence' and allows id and kod to be null, yet the description insists this tool works on a single record without explaining that one of id or kod must be supplied. This is a significant invocation gap: an agent might call it with only the evidence name and get an ambiguous or failed request. The presence of an output schema does not resolve this selection problem.
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 each parameter already has a meaningful description. The tool description adds only the context that the history belongs to a 'single record,' which is useful but does not substantially clarify parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('change history of a single record'), making the tool's core function clear. It does not explicitly differentiate from the sibling changes_get, but the phrase 'of a single record' adds useful scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as changes_get or evidence_get. There are no conditions, exclusions, or mention of prerequisites, so an agent is left to infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get the list' implies a non-mutating read, and the phrase 'available for an evidence' adds some scoping context, but the description does not clarify whether the tool returns relation names only, what happens for unknown evidence names, or whether any special permissions are needed. It is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb and resource immediately. It is concise with no filler, though the parenthetical 'sub-evidences (relations)' could be clearer for an unfamiliar agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with an output schema, so the description need not explain return values. However, there are no annotations, no usage guidance, and no clarification of what 'sub-evidences (relations)' means or how the evidence name should be supplied beyond the schema. The description is adequate for a straightforward list operation but leaves contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, 'evidence', is already described as 'Evidence name' with a required flag. The description adds only that the list is 'for an evidence', which loosely reconnects the parameter to the purpose but does not provide additional meaning such as expected format, examples, or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a resource ('list of sub-evidences (relations)'), and a scope ('available for an evidence'), so the agent can tell it is a read-oriented listing tool. It is reasonably distinct from sibling evidence_get_* tools because it focuses on relations, though the term 'sub-evidences' is jargon and no explicit sibling differentiation is offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives such as evidence_get_properties, evidence_get_labels, or evidence_get_reports. The description only states what the tool does, leaving the agent to infer the appropriate use case from the tool name and the word 'available'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation and the phrase 'to use' hints at selection logic, but the description does not explain how the number is selected, what happens when no number exists, or any error behavior. For such a simple getter this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence with no filler. The action and target are front-loaded, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers the parameters and an output schema exists, so the description does not need to explain return values. However, the description omits usage context, such as whether id or kod is preferred, how purpose affects the returned number, and how this relates to sibling phone/contact tools. It is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds little beyond the schema; 'to use' loosely maps to the purpose parameter but provides no additional semantic detail about id versus kod or the purpose 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 states a specific verb and resource: 'Get the cell phone number' for a contact. It is clear and distinct from sibling tools like contact_get_any_phone or contact_get_notification_email, though it does not explicitly name those 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?
No guidance is given about when to use this tool versus the many related contact tools. An agent cannot tell from the description whether to choose this over contact_get_any_phone, contact_get_notification_email, or contact_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the insert operation and does not surface important behaviors such as the atomic/dry_run options, partial-failure semantics, or the default non-atomic commit behavior. The schema defines these flags, but the description itself adds no transparency beyond the obvious 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 a single, front-loaded sentence with no filler. It immediately names the verb and resource while conveying the core batching distinction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents all parameters and an output schema exists, so the tool definition is structurally complete. However, the description itself is bare: it offers no usage context, no behavioral guardrails, and no hint about batch limits or error behavior. The overall definition is minimally adequate but leaves the agent to infer when and how this tool should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides: 'multiple records' is consistent with the records field but not more informative than its schema description. No compensation is needed given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action (insert), the object (records), the target (an evidence), and the batch nature (multiple in a single request). This clearly distinguishes it from single-record creation (evidence_create) and batch update (evidence_batch_update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like evidence_create or evidence_batch_update. It does not mention any tradeoffs, limits, or exclusion conditions; the only hint is the word 'multiple,' which implicitly suggests batch use but is never made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says the tool creates a record, which is nearly a restatement of the tool name. It does not disclose side effects, permissions, whether the operation is reversible, or the cross-company write behavior hinted at by the 'company' parameter. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. The core action and scope appear immediately, and every word earns its place. It is appropriately sized for a generic create operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for selecting and invoking the tool, especially because the output schema and fully documented parameters cover return values and arguments. However, it omits useful context such as when to prefer evidence_create over evidence_batch_insert or evidence-specific create tools, and it does not surface the potentially sensitive company override behavior. These are clear gaps, so 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents 'evidence', 'data', and 'company' with useful context, including the cross-company use case. The tool description adds no parameter-level detail, but it does not need to because the schema carries the explanatory burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('a new record'), and a clear scope ('any AbraFlexi evidence'). This distinguishes it from evidence-specific create tools like invoice_issued_create and from batch creation tools like evidence_batch_insert, because it emphasizes generic single-record creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no alternatives, and no exclusions. It does not mention that dedicated create tools exist for specific evidences (e.g., contact_create, invoice_issued_create) or that evidence_batch_insert should be used for batch creation. The phrase 'any evidence' implies generality, but the agent is left to infer routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state the destructive action ('Delete'), but does not disclose irreversibility, required permissions, side effects, or what happens if the attachment does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and object. Every word contributes to the meaning, and nothing extraneous is included.
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?
An output schema exists and parameter schemas are complete, so return values and argument meanings are covered. However, for a destructive tool with no annotations, the description lacks important context like irreversibility and record-identification behavior, making it minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all four parameters. The description adds no extra semantic meaning beyond the schema, which keeps this at 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?
The description uses a specific verb ('Delete') and resource ('an attachment from a record'), clearly distinguishing it from siblings like evidence_delete (deletes the record itself) and evidence_attach_file. Even without naming alternatives, the action and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of how the id vs. kod record identifiers should be chosen. The intended usage is only weakly implied by the tool name and one-line description.
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 does disclose mass scope and 'single request' behavior, but it does not mention side effects, reversibility, risks of affecting many records, or how the action and data parameters interact. For a mutation-capable tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with the verb and scope front-loaded. There is no redundant prose, and the parenthetical 'Davkove operace' is minor and not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core operation is stated and an output schema exists, but with no annotations and several closely related sibling tools, the description lacks explicit differentiators and expected-effect warnings. It is minimally viable but incomplete for guiding an agent to select this tool over evidence_batch_update or evidence_perform_action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail in the description. The description adds no meaningful semantic information beyond mapping 'update/action' to the data/action parameters and 'filter' to filter_expr, so it does not improve on 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 a specific operation: update, or perform an action on, every record of an evidence matching a filter. The phrase 'every record ... matching a filter' conveys the mass scope, which helps distinguish it from single-record tools, but it does not explicitly name or contrast sibling tools like evidence_batch_update or evidence_perform_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The filter-based 'every record' phrasing implies this is for bulk operations on records matching a filter. However, there is no explicit guidance about when to prefer this tool over evidence_batch_update, evidence_perform_action, or evidence_update, so the agent must infer the right usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly discloses the destructive scope ('all labels'), which is useful, but it does not mention irreversibility, idempotency, or whether permission is required. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the verb and object scope front-loaded; there is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has a full input schema and output schema, but the description does not explain how to choose it over the similar single-label sibling or how id/kod relate to the evidence parameter. For such a short mutation tool, additional routing context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with id, kod, and evidence each explained in the schema. The description itself adds no parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—remove—and a clear object scope: all labels on a record. The word 'all' distinguishes it from the sibling evidence_unset_label without naming it, though the description does not explicitly call out the plural-vs-singular contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over evidence_unset_label or evidence_set_label, and no selection criteria or prerequisites are provided. An agent must infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'Delete', implying irreversibility, but lacks details on soft delete, permissions, cascading effects, or output behavior. The output schema is not referenced.
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, zero wasted words. Clearly front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though output schema exists, the description fails to mention any return value or confirmation. For a deletion tool, this is minimal but acceptable. No discussion of error conditions or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the description adds no extra meaning beyond parameter names and descriptions. It doesn't clarify when to use id versus kod, but the schema already provides minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('a product from AbraFlexi'). It effectively distinguishes from sibling tools like contact_delete or evidence_delete by naming the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like product_update or product_get. No prerequisites or context for safe deletion are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only discovery operation, and 'public ... via bridge calls' clarifies scope. However, it does not mention authentication requirements, side effects, or any operational constraints, though for a listing tool these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word earns its place: 'List', 'public', 'python-abraflexi', 'methods', 'via bridge calls'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only two self-explanatory parameters, and an output schema exists, so return values do not need description. The only gap is the missing usage linkage to abraflexi_client_call, but everything needed to invoke the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no parameter-specific meaning, but the baseline of 3 applies because the schema fully compensates.
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 ('List') and a clear resource ('public python-abraflexi methods available via bridge calls'). It distinguishes itself from the sibling 'abraflexi_client_call' (which invokes a method) by focusing on enumeration, though it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. An agent must infer that this lists available methods for later use with 'abraflexi_client_call'; the description never states this relationship or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Call' implies execution, but it does not disclose whether this is a read-only operation, whether it may mutate data (a saved query could invoke actions?), what HTTP method behavior is, or what happens with parameters. The method and params fields hint at HTTP mechanics, but the description itself does not reveal side effects or response shape.
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 one short sentence with no waste. It front-loads the core action and resource. It could add a brief consequence or usage note without hurting conciseness, but as-is it is appropriately compact.
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?
An output schema exists, so return values are presumably documented elsewhere. Still, for a tool that executes a saved query with configurable HTTP method and params, an agent would benefit from knowing typical use cases, whether this is safe to call, and how query execution differs from evidence_get. The description is minimally complete but leaves behavioral ambiguity.
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 each parameter is documented in the schema. The description adds no parameter-level semantics beyond the schema. With full coverage the baseline is 3; the description does not elevate it by explaining query_id semantics or how params maps to AbraFlexi's N-arity syntax beyond what the parameter description already says.
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 says 'Call a saved user-defined query (uzivatelsky dotaz).' That is a specific verb ('call') with a clear resource ('a saved user-defined query'), and it distinguishes this from generic evidence operations. It could be stronger by clarifying what 'call' returns, but the verb+resource is enough to tell the agent this executes a saved query rather than reading a record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, the description implies it is for executing a saved user-defined query, which is contextually distinct from siblings like evidence_get or abraflexi_client_call. It does not name alternatives or exclusion criteria, so an agent must infer usage from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the burden of safety disclosure; 'Get' reasonably implies a read-only listing operation without side effects. However, it does not explicitly confirm no mutation, permissions, or error behavior, so the disclosure is minimal but acceptable for a get/list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently communicates the exact purpose without wasting tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description is mostly complete: it states the tool's purpose and the schema already documents the parameter and return shape. It lacks explicit guidance relative to sibling tools, but the operation is simple enough that the minimal description suffices.
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 sole parameter 'evidence' is already fully described in the schema with 100% coverage. The description adds no additional parameter meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Get') and the resource ('list of printable reports') for an evidence, making the tool's purpose understandable. It does not explicitly name sibling differentiators like evidence_export_report, but 'list of printable reports' implies a listing rather than an export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives such as evidence_export_report or evidence_get_sum. The description only states what the tool does, leaving the choice of tool entirely to inference.
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 correctly identifies the operation as a mutation scoped to the current company, but it does not disclose whether existing change-tracking history is preserved or deleted, whether the action is reversible, or whether special permissions are required. For a disable operation, these are significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the action front-loaded and a compact Returns line. Every word earns its place: the verb, resource, scope, API context, and return type are all present with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered elsewhere, and the zero-parameter surface keeps requirements small. However, with no annotations and no explanation of side effects, reversibility, or relationship to changes_enable, the description leaves important behavioral context missing for a mutating tool. Overall it is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object, so there is nothing for the description to add about parameters. The phrase 'current company' refers to an implicit execution context, not a schema parameter. Per the zero-parameter baseline, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb (Disable), the resource (change tracking), the scope (current company), and the API context (Changes API). This makes it immediately distinguishable from sibling tools like changes_enable, changes_status, and changes_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that changes_enable is the inverse operation, nor does it suggest any precondition such as reviewing changes_get before disabling. The list of sibling tools is provided in the context, but the description itself gives no routing 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but it does not disclose what happens when no identifier is supplied, when both id and kod are supplied, or what errors or requirements apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with zero filler; the resource and scope are front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return value documentation is not the description's job. Still, with no annotations and both parameters optional in schema, the description leaves the crucial invocation requirement—how to identify the contact—unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with descriptions for 'Contact ID' and 'Contact code (alternative to id)' already present, so the description need not repeat them. It adds no detail beyond 'registered for a contact'; this meets the baseline but does not clarify parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (bank accounts) and scope (registered for a contact) with the verb 'Get', making it immediately distinguishable from sibling getters such as contact_get_cell_phone and contact_get_notification_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is inferable: call this when bank accounts for a contact are needed. However, the description gives no explicit when-to-use guidance, no exclusion conditions, and no pointer to alternative contact-related getters.
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 only restates the basic action and does not mention that this is a read-only list operation, what the response contains, whether authentication is required, or how the attachments are represented. This is a significant gap for a tool that is part of a large sibling family.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key information is front-loaded: what the tool does, on what resource, and across what scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema present, the core purpose, scope, and parameter meaning are adequately covered by the description plus schema. However, with no annotations and no behavioral or alternative tool guidance, the agent is left to infer important selection and behavior details in a large sibling family. This is a minimum-viable definition with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents evidence, id, and kod. The description adds only the general context that attachments belong to 'a record' and the Slovak equivalent 'prilohy,' but it does not clarify precedence between id and kod or provide any additional parameter semantics. Baseline 3 is appropriate since the 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?
The description states a specific action ('List') and a specific resource ('attachments of a record'), and further clarifies that this applies to 'any AbraFlexi evidence.' This clearly distinguishes it from sibling attachment tools like evidence_get_attachment or evidence_delete_attachment, since the task is explicitly to list rather than fetch, download, or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of a record in any AbraFlexi evidence' gives useful context for when the tool applies, showing it is generic across evidence types. However, there is no explicit guidance about when to prefer this tool over the many attachment-related siblings, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action and payment type; it does not disclose side effects such as creating a cash document, updating the invoice's paid status, posting to a cash register, or any permission requirements. For a financial mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and includes the localized term 'Hotovostni uhrada' for additional clarity. There is no redundant 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?
The output schema and parameter schema are present and complete, so return values and parameters are covered elsewhere. However, the description does not explain the operational context, prerequisites, or consequences of recording a cash payment, and it does not help the agent choose among the many payment-related sibling tools. For a financial mutation, this leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters, including the optional extra_fields payment properties, so schema coverage is 100%. The tool description adds no additional meaning about how parameters relate to the cash payment behavior, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pay'), the resource ('an issued invoice'), and the payment method ('in cash'), so an agent can understand what the tool does. However, it does not explicitly contrast itself with sibling payment tools like invoice_issued_match_payment or invoice_issued_deduct_advance, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Pay an issued invoice in cash' gives clear context for when to invoke this tool: when a cash payment needs to be recorded against an issued invoice. It does not, however, state when not to use it or mention alternative payment-related tools, so it lacks explicit exclusion 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 are present, so the description carries the burden of behavioral disclosure. 'Get all' conveys a read-only enumeration, but the description does not explain behavior when both id and kod are omitted, authentication requirements, or potential side effects. The output schema covers the return shape, which softens this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. 'Get all recipient email addresses for an issued invoice' front-loads the action and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with fully documented optional parameters and an output schema, the description is mostly sufficient. It lacks explicit differentiation from adjacent invoice/contact email tools and provides no behavioral context beyond 'get', so an agent may not know when to prefer this over siblings like invoice_issued_get_email or contact_get_notification_email.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for id, kod, and purpose, so the description does not need to repeat parameter details. The description adds no extra meaning about how the parameters interact, but the schema already provides adequate baseline information.
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 names a specific action ('get') and a specific resource ('all recipient email addresses for an issued invoice'), so it is not a tautology. It does not explicitly differentiate itself from the similarly named sibling 'invoice_issued_get_email', though the word 'recipients' narrows the meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an issued invoice' implies this tool is used when recipient email addresses are needed for an issued invoice. However, it gives no explicit when-to-use/when-not-to-use guidance and does not mention any alternative sibling or prerequisites such as needing an id or kod.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states the core action but does not mention side effects, reversibility, permission requirements, or what happens when no bond exists. For a mutation tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the action verb front-loaded. The parenthetical Czech term 'Vazby ZDD' adds useful domain context without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation with an output schema, the description is close to adequate. It does not clarify that id and kod are alternatives or that at least one should be supplied, and it leaves the accounting implications of removing a ZDD bond unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters at 100% coverage, including 'Invoice ID' and 'Invoice code (alternative to id)'. The description adds no parameter-level detail, but because the schema is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a specific resource ('advance tax document (ZDD) bonding from an issued invoice'), making the action unmistakable. It also clearly differentiates from related siblings such as invoice_issued_link_zdd and invoice_issued_deduct_zdd by describing the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when a ZDD bond needs to be removed from an issued invoice. However, the description does not explicitly mention alternatives, when not to use it, or how to choose between the id and kod parameters.
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 does not warn that arbitrary client method calls may mutate data, fail unpredictably, or require deep python-abraflexi knowledge. 'Advanced workflows' is only a weak implicit caution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action and followed by usage context. There is no redundant or filler content, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic bridge tool exposing arbitrary client methods with 8 parameters and no annotations, the description is too sparse. It does not mention how to discover valid method names, refer to the sibling abraflexi_client_methods tool, or warn about the safety implications of dynamic invocation. An output schema exists, but the missing operational guidance is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters with meaningful descriptions. The tool description adds no parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Call a public python-abraflexi client method through MCP') and names the exact resource type. It also distinguishes itself from the many dedicated sibling tools by positioning itself as a bridge for workflows 'not yet covered by dedicated MCP wrappers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly says this is for advanced workflows and implicitly routes routine cases to dedicated MCP wrappers. It does not explicitly name an alternative tool or state 'use dedicated wrappers when available', but the intended context is clear enough.
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 indicates a mutation ('Attach') but does not explain side effects, whether repeated attachments are allowed, permission requirements, record-resolution behavior when both id and kod are supplied, or what happens if neither identifier is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence containing exactly the core action, target, and scope with no filler. The essential information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits a critical precondition: a target record must be identified somehow, but both id and kod are optional in the schema and neither is required. An agent could easily attempt a call with only evidence and filepath, which cannot succeed. The output schema exists, so return-value documentation is not the gap, but record identification guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds little beyond reinforcing 'local file' and 'any evidence'; it does not clarify the relationship or mutual exclusivity of id and kod, but the schema already labels kod as an alternative to id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it attaches a local file to a record in any AbraFlexi evidence. It clearly distinguishes this from sibling attachment tools like evidence_get_attachment, evidence_download_attachment, and evidence_delete_attachment by naming the attach action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a local file needs to be attached to a record, across any evidence type. It does not explicitly name alternatives or exclusions, but the attach action uniquely matches this tool among the siblings, so confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. The word 'Get' clearly signals a read-only operation, but the description does not mention error behavior, permission requirements, or what happens if the requested evidence does not exist. This is adequate for a simple retrieval tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant wording. Every word contributes to identifying the action and the result, making it appropriately concise for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with full schema coverage and an output schema present, the description and schema together provide enough to invoke the tool correctly. It falls slightly short of 5 because it offers no behavioral or alternative-routing context, though that is less critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'evidence' parameter described as 'Evidence name'. The description adds little beyond the schema, only reinforcing that properties belong to an evidence. It does not clarify whether evidence refers to a record type, a specific record, or a naming convention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Get') and identifies the exact resource retrieved ('list of properties (fields) supported by an evidence'). This distinguishes it from sibling evidence tools like evidence_get_sum, evidence_get_labels, and evidence_get_record_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus the many sibling evidence_get_* tools, nor does it mention any exclusions or alternatives. The only usage signal is the generic 'get properties' wording, which is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not explicitly confirm that no data is modified, nor does it mention the side effect of optionally writing a PNG file via output_path (though the schema covers that). It provides basic behavioral transparency but not complete reassurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero extraneous words. It states the core action and object directly, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the schema covers all parameters and provides an output schema, so a minimal description is acceptable for invocation. The main gap is the absence of usage guidance, which is already penalized under usage_guidelines. For a straightforward getter with full schema support, the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters and their meanings. The description adds no parameter-specific detail beyond the phrase 'for a document record', which maps naturally to the `evidence` parameter. This meets the baseline for schema-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('payment QR code for a document record'), clearly differentiating it from sibling getters like evidence_get_sum or evidence_get_record_changes. It immediately communicates what the tool produces and for what input 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?
There is no guidance on when to use this tool versus alternatives such as evidence_get or evidence_get_properties. The description lacks any contextual selection criteria or exclusionary information, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals the mechanism (custom action via dedicated URL) but does not disclose side effects, mutation risks, reversibility, authentication needs, or failure behavior. For a tool that can perform arbitrary business actions like payments, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and includes an example. The contrast clause adds useful differentiation without excessive verbosity, though it could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and fully documented parameters, which helps completeness. However, with no annotations and no description of side effects or how to distinguish from generic call tools like abraflexi_client_call, the definition leaves an agent without enough behavioral context to safely invoke arbitrary business actions.
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 descriptions already cover 100% of parameters with useful text like 'Record ID to act on' and 'Action name (e.g., pay)'. The description adds a business example, but does not meaningfully extend parameter understanding beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Perform a custom business action on a record' via a dedicated {id}/{action}.json URL, with the concrete example 'paying an invoice'. It also explicitly contrasts itself with the body-level @action attribute used by evidence_lock/evidence_storno/etc., which clearly differentiates it from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'as opposed to' exclusion, telling the agent that body-level @action tools like evidence_lock/evidence_storno are not the intended path here. However, it does not address overlapping generic tools in the sibling list such as abraflexi_client_call or call_user_query, leaving some selection ambiguity for an agent.
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 the behavioral disclosure burden. It communicates a read-only aggregation operation and the existence of optional filters, but does not describe how filters interact, error behavior, or whether the sum is server-computed. This is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant wording. Every part contributes to defining the operation and its optional filtering behavior.
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 that an output schema exists and all parameters are documented, the description provides the minimal core. Still, it does not clarify when to choose this tool over siblings, how 'conditions' and 'filter_expr' combine, or what kind of totals are returned, leaving moderate gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds only the general notion of optional filtering, not specific parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), resource ('evidence'), and operation type ('summation/totals'). This distinguishes it from sibling tools like evidence_get and evidence_get_record_changes, which return records rather than aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'optionally filtered' implies this tool is for aggregated totals rather than raw records, so usage context is inferable. However, it does not explicitly name alternatives or state when this tool should be preferred over evidence_get or other evidence getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that results are scoped to the server-bound AbraFlexi company, but it does not explicitly confirm the operation is read-only, discuss missing IDs, or describe pagination behavior. The 'Get' verb and output schema partially compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. The primary purpose is front-loaded, and the scope clarifier earns its place by narrowing the data set.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no required parameters, a detailed output schema, and fully described parameters, the description is largely sufficient. It names the source and scope and points to server_info; only default behavior when no IDs are supplied remains implicit.
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 clear descriptions for ids, limit, and detail. The tool description adds no extra parameter-level nuance, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get bank transactions (banka) from AbraFlexi.' It clearly distinguishes the tool from siblings like bank_transaction_create and other evidence_get tools by naming the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope note about transactions belonging to the bound AbraFlexi company adds context, but there is no explicit guidance on when to prefer this tool over alternatives such as evidence_get, nor are any exclusions stated. Usage must be inferred from the verb and resource.
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 of behavioral disclosure. It usefully reveals that results are scoped to the bound company and excludes the company itself, which is non-obvious. However, it does not explicitly state the read-only nature, side-effect absence, authentication needs, or rate limits, leaving only the 'Get' verb to imply a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the action and resource, and the second clarifies the data scope and eliminates a common misunderstanding about the company itself. This is efficient, front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich input schema with full parameter descriptions and an output schema, the description sufficiently covers the data domain and scope. It even references server_info for additional context about the bound company. An explicit read-only note or alternative-tool routing would improve it, but nothing essential is missing for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with meaningful descriptions ('List of contact IDs to retrieve', 'Contact code to search for', 'Maximum number of results', 'Contact name to search for (partial match)', 'Detail level (summary, id, full, custom:field1,field2)'). The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get contacts/companies (adresar) from AbraFlexi', clearly identifying a specific verb and resource. It adds valuable scope by explaining these are address-book entries (customers, suppliers, other contacts) and business partners, not the company itself. However, it does not explicitly contrast with sibling contact_get_* tools, so differentiation relies mostly on tool naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool is for: retrieving address-book entries belonging to the bound AbraFlexi company, and it points to server_info for company binding context. It does not explicitly state when not to use this tool or name alternative tools, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get metadata' clearly indicates a read operation that does not return file content, but it discloses nothing about authentication, error behavior, or response characteristics beyond what the output schema already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the core action and scope, with no filler. It earns its place and leaves the schema to handle details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-metadata operation with a complete input schema and an output schema, the description is mostly sufficient. It could be more complete by naming the sibling for download or list, but nothing required to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no parameter-level meaning. The schema already documents evidence and attachment_id as identifiers and id/kod as alternatives, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), object ('metadata'), and resource ('a single attachment of a record'). The qualifier 'metadata' distinguishes it from content-returning siblings like evidence_download_attachment, and 'single' distinguishes it from evidence_list_attachments.
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 purpose implies use when metadata for one attachment is needed, but the description does not explicitly say when to prefer alternatives or when not to use this tool. No sibling routing or exclusion conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does state the core behavior: downloading a thumbnail to a local file. However, it does not disclose whether an existing output file is overwritten, whether authentication is required, or what happens when the attachment is not an image.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence expresses the full purpose with no filler. The key resource ('thumbnail'), action ('download'), and destination ('local file') are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents the seven parameters and an output schema exists, the description does not need to explain return values. It is slightly light on usage caveats, but for a download operation the combination of description and schema is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Download'), a specific resource ('thumbnail of an image attachment'), and a destination ('a local file'). This clearly separates it from sibling tools like evidence_get_attachment and evidence_download_attachment, which concern full attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'thumbnail of an image attachment' implies the tool should be used when a smaller preview is needed rather than the full attachment, but it never explicitly mentions alternatives or exclusion conditions. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' and 'currently assigned' clearly signal a read operation and current state, but it does not explicitly state non-mutation or mention any access or performance considerations. Simple and accurate, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the verb, object, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with an output schema that covers return values, so the description does not need to explain those. It is nearly complete, though a brief clarification of how evidence/id/kod jointly identify the record would remove minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description does not add meaning about how 'evidence' relates to 'id' or 'kod', beyond referring to 'a record'; it only weakly indicates that a record is being targeted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), resource ('labels'), and scope ('currently assigned to a record'). It is immediately distinguishable from the sibling set/unset label tools, which are mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the current label set on a record, contrasting with sibling tools like evidence_set_label and evidence_unset_label. However, it does not explicitly state when to prefer this over evidence_get or how to choose among the label siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It adds one useful guarantee (existing labels are retained), but it does not disclose mutation side effects, permission requirements, or failure behavior, which matters for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence with the action front-loaded and the non-destructive qualifier immediately after. There is no filler or redundant restatement of the tool name.
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?
With an output schema present and all parameters fully described in the input schema, the description covers the core operation and its most important behavioral nuance. Minor gaps remain around identifier selection (id vs kod) and explicit routing to label-removal siblings, but an agent can invoke the tool correctly from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents evidence, label, id, and kod, including the id/kod alternative. The description merely reuses the words 'label' and 'record' and adds no syntax, constraints, or parameter relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') with a clear resource ('a label to a record') and, crucially, the qualifier 'keeping its existing labels' distinguishes it from sibling operations such as evidence_unset_label and evidence_unset_labels. It is not a tautology and tells an agent exactly what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use: add a label while preserving existing labels. However, it does not explicitly state when not to use it or mention alternatives like evidence_unset_label/evidence_unset_labels, so the agent must infer the route to sibling 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 are provided, so the description carries the burden. It adds meaningful behavioral context by explaining that products are cenik (price-list) entries and belong to the specific company the server is bound to. However, it does not disclose default retrieval behavior (e.g., what happens when no ids/kod/nazev are given) or pagination details, though the schema partially covers this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the primary action ('Get products') and uses the second sentence to provide essential scoping and semantic clarification 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?
For a simple getter with a rich input schema and an output schema, the description covers the most important contextual details: what the resource is, its domain meaning, and its scope. The only minor gap is explicit guidance on when to choose this tool over the generic evidence_get, but the naming and 'price-list entry' framing largely resolve that.
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, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, but given the thorough schema descriptions, no extra compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get products (cenik) from AbraFlexi.' It also clarifies the domain meaning ('price-list entries') and scopes the data to the bound company, which distinguishes it clearly from generic siblings like evidence_get and from mutation tools like product_create.
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 declaring it retrieves products and scoping them to the bound company, but it does not explicitly name alternatives or state when not to use this tool versus evidence_get or product-related mutations. The reference to server_info gives some context, but no exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals an important selection behavior: preferring a primary/purpose-matching contact over the address's own email. This goes beyond the tool name and gives useful insight into how the result is chosen. It does not detail error behavior or missing-input handling, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and then adds the key selection nuance. Every word earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero required parameters, and the description does not clarify that at least one of id or kod should be supplied, nor what happens if neither is provided. The output schema exists and parameter schema coverage is high, but the optional-identifier ambiguity leaves a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters id, kod, and purpose are already adequately documented in the schema. The description adds a slight semantic link by mentioning 'purpose-matching,' which hints at how the purpose parameter is used, but it does not need to restate the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get the email address to notify for a contact.' It also adds a distinguishing behavioral detail about preferring a primary/purpose-matching contact, which differentiates it from sibling tools like contact_get or contact_get_any_phone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Get the email address to notify for a contact') but does not explicitly mention alternatives or exclusion conditions, such as when contact_get or contact_get_any_phone would be more appropriate. The usage context is clear but largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that changes are scoped to the bound AbraFlexi company and that results are returned as a page, which supports safe usage. It does not explicitly state read-only behavior, authentication needs, rate limits, or what happens at the end of tracked history, though the schema partially covers pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action and purpose are front-loaded, and the scoping clarification is relevant and placed second. Every 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?
For a simple paginated read tool with a full output schema and 100% schema description coverage, the description is largely sufficient. It explains the tool's purpose and scoping, but could be more complete by noting how this differs from evidence_get_record_changes and by explicitly confirming the operation is non-mutating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the important 'page' and 'incremental synchronization' conceptual framing, but it does not provide additional parameter-level meaning beyond what the schema already documents for limit, start, and evidences.
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 operation ('Get') and the resource ('a page of company-wide recorded changes via the Changes API'), and adds the specific purpose of incremental synchronization. This differentiates it from siblings like evidence_get_record_changes, which is scoped to individual records rather than company-wide changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit mention of 'incremental synchronization of external systems' gives clear context for when this tool is the right choice, and the company-wide scope is stated. However, it does not explicitly name alternatives or conditions where a sibling tool like evidence_get_record_changes should be preferred instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the tool's selection behavior: it returns any usable phone number and prefers mobile over landline. This gives meaningful insight into fallback behavior, though it does not mention edge cases like no phone number existing or potential null returns, but the output schema likely covers return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and then adds the essential preference logic. No words are wasted, and the phrasing is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-style getter, the description covers the essential decision logic: what it returns and which phone type is preferred. Combined with 100% schema coverage and an output schema, this is largely complete. It could be slightly stronger by explicitly contrasting with contact_get_cell_phone, but that gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (id, kod, purpose) are already documented in the schema. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('any usable phone number for a contact'), and adds the key discriminator 'preferring mobile over landline,' which distinguishes it from sibling contact_get_cell_phone. The purpose is immediately understandable and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when any phone number is acceptable, with a preference for mobile. However, it does not explicitly name alternatives or state when not to use it, such as when a cell phone specifically is required, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states that the tool exports a report and writes it to a local file, which is the key side effect. It does not mention overwrite behavior or permissions, but the core side effect and output destination are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with no filler. It front-loads the primary action and resource, then specifies formats and scope, making it easy to scan and process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, a fully described schema, and an output schema, the description is sufficiently complete: it states the purpose, scope, format, and output destination. It does not enumerate parameter rules, but the schema covers those; the only minor gap is lack of explicit cross-reference to evidence_get_reports for report_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description adds some high-level meaning by mapping 'record' vs 'whole evidence listing' to the id/kod parameters, but it does not enrich individual parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and identifies the resource ('printable report') along with supported formats (PDF/XLSX). It also clearly differentiates the two main invocation modes: a single record or the whole evidence listing. This lets an agent understand exactly what the tool produces without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a printable report file is needed for a record or the full listing. However, it does not explicitly name alternatives, such as evidence_get_reports, or state when not to use this tool. The usage context is clear but exclusions and sibling differentiation are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that the tool performs local date arithmetic and has no external side effects, which is valuable transparency. It does not mention edge cases like future due dates or timezone handling, but for a simple date-difference calculation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the important behavioral trait ('does not contact AbraFlexi') is placed in the second sentence where it reinforces rather than obscures the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, a single documented parameter, and an existing output schema, the description covers everything needed to invoke it correctly. It states the input, the computation, and the lack of external side effects, so no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only says 'given its due date' and adds no additional meaning beyond the schema's ISO 'YYYY-MM-DD' string description. The schema already carries the parameter 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?
The description starts with a specific verb and resource: 'Get the number of days an invoice is overdue by, given its due date.' It clearly identifies the output (overdue days) and the input (due date), and the 'pure date arithmetic' clause distinguishes it from sibling tools that interact with the AbraFlexi API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context by stating this is pure date arithmetic and does not contact AbraFlexi, which implies it is appropriate for offline or quick calculations. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving the usage guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation returning data. No annotations are provided, but the behavior is straightforward. Could explicitly state it is safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lines, with the purpose front-loaded. It is concise and to the point, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description adequately explains the tool's purpose and return value. Could mention the read-only nature, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty). The description adds no parameter details because none are needed; baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available AbraFlexi evidences, which is a specific verb and resource. It distinguishes from sibling tools that are for specific CRUD operations on individual evidences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all evidence names, but does not explicitly state when to use this tool versus alternatives like evidence_get or evidence_create. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states the main side effect (changes are prevented) and the release condition (until unlocked). It does not mention permission requirements or what happens on already-locked records, but the core behavioral impact is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every phrase earns its place: the target resource, the scope, and the effect are all communicated efficiently.
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 parameter shape, the output schema, and the presence of siblings like evidence_unlock, the description is nearly complete. It could additionally note that evidence_unlock reverses this operation, but for selecting and invoking the tool, the provided context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'evidence', 'id', and 'kod' sufficiently. The description adds no parameter-level detail beyond describing the action on 'a record', so it does not elevate the semantics beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lock'), a clear resource ('a record in any AbraFlexi evidence'), and the intended effect ('preventing further changes until unlocked'). It distinguishes itself from obvious siblings such as evidence_unlock and evidence_lock_for_ucetni by covering any evidence rather than a specialized subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the core use case clear: use this when a record must be locked against further changes. It implies the complementary operation through 'until unlocked', but it does not explicitly name evidence_unlock or contrast with evidence_lock_for_ucetni, so some usage differentiation is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral constraint: only invoices issued by the server-bound company are returned, and it corrects a likely misinterpretation of the nazFirmy/firma fields as issuer rather than customer. This is useful, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. The following sentences earn their place by clarifying scope and field semantics. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a fully described 8-parameter schema and an output schema, the description adds the most important missing context: the company scope and the meaning of nazFirmy/firma. It is complete enough for correct invocation, though it could optionally point to invoice_received_get for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description adds no parameter-specific guidance beyond the schema, such as how ids, kod, and filter_expr interact. The mentions of nazFirmy/firma are about output fields, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get issued invoices (faktura-vydana) from AbraFlexi.' It directly distinguishes issued invoices from received invoices, and the additional context about the issuing company removes ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when this tool is appropriate: to retrieve invoices issued by the bound AbraFlexi company. It also provides an explicit limitation: there is no way to query another company's invoices from this server. It does not explicitly name alternatives like invoice_received_get, but the 'issued invoices' framing makes the boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a critical and non-obvious behavior: the 'nazFirmy'/'firma' fields identify the supplier/counterparty, not the receiving company, and the result set is restricted to the bound company. This addresses the most likely misinterpretations for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two purposeful sentences with no fluff. The first sentence immediately states the verb and resource, and the second efficiently packs the important scope caveat and field semantics. Every 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?
For a read-only retrieval tool with a fully documented input schema and an output schema, the description covers the non-obvious traps: company binding and field interpretation. It does not discuss combinations of ids/kod, but those are optional and schema-documented, so no critical invocation knowledge appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; all four parameters are already documented with descriptions in the input schema. The description adds no parameter-specific guidance and does not clarify how ids and kod interact or whether they can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Get' and resource 'received invoices' from AbraFlexi, including the Czech evidence name '(faktura-prijata)'. It removes ambiguity about directionality by clarifying these are invoices received BY the bound company, distinguishing it from sibling tools like invoice_issued_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: results are scoped to the AbraFlexi company bound to the server, and querying another company's received invoices from this server is impossible. It does not explicitly name alternatives such as invoice_issued_get, but the scope and exclusion are clearly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that this is a read-only status check and that it returns a JSON-formatted string. It does not mention error cases or permissions, but for a simple status query with no parameters, the described behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core behavior, and the second gives the return type. There is no wasted wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter status check, this description is complete. It states what the tool checks, for which scope, and what it returns. The presence of an output schema further covers return-value details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to document. The schema already reflects this, and the description adds no confusing parameter-related claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check whether') and a specific resource ('change tracking is currently enabled for the current company'). It clearly distinguishes this from sibling tools like changes_enable and changes_disable, whose purposes are evident from their names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the usage scenario: use this when you need to know whether change tracking is enabled for the current company. It does not explicitly name alternatives or exclusions, but the context is clear enough for a zero-parameter status check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it does so well: it reveals the server-level scope, the specific endpoint called, and the elevated auth requirement beyond single-company rights. It does not mention side effects or failure conditions, but for a create tool with an output schema, this is strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loaded with the core action before adding the differentiator and permission requirement. Every sentence contributes useful information with no redundant restatement of the tool name or schema contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a server-level creation tool with 7 parameters and no annotations, the description provides the essential operational context: resource, scope, endpoint, and required access level. The output schema covers the return shape, so nothing an agent needs to decide whether to call this tool and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions already explain name, IC, country, org_type, use_demo, and extra_fields. The tool description adds no parameter-specific meaning, which is acceptable under the high-coverage baseline but earns no extra credit.
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 first sentence states the exact action and resource: creating a brand-new AbraFlexi company at the server root, with a parenthetical clarifying what an accounting unit is. The second sentence explicitly distinguishes it from every other *_create tool, so an agent can differentiate it from the many create-family siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool does NOT operate on the company configured via ABRAFLEXI_COMPANY, which is the key decision boundary. It names the server-level endpoint and the required permission level, giving both when-to-use and when-not-to-use guidance in two sentences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so effectively. It discloses the one-company-per-process-lifetime binding, the relevant environment variables (ABRAFLEXI_URL/ABRAFLEXI_COMPANY), and the fact that all other tools' results already belong to that company. It also signals read-only behavior through the 'Report' verb and the 'read_only' field.
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 front-loaded with the purpose, followed by binding context, usage guidance, and return format in three compact paragraphs. Each sentence carries distinct information: identity, configuration, relationship to other tools, when to call, and output contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool, the description is complete: it says what it returns (abraflexi_url, company, read_only), when to call it, and why the concept matters. Nothing an agent would need to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty input schema already makes that obvious, so the baseline is 4. The description adds useful context about the configuration variables and the returned fields, though no parameter-specific explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report which AbraFlexi company/instance this MCP server session is bound to.' It further distinguishes the tool from siblings by explaining the server is bound to exactly one company for its whole lifetime, which no other listed tool appears to cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Call this tool first whenever the identity of "the company" matters to the request' and steers away from the alternative of inferring it from record fields such as an invoice's customer/supplier name. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

[![mcp-server-abraflexi MCP server](https://glama.ai/mcp/servers/VitexSoftware/mcp-server-abraflexi/badges/score.svg)](https://glama.ai/mcp/servers/VitexSoftware/mcp-server-abraflexi)

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/VitexSoftware/mcp-server-abraflexi'

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