WCS Points

Get a dancer's Jack & Jill finals partners

get_jj_partners

Read-onlyIdempotent

Who a dancer was placed with in Jack & Jill finals: each placement (1st to 5th) with the partner, most recent first, and the partners they placed with most often. The registry does not record couples; a final places couples, so the partner is the dancer of the other role who took the same place in the same division.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wsdc_id": "<wsdc_id>"
    },
    "name": "get_jj_partners"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of placements to list
`wsdc_id`	Yes	WSDC competitor ID

Output Schema

Name	Required	Description
`name`	Yes
`note`	Yes
`paired`	Yes	Placements whose partner could be identified
`wsdc_id`	Yes
`placements`	Yes	Placed Jack & Jill results (1st to 5th) of the dancer
`partnerships`	Yes	Placements with their partner, most recent first
`frequent_partners`	Yes	Partners placed with more than once, most often first

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower. The description adds genuinely useful semantics beyond them: it explains that the registry does not record couples and that a partner is inferred as the other-role dancer sharing the same place in the same division, plus result ordering and the aggregate of most frequent partners. It does not discuss empty results when a dancer has no JJ finals, which would be the remaining gap.

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?

Short and front-loaded with the core output definition, and the data-model caveat earns its place. The sentence fragments and stray line breaks make it slightly harder to parse than it needs to be, but there is no filler.

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-value structure need not be explained, and annotations carry the safety profile. Given that, the description covers the one thing an agent could not infer from structured fields — how partners are derived. Only the no-results edge case is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so wsdc_id and limit are already documented with bounds and defaults. The description mentions placements 1st–5th, which loosely signals typical result size, but does not explain the limit parameter's effect on the listing or the most-frequent-partners aggregate. Baseline 3 applies.

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 resource (Jack & Jill finals partners), the exact contents (each placement 1st–5th with partner, plus most-frequent partners), and the ordering (most recent first). This is clearly narrower than the sibling get_dancer_results, so an agent can distinguish scope without opening schemas.

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

Usage Guidelines3/5

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

The narrow scope implies when to use it (partner-focused JJ final questions rather than full result listings), but there is no explicit when-to-use or when-not-to-use statement and no named alternative such as get_dancer_results. Guidance is inferable rather than stated.

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

All WCS Points 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.