MCP: coding_repos_list returns mismatched instanceId, plus intermittent tool-registration/schema loop

[proagentstore]

Summary

Two distinct faults observed via the PAGS MCP server on 16 Aug 2026.

---

Fault 1 — Wrong instance attribution in coding_repos_list

Calling coding_repos_list with a specific instance_id returned repo records whose instanceId field belonged to a different instance than the one requested.

Observed across five concurrent calls for instances:

• f5e577a7-7147-443b-a491-795f1582544d
• 0f75dc66-b1f4-46df-898a-429868d39f45
• 5ef85042-e270-429d-8eb4-dd1d8d4fbbf6
• 00b91906-6613-4ef1-b16b-0fc1b3d097d1
• 73c4aced-d7a3-4dc4-84fc-48fe7c284d09

Each response carried a repo tagged to a different instance in the batch. Sequential single calls appear self-consistent, so the suspect mechanism is response routing/correlation under concurrency — replies from one request being delivered to the wrong concurrent caller.

Impact: Callers cannot trust which instance owns which repo, blocking automated rename or cleanup workflows.

---

Fault 2 — Intermittent tool-registration / schema loop

Tools that worked earlier in the same session became uncallable mid-session, cycling through the following error sequence:

1. "has not been loaded yet" — with a valid schema echoed back in the error
2. "tool not found"
3. "not registered"
4. Rejection of a call using the exact parameter names from the schema the error itself supplied

Affected tools: coding_repos_list and chat_with_instance — pointing to the MCP layer rather than a fault in any individual tool.

Additionally, tool naming flipped mid-session between two forms:

• mcp_<uuid>_<name>
• ProAgentStore:<name>

---

Steps to reproduce (Fault 1)

1. Issue five concurrent coding_repos_list calls, each with a distinct instance_id from the list above.
2. Inspect the instanceId field on each returned repo record.
3. Observe that the instanceId in the response does not match the instance_id passed in the request.

Steps to reproduce (Fault 2)

1. Open an MCP session and call any tool successfully.
2. Continue calling tools in the same session; observe intermittent "not loaded / not found / not registered" errors even for tools called successfully moments before.
3. Note that the error messages themselves echo a valid schema, yet a call using those exact parameter names is also rejected.

---

Environment

• Date observed: 16 Aug 2026
• Server: PAGS MCP server
• Both faults reproducible in the same session

---

Related

• A coding instance can push to and open PRs on any repo the user can reach, not just its registered one #676 (credential scope visibility)

[proagentstore]

3. No MCP tool to remove a repo from a coding instance

A third gap found in the same session:

The MCP surface exposes coding_repo_add and coding_repos_list but no coding_repo_remove / coding_repo_detach. There is a remove_repo tool, but it applies to repo-chat vector ingestion, not coding-instance bindings — so it doesn't help here.

Consequence: a repo attached in error can only be cleaned up in the console. The same automation that created a binding cannot undo it. Concrete cases motivating this:

• Instance 55f5f034-3243-4203-bd06-0e5019922afe ("FAGS Platform coder") carries a stray GitHub binding to proagentstore-online/platform, an org the user does not own. The correct repo FreeAgentStore/platform has since been attached alongside it, but the wrong binding cannot be removed via MCP.

• Instance 3cbb1d1d-5e6d-418f-8917-19e955707468 ("Parents Clubs coder") holds two local bindings with absolute /Users/serge-ivo/... workdirs that no longer exist on disk (cloneStatus: needs_attention), plus an obsolete apps/school-clubs entry — all three are stuck and unremovable via MCP.

Requested tool: coding_repo_remove (or coding_repo_detach) accepting instance_id plus repo id or name.

---

Addendum on fault #2 (tool-registration/schema loop): the loop is reliably worked around by retrying the identical call unchanged. This points to a registration/caching race rather than a validation problem — the retry succeeds without any change to parameters or schema.

[serge-ivo]

Resolution

Part 1 fixed — commit 759978f.

What was wrong

coding_repos_list made a correctly-scoped API call but had no defence against the MCP transport layer mis-routing a concurrent response. When five concurrent calls each asked for a different instance, the transport could deliver response B to the caller who asked for instance A — so the returned repos would carry instanceId: B against a request for instance_id: A. The tool had no way to detect or reject that.

Additionally, API errors (404 for stale/wrong instance ids) were silently collapsed to {repos:[]} rather than surfaced to the caller.

What the fix does

1. Extracted a pure function filterReposByInstance(repos, instanceId) that drops any repo whose instanceId field does not match the requested instance. In the normal single-request path every repo already carries the correct instanceId, so the filter is a no-op. Under concurrent mis-routing it returns empty rather than leaking the wrong instance's repos.

2. Added an explicit r.error check before consuming the repos, so API errors surface as the actual message rather than as empty repos.

3. Added instanceId?: string to the CodingRepoRow interface (the field was returned by the API but not typed).

4. Five unit tests pin the filter contract: matching pass-through, mismatching filtered out, mixed-response partial filter, no-instanceId defensive pass-through, and empty input.

Part 2 — tool-registration / schema loop

This is the same root cause as #759 ("has not been loaded yet, retry with exact parameter names"). That ticket is the canonical one and carries more context. Leaving this issue open until #759 is resolved (or until it's confirmed #759 covers the full symptom set). The retry-succeeds characterisation, the self-contradicting error message, and the occurrence on first touch of any tool in a session are all documented there.