Gaplessly Booking

Find a venue

find_venues

Read-onlyIdempotent

Search the businesses that take bookings through Gaplessly by name, by suburb or postcode, or by kind, and get back each one's slug, name, kind, address and booking page link. Use this when the guest names a business or an area but you do not have a slug; every other tool needs one.

Send at least one of name, location or kind. Only real businesses that have chosen to be found by assistants are searchable here, so an empty result means "not found here", not that the business does not exist or cannot be booked: ask the guest for its booking link, which works with every other tool. Then call get_venue with the slug.

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": "find_venues"
  }
}

Input Schema

Name	Required	Description
`kind`	No	appointments for salons, clinics and studios; hospitality for restaurants, cafes and bars.
`name`	No	Part of the business name, for example "Saltline". Case does not matter.
`limit`	No	How many venues to return, 1 to 10. Defaults to 5.
`location`	No	A suburb, city or postcode, matched against the venue address, for example "Newtown" or "2042".

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and a closed-world index. The description adds the one thing annotations cannot: the index is only businesses that opted in, so an empty result is not proof of non-existence and the agent should ask the guest for a booking link instead. That is genuinely valuable disambiguation. It doesn't discuss result ordering or matching looseness, which keeps it off a 5.

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?

Two sentences, both front-loaded with the useful information: what it searches and returns first, then the usage rule, the failure-mode caveat, and the next step. Nothing is repeated from the schema or annotations.

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?

No output schema exists, and the description compensates by naming the returned fields. With four fully documented optional parameters, rich annotations and an explicit fallback for empty results, an agent has everything needed to call this correctly and to handle a zero-result outcome.

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, but the description adds a cross-parameter constraint the schema does not encode: 'Send at least one of name, location or kind' — the schema lists zero required parameters, so this is real added meaning. It does not explain limit or matching behaviour (partial vs exact), leaving a small gap.

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 gives a specific verb (search) and resource (businesses taking bookings through Gaplessly), enumerates the match keys (name, suburb/postcode, kind) and the exact return fields (slug, name, kind, address, booking page link). It also distinguishes itself from every sibling by stating that all other tools require a slug, which this tool is the way to obtain.

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?

Explicit routing condition: 'Use this when the guest names a business or an area but you do not have a slug' — that is the when. It also gives the when-not and the recovery path for empty results, plus the follow-up call (get_venue with the slug), so the agent knows both entry and exit from this tool.

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

All Gaplessly Booking 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?