PricingOption Parameters is a shared type across all pricing models

[bokelley]

Summary

The parameters field on pricing options (pricing-option.json) uses a single shared Parameters type that contains fields from every pricing model combined. This means a flat_rate pricing option's parameters object includes DOOH-specific fields like loop_duration_seconds, min_plays_per_hour, sov_percentage, and venue_package.

Problem

1. No validation — You can set loop_duration_seconds on a flat-rate option and it silently accepts it
2. Schema is confusing — A consumer reading the schema can't tell which parameters apply to which pricing model
3. Tooling impact — IDE autocomplete suggests irrelevant fields, and generated SDK types inherit the confusion

Example

A flat-rate newsletter pricing option validates with all DOOH fields present:

{
  "pricing_option_id": "newsletter_weekly",
  "pricing_model": "flat_rate",
  "fixed_price": 250.00,
  "currency": "USD",
  "parameters": {
    "unit": "week",
    "loop_duration_seconds": 30,
    "sov_percentage": 0.5,
    "venue_package": "premium"
  }
}

No validation error, even though DOOH fields are meaningless here.

Suggested Fix

Discriminated parameter types per pricing model in the schema:

• FlatRateParameters — unit, etc.
• DoohParameters — loop_duration_seconds, min_plays_per_hour, sov_percentage, venue_package
• TimeBasedParameters — duration_hours, daypart
• CpmParameters — estimated_impressions, etc.

This would let validators and SDKs enforce that only applicable fields are present.

Origin

Reported downstream in adcontextprotocol/adcp-client-python#147 while building a sales agent with the Python SDK.