Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

wta_tournaments

Retrieve WTA tournament calendar events by season or date range, with optional level and surface filters, and browse up to 100 events per native page.

Instructions

Get WTA tournament calendar events. Returns one native page of up to100 events for a discovered calendar season, including lower tiers when no level is supplied. Level and surface filter the upstream resource. Event levels can differ from tournament-group defaults. Raw pageInfo is preserved even when numPages is zero with additional entries. Winners, player biographies and match details are outside this metadata response.

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

Input Schema

Name	Required	Description
`to`	No	Inclusive YYYY-MM-DD end, required with from when season omitted
`from`	No	Inclusive YYYY-MM-DD start, required with to when season omitted
`page`	No	Zero-based native page
`level`	No	Native season-specific levels, comma-separated OR
`season`	No	Season from discovery; mutually exclusive with from/to
`surface`	No	Native court surfaces, comma-separated OR
`page_size`	No	Positive native page size, default100; source caps at100

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the one-native-page return model, the 100-item source cap, the level/surface upstream filtering behavior, and the notable quirk that raw pageInfo survives even when numPages is zero. It omits auth requirements, rate limits, and error behavior, so it stops short of fully complete.

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?

Front-loaded with purpose, then scope rules, then exclusions — a sensible order with no filler. The pageInfo/numPages sentence is terse to the point of being cryptic, but it conveys a real edge case in one line.

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 7-parameter read tool with no annotations and no output schema, the description covers the return shape (one page of up to 100 events), filtering semantics, and pagination caveats. What remains thin is the absence of any statement on ordering of events or what the response envelope contains beyond pageInfo.

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 real meaning: omitting level widens results to lower tiers, level/surface filter the upstream resource rather than post-filtering, and season must come from discovery and is mutually exclusive with from/to. These semantics go beyond the field-level descriptions.

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 ("Get WTA tournament calendar events") and bounds the resource by explicitly excluding winners, player biographies and match details, which separates it from wta_tournament_matches, wta_tournament_players and wta_rankings. An agent can identify the tool's output domain 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 Guidelines3/5

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

Usage is implied rather than stated: the season is "discovered" (pointing at a discovery source) and results widen to lower tiers when no level is supplied. There is no explicit when-to-use/when-not statement and no named alternative for a per-tournament lookup, so the agent must infer routing.

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

Deploy Server