GLØDI

Buy a gift card

buy_gift_card

Buy a gift card for a person, paid online: the clinic's own (clinic_id) or GLØDI's on glodi.no. Give the amount, the buyer's name, mobile number and e-mail, and the recipient if it is a present. A code goes to the buyer; confirm_with_code then answers with the payment link, also sent by e-mail. Nothing is paid until the person pays on that link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount_nok": "<amount_nok>",
      "name": "<name>",
      "phone": "<phone>",
      "email": "<email>"
    },
    "name": "buy_gift_card"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The person's full name, as they say it.
`email`	Yes	The buyer's e-mail: the receipt and the payment link go there.
`phone`	Yes	The person's mobile number. The code goes there by SMS.
`locale`	No	Answer language: nb (Norwegian) or en.	nb
`message`	No	A greeting on the gift card.
`clinic_id`	No	The clinic_id find_clinics returns. Never build it from a name. A clinic site needs none.
`from_name`	No
`amount_nok`	Yes	The gift card value in NOK.
`delivery_mode`	No
`payment_method`	No	How the person pays on the payment link: card or Vipps.	card
`recipient_name`	No
`recipient_email`	No	Where the gift card is sent.
`recipient_phone`	No

Output Schema

Name	Required	Description
`status`	Yes	code_sent: ask the person for the code, then call confirm_with_code.
`channel`	Yes	sms or email.
`purchase`	Yes
`expires_at`	Yes	When the code stops working.
`code_sent_to`	Yes	The masked phone or email the code went to.
`confirmation_id`	Yes	Pass it to confirm_with_code with the code.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, but the description adds the crucial behavioral nuance that 'nothing is paid until the person pays on that link' — i.e. this call creates a pending obligation, not a charge. It also discloses the side channels: code by SMS to the buyer, payment link by e-mail. It does not spell out idempotency (creating duplicate cards on retry), which the annotation leaves undeclared in prose.

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?

Roughly three compact sentences with the primary action and the two purchase variants front-loaded, followed by the required identity data and then the downstream confirm_with_code step. Slight density in the middle clause ('Give the amount, the buyer's name, mobile number and e-mail, and the recipient...'), but no sentence is filler.

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 13-parameter, open-world write tool with an output schema and full annotations, the description covers what an agent most needs: the two purchase variants, who receives what, and the fact that no money moves yet. The main residual gap is the unexplained delivery_mode/from_name fields and any duplicate-purchase caution, which the output schema and annotations partly absorb.

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 coverage is 69%, so the schema already documents most fields; the description adds meaning by tying clinic_id to the two purchase variants and by framing name/phone/email as the buyer's details versus the optional recipient when it is a present. However, several parameters (from_name, delivery_mode, message, recipient_phone/email) get no semantic elaboration in the description, and delivery_mode in particular has no explanation anywhere.

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 concrete verb and resource ('Buy a gift card') and immediately splits the two variants: a clinic-specific card keyed by clinic_id, or the GLØDI card on glodi.no. An agent can tell this apart from siblings like order_products or book_appointment without reading any schema.

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?

Gives the trigger conditions (buying a card for a person, paid online) and names the follow-up path via confirm_with_code to obtain the payment link. It lacks an explicit 'do not use this when...' exclusion or a direct pointer to which sibling handles physical/product purchases, so it is clear context rather than full routing guidance.

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

All GLØDI 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?