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 state that this is a read-only listing operation, what authentication or permissions are needed, or what the response contains; it only names the endpoint action.

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 short and wastes little space, but "Actions: lista" is cryptic and the opening "Sales campaigns 1.0" adds little value. It is terse without being appropriately informative.

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?

There is no output schema, so the description should explain what listing promotional campaigns returns, but it gives no information about the response shape or record fields. For a list tool with no annotations and no output schema, this is a notable gap.

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 has 100% description coverage and only one parameter (`action`) with a single enum value, so the schema already fully documents the input. The description adds no meaning beyond restating that the action is "lista," which is the baseline for 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 identifies the resource as promotional campaigns ("akcije") and the action as "lista," but it does not translate or explain "lista" and does not distinguish this tool from the very similar sibling `luceed_prodajne_akcije`. The purpose is inferable but not sharply stated.

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?

It says only that the action is "lista," with no guidance on when to use this tool versus the closely related `luceed_prodajne_akcije` or other sales-related siblings. The agent must infer the usage context from the tool 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it never states that this is a read-only lookup, says nothing about permissions, pagination semantics (despite a 'page' param), or what the 'dokumenti'/'dodaci' actions actually do. The only weak signal is the implicit retrieval framing of 'by code, barcode, ...'.

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 resource clause is front-loaded, which is good, but roughly half the text is a raw dump of the 16 action names that exactly duplicates the schema's action enum. That listing consumes space without earning it, though the overall size remains 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?

For a 16-action dispatcher with 12 parameters, no annotations, and no output schema, the description is inadequate: it never explains what any individual action returns or which parameters each action requires. An agent has no way to pick the correct action or anticipate the response shape.

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 12 parameters and the action enum; baseline is 3. The description's access-dimension list loosely maps to some params (code→sifra, brand→robna_marka, attribute→atribut), but it adds no format, syntax, or interaction detail 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 opening clause 'Products (artikli): Product catalog' names the resource clearly, and the access dimensions (by code, barcode, UID, name, group, brand, attribute, list) tell an agent what kinds of lookups are supported. It stops short of differentiating from overlapping siblings such as luceed_grupe_artikala, luceed_robne_marke, luceed_prijevodi, and luceed_catalog, so it lands at 4 rather than 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, despite heavy overlap with siblings that expose the same data (groups, brands, translations). The description offers no condition that would tell an agent to prefer this tool over luceed_catalog or luceed_grupe_artikala.

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, yet it only says the tool returns on-sale articles. It omits permissions, pagination, whether results are filtered by company/warehouse, and any rate or scope limits.

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?

It is short and front-loads the core resource before the action list. Slightly terse and fragmented, but nothing wasted.

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?

No annotations and no output schema, so the description should compensate by explaining what 'lista' versus 'sifra' return and how the results are scoped. It does none of this, leaving the agent under-informed for a two-action tool.

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 'action' (enum lista/sifra) and 'sifra' (article code). The description merely repeats the two action names without explaining what each returns or how they differ, adding no meaning 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?

States a resource (articles currently on sale) with a gloss for the native term 'artiklipopusti', which is helpful. But it gives no differentiation from closely named siblings like luceed_akcije, luceed_prodajne_akcije, luceed_cijene or luceed_cjenik, so an agent cannot confidently pick this over them.

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 lists the two action values but never says when to use this tool, when not to, or which sibling to prefer for pricing/promotion data. No usage context is provided at all.

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 and delivers almost nothing: no indication of read-only vs mutating, no date-range behavior for od_datuma, no pagination, filtering, or return-shape hints. Only the bare implication of a listing action is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, but it is a fragmentary two-part label ("Scoring / points: ... Actions: lista") rather than a clear sentence, so it is borderline under-specified rather than genuinely efficient. It is not padded, which keeps it from scoring lower.

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 2-parameter data tool with no annotations and no output schema, the description should at least state what is returned and what the date filter does. It leaves both the operation semantics and the return content entirely to inference, so it is incomplete for its complexity.

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 both the action enum and the od_datuma date format ("D.M.YYYY or YYYY-MM-DD") are already documented in the schema. The description adds nothing about parameter meaning, so the baseline 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 names a resource domain ("Loyalty scoring system data", "points") and implies an operation via "Actions: lista", but it never states a concrete verb like "list" or "retrieve". An agent learns the topic is loyalty points but must infer that the tool only reads/returns a list, and it gets no differentiation from siblings such as luceed_poklon_bonovi or luceed_cjenik.

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 when-to-use guidance, no exclusions, and no mention of alternatives among the ~45 sibling tools. "Actions: lista" only names the single available action rather than explaining in which situations an agent should pick this tool over the others.

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 and discloses nothing: no indication of read-only vs. mutating behavior, no return/pagination info, no permission requirements. The "lista" action names weakly imply a listing/read operation, but nothing is stated explicitly, leaving behavior largely opaque.

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?

Very short and front-loaded, which is good, but the opening phrase is redundant/confusing rather than informative. Every token is technically "spent" on the enum restatement, so brevity comes at the cost of substance.

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 no output schema and no annotations, the description must explain the shape of returned bundle data and how uid/b2b map to the chosen action; it does neither. For a 3-parameter tool with a dependent-parameter enum pattern, this leaves the agent guessing about inputs and results.

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 enum on action plus the uid/b2b descriptions already document all three parameters, so the baseline is 3. The description merely re-lists the enum values and does not explain the pairing between action and its dependent parameter (lista_uid requires uid, lista_b2b requires b2b), adding no real meaning 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?

"Bundle items: Bundle article definitions and components" reads as a tautology of the name and uses "Bundle" ambiguously as a verb. The listed actions (lista, lista_uid, lista_b2b) suggest a read/list operation over article bundles, but the description never states plainly that it retrieves bundle definitions, nor does it distinguish it from siblings like luceed_artikli or luceed_varijante.

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 when-to-use guidance and no mention of alternatives among the many sibling tools. The action names are repeated from the schema enum, which adds no routing information about which action (and thus which of uid/b2b) to pick, and nothing tells the agent when this tool is preferable to luceed_artikli or luceed_varijante.

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. It does disclose the read-only nature of the listed resources and the intent of the Magento filter, but says nothing about the shape of the response, ordering, or size limits of the listing.

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, and the scope statement is front-loaded ahead of the filter guidance. Slightly clipped phrasing costs it a point but nothing is wasted.

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 no-output-schema, zero-required-parameter discovery tool, the description is minimally adequate. It gestures at the returned content ('resources/actions/paths') but does not describe the listing's structure, which matters because downstream tool selection depends on it.

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 both parameters are already documented in the schema; baseline 3 applies. The description roughly restates both filters and adds the 'Magento Debuglabs/Luceed' qualifier for magento_only, but adds no syntax or example beyond the schema's own 'e.g. nalozi_prodaje'.

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?

