Add a tool to list the 5 most recently MCP-interacted-with instances with live status

[proagentstore]

Feature request from a voice/chat session.

Problem: today, to see what my coding-agent instances are doing, I either have to already know the instance ID/nickname (direct lookup) or call my_instances, which dumps every subscribed agent I own (dozens, including non-coding ones) with no sense of what I actually touched recently. There is no way to get a quick 'what have I been working on lately, and what's the status of each' view in one call.

Request: add a tool (something like recent_instance_activity or list_recent_interactions) that:

1. Returns the 5 most recently interacted-with instances, where 'interacted with' means the caller (this user, via their MCP session) issued a tool call against that instance -- e.g. coding_loop_start, coding_loop_status, coding_session_message, call_instance_tool, chat_with_instance, etc. Not just whichever instance last ran on its own schedule.
2. For each of the 5, return in the same response: instance id, name/nickname if set, health (working/waiting/stalled/ended), status, stopReason, and waitingReason with its deadline if waitingReason is human.
3. Ordered most-recent-interaction first, so a new conversation can immediately resume context on whichever instance the user was just driving, without the user needing to name it.

Why: this lets a fresh conversation pick up previous work seamlessly -- ask 'what's going on' and get the real recent picture across the instances actually being worked on, instead of a static shortlist or a full unfiltered roster.

Currently the only paths are: (a) my_instances -- entire roster, no recency-of-interaction signal, includes non-coding agents; (b) coding_loop_status -- single instance only, must already know the id. Neither gives an at-a-glance 'last 5 I was actually working with' view.

[serge-ivo]

Delivered on main — 82d9ec9

What landed

A new always-on read tool, recent_instances, on the platform-wide MCP surface (workers/mcp/src/instance-tools/recent.ts). It answers "what was I working on?" for a fresh conversation that does not yet know an id:

• Returns the 5 instances this account drove most recently over MCP, newest interaction first.
• Each entry carries instanceId, name (display name when set), slug, status (the subscription's), lastInteractionAt, lastTool, and run — the instance's most recent autonomous run exactly as coding_loop_status reports it: runId, health (working/waiting/stalled/ended), status, stopReason, waitingReason, waitingUntil, waitNote, and an objective preview. run is null for an instance that has never run one; runError is present only when the run lookup itself was refused, so null is never mistaken for "never ran".
• health and waitNote are passed through from the API's own runHealth / waitClause (A run whose engine died at step 1 reported 'running' for 4.35 hours with a fresh lastProgressAt, and wrote nothing to the trace #580) — never re-derived on the MCP side. For a human park, waitNote states the deadline with the right verb (it is when the run gives up, not when it resumes).
• A caller with no recorded interactions gets {instances: [], hint} pointing at my_instances.
• SERVER_INSTRUCTIONS and platform_guide now name it beside my_instances, so a model discovers it at initialize.

How recency is tracked

The signal the issue asks for did not exist anywhere: audit() only writes on write/runtime/dry-run/denied/destructive events, and requirePermission only on a denial, so an hour of polling coding_loop_status left no row. This change records it and reads it back.

• Where: a touch hook on the registration pipeline (registration.ts), called after every call the suspension gate let through, with the tool name and the caller's raw arguments. Recorded at the pipeline seam rather than in the ~80 handlers that take an instance_id, for the same reason the gate lives there ([Admin] MCP repo/scaffold tools bypass the requireUser suspension gate #273): the next tool cannot forget it.
• What counts as an interaction: any call whose input names an instance_id (coding_loop_start, coding_loop_status, coding_session_message, call_instance_tool, chat_with_instance, …), and every call on a /mcp/i/<instance_id> pinned session (MCP: optional scoped single-instance connector/endpoint, additive to the existing platform-wide connector #783), where the instance is on the URL rather than in an argument. agent_id / supervisor_instance_id are deliberately not read. An instance's own scheduled activity does not count.
• Identity: keyed by the same subject audit() uses (subjectFor is now exported from safety.ts), so a scripted caller's per-call token is tracked as its own identity and an unverifiable token records nothing.
• Storage: no D1 change. One KV key per (subject, instance) — recent:{subject}:{instance} → {instance, tool, at} — in the existing OAUTH_KV namespace under its own prefix, 30-day TTL. Per-instance keys instead of one list per subject so concurrent calls cannot overwrite each other's entry. A per-session 30 s throttle keeps KV's one-write-per-second-per-key limit out of reach; a failed put is swallowed and never fails the call it rides on.
• Reading: recent_instances lists the prefix, sorts newest first, joins against the my_instances roster (drops cancelled instances, resolves a slug the way coding.ts's resolveId does, dedupes by resolved id), takes the top 5, and fetches each one's /loop listing in parallel.

Surface bookkeeping

• MCP_SERVER_VERSION 0.1.22 → 0.1.23 (new tool name + instructions moved); SURFACE_LOCK entry appended; server.json, the served manifest, and platform-docs/mcp.md follow.
• Tool counts: 151 total, 128 always-on, 23 surface-gated. MCP_RISK_COUNTS read +1; README table row, workers/mcp/CLAUDE.md layout, and every "N tools" claim updated (docs:drift clean). Contract table row added.
• File-size pins raised for index.ts (+5, reason recorded) and the ratchet itself.

Tests

• recent-instances.test.ts (new): recorder key/TTL, throttle per (subject, instance), no-op without instance/KV/subject, late-bound subject, swallowed KV failure, reader ordering and cross-subject isolation.
• instance-tools.test.ts: the join, the 5-cap, slug dedupe, cancelled-instance drop, newest-run pass-through, runError, empty hint, scope/read-only/auth/roster-error paths.
• index.test.ts: touches recorded through the real init() — instance_id call, no-id call, suspended account (nothing recorded), per-call token, pinned session, and read-back by recent_instances.
• Local: all MCP suites pass (413 tests); typecheck for every package, whole-tree biome, docs:drift, file-size, surface-lock --require-history, bare-catch, and MCP parity all green.

Two pre-existing local failures, unrelated

Both reproduce on a clean tree at 88c596c with this change stashed:

1. workers/api/src/lib/migration-hygiene.test.ts — runs check-migrations --require-history, which needs full git history; this checkout is a single squashed commit (CI checks out with fetch-depth: 0).
2. workers/host/src/admin-api-proxy.test.ts — fails to load workers/host/src/index.ts, which needs the node build.js artifact CI builds before pnpm test.

CI on 82d9ec9

Deploy MCP Worker ✅, Deploy Host Worker ✅, Publish MCP Registry ✅ (0.1.23). The CI workflow was still in progress at the time of this comment: https://github.com/ProAgentStore/platform/actions/runs/34308121295

Leaving the issue open for Serge to review.