Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

pgatour_schedule

Retrieve the default public golf schedule for a selected tour and season, returning native tour and resolved season context for scheduling or research use.

Instructions

Get the website-default golf schedule. Returns the selected public golf resource with its native identity, tour and resolved season context. Player IDs retain significant leading zeroes.

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

Input Schema

NameRequiredDescriptionDefault
tourNoR: PGA Tour; S: Champions; H: Korn Ferry; Y: Americas
seasonNoNative season value from tour-specific season discovery; omission preserves source default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden, and it does add real value by stating what comes back: native identity, tour, and a resolved season context. However, it omits prerequisites, rate limits, and error behavior, and the closing note about player ID leading zeroes is unexplained boilerplate that doesn't describe schedule behavior.

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 purpose is front-loaded in the first sentence and the text is short, but the third sentence about player ID leading zeroes is unexplained and does not earn its place in a schedule tool, and 'website-default' / 'native identity' are vague phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-optional-parameter read tool with no output schema, the description is close to adequate: it states what is returned and how the season defaults. It is still missing routing guidance relative to the seasons sibling and any disclosure of auth or failure modes, which matters given zero annotation coverage.

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%, with the tour enum values and the season defaulting behavior fully documented in the schema, so the schema does the heavy lifting. The description adds only the notion of a 'resolved season context' on return, which is marginal additional meaning for the two parameters.

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 names a specific verb and resource ('Get the ... golf schedule') and scopes it as the 'website-default' variant, which implicitly distinguishes it from the season-discovery sibling referenced in the schema. It stops short of naming pgatour_schedule_seasons outright, but an agent can tell what resource is returned.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not guidance and no alternative tool is named. The only usage cue is the schema's note that omitting 'season' preserves the source default, which is a parameter hint rather than routing guidance between this and pgatour_schedule_seasons.

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

Deploy Server

Other Tools