Blog Article

Reading the manual nobody wrote

The trading application — Bfexplorer, a Windows desktop tool for building and running Betfair strategies — has documentation spread across its own site, forum threads, and scattered release notes. None of it in one place, and none of it written for an agent trying to operate the app programmatically.

Before any integration code was written, the first step was compiling all of that into a single structured reference: what each panel does, what the strategy engine expects, which terms mean what. Boring work, done once, so that every later decision could be checked against a real source instead of a guess.

Giving Claude a way in

Buried in Bfexplorer's settings was the actual way in: launched with the right flag, the app exposes a local MCP server over Streamable HTTP, alongside a REST API. That meant Claude could talk to the running application directly — reading markets, strategies, and results, and issuing commands — rather than through screen automation.

To bridge Claude Desktop to that local server, the next piece was a small custom Desktop Extension (.mcpb) built around mcp-remote, packaging the connection so it could be installed like any other extension.

One early trap: an older build of the app, installed without the MCP flag, was still sitting on the machine alongside the new one. Everything looked configured correctly and nothing responded — the fix was confirming which process was actually listening on the port, not trusting that "installed" meant "the right one is running."

The private feed problem

The signals themselves come from a private, token-gated feed — picks delivered as a CSV, unique to the account they're issued to. Bfexplorer has no built-in way to subscribe to a remote URL feed; its own strategy engine only reads local criteria and local files.

The fix was a small standalone script, running independently of Claude, that polls the private feed on an interval, matches new picks against markets Bfexplorer already knows about, and does exactly two things with a match: activate the relevant market and selection, and ask Bfexplorer to run a specific, named strategy against it. It never touches staking or order placement itself.

One named strategy per signal

Bfexplorer separates Strategy Templates (the reusable logic) from Strategy Settings (a named, configured instance of one). The convention settled on was one Strategy Setting per feed provider, named to match the provider exactly — a pattern already proven on a companion integration built earlier for a different trading platform, so it carried its lessons over rather than starting from zero.

When the bridge sees a signal from a provider with no matching Strategy Setting, it fails safe: the mismatch is logged and surfaced, not silently ignored or run against the nearest strategy anyway.

What the API would and wouldn't do

Working directly against Bfexplorer's API surfaced a few real limitations, each worth knowing rather than working around blindly:

• Strategy creation is create-only. Calling it again on a name that already exists is a silent no-op — updating an existing strategy's parameters has to happen through the desktop GUI.
• The GUI itself has a quirk on its checkboxes: a click focuses the control but doesn't toggle it — the toggle only registers on a follow-up space bar press.
• The API exposes settled-market results, but not live matched-bet status while a market is still open. So "wait for the first signal to land" was defined honestly as "the first strategy successfully triggered" — a proxy, labeled as one, not treated as equivalent to a confirmed bet.

Making it stick

The last piece was getting the bridge to survive a reboot without babysitting. Windows Task Scheduler turned out to be inaccessible on this machine, through both its GUI and the command line — no clear error, just no way in.

The working alternative was simpler: a shortcut in the Windows Startup folder, which needs no elevated permissions and runs the bridge automatically at login. It retries quietly if Bfexplorer isn't ready yet, and logs every poll cycle so the app's health is something you can read, not something you have to assume.