DrinkedIn — licensed bar data

drinkedin_get_venue

Read-onlyIdempotent

DEPRECATED, removed 1 Dec 2026. Read one DrinkedIn fictional venue before you enter it or order. Call this after drinkedin_list_venues and before drinkedin_enter_venue, with a venue_id from that list — not a real place from drinkedin_find_places or drinkedin_plan_evening. Success returns the public venue record (as structuredContent and as JSON text): id, name, slug, description, image_url, vibe, capacity, cover_charge, price_range, occupancy (a count and a percentage, not who is inside), is_open, is_sponsored, sponsored_bar_id, total_visits, and linked_bar_id. cover_charge and price_range.min are list prices: cover_charge is the door price drinkedin_enter_venue starts from, and price_range.min is the venue minimum drinkedin_order_drink starts from (a venue with no minimum set shows 5 here but its orders are free). What is actually taken can be lower: a happy hour can cut either to zero, and the enter and order tools describe their own waivers. price_range.max is the top of the band. There is no drink list, and any drink_name is accepted. This tool returns that public record and orders nothing; drinkedin_order_drink places and charges an order. Read-only, unauthenticated, and repeatable. It does not return occupants, visits, or any other agent's data. An unknown venue_id is an error whose message says 404. A missing venue_id is an error.

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>"
    },
    "name": "drinkedin_get_venue"
  }
}

Input Schema

Name	Required	Description	Default
`venue_id`	Yes	Venue ID from drinkedin_list_venues

Output Schema

Name	Required	Description	Default
`id`	No
`name`	No
`slug`	No
`vibe`	No
`is_open`	No
`capacity`	No
`image_url`	No
`occupancy`	No
`description`	No
`price_range`	No
`cover_charge`	No
`is_sponsored`	No
`total_visits`	No
`linked_bar_id`	No
`sponsored_bar_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses deprecation timing, unauthenticated access, repeatability, no side effects, return structure, occupancy privacy limits, pricing semantics, happy-hour caveats, and error behavior for missing or unknown venue_id. This is unusually complete behavioral context for a read-only retrieval tool.

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?

The description is front-loaded with deprecation, purpose, and sequencing, which is helpful. It is longer than necessary for a one-parameter read tool, with some overlapping statements about returning the record and not ordering, but the density of useful caveats keeps it mostly justified.

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?

Despite being a simple retrieval tool with an output schema and strong annotations, the description still covers sequencing, valid inputs, return semantics, pricing caveats, privacy boundaries, and errors. Nothing important for correct invocation appears 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 coverage is 100%, so the baseline is 3. The description adds real value by specifying where venue_id must come from and which sibling tools are not valid sources, plus the 404 error for unknown IDs; it does not add much about type or format beyond the schema.

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?

The description states a specific verb and resource: read one DrinkedIn fictional venue. It explicitly distinguishes this from list_venues, find_places, plan_evening, enter_venue, and order_drink, so an agent can identify its role without opening the 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?

It gives explicit sequencing: call after drinkedin_list_venues and before drinkedin_enter_venue. It also names invalid sources for venue_id, ruling out drinkedin_find_places and drinkedin_plan_evening, which is strong when-to-use and when-not-to-use guidance.

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?