What it does
The connector gives Claude direct access to my ESPN basketball and football leagues, with my Yahoo basketball league joining as soon as API access is approved. It exposes nine tools, and every one of them reads: list_leagues, get_league_settings, get_standings, get_scoreboard, get_matchup, get_roster, get_player, get_free_agents and get_recent_activity. I use it from a dedicated Claude project to manage my teams, so Claude works from the actual league data instead of whatever I remember to paste in.
Why a connector instead of browser automation
Claude can drive a browser, but a browser session can reach anything I'm signed in to and breaks whenever a page layout changes. A connector flips that: it exposes a small, fixed set of operations, returns structured data, and has nothing to do with the rest of my accounts.
Security decisions
- Local only. The server runs on my PC alongside Claude Desktop, so any tokens it uses stay on my machine instead of in a hosted service.
- Read-only by design. There is no tool that can set a lineup, make a trade or post to a league. If the model is ever manipulated by something it reads, the worst case is that it reads more league data.
- Official access paths. Yahoo data goes through Yahoo's Fantasy Sports API program rather than scraping, which is why that half is waiting on approval.
- One interface, two providers. ESPN and Yahoo sit behind the same connector, so adding a source doesn't mean granting Claude a new kind of access.
Why this matters beyond fantasy sports
MCP is quickly becoming how AI agents get access to real systems, and the questions are the same ones I ask about any integration at work. What can it reach? Under whose identity? What happens if the model is fed instructions through the data it reads? Starting from read-only scope and a local trust boundary keeps the answers short.