States a specific verb (List) and resource (mapped Luceed read-only resources/actions/paths), making clear this is the catalog/discovery endpoint rather than a domain data tool. It is implicitly distinguishable from the domain siblings, but never explicitly says it is the index used to find the other endpoints.

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?

It explains how to narrow results (resource id filter, magento_only=true for Magento endpoints), which is useful filter guidance. However, it never states when to reach for this tool versus the many domain siblings, nor that it is the discovery step before calling them.

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 usefully discloses that prices are current and include promotions, but it does not state the read-only nature explicitly, nor does it describe authentication, rate limits, or return format.

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 short and front-loads the core resource. There is slight redundancy between 'Current prices' and 'Current selling price', but no wasted sentences.

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 tool with seven parameters and conditional action modes, the description does not explain which parameters apply to which action (e.g., partner and tip_partner for partner action, username for loyalty). With no output schema, it also does not describe the response shape or what price fields are returned.

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 seven parameters. The description confirms the action values but adds no additional meaning about how action-specific parameters such as partner, tip_partner, username, or valuta are used.

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 resource and scope clearly: 'Current prices' and 'Current selling price including promotions.' It also lists lookup modes, but it does not explicitly distinguish this tool from nearby siblings such as luceed_cjenik or luceed_cjenik_partner.

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?

Listing the action values ('sifra, barcode, partner, loyalty') implies the available lookup modes, but the description gives no explicit when-to-use guidance or alternatives to sibling pricing tools. The agent must infer that these actions select the lookup method.

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 says nothing about read-only status, return format, authentication, rate limits, or any side effects. This is a critical gap for an agent trying to call it safely.

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 short but suffers from under-specification rather than conciseness. It is front-loaded with the resource name, yet the fragment 'Actions: lista' is redundant with the schema and wastes space that could carry usage or behavior 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 low complexity (one enum parameter, no output schema, no annotations), the description is still incomplete. It fails to state what the tool returns or when to use it, leaving the agent unable to invoke it with confidence. A simple read tool still needs a clear purpose statement.

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 single action parameter has an enum with a description. The description mentions the action 'lista' but adds no meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema fully documents the parameter.

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 identifies the resource ('Service partner price list') and the action ('lista'), so an agent can roughly infer it lists service partner price list data. However, there is no explicit verb and the phrasing 'Price list: Service partner price list' is repetitive, leaving purpose vague. Sibling differentiation is weak against tools like luceed_cijene and luceed_cjenik_partner.

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. It does not mention prerequisites, conditions, or any of the many sibling tools. An agent must guess entirely from the name and action enum.

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 implies a read/lookup operation but never states it is read-only, whether pagination affects result completeness (the 'page' param), what a 'getdiff' returns or against what baseline, or any auth requirement.

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 compact fragments, front-loaded with the resource identity before the action list. It is efficient, though the action list is redundant with the schema and costs space without adding value.

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 7-parameter, multi-action tool with no annotations and no output schema, the description is too thin: it does not map the actions to their required parameters, explain the 'tip'/'modified' semantics, or describe what 'getdiff' produces. An agent can guess a call shape but not call it confidently.

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% (7 params, all documented in the schema), so the baseline is 3. The description adds nothing about which parameters pair with which action (e.g. uid for the uid action vs sifra for the sifra action) and merely echoes the enum values already 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 names the resource ('Partner price lists and diffs') and the three action modes, so an agent can tell it is about partner-specific pricing. However it never differentiates itself from the obvious siblings luceed_cjenik and luceed_cijene, leaving the agent to guess which pricing tool applies. The purpose is decipherable but not sharply drawn.

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 when-to-use guidance is given: it does not say when to prefer sifra over uid, what getdiff is for, or how this differs from the general cjenik/cijene siblings. The action list simply restates the schema enum, so the agent gets 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only semantics, authentication needs, caching, or pagination. The 'lista' action weakly implies a read, but nothing is stated explicitly.

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?

It is short and front-loaded, but the opening clause 'CRM visit causes: CRM visit reason codes' is redundant repetition rather than information. The 'Actions:' fragment is terse to the point of being cryptic.

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 single-parameter code lookup, so a minimal description is nearly sufficient, and the enum fully specifies invocation. However, with no output schema and no annotations, the description still omits what a caller receives, leaving the definition only marginally 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% and the single 'action' parameter is fully constrained by an enum, so the schema already does the heavy lifting. The description's 'Actions: lista' merely echoes the one allowed value rather than adding format or meaning.

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 identifies the resource (CRM visit reason codes) but supplies no verb, and the first two phrases are essentially restatements of the tool name. The only indication of what it does is 'Actions: lista', which implies a listing/retrieval endpoint. An agent gets the domain but must infer the 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 when-to-use guidance, no conditions, and no mention of any sibling tool (e.g. luceed_sifrarnici). 'Actions: lista' names the sole action but does not tell the agent when this codebook is the right one to call.

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 and does well: it declares the operation read-only and discloses that mutating paths are blocked when LUCEED_READ_ONLY=true, a conditional safety constraint an agent must know. It omits auth requirements, error/return shape, and rate behavior, keeping it short of a 5.

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?

Three short sentences, front-loaded with what the tool is, followed by the safety constraint, routing preference, and a concrete example. No filler; 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?

No output schema exists, but for a raw pass-through GET the description gives enough to call it correctly: scope, path format, example, and the read-only constraint. A brief note on the response envelope or failure modes would round it out.

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?

Only one parameter with 100% schema coverage, so the baseline is 3. The description adds real value beyond the schema by clarifying the path is relative under /datasnap/rest/ and giving a concrete example ('artikli/sifra/111') that demonstrates the expected format.

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?

States a specific verb and resource: a raw read-only GET against any relative datasnap/rest path. It explicitly scopes itself against siblings by saying it covers paths 'not covered' and to 'Prefer catalog tools when possible', so the agent can distinguish it from luceed_catalog and the many resource-specific tools.

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?

