modelcontextprotocol / modelcontextprotocol/modelcontextprotocol
Specification should be more prescriptive about client/host/LLM behavior
Personne n'a encore pris cette issue.
- Langage dominant
- TypeScript
- Étoiles
- 9.3k
- Forks
- 1.8k
- Merge moyen
- 1 j 12 h
- PR mergées (30 j)
- 25
Description
Is your feature request related to a problem? Please describe.
The spec tends to speak a lot about the client, a little bit about the host, and hardly anywhere about the end user. This leaves a lot of uncertainty for some capabilities. I frankly don't know what is expected when it comes to what the client receives and what the host passes on to the LLM. For instance, regarding progress notifications, a reasonable position is that this is a "UI-facing" feature, for hosts to provide a richer UI to the end user (e.g. a progress bar) - I'm not aware of any statement for or against including this information into the LLM's context. Unfortunately, I would argue the same is true of resource subscriptions (maybe the least utilized capability of all). As a user, if I elect to subscribe to a resource modification notification, I would like the LLM to be able to incorporate this information into its context - but this isn't really discussed anywhere that I know of.
Describe the solution you'd like
The specification focuses on server-client interactions, but the whole point is surely to serve the LLM, which is supposed to serve the end user. I'd like to know more about what the host is going to do with the messages that the client receives. I think the authors should consider being slightly more prescriptive about the behavior of hosts vis a vis LLM's. For example, a capability to send a tools/list message will result in the client receiving some data - but I don't know if there is anything explicit about whether the host is even obligated to inform the LLM(!). Maybe it's a lazy host and sometimes it chooses not to pass on the data (or all the data) to the LLM - is this application compliant with MCP?
I know this is a little vague and wide-scope, but I hope the general issue I'm trying to raise is clear enough.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par examiner les sections de la spécification qui couvrent les notifications de progression, les abonnements aux ressources et tools/list, puis comparez la manière dont elles décrivent les clients, les hosts et les LLMs. Le travail est terminé lorsque la spécification indique clairement ce que les hosts doivent faire des messages reçus par les clients et comment ces informations peuvent parvenir au LLM et à l’utilisateur final.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Domaine
- documentation
- Type d'issue
- Documentation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100