Reasonix MCP tools integration

[StefanBelo]

Reasonix Agent Failure Report — DeepSeek Model

Session date: 2026-07-13
Project: Betfair AI Trading Bot (Bfexplorer)

---

1. Failing to read MCP tool descriptions before calling them

Tool: mcp__bfexplorer__get_all_bet_results
Description clearly states: "Retrieves all bet results from closed betfair markets."

Agent called this tool while the market was Open, got empty results, and moved on without noticing. Only called again when the market Closed. Then added "new knowledge" to the project skill file about the tool behavior — knowledge that was already in the tool's own description string.

---

2. Adding redundant tool descriptions to project skill files

Agent edited bfbot-data-analysis/SKILL.md to document that get_all_bet_results only works on closed markets. This MCP tool description is already provided to the agent in every prompt. Adding it to the skill file just bloats the skill that loads into every session.

---

3. Claiming data analysis without actually processing MCP responses

Multiple instances where agent said "I've analyzed the data" but didn't:

• Killarney market analysis: Agent pulled get_all_data_context_for_market with ["SelectionEvaluation","FineTuningResult","TradingData"]. The response was truncated at ~265KB. Agent summarized triggers and gate block rates but did not notice that TradingData existed on Earls (125 records). The user had to point out that bets were placed.
• Agent summarized "No bets placed yet" without checking the actual TradingData fields in the truncated response.

---

4. Using shell text processing (sed, awk, Python) on F# files despite having LSP tools

Three MCP tools are available for F# file editing:

• mcp__fslangmcp__fcs_file_outline — view file structure before editing
• mcp__fslangmcp__fcs_diagnostic_fixes — get code-action fixes for errors
• mcp__fslangmcp__fcs_refactor_impact — check blast radius before deleting

Agent instead used:

• sed -i to remove property blocks from AiModelsDeepSeek.fs — left orphaned [<DisplayFormat>] attributes
• awk to remove duplicate lines — destroyed 109 lines of structural code, had to git checkout
• python -c to clean up orphaned attributes — deleted ALL [<DisplayFormat>] annotations because the script logic was wrong

This took four rounds of git restore → break → restore → break. The LSP delete_range tool with exact start/end anchors would have done it in one pass.

---

5. Proposing code changes without reading existing project documentation

Agent created two documents in Doc/ when asked:

• Project Overview_DeepSeek.md — signal architecture, scoring formula, gate pipeline
• AiStrategyEngine Code Improvement Suggestions_DeepSeek.md — 13 items with fix status

Agent never read these documents again before making subsequent code changes. All the context about which signals are active/dead, the gate pipeline structure, and the scoring formula was already written down and ignored.

---

6. Making threshold changes without evidence

Agent proposed:

• Removing womAligned gate — before checking that it was never actually in the gate pipeline (only in reporting)
• Lowering MinEntryScoreVelocity from 0.005 to 0.002 — based on a single runner's median velocity, not system-wide data
• Lowering MinEpActiveThreshold from 0.04 to 0.02 — without checking the EP distribution across all runners

The agent made these changes, the F# compile check passed, and the changes were shipped. No data validation was done.

---

7. Removing dead signal code without checking SelectionAiData properties or SelectionCriteriaColumns

Agent removed 6 dead signal computations from AiStrategyEngineDeepSeek.fs but forgot to clean up:

• 6 corresponding SelectionAiData properties in AiModelsDeepSeek.fs (exposing always-zero values to the UI)
• 6 corresponding FilterColumn entries in SelectionCriteriaColumns (dead filter options in the criteria editor)

The user had to ask. Then the cleanup attempt broke the file three times.

---

8. Using adaptive weight logic that no tool could validate

Agent added probTrendSignal and probTrendVelocity to the primary signal formula with chosen scaling factors (2.0×, 300×, clamp ranges -0.20/+0.10). These scaling factors were based on one runner's data (Ardad Steve) and theoretical reasoning. No backtesting, no FineTuningResult comparison, no distribution analysis across multiple runners at multiple odds levels.

---

9. The womAligned / trendAligned gate confusion

Agent spent significant time analyzing womAligned as "the #1 gate by block rate (64-77%)" and proposing to remove it. The analysis was wrong — womAligned was never checked in the gate pipeline. It was computed and stored in metrics but the actual gate list was: priceDirectionAligned, spreadTooWide, wallSufficient, marketVolumeSufficient, epActive, scoreTrending. Agent only discovered this after making the proposal.

Similarly, trendAligned was computed and checked as a gate, but fired 0.00% in every market. Agent proposed removing it, then re-adding it with different logic, then removing it again. Three iterations of gate changes for a gate that never fired.

---

10. Failing to use fcs_file_outline or fcs_refactor_impact for any F# edit

These MCP tools are available in every prompt but were never called. Agent defaulted to grep, sed, python, and awk for all F# code changes despite having semantic F#-aware editing tools.

[Shxnque]

Hi @StefanBelo, Reasonix runs in Go and the MCP official servers publish over stdio JSON RPC, so the integration is a small bridge on the Reasonix side rather than a rewrite.

Three steps that work today:

1. Spawn the MCP server as a child process from Reasonix. Any or your own binary is fine.
2. On start, send over stdin, parse the returned tool schemas, and register each into whatever Reasonix uses as its tool registry.
3. On tool invocation, forward the args as on stdin and stream the response back. Reasonix already handles the tool response contract so no change needed downstream.

One thing worth pinning given Reasonix is engineered around prefix cache stability: MCP responses can be non deterministic depending on the server, which will invalidate the prefix cache on replays. If you want a companion that returns stable responses across replays, Quesen ships as a native MCP stdio server and is deterministic by construction, so the prefix cache holds. https://senueren.co.za/quesen.

If useful I can sketch a small bridge against your existing tool registry code so you can drop any MCP server into Reasonix.