Gives clear when-to-use ('not covered', 'ad-hoc exploration') and names the preferred alternative (catalog tools). It does not explicitly state when NOT to use it beyond the preference, but the routing guidance is concrete and actionable.

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, and it discloses nothing. It does not say whether these actions read or mutate data, what permissions are needed, what each action returns, or what 'dodaci' actually means. The action labels are not explained.

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 text is short but this is under-specification rather than conciseness. It is written as two noun/verb fragments, and the action list adds no information beyond the enum already present in the schema.

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 no annotations, no output schema, and three parameters whose semantics are only partly clear, the description should explain the four actions and what each returns. Instead it only names them, leaving an agent unable to confidently pick an action or predict the shape of results.

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 three parameters (sifra, action, dio_naziva). The description only echoes the action enum values without adding meaning, so the baseline 3 for high schema coverage 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 is a fragment ('Product groups: Article groups. Actions: lista, sifra, naziv, dodaci.') that names a resource area but never states a clear verb. Listing the action enum values restates the schema rather than explaining what the tool does, and it does not distinguish itself from siblings like luceed_artikli or luceed_varijante.

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 the many sibling lookup tools (luceed_artikli, luceed_robne_marake, luceed_sifrarnici, etc.). The only implicit signal is that it concerns article groups, which an agent must infer from the resource 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?

No annotations are provided, so the description carries the full behavioral burden. It states nothing about whether these are read or write operations, permission/auth requirements, rate limits, or return shape—all five actions are effectively opaque behaviors.

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?

It is compact and front-loads the domain before the action list, with no filler. But the brevity comes from under-specification rather than efficient phrasing—the raw list of untranslated action names does little work for the reader.

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 10-parameter multi-action dispatcher with no annotations and no output schema. The description never explains which parameters apply to which action (e.g. does 'gosti' need datum or hotel_uid?), leaving the agent to guess the correct argument combination for each call.

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 10 parameters, and the action enum is fully described there. The description adds nothing beyond the enum values it repeats, so the baseline 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?

It identifies the resource domain (hotel reservations, registrations, guest overview) and the dispatcher action verb, which distinguishes it from siblings like luceed_artikli or luceed_partneri. However, the five action values are untranslated Croatian tokens with no gloss, so an agent cannot tell what 'prijave' or 'gosti' actually returns without external knowledge.

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 lists the available actions but gives no guidance on when to pick one over another, no preconditions, and no alternatives among the many luceed_* siblings. The action list is a bare enumeration, not usage direction.

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 and no output schema, the description carries the full disclosure burden and largely fails it: it does not say whether this is read-only, what permissions are needed, what the return shape is, or how the four actions differ behaviorally. The only useful nugget is that 'mjesta/list' yields the full list, which is marginal.

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?

Very short and front-loaded with the resource name and action list. The mid-sentence Magento reference is a slight non sequitur, but nothing is padded.

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 four-parameter multi-action tool with no annotations and no output schema, the description leaves too much unstated: the semantics of each action, how parameters bind to actions, and what any call returns. It is underspecified relative to the tool's complexity.

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 (sifra, dio_naziva, postanski_broj, action). The description merely repeats the action enum and adds no meaning about how parameters pair with actions, e.g. whether action=sifra requires the sifra parameter. Baseline 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 identifies the resource clearly (locations/cities, 'mjesta') and enumerates the available actions, so an agent knows this tool serves place data. However, it never states the actual operation in verb form — there is no 'retrieve'/'look up' — and the enum is restated rather than explained, so the intent of each action remains opaque.

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 siblings such as luceed_sifrarnici or luceed_partneri, nor when each action (list vs. sifra vs. naziv vs. postanskibroj) is appropriate. The lone hint — 'Magento uses mjesta/list for full list' — is contextual trivia rather than a usage rule.

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, and it discloses almost nothing. It does not say whether the call is read-only, whether od_datuma/do_datuma are required or defaulted, whether results are paginated, or what shape the response takes. Only the implicit read-only nature of a "calculation" is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses with the core purpose and the action list front-loaded; no filler or repetition. The phrasing is slightly telegraphic ("Actions: placanja, artikli") but compact and readable.

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 4-parameter, no-annotation, no-output-schema tool, the description covers the essential purpose and the action split, which is the minimum viable level. It leaves unresolved the overlap with near-identical siblings and gives no hint about date-range handling or return contents, so an agent may still pick the wrong retail-sales tool.

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 baseline would be 3, but the description goes beyond the schema by mapping the enum values to meaning: 'placanja' = turnover by payment type, 'artikli' = turnover by product. The schema only labels 'action' as "Which endpoint action to call", which is uninformative, so this mapping is genuine added value. The date and business-unit parameters still receive no explanation in either place.

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 purpose: retail turnover calculation broken down by payment type or by product, with the two action values named. That is clear enough for an agent to know what the tool returns. It does not, however, distinguish itself from the very similar siblings luceed_retail_sales_summary and luceed_retail_sales_by_product, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage cue is the vague trigger phrase "use for 'how much sales'". No when-not conditions and no alternatives are named, despite two obvious sibling candidates (luceed_retail_sales_by_product, luceed_retail_sales_summary) that an agent could easily confuse with this tool. Guidance is present but not actionable for selection.

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 behavioral burden. It implies read-only access by saying 'list and fetch', but does not state permissions, rate limits, whether the PDF action generates a file, or what each action returns. This is a significant gap for a multi-action 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 efficient sentence that front-loads the tool's purpose and then lists actions. It avoids waste, though the action list is somewhat redundant with the enum and could be structured more clearly.

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 complexity (8 parameters, 6 actions, no output schema, no annotations), the description is too minimal. It does not explain what each action does (e.g., lista vs uid vs pdf), leaving the agent to infer behavior from action names alone. This is inadequate 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 schema already documents all eight parameters including the action enum. The description only repeats the action names and adds no further meaning about parameters like godina, pj_uid, or date ranges. 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 clear verb (list and fetch) and resource (retail invoices), with the Croatian term 'Maloprodajni računi' adding specificity. It does not explicitly differentiate itself from sibling invoice tools like luceed_mpobracun or luceed_racuni_predujma, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the many sibling tools for invoices, sales orders, or calculations. The description lists actions but does not say which action to choose in a given situation or mention any alternatives.

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. It never states whether this is read-only or mutating, despite 'izmjena_status' strongly implying a write operation, and says nothing about permissions, side effects, or what each action returns. The action list is a hint at behavior, not a disclosure of it.

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?

