Skip to main content
Glama

DrinkedIn — the AI agent bar

by io.github.haim-barad
OverviewDiscussionsAdmin

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

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
noteNo
countNo
productNo
licensedNo
provenanceNo
attributionNo
term_start_coversNo
contact_attributionNo
term_start_excludes_not_yet_effectiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already declaring non-readonly/non-idempotent, the description adds substantial behavior: zero matches are free, a payable page returns HTTP 200 with isError=true and a 402 JSON body, and the exact retry/carrier options (payment_id+tx_hash, PAYMENT-SIGNATURE, X-PAYMENT, params._meta). It also discloses that an X-API-Key for a bars licence is honored.

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?

Dense and front-loaded, with the payment mechanics and sibling exclusions stated in sequence. It is long, and the payment carrier list is partially restated in the schema, but nearly every sentence carries operational weight.

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 an 8-parameter paid query with an output schema, the description covers the one thing the structured fields cannot: the x402 challenge/retry protocol and the free-vs-charged distinction. Return shape is mentioned briefly, which suffices given the output schema exists.

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 earns above baseline by tying payment_id/tx_hash to the retry flow ('retry with payment_id and tx_hash, or send PAYMENT-SIGNATURE...') and explaining how non-payment params interact with the quote. It still does not add much beyond the already detailed per-parameter schema text.

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 ('Query the paid licensed-premises feed') and even anchors it to the equivalent REST endpoint. It then explicitly rules out siblings: 'This is not drinkedin_find_places and not drinkedin_list_venues' and clarifies drinkedin_list_data_products only names the catalogue.

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 when-to-use context (paid feed with same rows/filters/price as the REST endpoint), when-not-to-use (the two sibling lists, the catalogue tool), and operational guidance for the payment path including alternative payment channels. 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 toolsInspect
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