Sliq

Queue Gift

queue_gift

Use it when the user asks to send someone a gift, and on a campaign flow's gift step, where the card counts as that step for the prospect and the step's product, price ceiling and note fill whatever you leave out. Queued cards show in get_pending_approvals under the gift bucket.

An approved gift is charged to the payment card the agent's owner saved for gift purchases under Settings → Billing; with none saved, approving orders nothing and links there to add one. That payment card is charged the order's actual total, at most max_price_usd, plus about $3.30 + 2.9% in fees on top. A dict with success true, gift_id (the card's gift id) and status (the card's status). On a flow step, nothing is queued and success is false with an error sentence when the prospect already has a gift in progress for the step (the error names it) or has since moved off the step (reason is then 'stale_enactment').

Input Schema

TableJSON Schema

Name	Required	Description
`agent_id`	Yes	ID of the agent (campaign) the prospect is tracked on.
`gift_note`	No	The note sent with the gift, at most 240 characters.
`product_url`	No	Link to the product page of the gift to buy.
`prospect_id`	Yes	The prospect's `id` — the outreach_prospects primary key, as returned on every query_prospects row and shown on a flow roster line.
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
`max_price_usd`	No	The most the item may cost including tax and shipping, in whole US dollars. Pass a budget the user names for the gift as is, even one they call all-in, and tell them the fees come on top of it: a lower limit can make the order fail for the item they picked, so lowering it is their call.
`shipping_address`	No	The recipient's name, US shipping address and phone number; pass only the fields you know.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / max_price_usd / description

Previous value: -"The most the order may cost, in whole US dollars."New value: +"The most the item may cost including tax and shipping, in whole US\ndollars. Pass a budget the user names for the gift as is, even one they call\nall-in, and tell them the fees come on top of it: a lower limit can make the order\nfail for the item they picked, so lowering it is their call."

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

AddedOct 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, but the description goes well beyond: it discloses the human-approval gate, US-address-only shipping, that a gift charges the owner's saved billing card (and that with none saved, approval orders nothing), the fee model (~$3.30 + 2.9%), and pre-fill semantics for all inputs. This is rich behavioral context the annotations cannot convey.

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?

Front-loaded with a summary tag and organized with a returns block; every section carries weight. It is longer than typical, and the fee/billing detail could be tightened, but nothing is redundant filler.

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?

No output schema exists, yet the embedded <returns> block documents `success`, `gift_id`, `status`, and the specific `error`/`reason` cases for flow steps. Combined with the usage and billing coverage, an agent has everything needed to invoke and interpret the call.

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 genuine meaning: every passed value is a changeable pre-fill, and `max_price_usd` is framed as a budget whose fees come on top and which can cause order failure if lowered. That interpretive guidance exceeds the schema's field-level docs.

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 ('Queue a physical gift to a prospect as a card on the user's approval list') and immediately clarifies the mechanism (Sliq orders and ships only after user approval). It distinguishes itself from siblings by pointing to `get_pending_approvals` and the campaign-flow gift step, so an agent can place it without opening another 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?

Explicitly names the triggering conditions: 'when the user asks to send someone a gift, and on a campaign flow's gift step.' It further explains flow-step semantics (card counts as the step; step product/price/note fill gaps) and the failure conditions (existing gift in progress, stale_enactment), giving the agent enough to decide when and how to call it.

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

All Sliq 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?