nabarfinder

search_venues

Search NABarFinder — a human-verified directory of 1514 venues with real non-alcoholic (NA) drink programs across 70 cities in the US, UK, and beyond. All filters are optional and combine with AND; with no filters it returns the top-rated venues overall. Returns at most 25 venues (sorted by NA Program Strength descending, then name), each with name, slug, city, venue type, naProgramStrength (1–5; 5 = fully alcohol-free or a dedicated NA program, 1 = a few NA options), a one-line summary, and the canonical nabarfinder.com page URL for citing/linking. The response includes the total match count; if it exceeds the cap, narrow with filters. Use get_venue with a result's slug for the full record. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	Limit to one covered city. Accepts a city slug ('austin-tx'), a plain name ('Austin'), or 'Austin, TX'. Call list_cities for the covered set — cities outside it return zero matches.
`query`	No	Free-text filter over venue name, neighborhood, venue type, and description. Case-insensitive; every word must match (e.g. 'kava lounge', 'zero proof cocktail').
`min_program_strength`	No	Minimum NA Program Strength on the registry's 1–5 scale (5 = fully alcohol-free / dedicated NA program). E.g. 4 returns only the strongest programs.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It covers the read-only nature, the 25-venue cap, sort order (NA Program Strength descending, then name), returned fields, the total match count, and the meaning of the strength scale, leaving no critical behavior undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: the first defines the directory and its scope, the second details the result set and ordering, and the third covers match count, narrowing, and the get_venue alternative. It is dense but not verbose, and critical information is front-loaded.

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 search tool with three optional parameters and no output schema, the description is fully complete: it explains filter behavior, result fields, sorting, limit, total count, and the path to full records via get_venue. An agent has everything needed to invoke this tool correctly.

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 parameters are already well documented. The description adds value by explaining how filters combine (AND), that they are optional, and how the no-filter default behaves, plus guidance to narrow when the cap is exceeded. This supplements the schema with usage-level semantics.

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 opens with 'Search NABarFinder', a specific verb plus resource, and immediately clarifies it is a human-verified directory of venues with non-alcoholic drinks. It distinguishes search_venues from get_venue by noting that get_venue is the tool for retrieving a full record via slug, and the scope (venues vs. drinks/menus) separates it from find_drink and get_menu.

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 explicitly explains filter semantics: all filters are optional and combine with AND, and no filters returns overall top-rated venues. It instructs the agent to narrow with filters when the match count exceeds the cap, and directs it to get_venue for full records, providing a clear alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All nabarfinder tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct query type: find_drink searches by drink, search_venues searches by venue attributes, get_venue fetches venue details, get_menu fetches a venue's menu, and list_cities enumerates supported cities. The overlap between find_drink and search_venues is resolved by their clear, different filtering purposes.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern: find_drink, get_menu, get_venue, list_cities, search_venues. The verbs are consistent in style and each noun clearly indicates the resource being acted on.

Tool Count5/5

Five tools is an appropriately scoped surface for a read-only venue and drink directory. Each tool covers a distinct need without redundancy, and the count is neither thin nor excessive.

Completeness5/5

The read-only domain is well covered: list cities, search venues, fetch full venue details, fetch a venue's menu, and find venues by specific drink. There are no obvious dead ends for the stated directory purpose.

Resources

Need Help?