Clarify docstring for Context implicit injection in Resource functions

[sam-tombury]

Resource functions do not (currently) support context injection, but support is implied by the current Context docstring. This change updates the docstring to accurately reflect the current implementation.

Motivation and Context

Lack of clarity in documentation. Developers may try to implicitly inject context into @resource-decorated functions following the current documentation and encounter surprising errors.

How Has This Been Tested?

Documentation only

Breaking Changes

None

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

Context injection support for resource functions (as is the case for tools) would be very nice to have, but there seems to be some complexity in how that interacts with the concept of concrete/direct resources vs resource templates. In particular, a resource function might accept only a Context param, for example if it lists all objects that a (contextual) user can access. Reading through the code, it appears that concrete resources are already lazy - so we could consider Context-only resources as concrete/direct and thread through the context in the read method. I'm happy to add a follow-up issue and work towards implementing that if there's interest.

[ihrpr]

Thank you for flagging, there is an ongoing PR to add support, we can move the conversation there

#413

[sam-tombury]

Awesome, thanks for pointing that out. I'll add a comment there about the interaction with concrete/direct resources and resource templates