I think this article is missing the point that MCP is simply using the mainstream building blocks that have already regressed from what we've had previously, namely, JSON in place of proper RCP.
The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things, so, it doesn't seem like a big deal that either one would be allowed in a JSON.
Honestly, my view that nothing of value ever gets published on medium, is strongly reinforced here.
Why would a hype protocol use outdated concepts instead of the hype JSON?
Wouldn't medical records actually be better in JSON, because the field could expressly have "kg" or "lb" suffix within the value of the field itself, or even in the name of the field, like "weight-in-kg" or "weight-in-lb"? This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer.
The biggest problem with medical data would probably remain the human factor, where regardless of the format used by the machines and by MCP, the underlying data may already be incorrect or not coded properly, so, if anything, AI would likely have a better chance of interpreting the data correctly than the API provider blindly mislabelling unitless data.
> This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer.
A field name doesn't turn an integer field into a unit of anything.
Suffixing a unit as part of the value only makes the field stringly-typed an complicates parsing.
BTW weight can take fractional values.
That might not matter much for a 125kg adult,
but it certainly matters for a newborn weighing 3.1kg.
And I bring up weight because I personally identified a unit conversion bug in a well-known medical records suite where a weight measured in pounds was displayed as kilograms.
A dose of opioids sufficient to relieve traumatic pain in a 125kg person would kill someone who weighs 125lb.
Medical record software is not in the move-fast-break-things category.
The fact that the model can recognize a Unix timestamp when it sees one doesn't really help you if it then tries to work around the API mismatch by helpfully converting the timestamp into a hallucinated ISO date.
The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things, so, it doesn't seem like a big deal that either one would be allowed in a JSON.
Honestly, my view that nothing of value ever gets published on medium, is strongly reinforced here.