Skip to main content
Glama

kicksmash

by sh.kicksma
OverviewDiscussionsAdmin

Find clubs

find_clubs
Read-onlyIdempotent

Padel clubs: booking link and platform, courts, today's free courts when the club shares its calendar, founding status. Every row says claimed: true when the club runs the page itself, false when Kicksmash listed it from public sources, where the courts and links are our reading and may be out of date. Pass include:'listed' to get both — that is what answers "where can I play here?". Filter by city (phuket, singapore) or ask for one club by name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNophuket or singapore
nameNoOne club by name; the slug is derived
includeNoclaimed (default): only clubs that run their own page. listed: also the clubs Kicksmash listed from public sources, each marked claimed:false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include
      Added value: +{
+  "description": "claimed (default): only clubs that run their own page. listed: also the clubs Kicksmash listed from public sources, each marked claimed:false.",
+  "enum": [
+    "claimed",
+    "listed"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses important behavioral details: the claimed flag indicates whether a club runs its own page, and that court/link data may be out of date when sourced from public listings. It also notes that free-court availability depends on the club sharing its calendar. These caveats add significant value beyond the annotations.

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?

The description is moderately long but front-loads the core purpose in the first sentence and then efficiently explains the claimed flag and usage guidance. Every sentence contributes either to understanding output or invoking the tool correctly, though a tighter phrasing could reduce wordiness without losing substance.

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?

The description explains the return fields (booking link, platform, courts, free courts, founding status, claimed) and the meaning of claimed, which is essential given there is no output schema. It does not mention ordering, pagination, or error cases, but for a read-only list tool with annotations, it covers what an agent needs to call it 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?

The schema already documents all three parameters thoroughly (city, name, include) with 100% coverage. The description reinforces the meaning of include and ties it to a user query, and clarifies that the name parameter uses a derived slug. It does not add new technical details but contextualizes the parameters effectively.

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 clearly identifies the tool as retrieving padel club information (booking link, platform, courts, free courts, founding status) and distinguishes it from sibling find_* tools by its focus on clubs rather than coaches, matches, or series. It states the resource and the key data fields, leaving no ambiguity about what the tool returns.

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?

The description gives explicit usage guidance: it explains that include:'listed' answers 'where can I play here?' and describes filtering by city or name. It does not explicitly mention alternatives, but the sibling list makes it clear that this is the tool for clubs, and the description provides concrete scenarios for when to use it.

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

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