fanlinewire
Registry code: 04ab83080f10a17d
Read-only data service for current FanDuel Sportsbook odds as carried by the FanLine Wire collector: live (in-play) and prematch tape rows with their American prices, price moves against the bettor, market counts and feed health. Use these tools when the user needs current FanDuel prices, what just moved, in-play markets, or the fixture prices behind a named match — for odds displays, betting or trading models and feature engineering, implied-probability work and cross-book checks on the FanDuel leg. No key and no signup is needed: this connector reads the same public demo document as…
- endpoint
- https://fanlinewire.com/mcp
- protocol
- streamable-http ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is fanlinewire live?
- Yes — it answered the hub's last check (checked 3h ago). It answered 99% of checks over the last 30 days.
- Is fanlinewire free to use?
- Yes — the hub reached it with no key and no payment.
- What tools does fanlinewire have?
- 6 tools: get_price_drops, get_fixture_by_name, get_prematch_fixtures, get_market_summary, get_feed_health, get_live_fixtures.
- Is fanlinewire safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.1%· all time 99.1%
last good check
of 6 tools
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- topic
- games & entertainment sports
- used for
- get live fanduel sportsbook odds
- get prematch odds
- find odds by fixture name
- list recent price drops
- takes → gives
- text → data
- tools
- 6 reads
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
get_prematch_fixtures reads open 24h ago
Pre-match (pre-game) rows from the FanLine Wire tape: the upcoming markets that just ticked, with their American prices. Same shape as get_live_fixtures, with inplay false. Use it for pre-game prices, model inputs and no-vig-style work on the FanDuel card. These rows are the prematch slice of the same rolling ~20-row tape window, not the whole card — prematch_total carries the real coverage number (it counts markets, not rows), so never describe the row count as the size of the card. Only status "OPEN" is tradeable. Not a bet-placement service, not a multi-book comparison, not an opening/closing-odds archive: snapshot the responses yourself if you want line history.
{ "type": "object", "properties": { "limit": { "type": "integer", "maximum": 20, "minimum": 1, "description": "Max rows returned. Default 20 (the whole window), max 20." }, "sport": { "type": "string", "description": "Sport name as the tape spells it (FanDuel's own names): \"Tennis\", \"American Football\", \"Ice Hockey\". Case-insensitive substring match, so \"hockey\" finds \"Ice Hockey\". Optional — omit for every sport in the window. The full vocabulary with counts is in get_market_summary." } } }arguments 15 linesget_market_summary reads open 6h ago
What the collector is tracking right now: live and prematch market totals plus the per-sport breakdown (FanDuel's own sport names). Use it before a board fetch to see whether anything is live, to resolve a sport= filter to a name that actually has markets, and to describe coverage honestly — the totals are market counts, not rows in the tape window. Cheap and free: it is one read of the same cached document. With sport given it also reports that sport's own live/prematch counts. Carries no prices: it answers "how much is covered", not "what are the odds", and it is not a schedule, an uptime record or an upsell meter.
{ "type": "object", "properties": { "sport": { "type": "string", "description": "Optional. Case-insensitive sport name to break out — \"Tennis\", \"American Football\". An unknown name answers with matched:false and the names that do have markets rather than an error." } } }arguments 9 linesget_feed_health reads open 6h ago
Feed liveness and freshness: whether the odds collector answered, how long it took to build the document (X-Server-Ms), generated_at, sequence, seconds since the last tick and the current board size. Call it before describing any price as current, and after an outage. This tool does NOT fail when the collector is down — reachable:false with ok:false IS the answer, so a data tool's isError can be told apart from a real outage. generated_at is the newest tick the collector recorded, so a settled board (no live games moving) shows a growing age without being broken; judge health by generated_at advancing, never by the row count.
{ "type": "object", "properties": {} }arguments 4 linesget_live_fixtures reads open 6h ago
In-play (live) rows from the FanLine Wire tape: the markets that just ticked while a game is running, with their American prices. Use it for live odds displays, in-play modelling or feature engineering, cross-book middles and arbitrage checks on the live FanDuel prices, and any agent workflow that needs what is moving right now. Only rows with status "OPEN" carry a tradeable price — never present a SUSPENDED or CLOSED row as live, and never render an unpriced selection (american:null) as a number. The rows are the live slice of a rolling ~20-row tape window, not the full live board: read live_total for coverage. Not a bet-placement service, not a multi-book comparison (one book, no best-price or line-shopping output), and not a historical archive — prices are current only and nothing is stored here.
{ "type": "object", "properties": { "limit": { "type": "integer", "maximum": 20, "minimum": 1, "description": "Max rows returned. Default 20 (the whole window), max 20." }, "sport": { "type": "string", "description": "Sport name as the tape spells it (FanDuel's own names): \"Tennis\", \"American Football\", \"Ice Hockey\". Case-insensitive substring match, so \"hockey\" finds \"Ice Hockey\". Optional — omit for every sport in the window. The full vocabulary with counts is in get_market_summary." } } }arguments 15 linesget_price_drops reads unknown never probed
Recent price moves against the bettor: outcomes whose price just shortened on the FanLine Wire tape, newest first, with the American price before and after and the move in implied-probability terms. Use it for dropping-odds / steam-move signal, market-movement narratives and as a candidate list for value screening. The feed holds only the most recent few moves (up to 12) and states no cause — it never proves a move is informed money, and it is not a line-movement history, a multi-book comparison or a bet-placement service. Snapshot results yourself if you need history.
{ "type": "object", "properties": { "limit": { "type": "integer", "maximum": 12, "minimum": 1, "description": "Max drops returned. Default 12 (everything the feed holds), max 12." }, "min_pct": { "type": "number", "minimum": 0, "description": "Only drops whose implied-probability move is at least this percent. Default 0, which returns everything the feed is holding. The feed itself only records moves of about 1% or more." } } }arguments 16 linesget_fixture_by_name reads unknown 24h ago
Find tape rows by fixture name: a case-insensitive substring match over the fixture strings in the current window ("peliwo" finds "Filip Peliwo v Tai Leonard Sach"; "v " finds every head-to-head). Use it when the user names a match or a player rather than a sport, to check whether their fixture is on the tape and what its prices are. Every row of a matching fixture is returned — all its markets, live and prematch alike. This searches the ~20-row tape window only, so a fixture the collector is tracking can be absent from the window; an empty answer is not proof the game is missing from the board. Not a fixture-id lookup (the public snapshot carries no ids), not a schedule or results source, and not a bet-placement service.
{ "type": "object", "required": [ "name" ], "properties": { "name": { "type": "string", "description": "Substring of the fixture name, case-insensitive. Required — an empty value would otherwise return the whole window, which is a wrong answer rather than an error." }, "limit": { "type": "integer", "maximum": 20, "minimum": 1, "description": "Max matching rows returned. Default 20 (the whole window), max 20." } } }arguments 18 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's id04ab83080f10a17d.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/04ab83080f10a17d/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/04ab83080f10a17d?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.