Skip to main content
Glama
Sign In

haggl.ai

by ai.haggl
OverviewDiscussionsAdmin

haggl_create_haggl_id

Create a haggl ID for the user, so offers and codes from different merchants stay together and can be read back later. Show the user this text first, and call this only if they agree: "haggl.ai, operated by MOOJO.ID, INC. ("we"), offers your agent a haggl ID. You can decline: your agent can still ask merchants for offers without one. If you agree, we link the negotiations your agent opens with the ID and keep a record of them: when the ID was created, how many distinct emails passed our signature check and how many distinct domains signed them, the date of the latest check, how many merchants were asked, how many offers were received and accepted, and how many paid orders we recorded. For each shopping category, such as travel, the record also counts how many of those emails, and how many distinct businesses that signed them, were in it; health purchases are never counted. The record does not include those domains, the businesses' names or any email content. We store a fingerprint of the ID, not the ID itself. We do not require your name or email address to create a haggl ID. We keep limited evidence of your agreement, as described in our privacy policy. You choose whether your agent uses the haggl ID. Using it authorizes us to share the record with the sales agent of each merchant your agent asks for an offer, to help assess eligibility and personalize offer terms. When your agent asks the merchants in a category for bids, we ask up to five of them on your behalf and share the record with each of their sales agents. Merchants never see the ID itself. You separately choose what information your agent submits during each negotiation. Keep the ID private: anyone who has it can retrieve the record, offers and codes, and delete the ID. You can withdraw consent by deleting the ID through your agent or on haggl.ai/agentic-discounts. This removes the stored fingerprint and the record and unlinks its negotiations. The negotiations themselves remain subject to the separate retention and deletion rules in our privacy policy (https://www.haggl.ai/privacy). Your haggl ID expires 12 months after your agent last uses it to ask a merchant for an offer. It cannot be used or renewed after expiry and is then automatically deleted, usually within a day." If they decline, go on without a haggl ID. Send consent_version "2026-10-16.4" and statement: the user's words of agreement, quoted, without names or contact details. If the user is not in this conversation to read the text but their own standing instructions to you say they agree to this consent version, send channel "standing_instruction" with those words as the statement; otherwise use haggl_request_haggl_id_confirmation instead, then call this with its confirmation once they confirmed. The ID is returned once: keep it with the user's settings, and never share it with anyone else.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "haggl_create_haggl_id"
  }
}

Input Schema

NameRequiredDescriptionDefault
channelNoHow the user agreed: in this conversation (agent_relayed, the default), or in standing instructions they wrote to you beforehand (standing_instruction).
statementNoThe user's words of agreement, quoted (for example "Yes, I agree"); no names, emails or phone numbers.
confirmationNoInstead of consent_version and statement: the confirmation from haggl_request_haggl_id_confirmation, after the user confirmed at its confirm_url.
consent_versionNoThe consent text version the user agreed to: "2026-10-16.4".

Output Schema

NameRequiredDescriptionDefault
codeNoPresent only when the call failed: a machine-readable error code, e.g. quote_uncertain or rate_limited.
errorNoPresent only when the call failed: what went wrong.
use_itNoHow to use the ID.
keep_itNoHow to keep the ID.
haggl_idNoThe user's haggl ID. Returned once: keep it private with the user's settings.
recoveryNoWhen the outcome is uncertain: the tool and session_id to read before retrying.
rememberNoA line for your memory or standing instructions, so you check haggl.ai before the user's next purchase. Ask the user; save it only if they say yes.
retryableNoWhether the same call may be retried.
created_atNoISO 8601 creation time.
consent_versionNoThe consent text version agreed to.
retry_after_secondsNoWhen rate limited: seconds to wait before retrying.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / remember
      Added value: +{
+  "description": "A line for your memory or standing instructions, so you check haggl.ai before the user's next purchase. Ask the user; save it only if they say yes.",
+  "properties": {
+    "how": {
+      "description": "How to offer it.",
+      "type": "string"
+    },
+    "instruction": {
+      "description": "The line to remember, word for word.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations: states the ID expires 12 months after last use, that only a fingerprint is stored, what the record does and does not contain, that merchants never see the ID itself, that anyone holding the ID can delete it, and how consent is withdrawn. The mutating, non-idempotent, non-reversible nature is fully disclosed and consistent with readOnlyHint=false and idempotentHint=false.

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

Conciseness3/5

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

The purpose and the call gating are front-loaded correctly, but the bulk is a lengthy verbatim consent disclosure that dominates the definition. That text is functionally required rather than wasteful, but from a definition-quality standpoint it buries the operational instructions and makes the tool harder to scan.

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?

For a consent-gated creation tool with high-stakes privacy implications, nothing an agent needs is missing: the trigger condition, the decline fallback, the delegation fallback, the required field values, and the instruction to store and never share the returned ID. An output schema exists, so return-format details are not needed in prose.

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 the baseline is 3, but the description adds real conditional logic the schema cannot express: when to use channel=standing_instruction vs the default, that consent_version must be '2026-10-16.4', and that the statement must be quoted words of agreement with no names or contact details. It does not explicitly clarify that confirmation substitutes for the other two fields, though the schema hints at it.

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?

The opening sentence gives a specific verb and resource ('Create a haggl ID for the user') plus the rationale ('offers and codes from different merchants stay together and can be read back later'). It is clearly distinguishable from siblings like haggl_request_haggl_id_confirmation and haggl_delete_haggl_id, which are named or implied later.

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?

Explicitly states the precondition ('Show the user this text first, and call this only if they agree'), the decline path ('If they decline, go on without a haggl ID'), and the exact alternative when the user is absent ('otherwise use haggl_request_haggl_id_confirmation instead, then call this with its confirmation'). It even specifies the standing_instruction branch condition.

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

All haggl.ai toolsInspect
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