Very short and front-loaded, but the opening clause is pure duplication of name and title, and the action list duplicates the enum. A small amount of text is wasted, though the overall length is appropriate.

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 multi-action dispatcher with four actions, no annotations, and no output schema, the description should at least explain what each action returns or requires. Nothing beyond the enum is given, leaving the agent unable to call the tool correctly without guessing from enum names.

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 merely repeats the action enum values already documented in the schema and adds no format, dependency, or conditional-meaning information (e.g., that 'uid' is required for the 'b2b' action).

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 restates the tool name ('Return orders: Return orders (NaloziPovrata)') and then lists the action enum values, which are already in the schema. There is no verb describing what the tool actually does with return orders (fetch? create? modify status?), and no differentiation from siblings such as luceed_nalozi_prodaje, luceed_narudzbe, or luceed_vpracuni.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling order-related tools. The agent must infer from the action names alone which endpoint to select.

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 Luceed does not sort or paginate, that raw statusi output is unsorted, and that statusi needs a filter. Critically, it omits that at least one action (izmjena_status) appears to be a mutation, so an agent cannot tell which actions write data, nor what permissions or side effects 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?

The most important constraint (no sort/pagination) is front-loaded and the alternative tool is named early, which is good structure. The trailing enum list is long but it does map directly to the action param, so it earns its space; the sentence is information-dense with minimal 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?

For a 9-param, 10-action, no-annotation, no-output-schema tool, the description covers the cross-cutting caveats well (sorting, pagination, alternative tool) but leaves per-action behavior, required parameters per action, and return shapes unexplained. It is adequate but clearly gapped for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 only one parameter-level insight (statusi requires a status filter); it does not say which params each action needs, nor clarify od_datuma/do_datuma/timestamp formats beyond the schema's terse labels.

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?

States a specific resource with scope ('B2B / wholesale sales orders') and enumerates the ten action endpoints verbatim, so the agent knows exactly what surface it is calling. It also names the sibling it is not (luceed_recent_sales_orders), which helps disambiguation. It stops short of 5 because the action names are given as bare strings with no gloss (e.g. 'izmjena_status' reads as a status change, not a read).

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?

Explicitly routes the agent away from this tool for 'latest N orders' toward luceed_recent_sales_orders, and warns that statusi results require a status filter. That is real when-to-use/when-not guidance. It does not, however, distinguish this from other order-like siblings such as luceed_narudzbe or luceed_racuni_predujma.

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, and it discloses nothing. It does not note that 'izmjena_status' is a mutation, whether any action requires authentication or specific partner/B2B credentials, or what a caller gets back.

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?

Very short, but it wastes its only sentence repeating the tool name and then dumping a bare action list. It is under-specified rather than genuinely concise, and nothing useful is 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?

For an 8-parameter, 6-action tool with no annotations and no output schema, the description is far too thin. An agent cannot tell what each action does, what it requires, or what it returns, so it cannot reliably invoke this tool without guessing.

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 only echoes the action enum names without adding meaning (e.g., what 'statusi' returns, or why 'od_datuma'/'do_datuma' matter for a given action), so it neither compensates nor regresses from baseline.

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 restates the tool name twice ('Production orders: Production orders (NaloziProizvodnje)') and then lists action identifiers that are already the schema's enum values. It never states in a functional sense what the tool does or returns, and gives no differentiation from siblings like luceed_nalozi_prodaje or luceed_radni_nalozi.

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 when-to-use guidance, no distinction from the many sibling order/document tools, and no indication of which action to pick for a given goal. The action list implies multiple operations but leaves selection entirely to the caller.

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. It does not disclose that 'izmjena_status' is a mutation while the other actions are reads, nor any permission requirements, side effects of status changes, date-range defaults, or pagination behavior.

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?

It is short and front-loads the resource, but the first clause is redundant, restating the name twice, and the action list is packed without structure or explanation. Roughly half the text is wasted repetition rather than useful signal.

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 10-parameter multi-action dispatcher with no annotations and no output schema. The agent needs to know how each action maps to its parameters and what it returns; the description supplies none of that, leaving the tool effectively undocumented 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 every parameter is already documented in the schema and the baseline is 3. The description only echoes the action enum values, adding no meaning about which parameters pair with which action (e.g. partner/godina/od_datuma for 'partner_statusi').

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 identifies the resource (purchase orders / narudžbe) and a general function (retrieve and status changes), but opens with a near-tautology, 'Purchase orders (narudžbe): Purchase orders'. The seven action names are listed but never characterized, so an agent cannot tell what 'statusi' versus 'partner_statusi' versus 'zaprimljene_kolicine' actually returns.

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 siblings like luceed_recent_sales_orders, luceed_nalozi_prodaje, or luceed_nalozi_povrata, nor which action to pick for a given intent. The action list is a bare enumeration with no selection criteria.

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 says 'lookup,' which weakly implies read-only behavior, but it does not disclose permissions, rate limits, pagination behavior, return shape, or action-specific side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence, front-loading the resource and lookup purpose before listing actions. It is not verbose, though the action list largely duplicates the schema enum.

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 multi-action tool with 12 parameters, no annotations, and no output schema, the description is too sparse. It does not explain action-specific parameter requirements, pagination, or what the lookup returns.

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 12 parameters. The description repeats the action enum but does not explain how the action determines which parameters matter, such as when to use oib versus dio_naziva versus partner_uid.

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/resource pair: partner master data lookup for partners/customers, and enumerates the available action names. It is clear what the tool is for, though it does not distinguish itself from siblings such as luceed_users or luceed_cjenik_partner.

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?

It gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The only implied usage is that it is a lookup tool for partner data.

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 carries the full burden. It usefully discloses that this is a non-destructive read that validates credentials and connectivity via a real endpoint (skladista/lista), but says nothing about failure behavior, error signaling, latency, or rate limits.

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; the purpose is stated first and nothing redundant follows.

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 diagnostic with no output schema, the agent has enough to call it correctly. A brief hint about what a success versus failure result looks like would have made it fully self-contained.

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 takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies no input is needed.

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?

States a specific verb (verify) and resource (credentials/connectivity) plus the method (via skladista/lista). It is naturally distinct from the many data-retrieval siblings because it is explicitly a health check, but it never names a sibling or confirms that 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?

