> ## Documentation Index
> Fetch the complete documentation index at: https://docs.etonecarg.com/llms.txt
> Use this file to discover all available pages before exploring further.

# IDs, Crosswalks, and Bounded Windows

> Learn how to preserve provider refs, use crosswalk confidence safely, and keep schedule-style requests bounded.

# IDs, Crosswalks, and Bounded Windows

Most integration mistakes happen before the deep call, not during it. The safest pattern is to preserve provider refs exactly as they came back from the server and to keep every schedule-style request bounded in time.

## Preserve the provider namespace

<Tabs>
  <Tab title="When IDs are unknown">
    Start with [`resolve_entities`](/sports-mcp-server/tool-reference/resolve_entities).

    What to keep from the response:

    * `gsdRefs` for GSD-first tools
    * `onRefs` for program-context and current-state-aware tools when the provider exposed them
    * `programHints` for program-first follow-ons
    * `meta.crosswalkConfidence` before enriching across providers

    Best next step:

    * choose one candidate
    * preserve the chosen ref with its provider namespace
    * call the smallest next tool that matches the job
  </Tab>

  <Tab title="When IDs are already known">
    Skip resolution when your host already has a stable, provider-specific ref.

    Good examples:

    * a GSD `eventId` from [`list_schedule`](/sports-mcp-server/tool-reference/list_schedule)
    * an On `programId` from your program guide
    * a stored `competitionSeasonId` from a prior flow

    Safety rule:

    * do not normalize everything into a fake server-owned canonical ID
    * keep enough metadata in your host to remember whether a ref is GSD-facing, watchability-facing, or program-facing
  </Tab>
</Tabs>

## Treat crosswalk confidence as a workflow signal

| Signal      | What it means    | What to do next                                           |
| ----------- | ---------------- | --------------------------------------------------------- |
| `0.90-1.00` | High confidence  | Safe to enrich across families when the product needs it  |
| `0.60-0.89` | Mixed confidence | Ask a narrowing question or stay inside one source family |
| `0.01-0.59` | Low confidence   | Do not automatically enrich across providers              |
| `null`      | No crosswalk     | Do not invent linkage in the client                       |

## Keep schedule-like flows bounded

Bounded windows are required for:

* [`list_schedule`](/sports-mcp-server/tool-reference/list_schedule)
* [`list_watchable_schedule`](/sports-mcp-server/tool-reference/list_watchable_schedule)
* [`list_live_slate`](/sports-mcp-server/tool-reference/list_live_slate)
* [`get_watch_availability`](/sports-mcp-server/tool-reference/get_watch_availability)
* [`get_event_center`](/sports-mcp-server/tool-reference/get_event_center)
* [`get_competition_hub`](/sports-mcp-server/tool-reference/get_competition_hub)

Bounded windows are optional, but must be paired when provided, for:

* [`list_programs_for_entity`](/sports-mcp-server/tool-reference/list_programs_for_entity)
* [`get_program_context`](/sports-mcp-server/tool-reference/get_program_context)

Special case:

* [`get_series_hub`](/sports-mcp-server/tool-reference/get_series_hub) can omit the window. When omitted, it uses a bounded default window rather than an unbounded browse.

Why this matters:

* it keeps fanout bounded
* it keeps live and watchability answers scoped to a real product moment
* it prevents the host from turning one prompt into an unbounded browse workload

## Typical handoff pattern

1. Resolve only if the user prompt is ambiguous.
2. Pick one provider ref and preserve the namespace.
3. Add `timeFrom` and `timeTo` when the workflow is schedule-like or watchability-like.
4. Deepen only if the user still needs more context.

## Read this next

* [Dual-Source Doctrine](/sports-mcp-server/concepts/dual-source-doctrine)
* [ID Acquisition and Tool Sequencing](/sports-mcp-server/tools/id-acquisition-and-tool-sequencing)