Clarify MCP manifests on Agentic Registry #1

Activity

1. iabeurope-beis commented on Mar 20, 2026

   

   iabeurope-beis

   on Mar 20, 2026

   Author

   More actions

   Listing some more suggestions based on testing of the registry via MCP:

   • Verify that endpoint_url reflects the current production MCP path for different entries, I've found a couple of stale URLs.
   • Verify that authentication_required matches runtime behavior.
   • Periodically validate registered MCP endpoints with a real tools/list probe and flag entries whose metadata no longer matches runtime behavior.
2. tidolblair-prog commented on Apr 27, 2026

   

   tidolblair-prog

   on Apr 27, 2026

   More actions

   I still don’t understand and never understood or not interested really where tf I should apply( almost like recipe book but you know at least physical aspect of it ) where and how. These instructions
3. jaanijuk commented on Jul 31, 2026

   

   jaanijuk

   on Jul 31, 2026

   More actions

   Have spent recent weeks testing the reference agents from Australia. The pattern this issue names is one I keep meeting one layer down, so adding corroboration and a suggestion on sequencing.

   The declared-vs-served gap is already conceded and fixed at the agent-card level. seller-agent v2.3.1 shipped fix/agent-card-a2a-truth: "card advertises only served protocols; A2A docs marked designed-not-implemented" (62803d4). Once the agent card is held to advertise only what's served, the Registry manifest inheriting the same rule is consistency rather than a new demand. To us that's the strongest argument for suggestions 1–2 above.

   Freshness without provenance decays quietly. I reported tag drift on the reference agents in July (a pinned tag resolving to three different commits inside five days) and the team responded by moving to immutable tagged point releases. Registry metadata has the same failure mode with fewer eyes on it; the stale endpoint_url finds above are the discovery-layer version of the same thing, and the fix shape is the same: make provenance and timestamp visible so staleness is detectable rather than silent.

   A sequencing suggestion: split the documentation half from the verification half. Suggestions 1–4 (advisory status, subject-to-change, provenance + timestamp, expectations for manual uploads) are documentation plus one metadata field. They could ship quickly and deliver most of the trust improvement. The probing regime is genuinely valuable but carries policy questions this thread hasn't opened yet: whether registrants consent to being probed, what happens on probe failure (flagged, delisted, grace period?), and how authenticated endpoints are handled. Splitting lets the cheap half stop waiting on the expensive half.

   One small precision note in support of the point about change: as we read MCP, notifications/tools/list_changed only reaches connected clients, so it's evidence that tool surfaces change rather than a mechanism a registry can consume. A probe/poll (or an out-of-band notification on re-registration) looks structurally necessary, which strengthens the case for making verification semantics explicit.

   Longer term the two layers compose: agents self-declaring served versions and tool surfaces in-protocol, plus a registry that records when it last verified them, together make discovery trustworthy - as either alone doesn't.
4. jaanijuk commented on Aug 6, 2026

   

   jaanijuk

   on Aug 6, 2026

   Last edited by jaanijuk

   More actions

   One datapoint since my comment above, which raises the stakes on this thread: in the seller reference implementation, registry trust status is a pricing and access input, not just discovery metadata.

   From docs/guides/pricing-rules.md at seller-agent v2.4.1, “Step 2: Trust Cap (for Agent-to-Agent)”:

   When the buyer is an agent, the agent registry trust status sets a ceiling:

   Trust status	Maximum access tier
   unknown	PUBLIC
   registered	SEAT
   approved / preferred	ADVERTISER
   blocked	denied (403)

   The effective tier is the minimum of the buyer’s claimed tier and this cap. So registry metadata does not merely describe agents; it changes the commercial terms they can access and, at the extreme, whether they can transact at all. A stale or wrong entry silently locks a legitimate buyer out of negotiated tiers; a wrong blocked shuts them out entirely.

   That moves the suggestions above from discovery hygiene to transaction integrity: provenance, freshness and verification semantics become part of the pricing chain’s audit trail, because the registry is already load-bearing in the reference implementation.