"Health check" implies the usage scenario (diagnostic before/around real calls), but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Adequate but leaves the agent to infer the trigger conditions.

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 never states whether this is a read-only lookup, what permissions or serial number are required, or what the response contains (validity vs. balance, format). For a lookup tool with zero annotation coverage, 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 short and front-loaded, stating the resource and purpose before the action note. The 'Actions: stanje' fragment is slightly redundant with the schema enum but costs little.

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 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It hints at what is returned (validity/balance) but omits the read-only nature, authentication needs, and result shape, leaving real 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 schema already documents both 'action' and 'serijski'. The description adds nothing beyond restating the single enum value, so the baseline 3 applies; no format or lookup-key guidance is contributed.

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 resource ('Gift vouchers') and its purpose ('validity / balance'), which is more than a tautology. However, the operation verb is only implied and the sole action 'stanje' is left untranslated/unexplained, so an agent must infer that this retrieves a voucher's status. No 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 statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The 'Actions: stanje' note merely echoes the schema enum rather than guiding selection. It could be confused with the many other state/balance siblings like luceed_bodovi or luceed_stanje_zalihe.

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 full behavioral burden but discloses only the resource. It does not state read-only status, permissions, whether actions are lookups or mutations, or return behavior.

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 fragments with the resource front-loaded. The action list is redundant with the schema enum, but there is no verbosity.

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 3-parameter tool with full schema coverage and no output schema, the description is minimally viable: it identifies the resource and allowed actions. However, it omits action semantics and when to use this versus siblings, leaving gaps for an agent selecting among many luceed_* tools.

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 uid, sifra, and action. The description merely repeats the action enum values and adds no meaning about which parameter each action expects or what the action returns.

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?

Identifies the resource as CRM/case records ('Cases (predmeti)') and lists the three available actions. It does not differentiate this tool from similarly named CRM or lookup siblings like luceed_crm_razlozi, but the core purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this tool over any sibling, or when to use each action. The action names are listed without conditions or alternatives.

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, and it discloses almost nothing: it does not state that this is a read-only listing, whether it requires auth, how results are scoped by table/language, or any pagination behavior. The word 'records' weakly implies retrieval but is not enough for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two terse fragments with no waste, but the brevity reflects under-specification rather than effective conciseness. It is front-loaded with the resource, which is the only structural merit.

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 four parameters, no annotations, and no output schema, the description is too thin to let an agent invoke this correctly — it never explains what 'lista' returns, how tablica/jezik filter results, or whether uid narrows to a single record.

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 four parameters (uid, jezik, action, tablica) are already documented in the schema, and the description adds no format or semantic detail beyond the generic word 'tables'. Baseline 3 applies when 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 names the resource (translation records for tables) and the sole action (lista/list), so an agent can tell it retrieves translations. However, it gives no distinguishing scope versus siblings like luceed_artikli or luceed_sifrarnici, and the verb is only implied by the enum value.

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 the many sibling lookup tools, nor any stated preconditions. 'Actions: lista' only restates the enum constraint already in the schema.

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 implies a read/list operation through 'lista' but never states that it is read-only, what it returns, or any permission/rate considerations, leaving the agent to infer behavior.

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?

It is very short and the resource is front-loaded. Minor redundancy between 'Sales campaigns 2.0' and 'Sales campaigns v2 (prodajneakcije)' costs it a point, but there is no wasted prose.

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 list tool with a fully documented schema and no output schema, the essentials are present. However, the missing distinction from the sibling luceed_akcije and the absent read-only/return context leave it only minimally 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% and there is a single enum parameter, so the schema already documents 'action' and its only value 'lista'. The description's 'Actions: lista' adds nothing beyond the enum, matching the baseline 3 for schema-covered params.

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 resource (sales campaigns, v2, prodajneakcije) and hints at the operation via 'Actions: lista', but never states a clear verb like 'list'. It does not differentiate itself from the sibling luceed_akcije, leaving the v1/v2 distinction implicit in '2.0'/'v2'.

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 luceed_akcije or the other sales-related siblings. The only usage signal is the enum value 'lista', which merely restates the single permitted action.

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, and it discloses nothing: not whether the call is read-only or mutating, not permissions, not pagination, not return behavior. For a tool with zero annotation coverage this is a severe 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?

It is short, but the brevity comes from under-specification rather than economy; the first two fragments are redundant restatements of the name and the trailing 'Actions: partneri' duplicates the schema enum. Not front-loaded with any actionable 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?

With two parameters, no annotations, and no output schema, the description should explain what is returned and how the partner code is used, but it says nothing about either. An agent cannot confidently invoke this tool from the description alone.

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 both parameters (action enum and partneri partner code) are already documented in the schema; the description adds no syntax, format, or multi-code semantics beyond it. Baseline 3 applies when 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 restates the tool name ('Sales conditions') almost verbatim and then repeats it again ('Sales conditions for partners'), offering no distinguishing verb or scope. It nominally conveys the resource but never says what the tool actually does with it (list? fetch? filter?).

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 the many siblings such as luceed_partneri or luceed_prodajne_akcije, and no prerequisites or exclusions are stated. The 'Actions: partneri' fragment only mirrors the enum in the schema rather than explaining context of 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?

No annotations and no output schema means the description carries the entire burden, yet it discloses nothing about read-only versus mutating behavior, auth/B2B key requirements, whether 'pdf' returns binary content, or failure modes. The action vocabulary alone is not behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the resource, but the bilingual restatement 'Računi predujma' adds no information and the whole definition is under-specified rather than truly concise.

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 three parameters, no annotations, and no output schema, the definition should explain what each action yields and the B2B-key requirement. It omits all of this, leaving the agent unable to predict results or prerequisites.

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 'uid' (advance invoice UID), 'b2b' (B2B key), and the action enum. The description merely repeats the three action values and adds no semantics about what each action returns or requires.

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 only restates the tool name as 'Advance payment invoices: Računi predujma' with no verb telling the agent whether it retrieves, lists, or creates anything. The 'Actions: uid, b2b, pdf' fragment hints at endpoint dispatching, but the tool is not distinguished from invoice-adjacent siblings like luceed_vpracuni or luceed_mpracuni.

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 statement of when to use this tool, when not to, or which sibling covers a related need. The agent is given only a bare enum of action names with no selection criteria.

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 and delivers almost nothing: no read-only/mutation signal, no auth or permission notes, no pagination or date-range behavior despite od_datuma/do_datuma existing, and no hint of what any of the five actions returns. For a multi-endpoint dispatcher with zero structured behavioral metadata this is a substantial 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?

It is short and front-loaded, which is good, but the second sentence enumerates the action values verbatim from the schema and therefore earns little of its space. Brevity here reflects under-specification rather than disciplined concision.

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 8 parameters, 5 dispatch actions, no annotations, and no output schema, the description should explain each action's purpose and required inputs; it does none of that. An agent cannot determine what 'stavke' versus 'webkod' returns or which parameters pair with which 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 schema already documents all eight parameters and the required action enum; the baseline of 3 applies. The description's action list duplicates the enum and adds no new meaning about how uid, webkod, partner, partner_uid, or stavke relate to each other.

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?

