Skip to main content
Glama

DrinkedIn — licensed bar data

drinkedin_query_licensed_bars

Query the paid licensed-premises feed, the same rows, filters, and price as GET /api/data/v1/bars. No agent_name or api_token. Zero matches are free. A page that would return rows is an x402 challenge: tools/call stays HTTP 200, isError is true, and the text is the 402 JSON (payment_id, payTo, and accepts). PAYMENT-REQUIRED and _meta x402/payment-required carry the same v2 challenge. Retry with payment_id and tx_hash, or send PAYMENT-SIGNATURE or X-PAYMENT on this tools/call, or send params._meta["x402/payment"]. An X-API-Key for a bars licence is honored. This is not drinkedin_find_places and not drinkedin_list_venues. drinkedin_list_data_products names the catalogue and does not deliver rows. Success returns product, count, and data (as structuredContent and as JSON text).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "drinkedin_query_licensed_bars"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoCase-insensitive substring of the premises locality. Omit to leave the city filter off. An empty string is omitted.
limitNoPage size. Missing becomes 50. Values below 1 become 1. The feed then clamps to at most 1000 and to the venues this page can return after filters and offset. The quote uses that clamped count.
offsetNoHow many matching venues to skip. Missing or below 0 becomes 0. An offset past the end is an empty page and is not charged.
countryNoCase-insensitive substring of the premises country. Omit to leave the country filter off. An empty string is omitted.
tx_hashNoOn-chain transaction hash for payment_id (0x and 64 hex characters). Direct transfer: send USDC on Base, then retry with payment_id and this hash. Omit both until a 402, then send both. A PAYMENT-SIGNATURE or X-PAYMENT header does not use this field.
payment_idNoFrom the 402 body after a direct USDC transfer on Base to payTo. On tools/call the error text is that JSON and the MCP HTTP status stays 200. Send with tx_hash to retry this same tool. Send both fields or neither. Omit both on the first call, or pay with PAYMENT-SIGNATURE, X-PAYMENT, or params._meta x402/payment instead.
include_futureNoWhen true, 1, or yes, include licence terms that have not started yet. Any other value leaves them out. The value is not stripped: a leading space is off.
term_started_afterNoISO date (YYYY-MM-DD). Keeps venues whose current licence term started after this date. A value that is not a date is a 400 and is not quoted. An empty string is omitted.

Output Schema

NameRequiredDescriptionDefault
dataNoEach row adds legal_drinking_age (the age on record for address_country, or null), hours_verified and prices_verified (both false). The page repeats those flags; its legal_drinking_age is set only when every row shares one known age.
noteNo
countNo
productNo
licensedNo
provenanceNo
attributionNo
hours_verifiedNo
source_noticesNo
prices_verifiedNo
term_start_coversNo
legal_drinking_ageNo
contact_attributionNo
term_start_excludes_not_yet_effectiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / data / description
      Added value: +"Each row adds legal_drinking_age (the age on record for address_country, or null), hours_verified and prices_verified (both false). The page repeats those flags; its legal_drinking_age is set only when every row shares one known age."
    • addedOutput schema / properties / hours_verified
      Added value: +{
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / legal_drinking_age
      Added value: +{
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / prices_verified
      Added value: +{
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / source_notices
      Added value: +{
      +  "items": {
      +    "type": [
      +      "object",
      +      "null"
      +    ]
      +  },
      +  "type": [
      +    "array",
      +    "null"
      +  ]
      +}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Well beyond the annotations, it discloses the charging boundary: zero matches are free, while a page that would return rows produces an x402 challenge. It also explains the unusual HTTP 200 plus isError behavior, challenge payload and signalling locations, payment retry options, API-key handling, and success envelope, preventing likely payment and error-handling mistakes.

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 purpose is front-loaded, followed logically by charging, payment handling, sibling differentiation, and results. The single paragraph is dense and repeats some schema-level payment details, but there is little filler and the length is largely justified by the unusual protocol.

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 complex paid feed with eight optional parameters, the description covers the dataset identity, free and chargeable outcomes, transport-level error behavior, authentication and payment routes, sibling boundaries, and result shape. The schema already supplies filter formats, pagination clamping, and detailed field constraints, leaving no material selection or invocation gap.

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, and much of the payment_id and tx_hash guidance repeats the schema. The description still adds useful integration context through the complete challenge-and-retry flow, the absence of agent_name or api_token credentials, the challenge fields, and the X-API-Key alternative, though it adds little about the ordinary filters.

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 opening sentence combines a specific verb and resource: querying the paid licensed-premises feed, with equivalence to GET /api/data/v1/bars. It also explicitly distinguishes the tool from drinkedin_find_places, drinkedin_list_venues, and the catalogue-only drinkedin_list_data_products.

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?

The description makes the selection criterion clear: use this tool to obtain licensed-premises rows, not to find places, list venues, or inspect the data-product catalogue. It further supplies concrete invocation guidance for the initial call, payment-required retry, alternative payment channels, and bars-licence API-key access.

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