HACCP Bulgaria

Prepare a HACCP order for the person

haccp_prepare_order

Saves the answers as a draft for 7 days and returns a link. Give the link to the person: it opens the questionnaire already filled in, where they check every answer, add what is missing, see a free preview and pay themselves. You cannot order or pay; the payment and the legal consents are the person's. Never send the manager's personal number (ЕГН). Show the person the "message" field of the result.

Input Schema

Name	Required	Description	Default
`company`	No
`facility`	Yes
`location`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / facility / properties / coolingUnits

Added value: +{
+  "description": "Every fridge, display fridge and freezer with the room it stands in. They fill the cooling equipment table; the person can add them in the draft if you leave this out.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "location": {
+        "enum": [
+          "Търговска зала",
+          "Кухненско помещение",
+          "Складово помещение"
+        ],
+        "type": "string"
+      },
+      "type": {
+        "enum": [
+          "Хладилник",
+          "Хладилна витрина",
+          "Фризер"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "location"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 25, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-destructive, non-idempotent, closed-world), the description discloses the 7-day draft lifetime, that a link is returned, that the agent cannot complete payment or legal consent, and a personal-data prohibition on ЕГН. That is substantive behavioral context the structured fields do not carry.

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

Conciseness4/5

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

Five short sentences, front-loaded with the action and result before the handling instructions. Each sentence carries an operational rule, though the phrasing is conversational and slightly redundant ('pay themselves' / 'the payment ... are the person's').

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?

For a tool with a deep nested schema and no output schema, the description covers the essentials: what is created, its lifetime, what is returned (a link and a 'message' field), and who completes the remaining steps. It does not address repeat calls or how a new call relates to an existing draft, which matters given idempotentHint=false.

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

Parameters2/5

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

Top-level schema description coverage is 0% for company, facility, and location, and the description never explains what those parameters are or which are required. Only one constraint is added ('Never send the manager's personal number (ЕГН)'), which maps to company.molName, leaving the bulk of the parameter semantics to the nested schema alone.

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 first sentence states a concrete action and result: it saves the answers as a draft for 7 days and returns a link. That is a specific verb+resource an agent can act on. It does not differentiate itself from the siblings haccp_check and haccp_options, which are never mentioned in the description.

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

Usage Guidelines4/5

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

It gives explicit downstream instructions: hand the link to the person, never send the manager's ЕГН, show the person the 'message' field, and it states a hard boundary ('You cannot order or pay'). What is missing is guidance on when to call this versus haccp_check or haccp_options, so the agent has no routing rule among siblings.

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

All HACCP Bulgaria tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?