einvoicewiz

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only query by listing credits remaining and calls used, which suggests no destructive effects. It does not mention authentication, rate limits, or what happens when the API key is missing or invalid, but the operation is simple and fairly transparent.

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

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

The description is brief and direct, with only one short sentence that is easy to parse. It front-loads the query concept and avoids irrelevant detail. It could be slightly stronger with a verb, but it contains 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?

For a one-parameter tool with no output schema and no annotations, the description names both the input scope and the expected return values, which covers much of what an agent needs. It leaves gaps around whether the api_key is required, how to obtain or pass the key, and what response format to expect. The tool is simple enough that these are notable but not fatal omissions.

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%, so the description must compensate for the undocumented api_key parameter. The phrase 'for an API key' loosely ties the parameter to the tool's purpose, but it adds no format, source, requiredness, or special behavior beyond what the parameter name and title already imply. The default empty string and zero required parameters also remain unexplained.

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

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

The description clearly identifies the resource (an API key) and the two outputs of interest: credits remaining and calls used. It is distinct from the sibling tools, which focus on PDF creation, XML generation, certificate lookup, signup, validation, and format selection, so an agent can tell it apart without much effort. However, it is phrased as a noun fragment rather than a stated action, which keeps it just shy 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 description gives no guidance on when to call this tool instead of a sibling, no preconditions, and no exclusions. It only states what the check returns. An agent can infer that it is used for quota/usage checks, but there is no explicit direction about context 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?

With no annotations, the description carries the full disclosure burden and does it well: it mentions the 1-credit cost, the 15 MB input limit, validation against EN 16931 and PDF/A-3, and that failures are not charged. It does not discuss auth or side effects beyond creation, but this is acceptable for a creation 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 compact, front-loaded with the core transformation, and efficiently covers cost, size limits, output fields, validation, and failure policy. Every sentence adds useful 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?

It names output fields and critical constraints, which is helpful given the lack of an output schema. However, the invoice JSON structure is not explained, and without it an agent may not be able to construct valid input reliably.

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 0%, so the description must compensate. It explains pdf_base64 (base64-encoded, max 15 MB) but leaves the invoice object's required structure and fields undocumented. The api_key parameter is also not described, leaving significant gaps for the required parameters.

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

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

The description names a specific operation and resource: converting an existing PDF invoice plus invoice JSON into a Factur-X/ZUGFeRD PDF/A-3 with embedded XML. This clearly differentiates it from siblings like generate_einvoice_xml and validate_einvoice.

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 states clear input prerequisites: an existing PDF invoice and invoice JSON. It also implies the intended use case by describing the output format, though it does not explicitly mention when to prefer an alternative such as generate_einvoice_xml.

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

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

With no annotations provided, the description carries the full burden and does so impressively: it discloses the credit cost, failure behavior ('failures free'), return shape ({xml, validation, verify:{id,url}, credits_left}), and HTTP 422 error body content. It also explains validation behavior and profile-specific prerequisites, leaving little hidden about the tool's 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?

The description is dense but every clause earns its place: transformation, cost, profile selection, required fields, return value, and error behavior are all present with no filler. The use of compact schema notation and a link to the full OpenAPI spec keeps it as tight as possible for the complexity involved.

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

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

Despite having no output schema and no annotations, the description provides enough operational context for an agent to call the tool correctly: required invoice fields, profile-specific requirements, return structure, cost, and failure semantics. The link to the full invoice schema further closes any remaining gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly documents the invoice object's required fields and the profile values with their meanings. The only gap is api_key, which is not explained, but it is optional with a default and the schema title provides some minimal signal.

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

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

The description opens with a precise transformation statement: 'Invoice JSON → validated EN 16931 CII XML', specifying verb, resource, and validation constraint. It also differentiates itself from siblings like validate_einvoice and create_facturx_pdf by naming the exact output format and the two profile modes.

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

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

The description provides clear context for when to choose each profile: en16931 for Factur-X/ZUGFeRD B2B data and xrechnung for German public sector, including required fields for xrechnung. It does not explicitly name alternatives like validate_einvoice or create_facturx_pdf for different workflows, so the when-not-to-use guidance is only implicit.

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

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

With no annotations provided, the description carries the transparency burden. It discloses access requirements ('free, no key'), implies a read-only lookup operation, and describes the output in terms of confirming hash validation and timestamps. This is strong behavioral context for a simple retrieval 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, tight sentence followed by a short clarifying clause. Every element adds value—what it does, the identifier format, access requirements, and expected output. There is no redundancy or 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 tool with one simple parameter and no output schema, the description covers the essential behaviors: what to look up, that no authentication is needed, and what the result conveys. It does not explain edge cases like expired or missing certificates, but the low complexity makes the current description reasonably complete.

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

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

The schema only provides the parameter name 'cert_id', so the description must compensate. It adds the EIW-… format hint, which helps the agent understand the expected value, but it does not explicitly explain where the cert_id comes from or how to format it. This is partial compensation rather than full parameter documentation.

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

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

The description states a specific action ('Look up a verification certificate'), identifies the resource type by its EIW-… prefix, and explains the value ('Confirms which file hashes passed validation and when'). This clearly distinguishes it from validation and creation tools like validate_einvoice and create_facturx_pdf.

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

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

The description gives clear context: this is a lookup, not a validation or creation operation, and it explicitly notes that no key is required. It does not name sibling alternatives or state when not to use it, but the intended use case is clear enough for an agent to select it appropriately.

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 adds a genuinely useful behavioral detail: 'The key is shown once — store it.' But it doesn't disclose response format, whether the email must be vverified, or what happens on duplicate signup.

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 with no filler. The core action is front-loaded and the critical warning follows immediately.

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

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

For a one-parameter tool with no output schema, the description should explain both the required input and what is returned. It neither mentions email nor explicitly states the response contains the new API key, though 'key is shown once' partially implies it. Important gaps remain.

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 only parameter, email, is not mentioned in the description at all. Schema description coverage is 0%, and the tool description does not compensate by explaining what email is used for or how to provide it.

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: 'Create an einvoicewiz API key'. cleary distinguishes from siblings like check_credits, create_facturx_pdf, and validate_einvoice — no other tool creates a key.

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?

Cleary implies when to use it: when a new API key with free credits is needed. No explicit exclusions or alternative mentions, but no sibling performs signup, so context is sufficient.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the credit cost (1 credit), the response shape, and the conditional behavior that verify is only set when validation passes. It could additionally mention failure modes or encoding details, but the key side effects and conditional outputs are covered.

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 dense sentences, front-loaded with purpose, followed by a concise return value description. Every sentence earns its place and no filler exists.

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

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

The tool has only two simple parameters and no output schema, so the description appropriately explains the return structure and conditional verify field. It lacks explicit mention of expected base64 formatting or error behavior, but is otherwise sufficient for an agent to invoke the tool 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 coverage is 0%, so the description must compensate. It clarifies that file_base64 is a PDF or XML base64 payload, which adds real meaning. However, it does not explain the api_key parameter at all, though the name and common SDK conventions make it somewhat inferable.

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

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

The description clearly states a specific action ('Validate'), the exact resource types (Factur-X / ZUGFeRD / XRechnung files in PDF or XML base64), and the standards applied (EN 16931 + KOSIT + PDF/A). This distinguishes it from sibling tools like create_facturx_pdf, generate_einvoice_xml, and check_credits.

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

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

The description implies when to use the tool: when an existing e-invoice file needs validation. However, it does not explicitly state when not to use it, nor does it reference alternatives like which_format_do_i_need or lookup_certificate for related but different tasks.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It states that the tool is free and keyless and that it tells the user which format is needed and whether plain PDF is acceptable, but it does not explain how the decision is made, what the output looks like, or any limitations.

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

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

The description is a single front-loaded sentence with no filler. It states the tool's role and key gating facts immediately and 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?

With two parameters, no output schema, and no annotations, the agent needs more practical guidance than this description provides. It cannot determine what result to expect or how the input parameters influence the tool's behavior, leaving room for incorrect 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 0%, and the description does not compensate by explaining recipient_country or recipient_is_public_authority. The only connection is the vague word 'recipient,' which does not convey how the parameters affect the decision.

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

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

The description clearly identifies a decision helper for selecting the correct e-invoice format and judging whether plain PDF is acceptable. This is a distinct purpose from the sibling generation/validation tools, though it does not explicitly name 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 gives clear context for when to use the tool: when unsure which e-invoice format a recipient requires or whether plain PDF suffices. It does not spell out exclusions or directly compare to alternatives, but the use case is unambiguous.

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