Issues with dates

[james2doyle]

It looks like the code tries to sniff fields that are supposed to be dates. I can't seem to get these to pass the validation.

What exactly is date-time format?

[lroot]

What exactly is date-time format?

Its way way to use letter characters to represent specific date formatting options. For example:

$now = new DateTime();
echo $now->format('Y-m-d H:i:s'); // 2025-05-10 01:29:05

See https://www.php.net/manual/en/datetime.format.php

[CodeWithKyrian]

Hi @james2doyle ,

You're correct, our current SchemaGenerator can be a bit too eager in inferring the format: date-time for string parameters if the name includes date. This then requires the input to be a strict RFC3339 date-time string (e.g., YYYY-MM-DDTHH:MM:SSZ or YYYY-MM-DDTHH:MM:SS+HH:MM).

What is format: "date-time"?

As per the JSON Schema specification (and RFC3339, which it typically follows), a string instance is valid against format: "date-time" if it is a "date-time" as defined by RFC 3339, section 5.6.

This means it expects a full date and time representation, including:

• A specific date (e.g., YYYY-MM-DD)
• The letter T as a separator
• A specific time (e.g., HH:MM:SS)
• Optionally, a fractional second part (e.g., .123)
• Optionally, a UTC offset (e.g., Z for UTC, or +HH:MM / -HH:MM)

Valid examples you provided:

• "1970-01-01T10:05:08" (Assumes local time or needs context if no offset)
• "1970-01-01T10:05:08.10"
• "1970-01-01T10:05:08Z" (UTC)
• "1970-01-01T10:05:08+01:00" (With offset)

Invalid example:

• "Jan. 1st, 1970 at 1 pm" (This is human-readable but not RFC3339 compliant)

The current auto-inference for date-time (and email, uri) was an attempt to provide some out-of-the-box semantic validation but yeah, it's imperfect without more context or explicit instruction from the developer.

For now, the best approaches are:

• Ensure the client sends the date string in a full RFC3339 date-time format if the server's schema for that tool parameter indicates format: "date-time".
• Alternatively, if your PHP method only needs a simple date string (e.g., YYYY-MM-DD), you could rename the parameter to something that doesn't include "date" (like $eventDay) to avoid this specific auto-inference. The parameter would then be treated as a plain string by MCP, and you can parse/validate it as needed in your method.

I know this isn't ideal, and I'm working on improving how these string formats are handled and allow for more developer control over the generated schema in the upcoming v2.0.0 release (or a v2.x release)

[james2doyle]

Great, thanks for all the info. I was struggling to find what the actual format was and which RFC it was actually following. I know this is a relatively new project so the documentation might not be fully available for these things. I did end up renaming my field. I just used the "_at" convention for the arguments

…

On Sat, May 10, 2025, 3:55 a.m. Kyrian Obikwelu ***@***.***> wrote: *CodeWithKyrian* left a comment (php-mcp/server#4) <#4 (comment)> Hi @james2doyle <https://github.com/james2doyle> , You're correct, our current SchemaGenerator can be a bit too eager in inferring the format: date-time for string parameters if the name includes date. This then requires the input to be a strict RFC3339 date-time string (e.g., YYYY-MM-DDTHH:MM:SSZ or YYYY-MM-DDTHH:MM:SS+HH:MM ). *What is format: "date-time"?* As per the JSON Schema specification (and RFC3339, which it typically follows), a string instance is valid against format: "date-time" if it is a "date-time" as defined by RFC 3339, section 5.6 <https://tools.ietf.org/html/rfc3339#section-5.6>. This means it expects a full date and time representation, including: - A specific date (e.g., YYYY-MM-DD) - The letter T as a separator - A specific time (e.g., HH:MM:SS) - Optionally, a fractional second part (e.g., .123) - Optionally, a UTC offset (e.g., Z for UTC, or +HH:MM / -HH:MM) *Valid examples you provided:* - "1970-01-01T10:05:08" (Assumes local time or needs context if no offset) - "1970-01-01T10:05:08.10" - "1970-01-01T10:05:08Z" (UTC) - "1970-01-01T10:05:08+01:00" (With offset) *Invalid example:* - "Jan. 1st, 1970 at 1 pm" (This is human-readable but not RFC3339 compliant) The current auto-inference for date-time (and email, uri) was an attempt to provide some out-of-the-box semantic validation but yeah, it's imperfect without more context or explicit instruction from the developer. For now, the best approaches are: - Ensure the client sends the date string in a full RFC3339 date-time format if the server's schema for that tool parameter indicates format: " date-time". - Alternatively, if your PHP method only needs a simple date string (e.g., YYYY-MM-DD), you could rename the parameter to something that doesn't include "date" (like $eventDay) to avoid this specific auto-inference. The parameter would then be treated as a plain string by MCP, and you can parse/validate it as needed in your method. I know this isn't ideal, and I'm working on improving how these string formats are handled and allow for more developer control over the generated schema in the upcoming v2.0.0 release. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK37GGHM4Q4QHOOSCJNSKL25XLL3AVCNFSM6AAAAAB4QHZCQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRYG42DEOJRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[CodeWithKyrian]

Hey @james2doyle — just a heads up that the latest release, v2.1.0, is now live and it introduces support for adding extra metadata to string types via a new #[Schema] attribute. For example, you can now specify formats like this:

#[Schema(format: 'email')]
string $email

Let me know if you run into anything or have suggestions!

[james2doyle]

@CodeWithKyrian Great! Thanks for the update