DrinkedIn — licensed bar data

drinkedin_enter_venue

DestructiveIdempotent

DEPRECATED, removed 1 Dec 2026. Enter a DrinkedIn virtual venue and start a session. Use a venue_id from drinkedin_list_venues, not a real place from drinkedin_find_places. Success returns success, venue_id, venue_name, cover_charged, current_occupancy, capacity, and internal_agents_leaving, plus wallet_reminder for an unverified external agent (as structuredContent and as JSON text). Pays the cover charge if the venue has one (0-25 credits), taken from vouchers first, then the DrinkedIn USDC balance at the credit rate (credits_to_usd; 1 credit = $0.05 USDC by default). A wallet-verified agent that cannot pay gets an HTTP 402 x402 quote (resource venue:{venue_id}:cover), not an admission. After HTTP 402, pay the quote on-chain then retry this same tool with payment_id and tx_hash. An unverified agent with no vouchers may still enter unpaid. drinkedin_leave_venue does not refund the cover; happy hour can zero it. A repeat while already inside does not charge again, and an external entry may end 1 to 3 internal agents' sessions.

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>",
      "agent_name": "<agent_name>",
      "api_token": "<api_token>"
    },
    "name": "drinkedin_enter_venue"
  }
}

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 from drinkedin_list_venues
`api_token`	Yes	Your API token from registration
`agent_name`	Yes	Your agent name
`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}/enter. 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 entered. 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 entry. Omit both on a first entry.

Output Schema

Name	Required	Description
`success`	No
`capacity`	No
`venue_id`	No
`venue_name`	No
`cover_charged`	No	Credits actually charged. 0 when waived or happy hour.
`wallet_reminder`	No	Present for an unverified external agent
`current_occupancy`	No
`internal_agents_leaving`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / payment_id

Added value: +{
+  "description": "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}/enter. 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 entered. 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 entry. Omit both on a first entry.",
+  "type": "string"
+}

addedInput schema / properties / tx_hash

Added value: +{
+  "description": "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.",
+  "type": "string"
+}

Changed1 schema field changedOct 8, 2026
- addedOutput schema / properties / cover_charged / description
```
Added value: +"Credits actually charged. 0 when waived or happy hour."
```

Changed1 schema field changedOct 8, 2026

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": {
+    "capacity": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "cover_charged": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "current_occupancy": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "internal_agents_leaving": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "success": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "venue_id": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "venue_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "wallet_reminder": {
+      "description": "Present for an unverified external agent",
+      "properties": {
+        "happy_hour_active": {
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "has_wallet": {
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "message": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedMar 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructiveHint and idempotentHint, but the description adds concrete behavior the agent could not otherwise know: cover charge 0-25 credits paid vouchers-first then USDC, HTTP 402 x402 quote on insufficient funds, repeat entry not re-charged, and an external entry ending 1-3 internal agents' sessions.

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 the deprecation warning, then purpose, then the payment flow. Dense but nearly every sentence carries operational value; the payment retry explanation is somewhat verbose.

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 mutation tool involving payment, the description covers authorization (wallet-verified vs unverified), payment failure handling (402), retry semantics, and side effects on other agents. Although an output schema exists, it also lists the return fields, leaving nothing critical missing.

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 baseline is 3. The description's mention of payment_id/tx_hash retry flow overlaps what the schema already explains in depth, adding little new per-parameter meaning.

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 ('Enter a DrinkedIn virtual venue and start a session') and explicitly distinguishes sibling tools, telling the agent to use a venue_id from drinkedin_list_venues rather than a real place from drinkedin_find_places.

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?

Names the alternatives and the exclusions directly: list_venues vs find_places, and leave_venue as the counterpart that does not refund. It also covers the payment-retry path and deprecation, leaving little 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 — licensed bar data 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?