{{ message }}
Repository navigation
[MCP host] Muse adapter does not forward MCP tool outputs (no viewers/archives) #59
Description
Parent: #53 (Phase B export step blocked). Follow-up of #58.
Observed
With bex-co/muse-code-acp 0.7.0, a completed MCP tool call reaches the coordinator as a tool_call event with:
- title namespaced as mcp____,
- rawInput = bare arguments (no {server, tool} envelope),
- NO rawOutput field,
- content = prose summary only (no artifact URIs).
The acpx session record keeps the same gap (tool_results content is empty Text). The agent itself sees the full result, so the export executes, but the host cannot capture tool results, archive export bytes, or build viewers. Viewers stay at 0 after a successful build123d_export turn.
Evidence: instrumented packaged-host run 2026-09-28 (CASYS_DEBUG_EVENTS, since removed).
Also noticed
bex emits reminderChild inProgress/completed pseudo tool calls that land as user-visible tool messages (noise, minor).
Acceptance
- Re-qualify the Muse adapter (newer bex or alternative) for MCP tool-output forwarding: a build123d_export turn through Muse must produce viewers + saved archives like the [MCP host] Complete the Build123d create, view, edit and export journey #52 Codex journey.
- Silence or filter non-tool pseudo calls (reminderChild) from the transcript.
- Then extend the first-build123d-result quickstart with the export step and close [MCP host] Download Casys and reach a saved Build123d result without manual Docker setup #53.
Activity
superWorldSavior commentedon Sep 28, 2026
Qualification result (2026-09-28):
Shipped meanwhile (fc2130c): the reminderChild noise filter (second acceptance item) — exact-prefix drop before transcript/capture, unit-tested, live-verified (0 reminderChild, real MCP tools intact).
#59 stays open, blocked on vendor (bex MCP tool-result forwarding). #53 export step stays blocked behind it.
superWorldSavior commentedon Sep 28, 2026
Cursor-agent qualification (2026-09-28, cursor-agent 2026.09.26, custom command profile, no code change): INCOMPATIBLE, worse than bex.
Conclusion: no agent swap fixes #59. bex stays (tools work, outputs missing). The relay tap + coordinator matcher remains the only host-side fix, and it is agent-agnostic.
superWorldSavior commentedon Sep 28, 2026
DEV bridge shipped (8684dfc), per direction: implement the tap, keep it dev-only, document the production limitation.
#59 proper fix still blocked on vendor (bex MCP output forwarding). #53 export step still pending behind it.
superWorldSavior commentedon Sep 29, 2026
Spike: can bex be adapted cleanly (no hacks) for modern MCP Apps? VERDICT: NO — impossible, the bytes don't exist on any muse surface.
Evidence (muse 1.4.0, bex 0.7.0 source + live runs):
What would unblock cleanly, in order: (1) Meta emits structured outputs/outputRefs again; (2) bex follows (version gate + forward); (3) acpx declares ext caps + exposes ext calls; (4) we call readOutput. Until then, the DEV relay tap stays the only working observation point, and the production limitation stands.
superWorldSavior commentedon Sep 29, 2026
Verdict spike Claude (CLI 2.1.284 + claude-agent-acp 0.84.0)
Claude expose et appelle nos outils, avec une exception bloquante cote provider.
Preuve bout-en-bout
(probes /tmp/claude-spike/, provider :3014 via proxy :3999).
Cause racine de l'invisibilite initiale
ToolSearch zero resultat, ni charges ni differes).
project_2d seul KO (0/1).
Consequence pour #59
correctement les outils valides.
normaliser le schema de project_2d en type: object au top-level.
que project_2d est servi tel quel). Le relay ne reecrit pas les contrats
provider, pas de filtrage contournement prevu.
Restes ouverts (pas testes ici)
a confirmer dans l'app.
superWorldSavior commentedon Sep 29, 2026
Spike turn export / viewers via Claude (adaptateur ACP 0.84.0)
L'adaptateur Claude transmet les outputs complets (contraire de bex)
mcp__build123d__build123d_export(Box 10x10x10,formats step) ->
tool_call_update status=completedavecrawOutputcontenant le JSON export complet : metrics (volume 999.9999999999998),
artefact STEP
casys://build123d/artifacts/26fa6bde....step(15379 octets)./tmp/claude-spike/acp-direct3.mjscontre proxy 3-outils :3999(sans project_2d, formes provider reelles, ni strip ni rewrite).
Mais le path normal du coordinator ne peut pas le consommer
rawInput/rawOutputverbatim (runtime.jsassignForwardedToolPayload).rawInput={server,tool,...}etrawOutput={result,error}(parseMcpRawInput/parseMcpRawOutput).rawInput= objet args,rawOutput= string JSON du resultat. Donc : normal path ignore,fallback tap en DEV, rien en prod. Meme sort que bex, pour une raison
differente (forme, pas absence).
En DEV, le tap attribue mecaniquement sous Claude
mcp__build123d__build123d_exportmatcheMCP_NAMESPACED_TITLE,rawInputobjet ->canonicalJsonmatche l'enregistrement relay(meme mecanique que bex, prouvee en 8684dfc). Viewers + turn export OK.
le relay sert les 4 outils, Claude droppe le serveur.
Fix prod propre, borne, in-repo (proposition)
mcp__server__tool+rawOutputstring JSON ->retain. Pas de tap,pas de relay, pas de changement provider. A chiffrer sur [MCP host] Download Casys and reach a saved Build123d result without manual Docker setup #53 (parcours
export) une fois le provider corrige project_2d.
superWorldSavior commentedon Sep 29, 2026
Fix provider applique : project_2d re-expose sous Claude (4/4)
Changement (repo mcp-build123d, non commite)
src/tools/projection-2d.ts:PROJECTION_2D_INPUT_SCHEMApasse deoneOftop-level atype: objectavec les variantesstep/stepResourceen proprietes optionnelles +includeSection, et unoneOf: [{required:[step]}, {required:[stepResource]}]imbrique.{step}xor{stepResource}, chacun avecincludeSectionoptionnel. La garde serveur pre-existante(
projection-2d-bridge.ts, "exactly one of step or stepResource") restel'enforcement.
tests/projection-2d_test.ts: assertions top-level object + proprietes,cas supplementaires (variantes avec/sans includeSection, rejet de
{includeSection}seul, rejet des deux variantes), nouveau test"enforces exactly one STEP variant server-side".
Verifications observees
deno test tests/projection-2d_test.ts: 7 passed, 0 failed.deno fmt --check+deno lintsur les 2 fichiers : verts.project_2dimportedu code modifie -> init expose
mcp__build123d__{execute,export,observe_assembly_integrity,project_2d}(4/4, contre 0/4 avant). Le
oneOfimbrique surrequiredpasse le CLI.Reste a faire cote provider
mcp-build123d.et parseur coordinator facon-Claude (proposition du commentaire precedent).
superWorldSavior commentedon Sep 29, 2026
0.7.1 publie : project_2d corrige en production
superWorldSavior commentedon Sep 29, 2026
Redeploiement 0.7.1 + parseur Claude : fait. E2E in-app : en attente quota
Redeploiement local 0.7.1 (fait)
launch groups (MCP_BUILD123D_071), observer pins, probe (identite +
fingerprint 28e6c8c9...), doc provider. Probe : current-surface.
Parseur coordinator facon-Claude (fait, d5b8a87)
#captureToolResultcapte desormais les events bruts : titremcp__serveur__outil + rawInput args + rawOutput string JSON (observe)
ou bloc texte unique (forme SDK). Formes inconnues : tap DEV ou rien.
Suite coordinator : 85 verts. Prod : plus besoin de tap sous Claude.
E2E in-app (bloquee : quota Claude epulse)
custom + mcp.ensure/enable + turn export.
(discover/tools/list vus), puis "session limit, resets 6:30pm Taipei".
inutile pour ce parcours.
superWorldSavior commentedon Sep 30, 2026
Revue indépendante du chemin MCP Apps/archives, le 30 septembre 2026, sur
0be84e7edba3c2f71f87d01867104039c048b3be, et vérification des sources amont actuelles. L'issue doit rester ouverte pour Muse. Deux problèmes distincts doivent garder des critères distincts.Côté fournisseur Build123d / Claude : le
oneOfau niveau racine debuild123d_project_2dfaisait refuser le serveur à Claude. Le pin local a été mis à jour vers Build123d 0.7.1 dansf1b62624, avec le schéma corrigé. Le coordinateur ajoute dansd5b8a87bla capture des événements Claude (mcp__server__tool, arguments directs, rawOutput JSON/texte). Les 104 tests ciblés coordinateur/relay/tap passent. C'est un progrès de compatibilité concret ; le dernier essai réel dans l'application est néanmoins arrêté par la quota Claude, donc aucune preuve finale de viewer/archive dans l'app ne peut encore être déduite de ces fixtures.Côté Muse / adaptateur ACP : le pin empaqueté est toujours
@bex-co/muse-code-acp 0.7.0. Vérification du registre npm : latest 0.7.0, publié le 26 septembre 2026 à 05:23:24 UTC, commite0cce00b, intégrité conforme au pin local. Les événements de cette version transmettent du texte borné et éventuellement les arguments, sans le rawOutput MCP complet attendu ici. ACP rend rawOutput optionnel : la seule présence d'un adaptateur ACP ne garantit pas la fidélité des résultats.Le README annonçant la lecture de sorties complètes ne démontre pas une correction plus récente : la documentation exacte de 0.7.0 qualifie une extension
_muse/readOutputsur Muse 1.2.1, avec une référence native disponible. La preuve publiée concerne des sorties shell. Elle précise que le mécanisme ne reconstitue pas les images/audio/ressources MCP aplatis ou omis ; le code vérifie précisément la version 1.2.1. Cela ne prouve pas les viewers/archives MCP sur le Muse 1.4.0 testé par Casys.Le tap de corrélation est toujours explicitement développement seulement, activé par
CASYS_DEV_RELAY_TAP=1; le parcours normal empaqueté ne le configure pas. Un succès obtenu avec ce tap doit rester identifié comme tel et ne clôt pas le comportement distribué.Suite attendue : obtenir et qualifier un chemin de production conservant le résultat MCP exact, les métadonnées App et les artefacts sous Muse, puis compléter #53. Si un mécanisme natif/extension est retenu, prouver ses références, son association à la bonne conversation/appel et le comportement d'absence de sortie. Ne pas remplacer implicitement l'acceptance Muse par Claude. #58 reste également ouvert sur le lancement et le changement d'agent ; #51 sur la conservation des identités des résultats.
Limites de cette revue : sources et tests déterministes, plus lecture des preuves existantes ; aucun nouveau tour LLM, appel fournisseur, changement de credentials ou modification du dépôt. PR #60 ouverte, non fusionnée ; main distant reste
94aaa037.superWorldSavior commentedon Sep 30, 2026
Implémentation reprise et validée le 2026-09-30. Changements dans le commit local, non poussé
070f66c8surcodex/desktop-mcp-host-reliability; ces preuves ne sont pas une livraison surmain.Le chemin de production observe maintenant la paire JSON-RPC exacte à travers une URL privée/revocable propre à chaque tour, sur le relais existant partagé. Cette URL est renouvelée à la reprise de la session ACP ; un résultat tardif d'un ancien tour ne peut plus être attribué au nouveau. Les cartes ACP restent textuelles et ne doublonnent pas les archives. Aucun flag DEV ni corrélation heuristique outil+arguments+temps n'est requis.
Tests : sessions concurrentes/appels identiques, annulation, retarget, reprise après échec préprompt, queue bornée et isolation passent. Une réponse >8 MiB est transmise intégralement sans capture ni fausse 502 ; le provider n'est exécuté qu'une fois. Le test du host empaqueté avec agent ACP sans rawOutput conserve deux révisions et leurs octets après restart.
Preuve réelle supplémentaire : paquet final Codex/ACPX + image Build123d 0.7.1, trois résultats, trois fichiers exportés sauvegardés et relus hors ligne. Les tours Muse réels restent distinctement non qualifiés.