docs: point service discoverability opt-in at the App Operator Terms - #376
Merged
Merged
Conversation
The ICP MCP terms were split into two bilateral agreements: User Terms for end users and App Operator Terms for the operators who enroll apps. The discoverability protocol's opt-in caution now links the App Operator Terms, names the operator as the accepting party, describes registration as the acceptance step, and treats manifest publication as activating the app's participation (acceptance by conduct when unregistered).
Contributor
There was a problem hiding this comment.
Pull request overview
Updates service discoverability guidance to reference the operator-specific ICP MCP agreement.
Changes:
- Links to the App Operator Terms.
- Clarifies acceptance and activation behavior while retaining the privacy-policy link.
Required metadata update: Remove the Claude Code attribution from the PR description to comply with repository policy.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
sea-snake
approved these changes
Sep 1, 2026
adamspofford-dfinity
approved these changes
Sep 1, 2026
aterga
added a commit
that referenced
this pull request
Sep 3, 2026
## Summary Follow-up to #376. That PR correctly retargeted the opt-in caution from the old single terms of service to the [App Operator Terms](https://internetcomputer.org/icp-mcp/app-operator-terms/), but it inherited the ambiguity those Terms carried: it presented registration as the acceptance step while also treating manifest publication as acceptance by conduct, so a reader could not tell what they must do before their app can be acted on. dfinity/internetcomputer-org#96 resolved that in the Terms themselves. This states the same model here, which matters because the Terms point at this page for how acceptance happens (and say that where the two differ, the Terms prevail). ## What the caution now says - **Publishing the Layer 1 manifest at `/.well-known/ic-architecture` opts the app in and constitutes the operator's acceptance** of the App Operator Terms. It is sufficient to make the app's declared canisters eligible for everything ICP MCP does with them, queries and state-changing calls alike; no separate registration is required. - **Publication is 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 carry the URL of the app's **own** privacy policy so ICP MCP can present it to users. - The privacy sentence describes what the [ICP MCP Privacy Policy](https://internetcomputer.org/icp-mcp/privacy-policy/) actually covers (what is disclosed to a participating app, and what registration processes), and states that the operator remains 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 processing and expressly does not govern theirs. - The **caution title** now names the trigger ("Publishing the Layer 1 manifest opts your app in"), which review caught contradicting the body: the old title read as though any layer opts an app in, while the body pins opt-in to Layer 1 and notes the layers are otherwise independently adoptable. The five-layer content below the caution is unchanged. ## Revision history This PR went through three models of what publication gates, because the code moved under it: 1. An early revision gated state-changing calls on DFINITY confirming the operator's registration. That was the wrong branch of the two the review offered; publication really was sufficient, so registration became optional instead. 2. Two review suggestions then narrowed what publication gates to **state-changing calls only**, on the correct ground that `crates/imcp2-core/src/discoverability.rs` gated writes only and its `READS_ARE_FINE` refusal text told agents that reads worked regardless. Both were applied verbatim in `60a73a0` and `8ec933f`. 3. **`e4ce4be`** undoes that narrowing, because dfinity/imcp2#184 (`64c48be`, "Gate every canister-reaching tool on the discoverability manifest") has since made reads gated the same way. `get_canister_candid`, `get_canister_api_doc`, `get_canister_oql_schema`, `canister_query` on both paths and `canister_update_call` are all restricted to declared canisters; per the module docs, "Reads and writes share one mechanism and differ only in what a refusal SAYS", `the_rule()` now says the server "**reads and calls** ONLY canisters an app declares", and `READS_ARE_FINE` is gone. So the two suggested sentences were accurate when written and are not now. Step 3 keeps their substance where it still holds (publication is sufficient, registration is optional) and moves the line to where the code now draws it: not reads versus writes, but **calls that reach a canister versus the surface that does not**. `open_app`, the static guides and the identity tools reach no canister and stay ungated, which is why the caution still says an app publishing no manifest is resolved and described. @sea-snake, your approval was on `8ec933f`, so this last commit is newer than what you read. ## Verification - `npm run validate` — **210 files, all checks passed** on each revision, including `e4ce4be` (the repo's no-em-dash rule caught new prose in the first draft, fixed before pushing). - Rendered preview checked, not just the source, on the earlier revisions: the caution reads as intended and the page links only `app-operator-terms/` and `privacy-policy/`, with no `/icp-mcp/terms/` link that would send operators to the User Terms. - The claims about the gate are quoted from `crates/imcp2-core/src/discoverability.rs` at imcp2 `main` (`64c48be`), not from memory. ## Companion dfinity/internetcomputer-org#97 makes the matching correction to App Operator Terms §3, §4 and §7. Merge that with or before this, since the Terms are the authority this page defers to. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/.well-known/ic-architecturemanifest as the act that activates participation, with acceptance by conduct as the unregistered fallback. The privacy policy link is retained.npm run buildpasses (210 pages).