#29826 MCP gateway: make ListResourcesResult.resources tolerant of missing field (upstream spec violations)
## Summary LiteLLM's MCP gateway parses upstream `resources/list` responses into a Pydantic `ListResourcesResult` model where `resources` is required. Some real-world MCP servers respond with `{}` (missing the field) when they have no resources. The parse fails:
``` ValidationError: 1 validation error for ListResourcesResult resources Field required [type=missing, input_value={}, input_type=dict] ```
This is technically the upstream's bug (the MCP spec requires `resources` in the response), but in practice a couple of widely-used servers ship like this (e.g., smith-and-web/obsidian-mcp-server). Tolerating the omission would let federation continue even when an upstream is non-compliant.
## Reproduction Federate any MCP server that returns `{}` on `resources/list`. We hit it on: - `smith-and-web/obsidian-mcp-server:v1.3.1` (issue filed there: smith-and-web/obsidian-mcp-server#21)
## Impact Every federating client that does a probe (`/v1/mcp/tools` or per-server initialize fan-out) waits ~30s per misbehaving upstream before the gateway returns.
## Suggested fix In whichever file defines `ListResourcesResult` for the MCP gateway: change `resources` to default to `[]` when missi…