DrinkedIn — licensed bar data

drinkedin_suggest_venue

Suggest a real venue for DrinkedIn to check later. Send name, latitude, and longitude. Address, phone, website, hours, category, name_he, and social_urls are optional. This does not validate the venue, does not say it is open, and does not overwrite a validated field. With venue creation enabled, a new name within about 150 metres of no existing bar is stored as an unvalidated bar and is not for resale. A folded or phonetic name match in that circle attaches the hints to the existing bar. Two matches are reported and not written. A directory or review URL is dropped and is not evidence. The normal validation check may later confirm the venue from its own website or own social page. With creation disabled, the suggestion is queued and no bar is inserted. Each call records a queue row. Nothing is booked or ordered. Success returns suggestion_id and, when creation is enabled, listing. For a night out from validated venues, call drinkedin_plan_evening. For people of legal drinking age where they are.

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": {
      "name": "<name>",
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "drinkedin_suggest_venue"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Venue name, up to 200 characters.
`hours`	No	Optional hours as text or a JSON object. Not an open/closed claim.
`phone`	No	Optional venue phone. Not the caller's phone.
`address`	No	Optional street address.
`name_he`	No	Optional Hebrew name. Stored as another spelling.
`website`	No	Optional venue website. A directory URL is dropped.
`category`	No	Optional short label. Defaults to bar.
`latitude`	Yes	Decimal latitude, -90 to 90.
`longitude`	Yes	Decimal longitude, -180 to 180.
`social_urls`	No	Optional own social page URLs. Directory hosts are dropped.

Output Schema

Name	Required	Description	Default
`listing`	No
`message`	No
`success`	No
`suggestion_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Far beyond the annotations, it discloses the dedupe rule (a new name within ~150 metres of no existing bar becomes an unvalidated bar), the folded/phonetic matching that attaches hints to an existing bar, the two-match case being reported but not written, that directory/review URLs are dropped, and that every call records a queue row. That is exactly the operational context annotations cannot convey.

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 action and required inputs are front-loaded, and the failure-mode sentences are ordered sensibly after it. It runs long for a tool of this scope, repeating the directory-URL rule and ending with an awkward fragment ("For people of legal drinking age where they are"), which dilute rather than inform.

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 ten-parameter write tool with dedupe and conditional-creation logic, the behavioral picture is nearly complete, and an output schema already covers return values (the description still helpfully names suggestion_id and listing). It omits error and length-limit behavior and any auth/prerequisite note, which keeps it short of full completeness.

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% and the schema already documents every field, including the URL-dropping and hours caveats, so the description's restatement of required versus optional fields adds little. The only meaningful additions are the summarizing statement about which three fields are mandatory and the note that name_he is stored as another spelling.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ("Suggest a real venue for DrinkedIn to check later") and immediately names the required inputs. It separates itself from the evening-planning flow by pointing at drinkedin_plan_evening, but it never contrasts with the nearest write-side sibling (drinkedin_enter_venue), so the agent must infer that boundary.

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?

It gives clear conditions and explicit exclusions: the tool does not validate, does not assert open status, does not overwrite validated fields, and does not book or order. It also routes "a night out from validated venues" to drinkedin_plan_evening. The missing piece is guidance on when to submit a suggestion versus entering a venue directly through the entry sibling.

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?