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

discovery.md: what should a client do when the card fetch returns a 429 from the recommended rate limit?

オープン
  • 何か問題がありますか？
#53 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
活発
領域
documentation

調査の方向性

Read docs/discovery.md, especially the client-flow and Denial of Service sections, then compare them with the SEP text at the current PR head. Determine and document the client behavior for a card-fetch 429, Retry-After, other error responses, and possible inline catalog data, with the client flow's failure outcomes updated to match the decision.

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

説明

One question on the discovery mechanics, from an operator's side.

docs/discovery.md reserves <streamable-http-url>/server-card and notes the resulting path-namespacing as a benefit (a server at https://host/mcp yields https://host/mcp/server-card). Under Denial of Service — the guidance restored in #21 — it recommends that servers rate-limit the card endpoint, and asks clients to respect Cache-Control and use ETags. The client flow has a single negative outcome, "Discovery unavailable for this domain", and it hangs off the catalog fetch (/.well-known/ai-catalog.json); the later step "Fetch Server Card from url" has no failure branch at all.

Why this is structural rather than hypothetical: a limit protecting an MCP endpoint is normally scoped by path prefix and placed ahead of application code. In my deployment, anonymous requests under the API prefix hit a per-client bucket in middleware before the application initializes and before any database query; authenticated requests are exempt elsewhere, but not under the MCP path itself, because resolving a bearer key there costs an HMAC and an indexed query per attempt. A card served under that prefix shares that bucket with all other anonymous traffic from the same client address by default — unless the operator carves it out, which the document does not tell them to do. A single first GET will not exhaust it, but a crawler fleet, a shared corporate egress, or a client that already made requests under the prefix can arrive with the bucket spent — and first contact is the one moment it holds neither a cache entry nor an ETag, so the document's mitigation is not yet available. A 403 from a bot filter, or a challenge page returned with 200, collapses the same way.

For comparison, RFC 9309 §2.3.1.3/§2.3.1.4 separates "unavailable" (4xx) from "unreachable" (5xx/network) for robots.txt, and Google's crawler documentation carves 429 out of its 4xx rule (https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt#http-status-codes). In the SEP text at the current PR head and in docs/discovery.md including its client-flow section, I find no mention of 429 or Retry-After; the SEP text repeats the recommendation ("Servers SHOULD rate-limit discovery endpoints") without naming a status code either.

So, one question: what should a client do when the card fetch — not the catalog — returns a 429 produced by the rate limiting the same document recommends: treat the entry as unavailable, retry after Retry-After, or fall back to inline data in the catalog?

Florian Berger — Bolzano/Bozen (IT)

主要言語
TypeScript
スター
9
フォーク
4
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 を短くまとめたダイジェスト。