Cochee

• 

Inspiration

Fantasy Premier League has grown to more than 11 million players, according to the official game. Behind that number are millions of managers trying to make the right decisions every gameweek: which players to pick, who offers the best value, and which fixtures present the best opportunities. Source: Official Fantasy Premier League

I became interested in how AI could make those decisions easier without requiring everyone to spend hours going through statistics or manually comparing players.

I wanted to build something that could take a question asked in plain English, work with actual player data, and return recommendations that a manager could understand. That idea became Cochee.

How I built it

I built Cochee using Python, Groq, PostgreSQL, pgvector, and the Model Context Protocol (MCP).

The LLM uses Groq's openai/gpt-oss-120b model to understand questions, choose the appropriate tools, and explain the results. I built a self-hosted MCP server that exposes four tools:

• Top Players: Ranks players using filters and configurable scoring weights.
• Similar Players: Finds statistically similar players using pgvector.
• Compare Players: Compares two to five players using consistent metrics.
• Player Fixtures: Retrieves upcoming fixtures and their difficulty ratings.

The application handles data retrieval and scoring, while the LLM handles the conversation and decides which tools to use. This separation was important to me because I wanted recommendations to be based on actual application data and calculations, not just what a language model might generate on its own.

Challenges and what I learned

1. Giving the model enough information

During testing, the model sometimes invented players' first names because my tool returned only their shorter display names. I fixed this by providing their first and last names.

That experience taught me something simple: sometimes, a model gets something wrong because the information it receives is incomplete. Better data can reduce the need for guessing.

2. Making the scoring match the decision

One issue I encountered was that a scoring method that worked reasonably well for general player rankings did not necessarily work for choosing a captain.

The reason was that I initially gave form, fixture difficulty, and value equal importance. Value could push cheaper players higher in the rankings, even when they weren't the strongest captaincy options. A player being a good bargain doesn't automatically make them a good captain.

I addressed this by adjusting the scoring weights to prioritize form and fixtures for captaincy recommendations and removing value from that particular calculation. I also added price filtering.

This taught me that a recommendation system needs to understand what it is trying to optimize. The best player for the money is not necessarily the best player to captain.

3. Making the agent more reliable

I encountered malformed tool-call output from the model and connection errors during testing. I added error handling for relevant failures so the client could respond more deliberately rather than simply crashing whenever something unexpected happened.

This helped me understand that building an AI agent involves more than getting the model to answer questions. The surrounding application also needs to handle failures and unexpected responses.

Testing Cochee

I recently used Cochee to build my own FPL team for Gameweek 7. It was my first time playing FPL, so I relied on its player recommendations instead of independently researching every selection.

The team scored 60 points, compared with the displayed gameweek average of 59.

I see this as an encouraging first test, not proof that Cochee will consistently outperform other managers. A single gameweek cannot establish that. I want to keep testing its recommendations across multiple gameweeks and understand where its decisions work well and where they need improvement.

For me, this was also a useful way to experience the product as a user rather than only as the person building it.

What I learned

Building Cochee has given me practical experience connecting an LLM to tools through MCP, integrating PostgreSQL and vector similarity search, designing scoring logic, and debugging the interaction between a model and an application.

More importantly, I've learned that a useful AI agent is not just about the model. The quality of its data, the tools it can access, the calculations behind its recommendations, and how it communicates the results all matter.

What's next

I want to take Cochee beyond Fantasy Premier League and develop it into a broader AI-powered sports analytics and decision-support product.

FPL is my starting point, but the bigger opportunity is helping people make better decisions about football teams using data, analytics, and AI. That could eventually include fantasy football managers, sports analysts, coaches, and other people who need to evaluate players, compare performance, and understand the factors behind different decisions.

I want to explore how the same foundation can support more advanced analysis while keeping recommendations understandable and grounded in data.

Cochee is an early step toward that vision. For now, my focus is on making its current recommendations more useful, testing them properly, and building from what I learn.

Built With

• docker
• fastapi
• fastapi-mcp
• github
• groq
• mcp
• pgvector
• postgresql
• python