modelcontextprotocol / modelcontextprotocol/modelcontextprotocol

Specification should be more prescriptive about client/host/LLM behavior

Ouverte
#910 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

enhancement
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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. 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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.