It identifies the resource (work / service orders, 'radni nalozi') but uses no verb and never says whether it reads, lists, or creates them beyond the generic 'Actions' list. It also fails to distinguish itself from the many similar sibling dispatchers (luceed_nalozi_prodaje, luceed_nalozi_povrata, luceed_nalozi_proizvodnje, luceed_recent_sales_orders). An agent can guess the domain but not the 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 when-to-use, when-not-to-use, or alternative-tool guidance at all. The 'Actions: uid, webkod, partner...' line merely restates the enum rather than explaining which action an agent should pick for a given intent or what each returns.

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 burden and does well: it discloses deduplication, the sort key (datum then broj, newest-first), and that output is truncated to `limit`. It does not cover auth requirements, rate limits, or what an order row contains, which is the remaining gap for a read tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the routing cue 'PREFERRED', then mechanics, then the anti-pattern. Every sentence earns its place; nothing is repeated from the schema.

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 five-parameter, no-output-schema tool with no annotations, the description covers the behavioral essentials an agent needs (dedupe, ordering, truncation, routing). It stops short of describing the returned order shape or any failure modes, which would have made it fully self-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 coverage is 100%, so all five parameters are already documented, giving a baseline of 3. The description adds only marginal semantics (status + date window drive the fetch, and statuses can miss orders), without explaining precedence between days and from_date/to_date or the accepted date formats 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?

States a specific verb and resource ('Fetches NaloziProdaje') plus the exact user phrasing it serves ('last N sales orders / nalozi prodaje'), and explicitly contrasts itself with the sibling luceed_nalozi_prodaje. An agent can pick between the two without opening either 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?

Gives an explicit positive selection rule ('PREFERRED for last N sales orders') and an explicit negative one ('Do NOT use raw luceed_nalozi_prodaje statusi'), with the reason (unsorted batches, single status missing recent orders). This is textbook when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. The parenthetical about wrapping mpobracun/artikli is a small implementation hint, but nothing states that this is a read-only aggregate, whether the date range is required, or how results are ordered or paginated.

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, front-loaded sentence with no filler, so it is not verbose. But it is under-specified rather than genuinely concise, so it earns only a middling score.

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?

A three-parameter tool with no annotations, no output schema, and no schema descriptions is left almost entirely unexplained. An agent cannot reliably determine required vs. optional semantics, output shape, or how this differs from the summary sibling.

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 0% across three parameters (pj_uid, from_date, to_date), and the description adds no meaning for any of them — not even what pj_uid identifies or whether to_date defaults to today. This is a complete gap the description should have compensated for.

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 phrase 'retail sales by product' names an aggregate resource, so the agent knows the general domain, and '(wraps mpobracun/artikli)' hints at the underlying operation. However it never distinguishes this tool from the sibling luceed_retail_sales_summary, leaving the by-product vs. summary granularity difference to inference.

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 word 'Convenience' implies this is a wrapper over a lower-level endpoint, but there is no stated when-to-use, no exclusions, and no mention of the obvious alternative luceed_retail_sales_summary. The agent gets no routing signal.

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. It usefully discloses that this is a convenience wrapper over mpobracun/placanja, signalling aggregation rather than raw records, but says nothing about permissions, rate limits, or the shape/size of the returned aggregates.

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 compact sentences, front-loaded with the purpose and followed by the selection cue. Every clause earns its place, 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?

With no output schema, the description does briefly indicate the return shape ('totals by payment type'), which is the key thing an agent needs. A wrapper tool with 100% schema coverage and no annotations is adequately described, though optional to_date behavior and aggregation granularity remain 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?

Schema coverage is 100%, so all three parameters are already documented in the schema (pj_uid example, from_date format, to_date). The description echoes 'PJ + date range' and adds the 'by payment type' grouping concept, but contributes no format or default 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?

States a specific verb+resource: 'retail sales totals by payment type for a PJ + date range', and discloses the underlying sources it wraps (mpobracun/placanja). It is clear about what it returns, though it does not explicitly differentiate itself from the sibling luceed_retail_sales_by_product.

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?

'Prefer this for "how much sales"' provides a concrete selection cue and implies alternatives exist, giving the agent a clear context for choosing this tool. It stops short of naming the alternatives or stating when NOT to use it (e.g., when per-product breakdown is needed).

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 implies a read-only list operation via 'list/lista', but says nothing about pagination, result size, authentication, or whether results are cached/filtered — all of which matter for a list endpoint with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is very short and front-loads the resource before the action, with no filler sentences. The mixed English/Croatian phrasing ('Brands: Brand / robne marke list') is slightly redundant but not wasteful.

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 trivial one-parameter, single-enum list endpoint with no output schema, the description is close to minimally viable but leaves the agent without any return-shape or usage context. It does not exploit the room available to explain what the brand list contains.

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 single 'action' parameter is fully enumerated, so the schema already documents the input. The description's 'Actions: lista' merely echoes the enum value without adding format or meaning, which matches the baseline 3 for high-coverage schemas.

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 identifies the resource (brands / robne marke) and the operation (list / lista), so an agent can infer it returns a list of brands. However, the phrasing is largely a restatement of the tool name and offers no differentiation from the many other catalog-style list siblings such as luceed_grupe_artikala or luceed_sifrarnici.

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 statement of when to use this tool, when not to, or which sibling to prefer for related lookups. The agent is left to infer usage purely from the name.

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-disclosure burden. It names actions but does not say whether the operations are read-only, what permissions are needed, how results are paged or returned, or how the actions differ behaviorally.

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 short and largely front-loaded, moving from resource to example to actions. The action list duplicates the enum but stays compact, and the Magento note is terse and potentially useful.

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 three-parameter generic retrieval tool with no annotations and no output schema, the description omits important context: return format, action semantics, and selection guidance. It gives an agent only the schema basics, not enough to call with confidence.

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 has 100% description coverage and already documents action, value, and sifrarnik. The description mostly repeats the action enum and the drzava example, adding little semantic value beyond the schema, though it does imply these are code-list lookup actions.

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 resource as generic Luceed code lists with an example (countries), and it enumerates the available actions. However, it never states the verb independently in a natural-language way and does not differentiate this generic tool from specific sibling code-list tools such as luceed_vrste_placanja or luceed_grupe_artikala.

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 generic code-list tool versus the many resource-specific sibling tools, nor when to choose one action such as list, fulllist, or list_one over another. The Magento/drzava note is a data-value hint, not usage 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the call is read-only, what the actions return, whether a UID/barcode must exist, or any permissions/rate limits. 'Actions:' hints at endpoint dispatch but discloses nothing beyond that.

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 single line is front-loaded with the resource and free of filler. It is lean rather than padded, though the extreme brevity means it is arguably under-specified rather than truly concise.

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 no output schema, no annotations, and two opaque action endpoints, the description omits what a caller needs to know: what each action retrieves, what the payload looks like, and how the action/parameter pairing works. It is far from sufficient for an action-dispatch tool.

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 (uid, barcode, action enum) is documented in the schema itself. The description only repeats the two action names already in the enum, adding no format or semantic detail, so the baseline 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?

