Inter-process schema validation cache

[dvisockas]

#363 introduced a in-process schema validation cache. The problem with this approach is that when the MCP server boots - the cache is stale and needs to be warmed, which might not always be trivial to do.

Could we extract the default cache implementation and allow users to configure a different cache store, say for an inter-process long lived cache?

MCP.configuration do |config|
  config.schema_validation_cache = FileBasedSchemaCache.new
end

Happy to put up a PR just want to align on the approach first

[dvisockas]

Example of how this could look like: https://github.com/modelcontextprotocol/ruby-sdk/compare/main...dvisockas:mcp-ruby-sdk:dvisockas/schema-cache-configuration?expand=1

[koic]

Thanks for the follow-up.

I'd rather hold off on pluggable cache backends for now. The cost we're recovering is relatively narrow (~32-100ms per distinct schema, paid once per process), which long-lived servers only pay once after boot.

Exposing a SchemaCache interface would also be a long-term API commitment, and persistent caches introduce correctness concerns: entries would need invalidation whenever the validator or metaschema dialect changes, otherwise stale results could silently bypass validation.

If the practical concern is simply that 1000 entries is not enough, a small MCP.configuration.schema_validation_cache_size knob would address that with much less API surface. That said, while such an option could be worth adding given a concrete use case, there does not seem to be a clear need for it at the moment.

[dvisockas]

The practical concern is not the entry size, but the time needed to warm the cache when you don't know schemas before hand. If you have 10 clients that each have schemas and 100 processes - it will take 1,000 requests to warm the schemas. And this will be lost on any deployment

[koic]

Fair point, the warming cost compounds across deploys here.

I agree that repeated warming across clients, processes, and deploys can add up. My impression, though, is that the main concern raised by this issue is the cost of JSON Schema validation itself. In that sense, a persistent cache helps avoid repeating the work, but doesn't reduce the underlying cost of validation.

To address that directly, I've opened PR #369, which replaces the underlying JSON Schema library and improves validation performance by roughly 5x to 100x.