ToolCairnFeedback Loop
ToolCairn gets smarter with every interaction. When agents report whether a recommended tool worked, that signal flows back into the graph — reinforcing good recommendations and weakening bad ones.
The Cycle
The feedback loop is a continuous cycle that connects tool usage to graph improvement:
┌──────────────────────┐
│ Agent uses tool │
│ (via search_tools) │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Agent evaluates │
│ tool effectiveness │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ report_outcome() │
│ success | failure │
│ partial │
└──────────┬───────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────────┐ ┌───────────┐ ┌──────────────┐
│ "success" │ │ "partial" │ │ "failure" │
│ +weight │ │ neutral │ │ −weight │
│ reset Δt │ │ log only │ │ attenuate │
└──────┬──────┘ └─────┬─────┘ └──────┬───────┘
│ │ │
└──────────────┼──────────────┘
│
▼
┌─────────────────────┐
│ Catalog updated │
│ │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Future searches │
│ improved for ALL │
│ users │
└─────────────────────┘
│
╰──────▶ (cycle repeats)Outcome Types
The report_outcome MCP tool accepts three outcome types, each with different effects on the graph:
✅ Success
The tool worked as expected. This is the strongest positive signal — it reinforces the graph edge between the tool and its related context, resets the decay timer, and adds a small weight boost.
// report_outcome with "success"
// → Reinforces the relationship between the recommended tool
// and the user's context/stack
report_outcome({
session_id: "sess_abc123",
outcome: "success",
tool: "chromadb",
context: "Used as embedded vector store in RAG pipeline"
})
// Effect on the catalog:
// 1. The relationship strength is reinforced
// 2. The freshness timestamp is updated (resets decay)
// 3. The successful pairing is recorded
// 4. Outcome logged to analytics❌ Failure
The tool didn’t work for the intended use case. This attenuates the edge weight by 15%, reducing the likelihood it will be recommended in similar contexts. Repeated failures may trigger a manual review flag.
// report_outcome with "failure"
// → Attenuates the relationship, reducing confidence
report_outcome({
session_id: "sess_def456",
outcome: "failure",
tool: "abandoned-db",
context: "Incompatible with Node.js 22, no ESM support"
})
// Effect on the catalog:
// 1. The relationship strength is attenuated
// 2. The failure is recorded against the pairing
// 3. Repeated failures flag the pairing for review
// 4. Outcome logged with failure reason🔶 Partial
The tool partially worked or worked with caveats. This is a neutral signal — the outcome is logged for analytics but causes minimal weight change. Over time, patterns in partial reports can inform health score adjustments.
// report_outcome with "partial"
// → Neutral signal — logged but minimal graph impact
report_outcome({
session_id: "sess_ghi789",
outcome: "partial",
tool: "some-orm",
context: "Works but missing TypeScript types for v5 API"
})
// Effect on the catalog:
// 1. No relationship-strength change
// 2. Outcome logged for analysis
// 3. May inform future health score recalculationImpact Summary
| Outcome | Weight Change | Decay Timer | Analytics |
|---|---|---|---|
| ✅ Success | +0.05 (capped at 1.0) | Reset to now | Logged |
| ❌ Failure | ×0.85 (15% reduction) | Unchanged | Logged + review flag if repeated |
| 🔶 Partial | No change | Unchanged | Logged |
A Self-Improving System
The feedback loop creates a network effect: the more agents use ToolCairn, the better it gets for everyone. Each outcome report is a data point that refines the graph’s understanding of tool relationships. Over time, this produces a recommendation engine that reflects real-world usage patterns rather than static editorial opinions.
Combined with temporal edge decay, the feedback loop ensures that the graph stays both accurate (reflecting current reality) and self-correcting (reducing bad recommendations automatically).