It names the resource (warehouse documents / Skladišni dokumenti) and its two actions, so an agent can tell it deals with warehouse documents. But it supplies no verb (retrieve/list/fetch) and gives no basis for distinguishing it from the sibling luceed_skladista (warehouses) or luceed_stanje_zalihe, leaving the exact purpose vague.

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 enumerates the two actions ('uid', 'barcode') but never says when to use one versus the other, nor when this tool should be chosen over the many related warehouse/stock siblings. Usage has to be inferred entirely.

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. 'Master data' weakly implies a read operation, but the description discloses nothing about authentication, rate limits, pagination, or what happens for an unknown code. For a tool with zero annotation coverage, 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 short and front-loads the resource, which is good. But the second sentence ('Actions: lista, sifra') duplicates the schema enum verbatim and does not earn its place, while the resource statement itself is too terse to be actionable.

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?

There is no output schema and no annotations, so the description is the only place return-shape and behavioral context could live. It says nothing about what each action returns or their difference, leaving the definition under-specified for an agent to invoke confidently.

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 both parameters ('action' with its enum and 'sifra' as 'Warehouse code') are already fully documented in the schema. The description merely echoes the enum values without explaining what 'lista' or 'sifra' produce, so it adds no meaning beyond the structured data; baseline 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 names the resource ('Warehouses') and its domain ('Warehouse and business unit master data'), which tells an agent this is a master-data read tool for warehouses. However, the actions 'lista' and 'sifra' are cryptic labels with no verb gloss, so the agent does not get a clear statement of what the tool actually returns. It also does not differentiate itself from the similarly-named sibling luceed_skladisni_dokumenti (warehouse documents).

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 like luceed_skladisni_dokumenti, luceed_mjesta, or the general luceed_get. It also does not say when to pick action 'lista' versus 'sifra', leaving selection 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?

No annotations are provided, so the description carries the full disclosure burden. 'Stock status' implies a read-only query, but the description says nothing about permissions, rate limits, pagination, or the shape of the response. For a 9-parameter query tool with zero annotation coverage this is a meaningful 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?

Two sentences, front-loaded with the resource, followed by the modus list. It is efficient overall, though the action enumeration duplicates the schema enum and consumes space without adding 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?

There is no output schema and no annotations, and the description does not explain the semantics of the eight actions or the return structure. It covers the tool's purpose adequately for a query endpoint but leaves real gaps for a nine-parameter tool.

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 nine parameters and the action enum. The description merely restates the action values rather than explaining what each action actually does (e.g. skladiste_artikl vs artikl), adding little beyond structured data. 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 resource (stock status / availability) and its query dimensions (warehouse, article, barcode, attribute), so the agent knows what it returns. It stops short of differentiating itself from the very similar siblings luceed_stanje_zalihe_dobavljaci and luceed_stanje_zalihe_serijski, leaving that distinction to inference.

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 when-to-use guidance and no mention of alternatives. The action list names modes but never says which situation selects which action, nor when to prefer this tool over the serial-number or supplier stock variants. Usage is left 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, the description carries the full disclosure burden, yet it says nothing about read-only nature, permissions, pagination, or result shape. It is essentially a restatement of the tool name plus an action list, so the agent gets no behavioral context beyond the bare minimum.

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?

Very short and front-loaded, with the resource stated first and the actions second. It is efficient, though the leading 'Supplier stock:' fragment duplicates the resource clause that follows it.

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?

A four-parameter query tool with no output schema and no annotations needs the description to explain what each action returns and how the optional code parameters interact. None of that is present, leaving the agent unable to invoke the actions 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?

Schema description coverage is 100%, so the schema already documents sifra, sifra_artikla, sifra_dobavljaca and the action enum. The description merely repeats the enum values without clarifying the semantics of the Croatian action names or which parameters pair with which action, so it adds no value over the schema. Baseline 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?

It names the resource (supplier stock levels) and echoes the internal endpoint name StanjeZaliheDobavljaci, which does distinguish it from the sibling luceed_stanje_zalihe. However, the four action values (lista, artikl, dobavljac, artikl_dobavljac) are listed without any explanation of what each one actually retrieves, so the agent cannot tell what the tool does in each mode.

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 when-to-use guidance is given. There are closely related siblings (luceed_stanje_zalihe, luceed_stanje_zalihe_serijski) that an agent must disambiguate against, and the description offers no criteria for choosing this tool over them.

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, yet it says nothing about what the two actions return, whether data is live or cached, pagination, or authentication needs. The bare 'Actions: artikl, serijski' listing does not disclose behavior of either mode.

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 two short fragments are front-loaded and contain no filler. It is efficient, though the second fragment ('Actions: artikl, serijski') is low-value repetition of structured data rather than earning its space.

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 no annotations, no output schema, and a dispatch-style action enum whose two values are never explained, the description is not complete enough for an agent to call this correctly. It neither clarifies how 'artikl' differs from 'serijski' nor what result either returns.

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 parameter documentation is already complete in the schema (sifra = article code, serijski = serial number, action = endpoint selector). The description adds no semantics beyond repeating the enum values, which is the baseline-3 case where 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 conveys the general resource (stock status by serial number), but 'Serial-number stock: Stock status by serial number' is largely a restatement of the tool name, and 'Actions: artikl, serijski' only echoes the enum without explaining what each action does. It does not differentiate from siblings such as luceed_stanje_zalihe or luceed_stanje_zalihe_dobavljaci.

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 explicit when-to-use guidance, no mention of prerequisites, and no routing to alternatives. The agent must infer usage from the terse purpose statement alone, which is especially risky given the many sibling stock/inventory 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 behavioral burden, and it discloses essentially nothing: no read-only assurance, no auth/permission requirements, no pagination or volume expectations. It does not contradict anything, but it also adds no behavioral context beyond the bare resource name.

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?

It is short and front-loads the resource, but it reads as a fragment list rather than a sentence, and the action enumeration duplicates the schema instead of earning its place with new information. Not wasteful in length, but poorly structured.

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 2-parameter tool with no annotations and no output schema, the description should explain what the call returns and how the actions differ. It does neither, leaving the agent unable to predict the response shape or the distinction between 'lista', 'domena', and 'nalozi_prodaje'.

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 both parameters, giving a baseline of 3. The description repeats the action enum verbatim and only vaguely gestures at the 'domena' parameter via 'by domain', adding no format or value guidance 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?

It names the resource (status definitions) and scopes it to a domain, but gives no verb (list/get/describe) and the phrase 'Status definitions by domain' is ambiguous about whether it returns the definition catalogue or a status value. The sibling set is large and nothing here distinguishes this tool from e.g. luceed_sifrarnici or luceed_nalozi_prodaje.

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 statement of when to use this tool versus alternatives, and no prerequisites. Notably, one of the enum actions ('nalozi_prodaje') overlaps a sibling tool name, luceed_nalozi_prodaje, and the description does not clarify the relationship, leaving the agent to guess.

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 disclosure burden, yet it says nothing about authentication, rate limits, pagination, or response shape. 'List' weakly implies a read-only operation, but nothing is confirmed.

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 resource and then the action. Efficient, though the second sentence is largely redundant with the enum already in the schema.

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 single-parameter tool with no output schema and no annotations, the description does not compensate by describing what a 'lista' call returns or when it is appropriate. An agent has essentially only the name and enum to work with.

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 single enum parameter is fully documented there, so baseline 3 applies. The description adds no meaning beyond the schema, merely repeating 'lista' as the action.

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 concrete resource ('Currency exchange rate list'), which separates it from siblings like luceed_cijene or luceed_cjenik. However, it largely restates the tool name (tecajna_lista = exchange rate list) and adds no verb beyond the implied 'list', so it is clear but thin.

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 indication of when to use this tool versus alternatives such as luceed_cijene or luceed_cjenik, nor any prerequisites or exclusions. 'Actions: lista' simply echoes the only enum value in the schema.

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, and it only discloses '(read)' — useful but minimal. It says nothing about pagination, result volume, required permissions, or what each action returns, which is a large gap for a six-parameter 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 single line is compact and front-loads the resource and read nature, but the trailing action list duplicates the schema enum and earns little space. Efficient yet under-specified rather than genuinely concise.

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 tool with no annotations, no output schema, and cryptic action names, the description should explain what each action returns and how the partial-name parameters (dio_imena, dio_prezimena) relate to the search actions. That essential context 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 all six parameters, and the description adds no syntax or meaning beyond echoing the action enum. Baseline 3 applies when 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 identifies the resource (loyalty/web users) and marks it as a read operation, which distinguishes it from write-oriented siblings. However, the action names (listatip, listaprezime, listaime) are opaque Croatian terms that are merely restated rather than explained, so an agent cannot tell what each action actually returns.

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 siblings like luceed_partneri or luceed_bodovi, nor any indication of which action to pick for a given intent. The action list is a menu without conditions.

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, yet it only says the tool lists variants. It does not disclose whether the call is read-only, what the response contains, pagination behavior, or authentication requirements. For a tool with zero annotation coverage 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 definition is very short and front-loads the resource, but it is fragmented and somewhat redundant ("Variants: Product variants"). It is concise without being well-structured 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?

For a one-parameter, no-output-schema list tool, the description gives enough to invoke it correctly, but it omits behavioral context such as return shape and read-only semantics. Given the absence of annotations, it is minimally adequate rather than 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 sole parameter and its enum are fully documented in structured form. The description merely repeats the "lista" action and adds no syntax or meaning beyond the schema, which is the expected baseline when 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 resource ("Product variants") and a specific action ("lista", i.e., list), so an agent can tell it retrieves a list of product variants. It does not, however, distinguish this tool from the many sibling luceed_* tools, and the fragmentary format blurs the verb-resource pairing.

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, nor any prerequisites or exclusions. The only usage signal is the single allowed action "lista", which is already enforced by the schema enum.

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 states nothing about read-only versus mutating actions, authentication needs, side effects, rate limits, or what each action returns or changes. The action names are opaque and the description offers no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the resource name, but it contains redundancy ('Wholesale invoices' repeated, plus translation of the tool name) and duplicates the action enum from the schema. It is not overly long, but every sentence does not fully earn 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 nine parameters, seven actions, no output schema, and no annotations, the description is far from complete. It does not explain what each action does, which parameters are relevant to which action, or what an agent can expect as a result. For a multi-action tool of this complexity, much more context is needed.

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 every parameter is already documented in the schema. The description repeats the action enum values but adds no new semantic meaning (e.g., which parameters apply to which action, date format, or UID relationships). Baseline 3 is appropriate when 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 identifies the resource as wholesale invoices and translates the tool name ('VP računi — wholesale invoices'). However, it provides no overarching verb or statement of what the tool actually does with those invoices, and the action list ('uid, broj, nalogprodaje, ...') is a bare enumeration rather than an explanation of capabilities. It is adequate for domain identification but not a clear statement of purpose.

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 luceed_mpracuni (retail invoices) or luceed_nalozi_prodaje. The action list hints at operations but does not indicate selection context, prerequisites, or exclusions.

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. "list" implies a read-only operation, but the description says nothing about pagination, result size, ordering, or whether the catalog is static — all of which matter for a master-data endpoint.

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 fragments, front-loaded with the resource and then the action, with no filler. It is efficient, though the colon-separated fragment style is slightly clipped rather than fully formed prose.

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 low-complexity, single-parameter tool with no output schema, so not much is required. Still, the description does not hint at what a payment type record contains or how results are returned, leaving a modest gap for an agent that must decide whether the output 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?

There is a single parameter (action) with 100% schema description coverage and a one-value enum, so the schema already fully specifies the input. The description's "Actions: list" merely echoes the enum, adding no syntax or format meaning beyond it; baseline 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 names the resource (payment types / payment type master data) and the available action (list), so an agent can infer it enumerates payment type records. However, "Payment types: Payment type master data" largely restates the tool name, and it offers no differentiation from adjacent master-data siblings such as luceed_sifrarnici or luceed_statusi.

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 statement of when to use this tool versus alternatives, nor any prerequisite or context. With many master-data siblings in the namespace, the agent receives no routing signal at all beyond the resource name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.