Let hosts own independent client connections and cancel async calls
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Ambito
- api, backend-api-design
Direzione di ricerca
Inizia esaminando il registro client attuale e l’invocazione sincrona degli strumenti, quindi confronta le discussioni correlate in #86, #109 e #118. Il lavoro sarà completato quando sarà definito se gli host possono avere cicli di vita dei client indipendenti e annullare le chiamate asincrone, preservando la gestione esistente del trasporto e dell’annullamento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I’m looking at using mcptools with mcp-repl to give a Deputy agent an R or Python session that persists across tool calls.
In a Shiny app, I’d like two agents to keep separate interpreter state, even when both use the same server configuration. The host would own each connection, close it when the conversation ends, and let the user cancel a long-running call while the app stays responsive.
The current client registry identifies connections by configured server name. Loading that name again closes the previous connection, so I can’t use the name alone as the ownership boundary for two independent agents. Tool invocation also waits synchronously for the response; sending an R interrupt is useful, but doesn’t by itself give a Shiny host an asynchronous call it can cancel.
Would a client connection object with an explicit lifetime fit the direction of mcptools? I’d like to reuse its transport and cancellation handling, with mcp-repl continuing to own interpreter execution and reset behavior.
This seems related to #86 and #109. My use case is the client connection to an external server, rather than the server-side async handlers in #118. I’m tracking the Deputy work in JamesHWade/deputy#69 and JamesHWade/deputy#48.
- Lingua principale
- R
- Stelle
- 204
- Fork
- 23
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di posit-dev/mcptools
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Tutte le issue di posit-dev/mcptools
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 71/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
OHDSI/PatientLevelPrediction#688 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
rfordatascience/tidytuesday#1098 ·