From b16ff6f692da1a0e606f31ecd2121317f3d4c10f Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 10:31:57 +0000 Subject: [PATCH 01/10] docs: state the two-tier opt-in model in the discoverability caution Review of the bilateral terms split found the opt-in caution ambiguous in the same way the App Operator Terms were: it presented registration as the acceptance step while also treating manifest publication as acceptance by conduct, leaving both readings open about what an operator must do before their app can be acted on. dfinity/internetcomputer-org#94 resolves that in the Terms; this states the same model here, since the Terms point at this page for how acceptance happens: - Publishing the Layer 1 manifest opts the app in and constitutes the operator's acceptance of the App Operator Terms. - Publishing enables discovery and read-only interaction; state-changing calls are enabled only after DFINITY confirms the operator's registration, which must be kept current as domains and canisters are added. - Registration includes the app's own privacy-policy URL, so ICP MCP can present it to users. - The privacy sentence now says what the ICP MCP Privacy Policy covers (what is disclosed to a participating app, and what registration processes) and that the operator stays responsible for handling that data lawfully and for keeping the app's own privacy notice accurate, rather than asking operators to "comply with" a notice that describes DFINITY's own processing. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 76dd567..106f3c8 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -10,7 +10,13 @@ When an agent working through ICP MCP is handed only your app's URL (for example This guide describes what a canister app exposes to make that possible, ordered by priority. :::caution[Adopting this protocol opts your app in] -Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. The operator accepts the terms by registering, as their acceptance section describes, and what ICP MCP discloses to a participating app is described in its [privacy policy](https://internetcomputer.org/icp-mcp/privacy-policy/). Publishing the Layer 1 manifest at `/.well-known/ic-architecture` is the act that activates the app's participation (publishing without registering counts as accepting the terms by conduct): the layers are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. +Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. + +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms.** Publishing enables discovery and read-only interaction: agents can find the app, read the metadata it publishes, and submit queries. **State-changing calls are enabled only after DFINITY confirms the operator's registration**, so an operator whose app needs to be acted on has to register (by email, as the terms' acceptance section describes) and keep that registration current as domains and canisters are added. + +Registration includes the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes when an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available at that URL. + +The layers below are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. ::: ## The five layers From acfdab2140c62b0575fe19dad798d09f0ad731f1 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 10:43:29 +0000 Subject: [PATCH 02/10] docs: name the Layer 1 trigger in the caution title Review caught the title contradicting the body it introduces: "Adopting this protocol opts your app in" reads as though any layer opts an app in, while the body pins opt-in to publishing the Layer 1 manifest and says the layers are otherwise independently adoptable. An operator adopting only Layers 2 to 5 got two answers. The title now states the trigger. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 106f3c8..aa7b869 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -9,7 +9,7 @@ When an agent working through ICP MCP is handed only your app's URL (for example This guide describes what a canister app exposes to make that possible, ordered by priority. -:::caution[Adopting this protocol opts your app in] +:::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. **Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms.** Publishing enables discovery and read-only interaction: agents can find the app, read the metadata it publishes, and submit queries. **State-changing calls are enabled only after DFINITY confirms the operator's registration**, so an operator whose app needs to be acted on has to register (by email, as the terms' acceptance section describes) and keep that registration current as domains and canisters are added. From 1a941e6d58f11d0e4034145c52dd52d3d12ecc4c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 10:51:54 +0000 Subject: [PATCH 03/10] docs: manifest publication is sufficient; registration is optional Corrects the model stated here. The previous revision gated state-changing calls on DFINITY confirming the operator's registration. That was the wrong branch of the two the review offered: publishing the Layer 1 manifest really is sufficient, so registration is labelled optional instead. Publishing the manifest accepts the App Operator Terms and opts the app into discovery, reads, and state-changing calls for users who authorized actions, with nothing further required. Registration conditions no part of that: it identifies the operator so DFINITY can reach them with notices, records who accepted and which version, and can carry the app's own privacy-policy URL. The operator's own privacy-notice obligation is unchanged. Matches dfinity/internetcomputer-org#96, which makes the same correction in the Terms this page points at. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index aa7b869..2f2ae46 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,9 +12,9 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms.** Publishing enables discovery and read-only interaction: agents can find the app, read the metadata it publishes, and submit queries. **State-changing calls are enabled only after DFINITY confirms the operator's registration**, so an operator whose app needs to be acted on has to register (by email, as the terms' acceptance section describes) and keep that registration current as domains and canisters are added. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**, and it is sufficient on its own: a published manifest opts the app into discovery, reads of the metadata it publishes, and, for users who authorized actions, state-changing calls to its declared canisters. Nothing further is required. -Registration includes the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes when an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available at that URL. +**Registration is optional** and conditions no part of that participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. The layers below are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. ::: From 60a73a0e2871942083d11ce03aa548534af73092 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 12:47:48 +0000 Subject: [PATCH 04/10] docs: apply the reviewer's wording for what the manifest gates The previous revision said a published manifest opts the app into discovery, reads, and state-changing calls, which overstated what publication controls. Per review, publication is the condition ICP MCP applies to state-changing calls specifically: metadata retrieval and query calls do not require a published manifest at all. That matches the server, where only the protocol manifest path authorizes a write. Reviewer's suggestion applied as given, with one pronoun adjusted in the following sentence so it still reads ("conditions none of it"). Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 2f2ae46..a650997 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,9 +12,9 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**, and it is sufficient on its own: a published manifest opts the app into discovery, reads of the metadata it publishes, and, for users who authorized actions, state-changing calls to its declared canisters. Nothing further is required. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for state-changing calls from users who authorized actions; no separate registration is required. Publishing the manifest is the additional condition ICP MCP applies to state-changing calls. It does not require manifest publication for metadata retrieval or query calls. -**Registration is optional** and conditions no part of that participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. +**Registration is optional** and conditions none of it. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. The layers below are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. ::: From 8ec933fd377b9c0e562e84bc6498329ab32b24b4 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 12:48:21 +0000 Subject: [PATCH 05/10] docs: apply the reviewer's wording for the registration paragraph Second suggestion on the same review, applied verbatim: "Registration is optional and is not a condition of participation", replacing the pronoun phrasing improvised in the previous commit. The rest of the paragraph is unchanged. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index a650997..793f966 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -14,7 +14,7 @@ Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) **Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for state-changing calls from users who authorized actions; no separate registration is required. Publishing the manifest is the additional condition ICP MCP applies to state-changing calls. It does not require manifest publication for metadata retrieval or query calls. -**Registration is optional** and conditions none of it. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. +**Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. The layers below are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. ::: From e4ce4be038cf7acfe5315aa3b6a6eac983021f3c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:01:22 +0000 Subject: [PATCH 06/10] The manifest gates reads too, not only state-changing calls imcp2 64c48be ("Gate every canister-reaching tool on the discoverability manifest", dfinity/imcp2#184) restricted every tool that reaches a canister to canisters a manifest declares: get_canister_candid, get_canister_api_doc, get_canister_oql_schema, canister_query on both its paths, and canister_update_call. Reads and writes now share one mechanism and differ only in what a refusal says. The caution said the opposite: that publication was the additional condition for state-changing calls and that ICP MCP did not require a manifest for metadata retrieval or query calls. Both were accurate when written. They are not now, so an operator reading this page would expect their undeclared canisters to stay readable. It now says publication is the condition for every call that reaches a canister, and draws the line where the code draws it: an app that publishes no manifest is still resolved and described, because that surface reaches no canister, but none of its canisters is read or called. Removal stops new calls of every kind. Matches the App Operator Terms sections 3, 4 and 7 as revised in dfinity/internetcomputer-org#97. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 793f966..6f9f71e 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,7 +12,7 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for state-changing calls from users who authorized actions; no separate registration is required. Publishing the manifest is the additional condition ICP MCP applies to state-changing calls. It does not require manifest publication for metadata retrieval or query calls. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for everything ICP MCP does with them, queries and state-changing calls alike; no separate registration is required. Publication is also the condition ICP MCP applies to every call that reaches a canister: it reads and calls only canisters a manifest declares, so an app that publishes none is still resolved and described, but none of its canisters is read or called. Removing the manifest stops new calls of every kind. **Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. From 86200ae05dc03b8f9327a83403f31b68ea1ef716 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:18:59 +0000 Subject: [PATCH 07/10] Say what survives publication, and what a developer loses without it The caution said an app publishing no manifest "is still resolved and described, but none of its canisters is read or called". Two problems, both raised in review of the companion Terms change. "None of its canisters is read or called" overclaims. Discovery is HTTPS requests to the app's origin, and those are served by the app's own frontend asset canister through the gateway; the x-ic-canister-id header is the gateway naming the canister that answered. The claim is true of the calls ICP MCP makes to a canister, which is what the sentence now says. "Resolved and described" also said nothing a reader could act on. The caution now names the discovery sources a developer would recognise from their own app (the gateway header, /env.json, the JS bundle) and states the consequence #184's own scope note draws: those candidates can no longer be confirmed, so a manifest is the only route from an app to a canister an agent can use. That is the concrete cost of not publishing, which is the thing this caution exists to convey. Matches App Operator Terms sections 4 and 7 as revised in dfinity/internetcomputer-org#97 (60ef171). Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 6f9f71e..76d7ec9 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,7 +12,7 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for everything ICP MCP does with them, queries and state-changing calls alike; no separate registration is required. Publication is also the condition ICP MCP applies to every call that reaches a canister: it reads and calls only canisters a manifest declares, so an app that publishes none is still resolved and described, but none of its canisters is read or called. Removing the manifest stops new calls of every kind. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for everything ICP MCP does with them, queries and state-changing calls alike; no separate registration is required. Publication is also the condition ICP MCP applies to every call it makes to a canister: it reads and calls only canisters a manifest declares. An app that publishes none is still resolved and described from the files it serves publicly over HTTPS, and its canister IDs may still turn up there (from the gateway's `x-ic-canister-id` header, `/env.json`, or the JS bundle). ICP MCP will not read or call those, though, so it cannot confirm what they are: a manifest is the only route from an app to a canister an agent can use. Removing the manifest stops new calls of every kind. **Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. From 51d7754901e60fec85c29dd0b2f74c82a42a11e2 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:20:10 +0000 Subject: [PATCH 08/10] Layer 1 is required, not independently adoptable Two sentences still said every layer was independently adoptable, written before this PR made Layer 1 the opt-in act. With publication now the condition for every call ICP MCP makes to a canister, "each layer is independently adoptable" contradicted the caution three paragraphs above it. Both now state the reviewer's wording: Layer 1 is required for participation through ICP MCP, and Layers 2 to 5 remain independently optional and useful once the manifest is published. The claim appeared in two places serving different readers, so it is corrected in both: the closing line of the opt-in caution, and the line introducing the five-layer table. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 76d7ec9..a6039c0 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -16,7 +16,7 @@ Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) **Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. -The layers below are otherwise independently adoptable, and the rest of them describe how an agent works with an app once it has been discovered. +Layer 1 is required for participation through ICP MCP. Once the manifest is published, Layers 2–5 remain independently optional and useful; together they make an app fully agent-ready. ::: ## The five layers @@ -29,7 +29,7 @@ An agent handed only your app's URL should be able to do five things, unattended 4. Query the app's data efficiently, without a bespoke method per question. 5. Act as the signed-in user, with that user's own permissions. -Each layer is independently adoptable and independently useful. Together they make an app agent-ready. +Layer 1 is required for participation through ICP MCP. Once the manifest is published, Layers 2–5 remain independently optional and useful; together they make an app fully agent-ready. | Layer | Question it answers | Mechanism | |-------|---------------------|-----------| From 217e9c2879cdd6741821f45e7b398a074e7bebb1 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:22:01 +0000 Subject: [PATCH 09/10] Take the reviewer's tighter statement of what the manifest gates Replaces my version of the opt-in paragraph with the reviewer's, which says the same thing in half the words and orders it as a sequence the reader can follow: fetch the public website and manifest to resolve the app, validate the manifest, then retrieve metadata or invoke query or update methods only on canisters it declares. It also states the invalid-manifest case, which mine left out and which the code does handle: per discoverability.rs, "an unreachable origin, an unparseable document, and an absent manifest all refuse". Dropped from mine: the enumeration of discovery sources (the gateway header, /env.json, the JS bundle) and the note that unconfirmable candidates make a manifest the only route to a usable canister. The paragraph reads better without them, and "may fetch the app's public website and manifest to resolve it" carries the part that mattered, which is that the fetching is of public web files and is not a canister call. "No separate registration is required" also goes, since the paragraph below already says registration is optional and not a condition of participation. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index a6039c0..2697697 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,7 +12,7 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. It is sufficient to make its declared canisters eligible for everything ICP MCP does with them, queries and state-changing calls alike; no separate registration is required. Publication is also the condition ICP MCP applies to every call it makes to a canister: it reads and calls only canisters a manifest declares. An app that publishes none is still resolved and described from the files it serves publicly over HTTPS, and its canister IDs may still turn up there (from the gateway's `x-ic-canister-id` header, `/env.json`, or the JS bundle). ICP MCP will not read or call those, though, so it cannot confirm what they are: a manifest is the only route from an app to a canister an agent can use. Removing the manifest stops new calls of every kind. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. ICP MCP may fetch the app’s public website and manifest to resolve it. After validating the manifest, ICP MCP retrieves canister metadata or invokes query or update methods only on canisters declared in that manifest. If the manifest is missing or invalid, these operations are refused. Removing the manifest blocks new metadata reads and query or update calls. **Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. From 44607c2a3fd95cbce9b05390084abbc449b64cd5 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:55:21 +0000 Subject: [PATCH 10/10] Qualify removal with observation, and stop repeating the Layer 1 rule Two review decisions. Removal is not instantaneous from ICP MCP's side, so the caution now says "Once ICP MCP observes the removal, it blocks new metadata reads and query or update calls". This matches App Operator Terms sections 4 and 7, which carry the same qualifier, and matters to an operator who removes the manifest expecting an immediate cutoff. The Layer 1 requirement was stated twice in identical words, thirteen lines apart. The caution keeps the full statement, since that is where an operator decides whether to participate. The line introducing the five-layer table now back-references it and leads with what is new at that point in the page, which is that the remaining layers are individually worth adopting. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --- docs/guides/frontends/service-discoverability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/frontends/service-discoverability.md b/docs/guides/frontends/service-discoverability.md index 2697697..5698b3c 100644 --- a/docs/guides/frontends/service-discoverability.md +++ b/docs/guides/frontends/service-discoverability.md @@ -12,7 +12,7 @@ This guide describes what a canister app exposes to make that possible, ordered :::caution[Publishing the Layer 1 manifest opts your app in] Making an app available through [ICP MCP](https://internetcomputer.org/icp-mcp/) is governed by the [ICP MCP App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), an agreement between DFINITY and the app's operator: the person or entity legally authorized to operate the app and declare its canisters. -**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. ICP MCP may fetch the app’s public website and manifest to resolve it. After validating the manifest, ICP MCP retrieves canister metadata or invokes query or update methods only on canisters declared in that manifest. If the manifest is missing or invalid, these operations are refused. Removing the manifest blocks new metadata reads and query or update calls. +**Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app into ICP MCP and constitutes the operator's acceptance of those terms**. ICP MCP may fetch the app’s public website and manifest to resolve it. After validating the manifest, ICP MCP retrieves canister metadata or invokes query or update methods only on canisters declared in that manifest. If the manifest is missing or invalid, these operations are refused. Once ICP MCP observes the removal, it blocks new metadata reads and query or update calls. **Registration is optional** and is not a condition of participation. It is how an operator tells DFINITY who they are, so they can be reached with the notices the terms provide for, and so there is a record of who accepted and which version; it can include the URL of the app's own privacy policy, so ICP MCP can present it to users. What ICP MCP discloses to a participating app, and what it processes if an operator registers, are described in the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/); under the App Operator Terms the operator remains responsible for handling the personal data that reaches the app lawfully, and for keeping the app's own privacy notice accurate and available to its users. @@ -29,7 +29,7 @@ An agent handed only your app's URL should be able to do five things, unattended 4. Query the app's data efficiently, without a bespoke method per question. 5. Act as the signed-in user, with that user's own permissions. -Layer 1 is required for participation through ICP MCP. Once the manifest is published, Layers 2–5 remain independently optional and useful; together they make an app fully agent-ready. +Layers 2–5 are independently optional and independently useful; only Layer 1 is required, as noted above. Together they make an app fully agent-ready. | Layer | Question it answers | Mechanism | |-------|---------------------|-----------|