Add recall_dispatches MCP read tool, mirrors HTTP GET dispatches route #22

New issue

Open

opened 2026-05-23 20:55:23 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-05-23 20:55:23 +00:00

Owner

Originally filed by @coilysiren on 2026-05-20T06:07:38Z - https://github.com/coilysiren/repo-recall/issues/213

Child of #210.

Add MCP read tool recall_dispatches(repo_id: i64) that returns the same list the HTTP route GET /api/repos/{repo_id}/dispatches already serves.

Why. Today the MCP surface has multiple write tools for dispatches (recall_record_dispatch, the recall_dispatch_* lifecycle family) but no read counterpart. A consumer that records a dispatch via MCP cannot then list dispatches via MCP - it has to fall back to HTTP. That's exactly the asymmetry #210 calls out.

Shape.

Args: repo_id: i64.
Return: same JSON shape as the HTTP route. Whatever the existing api::repo_dispatches handler returns, this tool wraps.
Implementation: thin wrapper over the same DB call the HTTP handler uses.

Surface changes.

src/display/mcp/tools.rs - add DispatchesArgs { repo_id: i64 } + pub async fn dispatches(...).
src/display/mcp/mod.rs - register recall_dispatches, bump the tool-count doc comment.
tests/mcp_smoke.rs - smoke test that records a dispatch via the existing write tool and reads it back via the new read tool.

Test gate. make ci + mcporter call repo-recall-staging recall_dispatches repo_id=<id> returns the same payload as curl http://127.0.0.1:7777/api/repos/<id>/dispatches.

Naming check. If recall_dispatches reads ambiguously next to the existing recall_record_dispatch and the recall_dispatch_* lifecycle tools, the alternative is recall_list_dispatches. Punt the naming call to implementation time.

_Originally filed by @coilysiren on 2026-05-20T06:07:38Z - [https://github.com/coilysiren/repo-recall/issues/213](https://github.com/coilysiren/repo-recall/issues/213)_ Child of #210. Add MCP read tool `recall_dispatches(repo_id: i64)` that returns the same list the HTTP route `GET /api/repos/{repo_id}/dispatches` already serves. **Why.** Today the MCP surface has multiple write tools for dispatches (`recall_record_dispatch`, the `recall_dispatch_*` lifecycle family) but no read counterpart. A consumer that records a dispatch via MCP cannot then list dispatches via MCP - it has to fall back to HTTP. That's exactly the asymmetry #210 calls out. **Shape.** * Args: `repo_id: i64`. * Return: same JSON shape as the HTTP route. Whatever the existing `api::repo_dispatches` handler returns, this tool wraps. * Implementation: thin wrapper over the same DB call the HTTP handler uses. **Surface changes.** * `src/display/mcp/tools.rs` - add `DispatchesArgs { repo_id: i64 }` + `pub async fn dispatches(...)`. * `src/display/mcp/mod.rs` - register `recall_dispatches`, bump the tool-count doc comment. * `tests/mcp_smoke.rs` - smoke test that records a dispatch via the existing write tool and reads it back via the new read tool. **Test gate.** `make ci` + `mcporter call repo-recall-staging recall_dispatches repo_id=<id>` returns the same payload as `curl http://127.0.0.1:7777/api/repos/<id>/dispatches`. **Naming check.** If `recall_dispatches` reads ambiguously next to the existing `recall_record_dispatch` and the `recall_dispatch_*` lifecycle tools, the alternative is `recall_list_dispatches`. Punt the naming call to implementation time.

coilysiren referenced this issue

2026-05-23 20:55:31 +00:00

dirty_tree: handle mixed real-vs-stat-stale modifications #76

coilysiren added the

label

2026-05-31 01:55:05 +00:00

coilysiren added

and removed

labels

2026-05-31 07:01:17 +00:00