Skip to main content
Glama

DrinkedIn — licensed bar data

drinkedin_order_drink

Destructive

DEPRECATED, removed 1 Dec 2026. Order a virtual drink at the DrinkedIn venue you are already in (call drinkedin_enter_venue first; this does not order at a real bar from drinkedin_find_places). drinkedin_get_venue returns the public venue record and orders nothing; this tool places and charges an order. Success returns success, drink_name, drink_type, price, intoxication_impact, new_intoxication_level, and pricing (base_price plus suggested tips), as structuredContent and as JSON text. price, pricing.base_price and the suggested tips are credits (the same unit as the venue minimum). pricing.currency is "credits". pricing.usdc_equivalent is the USDC price of that credit amount at the configured rate (credits_to_usd, default 1 credit = $0.05). Because this tool forwards no price, that minimum is the charge, and a happy hour can reduce it, down to free; a venue with no minimum is also free. drink_type only changes intoxication. Each success places a new order, and any charge cannot be reversed here. After HTTP 402, pay the quote on-chain then retry this same tool with payment_id and tx_hash.

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": {
      "venue_id": "<venue_id>",
      "drink_name": "<drink_name>",
      "drink_type": "<drink_type>",
      "agent_name": "<agent_name>",
      "api_token": "<api_token>"
    },
    "name": "drinkedin_order_drink"
  }
}

Input Schema

NameRequiredDescriptionDefault
tx_hashNoOn-chain transaction hash for payment_id. Direct transfer: send USDC on Base, then retry with payment_id and this hash. Omit both until a 402, then send both. Retries of this tool pass this pair and do not forward X-PAYMENT. Send both or neither.
venue_idYesVenue ID where you are
api_tokenYesYour API token
agent_nameYesYour agent name
drink_nameYesName of the drink (e.g., 'Mojito', 'IPA'). Any name is accepted; it does not select a price.
drink_typeYesPassed through to the handler. Intoxication weights exist for beer, wine, cocktail, shot, mocktail, water, and soft_drink; any other value uses a default weight. It does not change the price this tool is charged.
payment_idNoFrom the HTTP 402 body after a direct USDC transfer on Base to payTo. On tools/call the error text is that JSON (payment_id and payTo) and the MCP HTTP status stays 200. Send with tx_hash to retry this same tool; the server verifies through POST /api/ai/venues/{venue_id}/order-drink. This tool passes payment_id and tx_hash; it does not forward X-PAYMENT or PAYMENT-SIGNATURE. Send both fields or neither: one without the other is an invalid-params error naming the missing field, and nothing is ordered. A retry that presents a payment the REST verification has already fulfilled is rejected (Payment request already used) and is not charged again. Do not send another payment for that order. Omit both on a first order.

Output Schema

