Skip to content

Point the operator-facing terms references at the App Operator Terms - #182

Merged
aterga merged 1 commit into
mainfrom
claude/icp-mcp-operator-terms-refs-r5l8mw
Sep 2, 2026
Merged

Point the operator-facing terms references at the App Operator Terms#182
aterga merged 1 commit into
mainfrom
claude/icp-mcp-operator-terms-refs-r5l8mw

Conversation

@aterga

@aterga aterga commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Summary

The ICP MCP terms were split into two bilateral agreements on 2026-09-01 (dfinity/internetcomputer-org#90): User Terms for end users, App Operator Terms for the operators who enroll applications. Three references here still pointed at the User Terms while describing what an operator accepts by publishing a manifest — and the User Terms expressly do not govern operators.

Companion to dfinity/internetcomputer-org#96 (which resolves the registration model those Terms describe) and dfinity/developer-docs#377 (the discoverability guide).

Changes

  • crates/imcp2-core/src/discoverability.rs — the module doc (line 65) and the legacy-manifest refusal message (line 382) both name "the terms that publishing the standard manifest now signifies". Both now link /icp-mcp/app-operator-terms/. That refusal text is read by the operator of an early-adopter origin who is being told to move their manifest to the standard path, so it has to name the agreement they would actually be accepting.
  • docs/openai-directory-submission.md — the Terms of Service row still described one document covering "app-developer acceptance via service discoverability". It now identifies /icp-mcp/terms/ as the User Terms (the URL a directory listing wants) and names the App Operator Terms as the separate operator-side agreement, so a submitter doesn't enter the wrong URL.

Deliberately unchanged: II_TERMS_OF_SERVICE_URL in src/lib.rs still points at /icp-mcp/terms. The Internet Identity consent screen is shown to end users, so it must keep linking the User Terms.

Testing

  • cargo build --locked --all-targets
  • cargo test --locked --all-targets — 69 passed, 0 failed (root package)
  • cargo test --locked -p imcp2-core175 passed, 0 failed, which is the suite that actually covers discoverability.rs, including legacy_manifest_refusal_* asserting the refusal names why the older document cannot stand in. Worth noting for future changes here: --all-targets from the workspace root does not run the imcp2-core tests, so this crate needs -p imcp2-core explicitly.
  • cargo fmt --all / cargo clippy --all-targets — untouched, pre-existing: this container's rustfmt disagrees with the committed style across many files (no rustfmt.toml, no CI fmt gate) and clippy's warnings reproduce on pristine main. These two edits are comment and string text.
  • npm test --prefix monitoring/mcp-status — not applicable, the dashboard is untouched.

Checklist

  • I have read the Contributing guidelines.
  • Docs updated for any user-visible change — the submission doc is the doc affected; the changed refusal string is itself operator-facing text.
  • No secrets, credentials, or internal-only information are included.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB


Generated by Claude Code

The ICP MCP terms were split into two bilateral agreements on
2026-09-01 (dfinity/internetcomputer-org#90): User Terms for end users,
App Operator Terms for the operators who enroll applications. Three
references here still pointed at the User Terms while describing what an
operator accepts by publishing a manifest — and the User Terms expressly
do not govern operators.

- crates/imcp2-core/src/discoverability.rs: the module doc and the
  legacy-manifest refusal message both name the terms that publishing
  the protocol manifest signifies. Both now link
  /icp-mcp/app-operator-terms/. That refusal is read by the operator of
  an early-adopter origin, so it has to name the agreement they would
  actually be accepting.
- docs/openai-directory-submission.md: the Terms of Service row still
  described a single document covering app-developer acceptance. It now
  identifies /icp-mcp/terms/ as the User Terms (the URL a directory
  listing wants) and names the App Operator Terms as the separate
  operator-side agreement.

The Internet Identity consent-screen URL in src/lib.rs is deliberately
unchanged: that screen is shown to end users, so it must keep linking
the User Terms.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xpg83AWtkQo34jbMxpX8WB

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The reviewed changes are focused and have no unresolved issues.

Pull request overview

Updates operator-facing references to distinguish App Operator Terms from User Terms.

Changes:

  • Corrects discoverability guidance and refusal messaging.
  • Clarifies separate agreements in directory submission guidance.
File summaries
File Description
docs/openai-directory-submission.md Distinguishes User Terms from App Operator Terms.
crates/imcp2-core/src/discoverability.rs Links operator-facing guidance to the applicable terms.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@aterga
aterga marked this pull request as ready for review September 2, 2026 10:52
@aterga
aterga requested a review from a team September 2, 2026 10:52
@aterga
aterga merged commit d13ea7f into main Sep 2, 2026
13 checks passed
@sea-snake sea-snake mentioned this pull request Sep 2, 2026
aterga pushed a commit that referenced this pull request Sep 2, 2026
A minor bump rather than a patch, because the served tool surface changed
incompatibly since 0.3.0.

Every tool that reaches a canister is now gated on the owning app's
service-discoverability manifest (#184). `get_canister_candid`,
`get_canister_api_doc`, `get_canister_oql_schema` and `canister_query` used to
work on any canister; they reach one only when the app that owns it declares
that canister at `/.well-known/ic-architecture`, exactly as
`canister_update_call` already did. Each of the four grew an optional `app_url`
naming the app whose manifest decides, and every successful reply echoes
`declared_by`/`declared_at`. A client that read an undeclared canister against
0.3.0 gets a refusal here.

`open_app` moved with it: it probes only declared canisters for their
oql/api-doc flags, so a candidate mined from `/env.json` or the JS bundle comes
back with null flags and without the `[declared]` marker, and the server
instructions no longer promise that reading is ungated.

No public Rust item changed — the gate lives in the private `discover` and
`discoverability` modules — so an embedder still compiles against 0.4.0
unchanged. What changed is what its server answers, which is the part its own
users see.

Under cargo's 0.x rules `0.3` is the compatibility range, so shipping this as
0.3.1 would hand that break to everyone on `imcp2 = "0.3"` — the requirement
our own README recommends — the next time they ran `cargo update`. 0.4.0 opens a
new range instead; existing users stay on 0.3.x until they choose to move. The
README's dependency line follows, as `"0.3"` would no longer resolve to a
current release.

The other two changes since 0.3.0 are the status dashboard's landing-page check
(#181) and the operator-facing terms references (#182); neither touches the
crate.

`imcp2-core` moves in lockstep: publish-crate.yml checks the tag against both
manifests, and the workspace pin that binds them (`imcp2-core = { path = …,
version = … }`) has to name the same number or the path dependency stops
resolving. `imcp2-local` moves with them — it releases on its own
`imcp2-local-…` version tags and has never been cut, so there is nothing to keep
it behind, and its `--version` output would otherwise report 0.3.0 from a 0.4.0
tree.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants