KRA eTIMS MCP Server

generate_qr_code_string

Formats invoice confirmation data into the official KRA eTIMS QR code string so receipt details can be encoded and scanned correctly.

Instructions

Formats invoice confirmation data into the official KRA eTIMS QR code string: 'invoice_date(ddmmyyyy)#time(hhmmss)#cu_number#cu_receipt_number#internal_data#receipt_signature'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "invoice_date": "<invoice_date>",
      "time": "<time>",
      "cu_number": "<cu_number>",
      "cu_receipt_number": "<cu_receipt_number>",
      "internal_data": "<internal_data>",
      "receipt_signature": "<receipt_signature>"
    },
    "name": "generate_qr_code_string"
  }
}

Input Schema

Name	Required	Description
`time`	Yes	Time formatted as HHMMSS (e.g. '123005')
`cu_number`	Yes	Control Unit ID (sdcId from response, e.g. 'KRAMW010000001')
`invoice_date`	Yes	Invoice date formatted as DDMMYYYY (e.g. '22102026') or YYYYMMDD
`internal_data`	Yes	Internal fiscal data returned in intrlData
`cu_receipt_number`	Yes	Receipt counter number (rcptNo, e.g. 4521)
`receipt_signature`	Yes	Cryptographic receipt signature returned in rcptSign

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 23, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the output structure precisely (field order and '#' separator), which is genuinely useful. But it never states whether this is a pure local formatting operation or a network call to KRA, nor whether signing/credentials are needed – ambiguous given the sibling set mixes API-spec and validation tools.

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

Conciseness5/5

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

A single front-loaded sentence with the exact format template appended; nothing redundant, and the essential output contract is stated first.

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

Completeness4/5

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

With no output schema and no annotations, the description does the heavy lifting by fully specifying the returned string layout and all six required inputs are documented in the schema. It falls short only on execution semantics (local formatting vs. remote call) and on how date-format ambiguity is handled.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema by specifying the concatenation order and the '#' delimiter for all six values, which the property descriptions do not convey. It doesn't address the alternate accepted date format (DDMMYYYY vs YYYYMMDD) noted in the schema.

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

Purpose4/5

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

The description gives a specific verb ('formats') and resource ('invoice confirmation data into the official KRA eTIMS QR code string'), and spells out the exact output template. The operation is distinct from siblings like validate_etims_payload and generate_sample_payload, though the description never explicitly contrasts with them.

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

Usage Guidelines3/5

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

Usage is only implied by 'invoice confirmation data' – an agent can infer this runs after a successful invoice submission, but there is no explicit when-to-use statement, no prerequisite ordering versus validate_etims_payload, and no exclusions.

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

Deploy Server