fix(fastmcp): refuse an undeclared tool argument instead of dropping it

[ciaransweet]

An argument a tool does not declare is currently accepted, discarded, and never
mentioned. The tool then runs as though it had never been asked for.

langchain_mcp_adapters.to_fastmcp publishes the input schema from
tool_call_schema, but validates against a separate model built from that
schema's fields alone:

arg_model = create_model(f"{tool.name}Arguments", **field_definitions, __base__=ArgModelBase)

ArgModelBase sets no extra policy, so pydantic's default applies and the
extras are stripped before the tool is called.

That is a silent wrong answer rather than a loud failure: the call succeeds, the
result looks ordinary, and the one thing that would explain it — that an
argument went missing — is the one thing nobody is told. It is easy to hit
wherever a tool renames or reshapes a parameter that a model has seen named
another way somewhere else; the model sends the name it saw, and gets a
confident answer to a question it did not ask.

Two lines, both needed:

• extra="forbid" on fn_metadata.arg_model — the enforcement.
• additionalProperties: false on the published schema — what tells a client
  the rule exists. Upstream publishes no extra policy at all, so enforcing on
  its own would refuse calls the advertised schema allowed.

./scripts/test 375 passed, ./scripts/lint clean.

Behaviour change worth a look before merging: any caller that has been
sending a stray argument starts getting an error rather than being quietly
tolerated. That is the point, but it will surface wherever it has been
happening. It surfaces as a tool-call error result, not a raised exception —
the same path an argument with a wrong type already takes today — so the model
gets a ToolMessage it can act on and retries, and the thread stays
well-formed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqYYX2DusBMsnR58iDro1Y