Allow configuring additionalProperties on generated tool schemas

Problem

mcp.AddTool generates JSON schemas from Go structs via jsonschema-go, which sets additionalProperties: false on all object types. This means tool inputs that include extra fields (common in protocol envelopes) are rejected at schema validation before reaching the handler.

Use case

The Ad Context Protocol (AdCP) sends protocol-level fields like adcp_major_version alongside tool arguments. These fields are not part of any individual tool's schema but are part of the protocol envelope. The strict additionalProperties: false rejects these requests.

Current workaround

We use the low-level server.AddTool with a manually-patched schema:

schema, _ := jsonschema.ForType(reflect.TypeFor[MyInput](), &jsonschema.ForOptions{})
// Walk schema tree and set AdditionalProperties = nil on all objects
server.AddTool(&mcp.Tool{InputSchema: schema, ...}, rawHandler)

This works but loses the typed handler benefits of mcp.AddTool.

Proposed solution

Either:

1. Add AllowAdditionalProperties bool to jsonschema.ForOptions (upstream in google/jsonschema-go)
2. Add a SchemaOptions parameter to mcp.AddTool that allows configuring schema generation
3. Allow overriding the generated schema on the Tool struct even when using the generic AddTool

Option 1 is the cleanest since it fixes the root cause.

Context

• AdCP Go SDK: https://github.com/adcontextprotocol/adcp-go/pull/27
• The workaround is in adcp/addtool.go — allowAdditionalProperties() function

Start with mcp.AddTool and the jsonschema.ForType call described in the issue, then inspect the allowAdditionalProperties() workaround in adcp/addtool.go. Compare the proposed jsonschema-go, SchemaOptions, and Tool override approaches, and check the referenced adcp-go pull request for requirements. Done means typed handlers can accept configurable additional properties without manual schema patching.