modelcontextprotocol / modelcontextprotocol/modelcontextprotocol

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

Open
#910 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
9.3k
Forks
1.8k
Avg merge
1d 12h
Merged PRs (30d)
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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the specification sections covering progress notifications, resource subscriptions, and tools/list, then compare how they describe clients, hosts, and LLMs. Done means the specification clearly states what hosts should do with client-received messages and how that information may reach the LLM and end user.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.