Skip to main content
Glama
Sign In

Zarvo

by uk.zarvo
OverviewDiscussionsAdmin

Search padel clubs

search_clubs
Read-onlyIdempotent

Use this lightweight directory lookup to find clubs by location and facilities or resolve a club description, nearby landmark, or partial club name into candidate club_id, club_name, and provider values. Put only club-name wording in query; add location when an area was supplied. Use court_type for indoor/outdoor/covered courts, racket_rental for racket hire, and facility for a requested amenity. Preserve these filters when refining a search. Do not infer or pass provider from a club or brand-like name: provider is only an explicit booking-platform hint. If that hint conflicts with the directory, name resolution may return the canonical provider instead. It returns Zarvo club metadata, not live court availability. Follow with get_club for full metadata or get_availability for live slots at a selected provider club.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
facilityNo
locationNo
providerNoOnly filter by provider when the user explicitly names a booking platform. Never infer this from the club name.
radius_kmNo
court_typeNo
racket_rentalNo

Output Schema

NameRequiredDescriptionDefault
dataYes
metaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "padelstars",
-  "playtomic",
-  "padelmates",
-  "matchi",
-  "clubspark",
-  "matchpoint"
-]New value: +[
+  "padelstars",
+  "playtomic",
+  "padelmates",
+  "matchi",
+  "clubspark",
+  "matchpoint",
+  "nettla"
+]
    • changedOutput schema / properties / data / items / properties / provider / enum
      Previous value: -[
-  "padelstars",
-  "playtomic",
-  "padelmates",
-  "matchi",
-  "clubspark",
-  "matchpoint"
-]New value: +[
+  "padelstars",
+  "playtomic",
+  "padelmates",
+  "matchi",
+  "clubspark",
+  "matchpoint",
+  "nettla"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / meta / properties / snapshot_at / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  3. Changed2 schema fields changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "padelstars",
-  "playtomic",
-  "padelmates",
-  "matchi",
-  "clubspark"
-]New value: +[
+  "padelstars",
+  "playtomic",
+  "padelmates",
+  "matchi",
+  "clubspark",
+  "matchpoint"
+]
    • changedOutput schema / properties / data / items / properties / provider / enum
      Previous value: -[
-  "padelstars",
-  "playtomic",
-  "padelmates",
-  "matchi",
-  "clubspark"
-]New value: +[
+  "padelstars",
+  "playtomic",
+  "padelmates",
+  "matchi",
+  "clubspark",
+  "matchpoint"
+]
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, closed-world behavior, and the description adds genuinely new behavior: provider hints may be overridden by canonical directory data during name resolution, and results are directory metadata rather than availability. The 'do not infer provider from a club name' constraint is a real invocation trap it warns about.

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?

Purpose and key filtering rules are front-loaded, and each sentence carries operative information rather than filler. It is dense but slightly long, packing provider-reservation semantics and follow-up routing into one block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape detail is unnecessary, and the description still clarifies the return is club metadata with the three key fields. Coverage of the 8 parameters is nearly complete, with only limit and radius_km unmentioned.

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?

With only 13% schema description coverage, the description carries most of the load and does so for query, location, facility, court_type, racket_rental, and provider semantics. It leaves limit and radius_km unaddressed, which prevents a 5.

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 ('lightweight directory lookup to find clubs') plus the exact resolution targets (club_id, club_name, provider). It explicitly draws the boundary against siblings, noting it returns directory metadata 'not live court availability' and pointing to get_club and get_availability.

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?

Gives concrete routing rules: put only club-name wording in query, add location when an area was supplied, use court_type/racket_rental/facility for the matching attributes, and preserve filters when refining. It also names the follow-up tools for the next step, leaving little to inference.

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

All Zarvo 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