Skip to main content
Glama

haggl.ai

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.

Input Schema

TableJSON 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

TableJSON 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.
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. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, but the description adds substantial non-obvious behavior: the ID is returned only once, anyone holding it can read or delete it, it expires 12 months after last use, only a fingerprint is stored, consent can be withdrawn via deletion, and record-sharing with merchant sales agents is authorized. This goes far beyond the annotation surface.

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 verbatim consent disclosure earns its place because it must be shown to the user, but it is a large block that buries the remaining routing instructions ('If they decline...' and the standing-instruction rule) after dozens of sentences. Key procedural guidance for the agent appears in the final third rather than being front-loaded.

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 an output schema, the definition covers everything the agent needs: the prerequisite disclosure, the accepted consent-proof paths, the fallback tool, post-call handling of the ID, expiry, and deletion semantics. Return values are covered by the output schema and need not be repeated.

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?

Schema description coverage is 100%, so the baseline is 3. The description largely restates schema content (channel semantics, quoting the user's words without contact details, consent_version value, confirmation as an alternative to consent_version/statement), adding little parameter-level meaning beyond what the schema already documents.

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 states a specific verb and resource ('Create a haggl ID for the user') and immediately explains the purpose ('so offers and codes from different merchants stay together and can be read back later'). Combined with the named alternative haggl_request_haggl_id_confirmation, an agent can distinguish it from siblings without opening the schema.

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?

Explicit when-to-use and when-not-to-use: show the consent text first, call only on agreement, 'If they decline, go on without a haggl ID', and route to haggl_request_haggl_id_confirmation when the user cannot read the text in-conversation. The standing-instruction path is also specified. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources