Skip to main content
Glama

Labelixa

by com.labelixa
OverviewDiscussionsAdmin

Validate TSPL

tspl_validate
Read-onlyIdempotent

Lint TSPL/TSPL2 label code and return positioned findings with severity as JSON. Checks the command set Labelixa implements from the TSPL2 manual — a clean result is not a guarantee that a specific printer accepts the job. Run this before tspl_preview; if you are not sure which language the code is, call language_detect first.

Input Schema

NameRequiredDescriptionDefault
tsplYesRaw TSPL/TSPL2 code

Output Schema

NameRequiredDescriptionDefault
summaryYes
diagnosticsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedOutput schema / properties / diagnostics / items / properties / mesaj
      Removed value: -{
-  "description": "Human-readable message in the requested language",
-  "type": "string"
-}
    • addedOutput schema / properties / diagnostics / items / properties / message
      Added value: +{
+  "description": "Human-readable message in the requested language",
+  "type": "string"
+}
    • removedOutput schema / properties / ozet
      Removed value: -{
-  "properties": {
-    "error": {
-      "type": "integer"
-    },
-    "info": {
-      "type": "integer"
-    },
-    "toplam": {
-      "type": "integer"
-    },
-    "warning": {
-      "type": "integer"
-    }
-  },
-  "required": [
-    "toplam",
-    "error",
-    "warning",
-    "info"
-  ],
-  "type": "object"
-}
    • addedOutput schema / properties / summary
      Added value: +{
+  "properties": {
+    "error": {
+      "type": "integer"
+    },
+    "info": {
+      "type": "integer"
+    },
+    "total": {
+      "type": "integer"
+    },
+    "warning": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total",
+    "error",
+    "warning",
+    "info"
+  ],
+  "type": "object"
+}
    • changedOutput schema / required
      Previous value: -[
-  "diagnostics",
-  "ozet"
-]New value: +[
+  "diagnostics",
+  "summary"
+]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "diagnostics": {
+      "items": {
+        "properties": {
+          "code": {
+            "description": "Stable diagnostic code, e.g. ZPL0002",
+            "type": "string"
+          },
+          "col": {
+            "type": "integer"
+          },
+          "end_col": {
+            "type": "integer"
+          },
+          "end_line": {
+            "type": "integer"
+          },
+          "line": {
+            "type": "integer"
+          },
+          "mesaj": {
+            "description": "Human-readable message in the requested language",
+            "type": "string"
+          },
+          "message_key": {
+            "description": "i18n key for the message",
+            "type": "string"
+          },
+          "severity": {
+            "enum": [
+              "error",
+              "warning",
+              "info"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "code",
+          "severity",
+          "line",
+          "col"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "ozet": {
+      "properties": {
+        "error": {
+          "type": "integer"
+        },
+        "info": {
+          "type": "integer"
+        },
+        "toplam": {
+          "type": "integer"
+        },
+        "warning": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "toplam",
+        "error",
+        "warning",
+        "info"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "diagnostics",
+    "ozet"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: validation is limited to Labelixa's implemented command subset, and 'a clean result is not a guarantee that a specific printer accepts the job' — an important scope caveat. It stops short of elaborating finding severity levels or any limits, so 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.

Conciseness5/5

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

Three tight sentences, no filler. Front-loads what the tool does, then the scope caveat, then the workflow ordering — a sensible information hierarchy.

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

Completeness5/5

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

Output schema exists so return values need not be re-explained, and annotations cover the safety profile. The description still supplies the non-obvious bits an agent needs — validation scope limits and the tspl_preview/language_detect workflow — making it complete for this tool's complexity.

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

Parameters3/5

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

Single parameter with 100% schema description coverage ('Raw TSPL/TSPL2 code'), so the schema already carries the semantics. The description mentions 'TSPL/TSPL2 code' but adds no format, encoding, or size guidance beyond the schema. Baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource — 'Lint TSPL/TSPL2 label code' — plus the output shape ('positioned findings with severity as JSON'). The scoping phrase 'Checks the command set Labelixa implements from the TSPL2 manual' cleanly separates it from zpl_validate/cpcl_validate/epl_validate siblings.

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

Usage Guidelines5/5

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

Gives explicit ordering ('Run this before tspl_preview') and a conditional routing rule ('if you are not sure which language the code is, call language_detect first'), naming the exact sibling by name. No inference required.

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

All Labelixa toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources