Marketplace: add a live-tennis match-state data-provider (complements the Polymarket + Kalshi event-contract adapters)

[bensynapse]

Disclosure: I run the Live Tennis API — judge this purely on the merits, and please close it if it isn't a fit. I'm not proposing a venue or an execution adapter; Gordon already has those. This is a read-only market-data feed for a market Gordon can already reach.

The gap

The marketplace already lists two adapters that carry tennis event contracts:

• polymarket (execution) — general prediction-market discovery + order management
• kalshi (execution) — "CFTC-regulated event contracts — politics, economics, weather, sports"

But there's no data-provider that tells the agent what is actually happening in the tennis match those contracts settle on. Right now the researcher/executor can find a Sinner-vs-Alcaraz event contract and read its price, but has no primary source for live score, who's serving, break-point pressure, or whether someone just retired — the exact state that moves those prices. The catalog has fred for macro and financial-datasets for equities fundamentals; the tennis event-market surface has no equivalent live-state feed.

Proposal

Add one data-provider entry for livetennisapi-mcp — an MCP server (npm, also on the official MCP Registry) that exposes live tennis match state to an agent. It is strictly a data source: no orders, no wallet, no venue. It pairs naturally with the existing Polymarket/Kalshi adapters — one reads the market, this reads the underlying match.

What the free tier returns (no card): live scores, match status (in-progress / retired / walkover / completed), the serving player, a three-valued break-point flag (true / false / undefined-in-tiebreak), players with ranking + Elo, fixtures, and tournament metadata. Paid tiers add match-winner prices, in-play serve/break statistics, full rankings history, a 1968–2022 results archive, and a model win-probability tool — but nothing paid is required for the match-state use case above.

Fit against the catalog's own rules

I read the marketplace code before writing this, so the entry is drop-in:

• Category — data-provider is in ALLOWED_CATEGORIES in src/infra/ai/mcp/marketplace/categoryEnforcement.ts (market/financial data), so it passes the install-time category gate rather than being filtered out.
• Schema — it carries id / name / description / category / transport / pricing, so it satisfies every required-field and known-category assertion in src/infra/ai/mcp/marketplace/catalog.test.ts.
• Transport — stdio via npx -y, matching the existing lightweight data-provider pattern (e.g. fred, synthdata).

Suggested entry for src/infra/ai/mcp/marketplace/catalog.json

{
  "id": "livetennisapi",
  "name": "Live Tennis API",
  "description": "Live tennis match state — scores, serving player, three-valued break-point flag, retirement/walkover/completed status, players (ranking + Elo), and fixtures for ATP, WTA, Challenger, ITF and juniors. Read-only underlying-event data for tennis event markets.",
  "category": "data-provider",
  "transport": "stdio",
  "install": "npx -y livetennisapi-mcp",
  "credentials": [
    { "env": "LIVETENNISAPI_KEY", "required": true, "description": "Free key, no card, from livetennisapi.com/subscribe/free" }
  ],
  "docsUrl": "https://docs.livetennisapi.com",
  "pricing": "freemium",
  "pricingNote": "Free tier: live scores, match state, players, fixtures, tournaments (30 req/min, 100/day, no card). Paid tiers add match-winner prices, in-play stats, rankings, 1968–2022 archive, and win-probability.",
  "toolCount": 24
}

(There's also an HTTP transport at https://mcp.livetennisapi.com/mcp with Authorization: Bearer auth, if you'd rather list the http variant to match financial-datasets/debridge — happy to write it either way.)

Prior art for match ↔ market matching

If it helps reviewers see the shape of the integration, there's a small MIT, observe-only toolkit that already does tennis-event-market discovery on Polymarket's Gamma API and matches markets to live matches: github.com/livetennisapi/polymarket-tennis. It's a reference, not a dependency — nothing in this proposal needs it.

Honest scope / what this is not

• Not an execution path and not a venue — it never places or cancels anything, so it stays entirely outside the risk gate and deny-list (it's a get_*-only data source).
• Not a signal or a strategy — it reports match facts; any edge is the agent's to derive.
• Tennis only. If you'd rather keep the data-provider set broad-market and not per-sport, that's a completely reasonable close.

If you're open to it I'm glad to open the PR myself — the one-object catalog addition plus a line in the docs — and run bun test/bun run typecheck/bun run check per CONTRIBUTING.md first. Either way, thanks for building Gordon; the deny-first harness is a genuinely good piece of design.