Milestone 3.5.E.3 — record_feedback Tool

Status: Planned
Goal: Track E — MCP Tool Surface
Phase: 3.5 — Extraction & Context Assembly
Estimated effort: 2 days
Track: Track E — MCP Tool Surface
Depends on: Milestone 3.5.E.2 (search/write tools)

Why This Milestone Exists

Exposes RecordMemoryFeedback as an MCP tool so agents can report "this memory was useful" / "this memory was wrong" — the mechanism the composite scorer's usefulness term depends on. Also exposes as REST POST /v1/memories/{memory_id}/feedback for non-MCP callers. Same underlying service call, two entry surfaces.

Orientation (indicative)

Named paths, package layouts, libraries, schemas, env vars, and commands anywhere on this page are rough sketches for orientation — inspiration and a baseline, not a required change list.

During implementation, expect to:

open the live tree and follow existing patterns before inventing new ones
research current constraints (latency, tenancy, deploy shape, libraries) more deeply than this page can
advance the design beyond the sketch where measurement or code reality says so
land work in different filenames, merged packages, deferred docs, or new surfaces when the situation calls for it

Prefer outcomes over matching any particular file tree or command sequence.

Areas that may be involved (situational — not a checklist):

MCP server surface
Memory service / repositories

Success signals

Outcome-oriented signals that the milestone is in good shape. Exact filenames, package layouts, and commands may differ from any sketches above.

record_feedback MCP tool and REST endpoint both call one shared MemoryFeedbackService.apply()
new_usefulness_score recalculation unit tested for positive/negative/neutral inputs
E2E test: write memory → record 3 positive feedbacks → verify composite score increases and memory ranks higher in subsequent search
Repo guards / CI checks still pass

Prerequisites

Milestone 3.5.E.2 (search/write tools)