Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#44 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
typescript

調査の方向性

まず SDK のリファレンス実装から始め、次に docs/discovery.md と docs/best-practices.md を読んでください。consumer がカタログを解決する方法を追跡し、文書化された深さの上限と訪問済み URL の追跡を伴う、ネストされた application/ai-catalog+json エントリに対応するよう更新してください。実装と併せて、Discovery と Best Practices のドキュメントにネストされたカタログ、深さの制限、循環の処理が記載されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
9
フォーク
4
PR マージ指標
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/ext-server-card のほかの issue

modelcontextprotocol/ext-server-card の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。