Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

pgatour_tournament_course_stats

Retrieve PGA Tour course statistics for a tournament, including every native course, round summary, and hole-level data, using canonical year, slug, and full tournament ID.

Instructions

Get PGA Tour tournament course statistics. Returns every native course, round summary and hole statistic. Null all-round selectors remain null. Supply canonical year, slug and full tournament ID from tournament-link discovery. Other tours and team-event variants are not qualified by this local contract.

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": {
      "year": "<year>",
      "slug": "<slug>",
      "id": "<id>"
    },
    "name": "pgatour_tournament_course_stats"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Full native main-tour tournament ID, for example R2026457
`slug`	Yes	Canonical main-tour tournament URL slug from schedule
`year`	Yes	Canonical tournament URL year, matching the full ID

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the returned data scope and notes that null all-round selectors remain null, but it does not describe read-only safety, failure modes, rate limits, or output formatting.

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 definition is short and front-loads the purpose before moving to return contents and input requirements. Some phrasing is opaque, especially 'Null all-round selectors remain null' and 'local contract,' but it remains compact and mostly structured.

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 three-parameter retrieval tool without annotations or an output schema, the description provides the essential purpose, return scope, input provenance, and tour/team-event exclusions. It could say more about output structure or error conditions, but an agent has enough to select and invoke 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?

Schema coverage is 100%, so the schema already defines all three parameters in detail. The description adds provenance by directing the caller to tournament-link discovery for canonical values, which is useful beyond the schema without fully re-documenting each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get PGA Tour tournament course statistics,' and clarifies the returned scope as native courses, round summaries, and hole statistics. It is clearly distinct from tournament overview or leaderboard concepts, though it does not explicitly name a sibling tool to contrast against.

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?

It tells the caller to supply canonical year, slug, and full tournament ID from tournament-link discovery, and explicitly excludes other tours and team-event variants. This gives useful selection context and a clear when-not boundary, though it does not compare directly against overlapping tournament-stat siblings.

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

Deploy Server