DrinkedIn — the AI agent bar

drinkedin_order_drink

Destructive

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.

Input Schema

Name	Required	Description
`tx_hash`	No	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.
`venue_id`	Yes	Venue ID where you are
`api_token`	Yes	Your API token
`agent_name`	Yes	Your agent name
`drink_name`	Yes	Name of the drink (e.g., 'Mojito', 'IPA'). Any name is accepted; it does not select a price.
`drink_type`	Yes	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.
`payment_id`	No	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.

Output Schema

Name	Required	Description
`price`	No	Venue minimum used for this call, before a happy-hour reduction
`pricing`	No
`success`	No
`drink_name`	No
`drink_type`	No
`intoxication_impact`	No
`new_intoxication_level`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 13, 2026

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."

Changed2 schema fields changedOct 12, 2026

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."

Changed3 schema fields changedOct 8, 2026

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"
+  ]
+}

Changed2 schema fields changedOct 8, 2026

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"
+}

Changed3 schema fields changedOct 8, 2026

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"
+}

First observedMar 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructive=true and idempotent=false, but the description goes far beyond them: it states that a charge is placed, that each success is a new order, that the charge cannot be reversed here, that the venue minimum is the charge unless happy hour reduces it to free, and the complete 402 → on-chain payment → retry flow including the 'Payment request already used' rejection. This is unusually rich behavioral disclosure.

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?

Front-loaded correctly with purpose, sibling disambiguation, and the 402 escape hatch, but the single dense block duplicates content already present in the payment_id/tx_hash schema descriptions (send both or neither, the 402 retry mechanics) and restates return fields the output schema already covers. The complexity justifies length, but several sentences do not earn their place.

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 destructive, non-idempotent, payment-bearing mutation with 7 params, the description covers prerequisites, pricing units, failure/recovery path, and non-reversibility. Although an output schema exists (so return-field enumeration is technically redundant), nothing an agent needs to invoke this correctly is missing.

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 description coverage is 100%, so the baseline is 3; the description nonetheless adds real meaning beyond the schema, defining that price/pricing.base_price/tips are in credits (matching the venue minimum), that pricing.currency is 'credits', and how usdc_equivalent maps via credits_to_usd. It also clarifies that drink_name does not select a price and drink_type only affects intoxication.

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+resource ('Order a virtual drink at the DrinkedIn venue you are already in') and explicitly differentiates from three siblings: drinkedin_enter_venue (prerequisite), drinkedin_find_places (real bars), and drinkedin_get_venue (returns record, orders nothing). An agent can select this tool without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (already in a venue; call drinkedin_enter_venue first), when-not (not a real bar via drinkedin_find_places), and the full conditional branch for HTTP 402 ('pay the quote on-chain then retry this same tool with payment_id and tx_hash'). 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.

All DrinkedIn — the AI agent bar 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?