An AI Catalog entry can point at another catalog rather than at an artifact: per the specification's Composability goal, "a catalog entry can have a type of application/ai-catalog+json". Hosts can use this to organize by team, product line, or business unit rather than flattening everything into one document at the domain root.
We do not currently account for this. A consumer that fetches a catalog, filters for application/mcp-server-card+json, and stops will silently find nothing on any domain that organizes by nesting — including the shapes the spec itself uses as worked examples.
Resolving nested catalogs is not just "recurse." The spec attaches two requirements:
- Depth limit. "Clients processing nested catalogs SHOULD impose a maximum nesting depth to prevent circular references. A depth limit of 4 is RECOMMENDED. Implementations MAY support deeper nesting but SHOULD document their limit." (See also ADR-0001.)
- Cycle tracking. "Clients SHOULD track the set of catalog URLs visited during recursive resolution and reject any catalog URL that has already been fetched in the current traversal path." This lives in the spec's Security Considerations — unbounded traversal is a denial-of-service vector, not just a correctness bug.
Scope
- SDK reference implementations — recursive resolution with a documented depth cap and a visited-URL set.
docs/discovery.md — document nested entries in the client discovery flow, and add the depth/cycle requirements to Security Considerations alongside the existing denial-of-service guidance.docs/best-practices.md — currently describes a single flat catalog. Update once the above lands.
Relationship to #43
Same shape: both are places where the AI Catalog spec supports something broader than the flat, well-known-path-only model this extension documents and implements today. Worth deciding whether they land together, since both change what "resolve a catalog" means for a consumer.
Not urgent
A single flat catalog at the well-known path is the common case, and nothing is blocked on this. Filing so the gap is tracked rather than rediscovered.
An AI Catalog entry can point at another catalog rather than at an artifact: per the specification's Composability goal, "a catalog entry can have a
typeofapplication/ai-catalog+json". Hosts can use this to organize by team, product line, or business unit rather than flattening everything into one document at the domain root.We do not currently account for this. A consumer that fetches a catalog, filters for
application/mcp-server-card+json, and stops will silently find nothing on any domain that organizes by nesting — including the shapes the spec itself uses as worked examples.Resolving nested catalogs is not just "recurse." The spec attaches two requirements:
Scope
docs/discovery.md— document nested entries in the client discovery flow, and add the depth/cycle requirements to Security Considerations alongside the existing denial-of-service guidance.docs/best-practices.md— currently describes a single flat catalog. Update once the above lands.Relationship to #43
Same shape: both are places where the AI Catalog spec supports something broader than the flat, well-known-path-only model this extension documents and implements today. Worth deciding whether they land together, since both change what "resolve a catalog" means for a consumer.
Not urgent
A single flat catalog at the well-known path is the common case, and nothing is blocked on this. Filing so the gap is tracked rather than rediscovered.