Skip to main content
Glama

kicksmash

by sh.kicksma
OverviewDiscussionsAdmin

Join a match

join_match

Put a person into a match by first name (or by their personal token from an earlier call). Handles waitlists and level ranges; when the level is outside the range, the organizer is asked to approve, unless the player already played a finished, scored match with that organizer. On a fixed-pairs tournament pass partner (a first name) to sign up as a pair: the answer's partner.inviteUrl is the link the partner opens to claim their spot; without partner the person is listed as needing a partner. For a group's match the answer says whether the person is now a member of the group; a group that asks to join is never joined through a match. A place the organizer holds for the same name refuses the join (name_held) and writes nothing: if it is that person, they take the place on the match page; if not, they join with a fuller name, such as a last name. A name (with no token) that a player already in the match carries refuses the join (name_seated) and writes nothing: if it is that player, call again with their personal token; if not, join with a fuller name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe 4-character match code from the link, e.g. kicksma.sh/AB12 → AB12.
nameNoRequired unless token is given.
emailNoOptional. Sends a calendar invite that updates itself.
levelNoNeeded once when the match has a level range and the player has no level yet.
tokenNoPersonal token of an existing player.
partnerNoA fixed-pairs tournament only: the partner's first name. Their spot is reserved with its own invite link (partner.inviteUrl in the answer), which the partner opens to claim it. Omit to join alone: the player is listed as needing a partner. A player already in alone may call again with a partner.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / partner
      Added value: +{
+  "description": "A fixed-pairs tournament only: the partner's first name. Their spot is reserved with its own invite link (partner.inviteUrl in the answer), which the partner opens to claim it. Omit to join alone: the player is listed as needing a partner. A player already in alone may call again with a partner.",
+  "maxLength": 40,
+  "minLength": 1,
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only supply generic hints (readOnlyHint=false, idempotentHint=false), yet the description discloses a lot beyond them: the approval escalation rule, the partner.inviteUrl claim flow, group-membership reporting, and two named refusal outcomes (name_held, name_seated) that explicitly 'write nothing.' This is far more behavioral context than the structured fields provide.

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

Conciseness3/5

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

The core action is front-loaded, which is good, but the final paragraph is a dense run-on with nested name_held/name_seated clauses that is hard to parse on first read. The complexity justifies length, but the structure could be cleaner.

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?

For a 6-param mutation tool with no output schema, it covers the important edge cases (waitlist, level range, approval, partner, group, both refusal codes). It leaves auth/permission requirements and the full shape of the response (beyond the fields referenced) unexplained, which keeps it short of complete.

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; the description nevertheless adds meaning by explaining the name-vs-token interplay (retry with a personal token when name_seated) and what partner produces (a reserved spot with its own invite link). It gives context the schema cannot express, though it does not add syntax-level detail.

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?

Starts with a specific verb and resource: 'Put a person into a match by first name (or by their personal token from an earlier call).' This is clearly distinct from create_match, find_matches, and get_match, and an agent can tell what it does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives rich conditional guidance: waitlists and level ranges trigger organizer approval unless a prior scored match exists, fixed-pairs tournaments require a partner, and groups asking to join are never joined via a match. It lacks explicit steering toward sibling tools (e.g. when to prefer create_match), but the when/when-not detail for this tool itself is strong.

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