jsonschema reporting type "object" that should be "string" for nested time.Time struct

[iwyrkore]

Describe the bug
A struct containing an embedded time.Time is reported by jsonschema to be of type object but it gets marshalled to JSON as string.

To Reproduce
Steps to reproduce the behavior:

1. Create a tool:

type MyDate struct {
	time.Time
}

type MyToolArgs struct {
	Date MyDate `json:"date" jsonschema:"The date"`
}

type MyToolResponse struct {
	Date MyDate `json:"date" jsonschema:"The date"`
}

var MyTool = mcp.Tool{
	Name:        "MyTool",
	Description: "My tool",
}

func MyToolHandler(
	ctx context.Context,
	req *mcp.CallToolRequest,
	args MyToolArgs) (*mcp.CallToolResult, *MyToolResponse, error) {
		return &mcp.CallToolResult{
			Content: []mcp.Content{&mcp.TextContent{Text: "Hello, world!"}},
		}, &MyToolResponse{Date: args.Date}, nil
}

2. Look at the JSON:

	myToolArgs := MyToolArgs{
		Date: tools.MyDate{Time: time.Date(2023, 11, 7, 0, 0, 0, 0, time.UTC)},
	}
	jsonBytes, err := json.Marshal(myToolArgs)
        fmt.Println(string(jsonBytes))

   // output: {"date":"2023-11-07T00:00:00Z"}

3. Look at the schema:

{"description":"My tool","inputSchema":{"type":"object","required":["date"],"properties":{"date":{"type":"object","description":"The date","additionalProperties":false}},"additionalProperties":false},"name":"MyTool","outputSchema":{"type":"object","required":["date"],"properties":{"date":{"type":"object","description":"The date","additionalProperties":false}},"additionalProperties":false}}

Expected behavior
Schema would contain type "string" for "date"

(This example may seem a bit contrived but the real-world MyDate marshals to a "YYYY-MM-DD" format with the same problem.)

[unbekanntes-pferd]

I have the same issue with union types:

type IntOrString struct {
    IntValue: *int,
    StrValue: *string
}

type Foo {
    Bar: InOrString `json:"bar"`
}

I assume this is an issue with jsonschema analogue to #437 - nested fields are ignored and jsonschema always relies on the struct definition.
My current workaround (as with #437) is creating a custom json schema.
I'd really like to remove custom generated json schemas if possible, as it is additional code to maintain.

[iwyrkore]

I have the same issue with union types:

type IntOrString struct {
IntValue: *int,
StrValue: *string
}

type Foo {
Bar: InOrString json:"bar"
}
I assume this is an issue with jsonschema analogue to #437 - nested fields are ignored and jsonschema always relies on the struct definition. My current workaround (as with #437) is creating a custom json schema. I'd really like to remove custom generated json schemas if possible, as it is additional code to maintain.

Nested structs are now flattened properly in 0.5.0 but unions seem like they would be problematic to detect from the Go struct.

[findleyr]

Indeed, I suppose we need to check whether the receiver of the UnmarshalJSON method is a *time.Time. When we decide to sustitute known schema.

I.e. check the method identity, not the type identity.

[findleyr]

@unbekanntes-pferd: does your IntOrString type have a custom JSON marshaller?

If so, you should be able to pass just one custom schema to jsonschema.ForOptions.TypeSchemas, and let inference do the rest.

[findleyr]

Having looked into this more:

1. There's no good way to achieve this automatically, and
2. There's no obvious semantics that works in all cases.

Regarding 1: reflection creates a wrapper around promoted methods, where the receiver is MyDate in your example (stackoverflow reference). Therefore, any attempt to automatically detect that MyDate will marshal and unmarshal like a time.Time is bound to be problematic: if you defined your own custom UnmarshalJSON and MarshalJSON methods, it would be very hard/buggy for us to detect the correct receiver.

Regarding 2: right now, jsonschema.For does not differentiate whether the schema is an input schema or an output schema, but you can imagine that it matters! If it's an input schema, we need to look for UnmarshalJSON methods. If it's an output schema, we need to look for MarshalJSON methods. We can't know which of those is important for matching receivers (even if that was possible, but see 1: it's not).

Therefore, the solution is to pass a custom schema for MyDate in ForOptions.TypeSchemas, to effectively tell inference that MyDate marshals like a string. That is explicit, readable, and reliable, so I think it's the best solution. As described above, if we were to do anything more magical than this, it would be brittle and error prone.

I'll close this issue with an example that illustrates how to do this correctly.