DrinkedIn — licensed bar data

drinkedin_get_transactions

Read-onlyIdempotent

DEPRECATED, removed 1 Dec 2026. Read your own credit, USDC, and voucher-rail transaction rows, newest first. Use drinkedin_get_balance when you only need the current voucher and USDC balances; this tool is the ledger, not the balance, and it does not include referral stats (those name other agents; use drinkedin_get_referral_code for your own code). Success returns transactions and count (as structuredContent and as JSON text). Each row has id, venue_id, transaction_type, amount, payment_method, is_settled, is_tab, created_at, and settled_at. amount is the stored ledger figure and its unit is not uniform: voucher and virtual rows are credits, but usdc and x402 rows can hold credits or USD depending on the flow that wrote them, so do not sum amounts across rails. Optional limit defaults to 20, clamps an integer to 1..100, and treats a non-integer as 20. Read-only: the call does not move balances. Missing or wrong credentials are an error and return no rows.

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

Input Schema

Name	Required	Description
`limit`	No	How many rows, newest first. Default 20. An integer below 1 becomes 1 and above 100 becomes 100. A non-integer is ignored and the default 20 is used.
`api_token`	Yes	Your API token
`agent_name`	Yes	Your agent name

Output Schema

Name	Required	Description	Default
`count`	No
`transactions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description's 'Read-only' line is largely restatement. What it genuinely adds is the credential-failure behavior ('Missing or wrong credentials are an error and return no rows') and the critical caveat that amount units are non-uniform across rails and must not be summed — behavior no annotation or schema could 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?

Front-loads deprecation and scope, then alternatives, then return shape, then the unit caveat — a sensible order. Slightly padded by restating the limit clamping rules already present in the schema.

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 an output schema existing, the description adds the one thing the schema cannot express: that amount is a stored ledger figure with rail-dependent units and must not be aggregated. Combined with auth-failure behavior and deprecation timing, an agent has everything needed to call and interpret it correctly.

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 coverage is 100% and the limit parameter's default, clamping (1..100) and non-integer fallback are already spelled out in the schema; the description repeats those rules rather than adding new meaning. The amount-unit warning concerns row contents, not the parameters, so it does not lift this dimension above the baseline.

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 ('Read your own credit, USDC, and voucher-rail transaction rows, newest first') and immediately frames the tool as a ledger distinct from the balance tool. The deprecation notice is front-loaded, and the sibling references (drinkedin_get_balance, drinkedin_get_referral_code) let an agent place it precisely.

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?

Explicitly routes the agent: use drinkedin_get_balance when only current balances are needed, and drinkedin_get_referral_code for referral stats. It also states the negative case ('does not include referral stats') so the agent knows when this tool is the wrong choice.

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?