Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support nested catalogs (application/ai-catalog+json entries), with depth cap and cycle tracking

Đang mở
#44 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript
Lĩnh vực
api, documentation, security

Hướng nghiên cứu

Bắt đầu với các triển khai tham chiếu của SDK, sau đó đọc docs/discovery.md và docs/best-practices.md. Theo dõi cách một consumer phân giải một catalog và cập nhật để hỗ trợ các mục application/ai-catalog+json lồng nhau, với giới hạn độ sâu được ghi rõ trong tài liệu và việc theo dõi các URL đã truy cập. Công việc được xem là hoàn tất khi tài liệu về discovery và best-practices mô tả các catalog lồng nhau, giới hạn độ sâu và cách xử lý chu kỳ cùng với phần triển khai.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
10
Fork
4
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/ext-server-card

Tất cả issue của modelcontextprotocol/ext-server-card

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.