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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.