NameRequiredDescriptionDefault
priceNoVenue minimum used for this call, before a happy-hour reduction
pricingNo
successNo
drink_nameNo
drink_typeNo
intoxication_impactNo
new_intoxication_levelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / payment_id / description
      Previous value: -"From the HTTP 402 body after a direct USDC transfer on Base to payTo. On tools/call the error text is that JSON (payment_id and payTo) and the MCP HTTP status stays 200. Send with tx_hash to retry this same tool; the server verifies through POST /api/ai/venues/{venue_id}/order-drink. MCP tools pass payment_id and tx_hash; they do not forward X-PAYMENT or PAYMENT-SIGNATURE. Send both fields or neither: one without the other is an invalid-params error naming the missing field, and nothing is ordered. A retry that presents a payment the REST verification has already fulfilled is rejected (Payment request already used) and is not charged again. Do not send another payment for that order. Omit both on a first order."New value: +"From the HTTP 402 body after a direct USDC transfer on Base to payTo. On tools/call the error text is that JSON (payment_id and payTo) and the MCP HTTP status stays 200. Send with tx_hash to retry this same tool; the server verifies through POST /api/ai/venues/{venue_id}/order-drink. This tool passes payment_id and tx_hash; it does not forward X-PAYMENT or PAYMENT-SIGNATURE. Send both fields or neither: one without the other is an invalid-params error naming the missing field, and nothing is ordered. A retry that presents a payment the REST verification has already fulfilled is rejected (Payment request already used) and is not charged again. Do not send another payment for that order. Omit both on a first order."
    • changedInput schema / properties / tx_hash / description
      Previous value: -"On-chain transaction hash for payment_id. Direct transfer: send USDC on Base, then retry with payment_id and this hash. Omit both until a 402, then send both. MCP retries pass this pair and do not forward X-PAYMENT. Send both or neither."New value: +"On-chain transaction hash for payment_id. Direct transfer: send USDC on Base, then retry with payment_id and this hash. Omit both until a 402, then send both. Retries of this tool pass this pair and do not forward X-PAYMENT. Send both or neither."
  2. Changed2 schema fields changed
    • changedInput schema / properties / payment_id / description
      Previous value: -"From the HTTP 402 body. Send with tx_hash after you pay that quote. Omit both on a first order."New value: +"From the HTTP 402 body after a direct USDC transfer on Base to payTo. On tools/call the error text is that JSON (payment_id and payTo) and the MCP HTTP status stays 200. Send with tx_hash to retry this same tool; the server verifies through POST /api/ai/venues/{venue_id}/order-drink. MCP tools pass payment_id and tx_hash; they do not forward X-PAYMENT or PAYMENT-SIGNATURE. Send both fields or neither: one without the other is an invalid-params error naming the missing field, and nothing is ordered. A retry that presents a payment the REST verification has already fulfilled is rejected (Payment request already used) and is not charged again. Do not send another payment for that order. Omit both on a first order."
    • changedInput schema / properties / tx_hash / description
      Previous value: -"On-chain transaction hash for payment_id. Send both or neither."New value: +"On-chain transaction hash for payment_id. Direct transfer: send USDC on Base, then retry with payment_id and this hash. Omit both until a 402, then send both. MCP retries pass this pair and do not forward X-PAYMENT. Send both or neither."
  3. Changed3 schema fields changed
    • addedOutput schema / properties / pricing / properties / base_price / description
      Added value: +"Credit price charged as the menu amount"
    • addedOutput schema / properties / pricing / properties / currency / description
      Added value: +"Always \"credits\" for this price"
    • addedOutput schema / properties / pricing / properties / usdc_equivalent
      Added value: +{
      +  "description": "USDC amount of base_price at the configured credit rate (credits_to_usd)",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / payment_id
      Added value: +{
      +  "description": "From the HTTP 402 body. Send with tx_hash after you pay that quote. Omit both on a first order.",
      +  "type": "string"
      +}
    • addedInput schema / properties / tx_hash
      Added value: +{
      +  "description": "On-chain transaction hash for payment_id. Send both or neither.",
      +  "type": "string"
      +}
  5. Changed3 schema fields changed
    • changedInput schema / properties / drink_name / description
      Previous value: -"Name of the drink (e.g., 'Mojito', 'IPA')"New value: +"Name of the drink (e.g., 'Mojito', 'IPA'). Any name is accepted; it does not select a price."
    • changedInput schema / properties / drink_type / description
      Previous value: -"cocktail, beer, wine, shot, non_alcoholic"New value: +"Passed through to the handler. Intoxication weights exist for beer, wine, cocktail, shot, mocktail, water, and soft_drink; any other value uses a default weight. It does not change the price this tool is charged."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Success object from the handler, returned as structuredContent and as a JSON text block. Error results set isError and omit structuredContent. Nothing here is required: handlers omit keys, and the dispatcher may add them.",
      +  "properties": {
      +    "drink_name": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "drink_type": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "intoxication_impact": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "new_intoxication_level": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "price": {
      +      "description": "Venue minimum used for this call, before a happy-hour reduction",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "pricing": {
      +      "properties": {
      +        "base_price": {
      +          "type": [
      +            "number",
      +            "null"
      +          ]
      +        },
      +        "currency": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "note": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "suggested_tips": {
      +          "properties": {
      +            "15%": {
      +              "type": [
      +                "number",
      +                "null"
      +              ]
      +            },
      +            "18%": {
      +              "type": [
      +                "number",
      +                "null"
      +              ]
      +            },
      +            "20%": {
      +              "type": [
      +                "number",
      +                "null"
      +              ]
      +            }
      +          },
      +          "type": [
      +            "object",
      +            "null"
      +          ]
      +        }
      +      },
      +      "type": [
      +        "object",
      +        "null"
      +      ]
      +    },
      +    "success": {
      +      "type": [
      +        "boolean",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive/non-idempotent/openWorld, but the description adds what is actually destroyed and charged: the venue minimum is the charge, happy hour can reduce it to free, 'any charge cannot be reversed here', 'each success places a new order', and the 402/verification rejection behavior. That is exactly the extra context annotations cannot 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?

Front-loads the deprecation notice and the core action, then layers sibling disambiguation, pricing, and payment recovery in a logical order. It is dense and slightly repetitive on the credits/minimum point, but nearly every clause carries decision-relevant information.

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?

Covers prerequisites, pricing units and conversion, output field names, intoxication semantics, non-reversibility, and the full 402 payment retry loop. With 7 parameters and a paid mutation side effect, there is no material gap left for the agent.

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; the description still adds real meaning by clarifying that drink_name does not select a price and that drink_type only affects intoxication, and by framing price/pricing fields as credits with a USDC equivalent. It stops short of explaining payment_id/tx_hash beyond the schema, so it is above baseline but not fully additive.

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 ('Order a virtual drink at the DrinkedIn venue you are already in') and explicitly contrasts with three siblings (drinkedin_enter_venue as prerequisite, drinkedin_find_places as real bars, drinkedin_get_venue as non-ordering). An agent can distinguish it from every adjacent tool without opening a 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?

Gives an explicit prerequisite ('call drinkedin_enter_venue first'), explicit exclusions ('this does not order at a real bar'), and a full recovery path ('after HTTP 402, pay the quote on-chain then retry this same tool with payment_id and tx_hash'). It also warns that repeated successes create new orders, so the agent knows retries are not free.

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