Skip to content

Make ResourceTemplate list callback optional #566

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kentcdodds
Copy link

This removes the | undefined in exchange for optional because forcing the inclusion of list is unnecessary and confusing.

Motivation and Context

list is not a MUST in the spec and having to specify list is annoying. Sometimes listing all resources is not feasible or possible.

The note in the comment suggests it's here to help people not forget to include it, but I do not think this is sufficient reason to force its inclusion all the time. If people forget, then listing won't work and they'll figure out why.

How Has This Been Tested?

In my epicshop mcp server, I edited the type changes locally and it works as expected. All of these are typesafe:

new ResourceTemplate('epicshop://{workshopDirectory}/workshop-context')
new ResourceTemplate('epicshop://{workshopDirectory}/workshop-context', { list: undefined })
new ResourceTemplate('epicshop://{workshopDirectory}/workshop-context', { list: async () => { /* ... etc... */ } })

Breaking Changes

No breaking changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

Related discussion: modelcontextprotocol/modelcontextprotocol#586

This removes the `| undefined` in exchange for optional because forcing the inclusion of `list` is unnecessary and confusing.

modelcontextprotocol/modelcontextprotocol#586
*/
list: ListResourcesCallback | undefined;
list?: ListResourcesCallback;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is interesting, i need to read the code more to grok what's going, but i see that foo: bar | undefined is frequently preferred over the usual foo?: bar here, and I suspect it's intentional, and my current guess is it has to do with zodToJsonSchema, where this is a distinction with a difference, apparently, because in the generated JSONSchema, list will be included in "required" if you use the bar | undefined syntax, whereas it will not be required with the foo?: syntax... I don't know how all these pieces fit together, and my interpretation does not comport well with the the comment about forgetting things, but my suspicion is there is (or was thought to be) a good reason for this. So far I haven't found how JSONSchema is used in this repo, maybe there is validation against schema.ts to check compliance(?). Obviously someone more directly involved in writing this should probably weigh in but without further context about the issues discussed above, I don't think it's so simple.

Copy link
Author

@kentcdodds kentcdodds May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, the way it is currently, you have to include the callback object with a list property even if you can't list your resources and you must set it to undefined.

@jspahrsummers was the original author of this code, and no explanation was given other than the comment in the code. I do not think other SDKs have this same requirement. But in any case, I don't think supplying an undefined callback should be required.

Copy link

@hesreallyhim hesreallyhim May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, the way it is currently, you have to include the callback object with a list property even if you can't list your resources and you must set it to undefined.

Right, so from what I gleaned, this makes a difference if you use something like zodToJsonSchema, because it means the schema will put "list" in the "required" properties array (even if the value is undefined, which I'm not sure if that's recommended anyway). But, either way, you can see this style repeated in the file, so it appears deliberate to me, so I'll just defer to someone who's more intimate with the codebase. But in any case, I hope you see my point, I just don't know how zodToJsonSchema is being leveraged in this repo.

EDIT: If I had to speculate (which I don't), I'd guess it might enable you to generate a JSONSchema and then validate it against the protocol's JSONSchema...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants