Allow function argument to be excluded from the tool's JSON schema

[martina-zxy]

Add client_provided_arg_model to FuncMetadata to allow certain arguments to be excluded from the JSON schema. This creates a cleaner interface for LLMs while still providing the necessary context at execution time.

Motivation and Context

With the current implementation, all function arguments are included in the JSON schema when list_tools is called, which prompts the LLM to provide values for all arguments when calling the tool. This can be limiting in scenarios where some arguments are intended to be provided by the client at execution time rather than being part of the LLM’s input. For example, if a tool requires a customer ID or session token the LLM should not be prompted to provide these values.

This solves #375

How Has This Been Tested?

Unit tests have been added to verify the changes are working.

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

[mcp-shadow]

Thank you for your contribution addressing issue #375. While we appreciate the effort to solve the problem of client-provided context for tools, this implementation adds significant complexity through a new argument classification system.

1. Unnecessary complexity: The implementation adds significant complexity to the argument handling system. This will increase maintenance burden and potential for bugs.

2. Alternative solutions exist: The SDK already has a Context object that can be used to pass client-specific information to tools. This existing mechanism could be enhanced rather than creating an entirely new argument classification system.

3. Inconsistent mental model: Creating two types of arguments (LLM-visible vs client-provided) creates confusion around the execution model. It's less clear where argument values come from and what the boundaries of responsibility are.

4. Protocol deviation: The MCP protocol works best when tools have a clear, consistent interface. This change introduces a "hidden" part of the interface that isn't visible in the schema, potentially causing confusion.

5. Testability concerns: Tools with "hidden" arguments are more difficult to test since their behavior depends on implicit inputs not visible in their signature.

[mikeedjones]

@mcp-shadow The SDK's Context object can't be used to retrieve arguments from the request which were not generated by the LM. Your proposal alternative solution does not resolve the issue.

The tools do not have hidden arguments, the LM is just not prompted to generate those arguments which should be provided by code.

This is a significant issue with MCP and a real solution is required.

[samirbajaj]

This is a significant issue with MCP and a real solution is required.

+1