fix(server): forward tool args under the real parameter name, not the…

[jayzuccarelli]

Forward tool arguments to the underlying function under the real parameter name instead of the schema alias.

Motivation and Context

A tool parameter with an explicit alias, e.g. city: Annotated[str, Field(alias="location")], is advertised in the tool input schema as location, and clients send location. At call time model_dump_one_level forwarded the value under the alias, so the function was invoked as fn(location=...) and raised TypeError: got an unexpected keyword argument 'location'. Both sync and async tools are affected.

The root cause is that field_info.alias is used as the kwarg name, but the alias is a wire name, not necessarily a valid Python parameter. It happens to be correct for the internal shadow-rename case (a param named after a BaseModel attribute, e.g. schema -> field field_schema with alias="schema"), where the alias is the real param name — so the two cases are indistinguishable from FieldInfo alone.

The fix records each field's real Python parameter name at metadata-build time and forwards arguments under it. The shadow-rename case keeps working because its real name is recorded the same way. Resolver arg-name matching in tools/base.py reads the same map so by-name resolvers keep resolving.

How Has This Been Tested?

Added a regression test (test_call_with_aliased_parameter) that fails before the change with the TypeError above and passes after. Repro:

from typing import Annotated
from pydantic import Field
from mcp.server.mcpserver.utilities.func_metadata import func_metadata

def tool(city: Annotated[str, Field(alias="location")]) -> str:
    return city

meta = func_metadata(tool)
# input schema advertises "location"; a client sends {"location": "Paris"}
# -> TypeError: got an unexpected keyword argument 'location'

Full tests/server/mcpserver/ suite passes locally (552 tests), along with ruff, pyright, and strict-no-cover.

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