Added RFC 6570 complaint form style query expansion as optional param…

[codecracker007]

Add RFC 6570 support for optional parameters as form-style query expansions

Motivation and Context

Adds optional parameter support with RFC 6570 compliance as form-style query expansions. This change addresses issue #378, .

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

[ihrpr]

Thank you for working on this!

This PR makes good progress toward RFC 6570 support by adding form-style query expansion.

There are a few suggestions:

1. Type Conversion for Query Parameters. Query parameters from URLs are always strings, but the code doesn't convert them to match function parameter
   types.

Example of the problem:

@server.resource("resource://items/{category}{?limit}")
def get_items(category: str, limit: int = 10) -> str:
    # When called with resource://items/books?limit=20
    # limit will be string "20" not int 20
    return f"Items in {category}, limit: {limit} (type: {type(limit)})"

Suggested fix: Add type conversion based on function annotations in

2. Handle Edge Cases in Query Parsing. The current implementation might not handle edge cases properly:

• Empty query values (?param=)
• URL-encoded values (?name=John%20Doe)

3. Add Tests for Type Conversion Scenarios

4. Consider Documenting Query Parameter Behavior

[codecracker007]

@ihrpr thanks for the feedback

during the fn call with params result = self.fn(**params)

can i use call_fn_with_arg_validation

python-sdk/src/mcp/server/fastmcp/utilities/func_metadata.py

Line 45 in f2f4dbd

async def call_fn_with_arg_validation(

for type validation and conversion and should i fallback to default values for optional parameters if validation fails for any one of them

[codecracker007]

@ihrpr the pydantic validate_call already takes care of the compatible type conversion based on annontated parameters for query parameters and raises validation error for incompatible types added a decorator which check if the validation error is raised by optional parameters and ignores them so they fall back to default values to keep it compliant

added relevant tests covering these cases

for the cases in query parsing the empty values and url encoded parameters are handled by parse_qs added relevant tests covering these

[felixweinberger]

Apologies for the delay in coming back to this - there seem to be some failing tests & merge conflicts, would you be able to resolve?

I'll prioritize responding quickly if you have the bandwidth to update the PR here.