EAN Check barcode tools

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

Annotations already establish that this is a read-only, idempotent, closed-world calculation, so the safety profile is covered. The description adds useful behavioral context by saying the result includes the GS1 allowed range, giving agents a sense of the return content even without an 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?

The description is a single, front-loaded sentence with no unnecessary wording. It communicates the operation, the conditional inputs, and the returned range efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter calculation tool with no output schema, the description provides enough context to call it correctly. It could be slightly more explicit about supplying either magnification or X-dimension depending on type, but the essential behavior is clear.

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 is 3, but the description adds meaningful mapping beyond the schema: GS1 magnification applies to retail and carton types, while X-dimension applies to other types. This helps an agent choose between the optional numeric parameters based on the barcode type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns the printed size of a barcode type under either GS1 magnification or X-dimension. It is clearly a sizing/calculation tool rather than a creation or validation tool, though it does not explicitly name sibling alternatives for contrast.

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

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

The description implies when to use magnification versus X-dimension by noting retail and carton GS1 types versus other types, but it does not explicitly state when to use this tool over siblings or exclude any cases. Usage is inferable from the parameter guidance rather than directly specified.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and repeatability are covered by structured data. The description adds nothing behavioral beyond that: no statement about what happens to malformed lengths, non-numeric characters, or already-complete 8/12/13/14-digit inputs.

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 operation and its input-length mapping, followed by the input-format note. Every clause carries information; nothing is padding.

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, read-only, idempotent utility with full schema coverage, the description covers the core contract well. Gaps are minor: behavior on invalid or already-valid inputs and whether output aligns one-to-one with the input list are unstated, and there is no output schema to compensate.

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% and the schema says 'one per line', but the description adds a genuine alternative the schema omits: comma-separated input is also accepted. That is real meaning beyond the input schema, though it does not explain the output shape (order, error handling per line).

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: adds the GS1 check digit to GTIN numbers lacking one, and enumerates the accepted input lengths (7, 11, 12, 13) with their resulting formats (GTIN-8, UPC-A, EAN-13, GTIN-14). This implicitly separates it from validate_gtins and repair_gtin, but never names those siblings, so the distinction is inferential rather than explicit.

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?

Use when a number is 'missing' a check digit is implied clearly enough, but there is no instruction on what to do with numbers that already have one, nor any routing to validate_gtins or repair_gtin for related but different tasks. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it states that each part of the code is explained and, importantly, discloses a capability boundary (no product lookup), which prevents an agent from misusing the result as a product resolver.

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 with no filler: the capability and its scope come first, and the limitation follows. Every clause earns its place and nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only inspection tool with full schema coverage and clear annotations, the description covers what it does, what it accepts, and what it cannot do. The only mild gap is that there is no output schema, and "explains each part" only loosely sketches the return 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?

There is a single parameter and schema description coverage is 100%, with the schema already supplying a concrete example ("LPN RR AB1234567"). The description reinforces that the input is the code exactly as printed on the sticker, which is mildly useful, but it adds no format, normalization, or whitespace-handling details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ("Read the code from an Amazon sticker") and enumerates exactly which sticker code types it resolves (LPN, FNSKU, ASIN, FBA box label, Amazon Logistics tracking number, UPC/EAN). However, it never distinguishes itself from the sibling tool identify_code, whose name suggests a very similar role, so an agent cannot pick between them from the description alone.

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?

Usage context is implied by "from an Amazon sticker" and one explicit exclusion is given: it cannot look up which product a code belongs to. What is missing is routing guidance — if a code is a generic retail barcode rather than an Amazon sticker, the description does not point the agent to identify_code, parse_gs1, or convert_upc_e.

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 readOnlyHint and idempotentHint already covering the safety profile, the description adds real value by stating that the check digit is recalculated, that output is hyphenated, and that 979-prefixed ISBN-13s have no ISBN-10 (a failure mode to expect).

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 with the core action front-loaded and the edge case appended; nothing is redundant or 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?

The tool is a simple one-param transform with no output schema, and the description adequately conveys the result (hyphenated form with recalculated check digit) plus the main edge case, though it could mention error behavior for invalid input.

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% and the single 'isbn' parameter already documents that hyphens are accepted, so the description adds little parameter meaning beyond what the schema provides; 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?

States a specific verb (convert) and resource (ISBN-10/ISBN-13) with bidirectional scope, which is enough to distinguish it from siblings like calculate_check_digits and validate_gtins 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?

The description implies usage for converting between ISBN formats and notes the 979 edge case that makes conversion impossible, but it never explicitly routes the agent against alternatives such as calculate_check_digits or convert_upc_e, leaving selection 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?

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds genuinely new behavior beyond them: check-digit validation and the rule-bound limit on reverse conversion. It does not say whether a bad check digit raises an error, is repaired, or is returned as a flag — a notable remaining ambiguity.

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, zero filler, and the primary forward conversion is front-loaded ahead of the conditional reverse path. Length is well matched to a one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should imply what comes back; the '12-digit UPC-A' phrasing does that for the forward direction, and it explains the failure condition for the reverse. Missing is any statement of what a failed check-digit check yields, which is the one thing an agent cannot infer.

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% and there is a single parameter, so baseline is 3. The description earns an extra point by constraining accepted UPC-E lengths to 6, 7 or 8 digits, which the schema only calls 'digits only'.

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?

Names a specific verb (convert) plus the exact resource pair (UPC-E 6/7/8 digits <-> UPC-A 12 digits) and states it checks the check digit. The format naming alone separates it from siblings like convert_isbn and repair_gtin.

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 a real conditional for the reverse direction: UPC-A to UPC-E only applies when one of the four GS1 zero-suppression rules fits, so an agent knows the reverse call can legitimately fail. It does not route to siblings such as calculate_check_digits or validate_gtins for check-digit problems.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that the result includes check digit status, which is real behavioral value, but with no output schema it says nothing about the returned shape (e.g., type plus validity fields) or what happens for an unrecognized string.

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 front-loaded sentence that states the action first and then the accepted formats, with no filler. The long format enumeration is functional scope-setting rather than padding, though it is dense enough to read as a list dump.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only, idempotent, single-parameter tool this covers the essentials, and check digit status is disclosed. It is still thin on outcome behavior — no statement of what is returned for unknown codes or the response structure — which matters because there is no output schema.

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 with full schema description coverage, so the baseline is 3. The schema already says the code is taken exactly as printed or scanned, and the description's format list mildly reinforces what inputs are accepted without adding parsing or format details beyond that.

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?

Names a specific verb ("find out what kind of code") and an enumerated set of supported formats (GTIN, ISBN, ISSN, SSCC, GLN, GS1-128, Digital Link, VIN, IMEI, ASIN, LPN, FNSKU), which makes the scope unmistakable. It doesn't contrast itself against siblings like validate_gtins or parse_gs1, so the boundary is inferred from the enumeration rather than stated.

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

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

Usage is only implied: an agent can infer this is the tool for an unknown code, but the description never says when to pick it over validate_gtins, parse_gs1, or check_amazon_code, nor does it state any preconditions. No exclusions or sequencing guidance is given despite a crowded sibling set.

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?

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral detail beyond them: output is a scalable vector file measured in millimetres and includes a link back to the generator. It stops short of covering failure modes (e.g., invalid value for a type) or whether the link expires.

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 dense sentences with the deliverable front-loaded and no filler. The main inefficiency is repeating the full 14-value type enum already present in the schema, which consumes space without adding 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?

For a generation tool with no output schema, the description adequately covers what comes back (SVG/EPS in mm plus a link) and the GS1 sizing constraint. Minor gaps remain around error behavior for mismatched value/type combinations and how the returned link should be used.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents type, value, x_mm, format, gs1, and magnification. The description adds one useful fact not in the schema, the 80–200 magnification range for GS1 retail types, but otherwise restates the type enum that the schema already carries.

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 concrete verb and resource ('Draw a print-ready barcode') plus the return artifact ('SVG (or EPS) in millimetres, plus a link'). The enumerated type list makes clear this is a generator, cleanly separating it from sibling validators such as validate_gtins and calculate_check_digits.

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?

Usage is only implied: the description says what the tool produces but never states when to choose it over barcode_size, check_amazon_code, or identify_code. The one constraint given ('GS1 retail types use magnification 80 to 200') is a parameter rule rather than routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), but the description adds behavior the annotations do not: it returns one entry per AI with the AI's human name and surfaces format errors instead of silently failing, which matters because there is no output schema. It stops short of saying what a malformed string yields (empty list vs. error field), so it is not a full 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?

A single sentence, front-loaded with the action and resource, with the output shape stated last. No filler and nothing to trim.

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, non-destructive parsing tool with no output schema, the description conveys enough: accepted formats, the unit of output, and that errors are reported as data. Only the precise return shape for invalid input is left ambiguous.

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% and the single parameter's description already gives example forms including FNC1 and Digital Link URLs, so the schema carries most of the burden. The description's format list reinforces accepted input types but adds no syntax or encoding detail beyond the schema, matching the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (split) and resource (GS1 data), enumerates the accepted formats (GS1-128, GS1 DataMatrix, Digital Link), and says what the output contains (Application Identifiers, AI names, format errors). This is clearly distinct from validate_gtins or identify_code, which check or classify rather than decompose a GS1 string.

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?

Usage is only implied: an agent can infer the tool applies to raw GS1 strings needing decomposition, but the description gives no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling such as validate_gtins for validation-only needs.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's job is to add semantics — and it does: results are filtered by the GS1 check digit, and the return is a set of candidates rather than a single value, which tells the agent to expect multiple matches. It stops short of saying what happens when no candidate passes.

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

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

A single sentence that front-loads the use case and then the output contract. No filler, nothing repeated for its own sake.

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 tool this covers the essentials: input convention, validation criterion, and that multiple values can come back. Minor gaps remain around empty results and ordering of candidates.

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%, and the parameter description already carries the wildcard convention and an example. The description restates the same '? or *' convention without adding format constraints such as length rules or mixed-wildcard limits, so 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?

States a specific verb (recover) and resource (GTIN) plus the exact operating mode: wildcard digits with ? or *. That mechanism is unique among the siblings (validate_gtins, calculate_check_digits, parse_gs1), so an agent can route here without opening another schema.

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

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

The trigger condition is explicit: use this when a GTIN has unreadable digits. It does not name alternatives (e.g. validate_gtins for a fully known code) or state exclusions, so usage is clear but not fully disambiguated.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that results are reported per code along with detected length, but it does not say what happens with malformed or partially invalid input lines, or whether one bad line fails the whole batch.

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

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

One sentence, front-loaded with the action and the accepted code families, followed immediately by what is returned. No filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only validator with no output schema, the description covers both the input constraint and the shape of the answer (check-digit verdict plus GTIN length). The remaining gap is error/batch behavior for invalid inputs, which matters given the tool accepts multiple codes at once.

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% and the single parameter already documents both the 'complete numbers' constraint and the one-per-line/comma-separated formats. The description reinforces the 'complete' requirement but adds no new syntax or formatting 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?

Names a concrete verb (check/validate) and the resource types (GTIN, EAN, UPC, ITF-14), and it also hints at the response shape (check-digit validity plus GTIN length). The word 'complete' scopes it away from compute-oriented siblings like calculate_check_digits and repair_gtin, but no sibling is named explicitly.

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?

Usage is only implied: 'complete' numbers signals this is for validation rather than check-digit calculation or repair, which is useful routing information. There is no explicit when-to-use, when-not, or named alternative among the many siblings such as identify_code or repair_gtin.

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