mcp: bridge the authoring ToolRegistry through the hosted HTTP MCP runtime behind a metadata:write OAuth scope — today handleHttpRequest exposes only data/action tools, so a hosted environment can be read and run over MCP but never built

Filing gate: ③ a task on the maintainer's word (batch 1 · MCP build, platform half; the cloud half is the cloud consumer card (filed right after this one in objectstack-ai/cloud)).

Context

packages/mcp/src/mcp-server-runtime.ts handleHttpRequest (the runtime cloud mounts at /api/v1/mcp) lists the data and action tools only: list_objects, describe_object, validate_expression, query_records / get_record / create_record / update_record / delete_record, list_actions, run_action, resume_run, plus the skill prompts (mcp-http-tools.ts, read at main 2026-10-27). The authoring ToolRegistry is bridged only by the local stdio path (os dev), on purpose. packages/spec/src/ai/mcp.zod.ts declares the OAuth scopes data:read, data:write, actions:execute — no metadata scope exists, so a token cannot even ask for authoring.

The maintainer ruled 2026-10-27 that a developer driving Claude Code over MCP builds apps and metadata in a hosted environment with their own model and tokens, landing drafts that a human publishes in the UI (verbatim in Provenance below). cloud's handlers already serve the in-UI doors; what is missing is the HTTP door into them.

The change

packages/spec/src/ai/mcp.zod.ts: add the scope metadata:write (and the consent copy the hosted OAuth screen renders), with its first reader in the same PR (cross-repo rule 2: a new spec key ships with its reader).
mcp-server-runtime.ts: handleHttpRequest accepts an injected authoring ToolRegistry from the host. Its tools appear in tools/list only when the token carries metadata:write; tools/call on one without the scope returns the scope refusal the data tools already use for data:write.
Every call into the injected registry carries the door provenance (door: 'mcp', the token's principal and the environment) in the tool context, so the host's access check and tier mapping read it from the context, never from a request header.
The runtime stays door-agnostic: which tools the host injects (cloud decides to inject no publish / discard tool, the cloud consumer card (filed right after this one in objectstack-ai/cloud)) and what version of the whitelist they answer (objectstack-ai/cloud#3299) are the host's business.
The served skill prompt (skill-md.ts) names the authoring tools when the scope is present, so the client model learns the build loop (create → verify_build → draft, publish in the UI) from the same source as today's data loop.

Why

Without this bridge the developer path to a hosted environment is os build → os package publish → Marketplace install (content/docs/getting-started/deploy.mdx), which is a release cycle, not a build loop. Beneficiary: every developer with a hosted environment and an MCP-capable agent; cloud, which gets the build door without a second MCP server.

Reader

objectstack triage routes (the file surface is packages/mcp + one scope key in packages/spec). Downstream consumer: the cloud consumer card (filed right after this one in objectstack-ai/cloud) (repo:cloud lane, seat 2), which carries Blocked-by: on this card. M.

Acceptance

tools/list over HTTP with a metadata:write token lists the injected authoring tools; without the scope it lists none and tools/call on one is refused by scope.
A tool call through the bridge reaches the injected handler with door: 'mcp' in its context.
The stdio path and the existing data/action tools are byte-identical in behaviour (existing tests green).

Dedup: objectstack issues for "mcp authoring tools http bridge metadata scope" → 0 hits (open or closed); objectstack#20791 was the only related hit and does not ask for the bridge.

Provenance

Filed by the cloud project thread 「评估云端 build 支持 automation 元数据」 (session session_01MLe2jYCJNnaCwcEAbA7BBW) on the maintainer's order, 2026-10-27. Sam (os-zhuang), in that thread, verbatim: 「真审批 + MCP build」 (03:55Z, choosing the two lines to push); 「开发 / 预览环境可直写，生产环境走发包，这个本身没有意义，现在生产环境再界面上开发是否也算一种元数据开发」 (03:57Z, ruling the MCP landing posture); 「MCP build 花的不是开发者自己的token吗？」 (04:06Z, ruling that Free is not excluded for token-cost reasons); 「同意」 (04:07Z) to the filing plan: batch 0 foundation cards now, batch 1 MCP build cards plus an ADR-0112 amendment, batch 2 in-UI real approvals as pm:blocked. The evaluation and the batch plan: https://claude.ai/artifact/3ErDZw2FzAnb1keGYcZn5c (section 「执行计划」).

Governing text: docs/adr/0112-cloud-ai-build-lite-boundary.md (D1 one whitelist, D2 version road, D3 repository-only classes, D5 Free/paid differences, D6 single source); packages/service-ai-studio/src/authoring-whitelist.ts (the single declaration, cloud#1956).

Filed · thread 「评估云端 build 支持 automation 元数据」 · 2026-10-27T04:30Z · gate ③ (maintainer-directed) · pre-labelled pm:queue only — domain, type and priority are objectstack triage's to set; the consumer card is objectstack-ai/cloud#3302

Authorizing words (os-zhuang, verbatim, 2026-10-27): 「真审批 + MCP build」 and 「同意」 to the three-batch plan (https://claude.ai/artifact/3ErDZw2FzAnb1keGYcZn5c §执行计划). The landing-posture ruling and the Free-tokens ruling are quoted in the card's Provenance block.
Batch position: batch 1 of 3 (MCP build); siblings: objectstack-ai/cloud#3302 objectstack-ai/cloud#3303 objectstack-ai/cloud#3304 objectstack-ai/cloud#3305 objectstack-ai/cloud#3306.
Batch-of: 14
Session: session_01MLe2jYCJNnaCwcEAbA7BBW

Generated by Claude Code

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:ai` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T04:57Z

⛔ Not a claim, ⛔ not a dispatch.

p1, a protocol addition (a new OAuth scope metadata:write in packages/spec/src/ai/mcp.zod.ts, with its first reader) on the maintainer's 2026-10-27 ruling. security: it opens authoring over hosted MCP, so the scope is a security boundary. The PR keeps drafts-only landing (a human publishes in the UI), and every authoring tool checks the scope and the caller's own metadata permission. ⛔ The scope is never a bypass.
Lane: the HTTP MCP runtime (packages/mcp) is domain:server. The mcp.zod.ts scope line falls under the server fence (a spec seat signs off, or it splits). The cloud half is the cloud card. Skills, docs and eval are owed ([Decision] pm-dispatch: which PRs owe a Skills-docs: line (the #26184 audit Part B rule draft) — protocol-kind only, protocol-kind plus narrowing, or not adopted #26369 B).

Generated by Claude Code

Seat note · domain:server seat 1 · os-project-manager · session_01R1q2xdtYgU6FKrZ7LgjPCC · 2026-10-27T05:41Z · ⛔ not a claim, ⛔ not a dispatch

Lane: domain:server → domain:spec. The server lane's red line (lanes/server.md): 「触 packages/spec 的卡一律归 spec 席;改元数据格式或接受面的卡亦然,不论碰没碰 spec。」 This card's change 1 adds the OAuth scope metadata:write to packages/spec/src/ai/mcp.zod.ts, and cross-repo rule 2 (a new spec key ships with its first reader) puts the reader (packages/mcp handleHttpRequest, changes 2–5) in the same PR. So the card goes whole to the spec seat rather than being split into a spec half with no reader.

Grade, security and the triage line 6434128092 stay as they are: p1, every authoring tool checks the scope and the caller's own metadata permission, the scope is never a bypass, and landing is drafts-only.
The reader surface is packages/mcp (mcp-server-runtime.ts, mcp-http-tools.ts, skill-md.ts). If the spec seat would rather have the server seat build the reader against a landed scope, file the spec half as its own card and put Blocked-by: on this one; this seat then dispatches the rest.
The consumer card objectstack-ai/cloud#3302 keeps its Blocked-by: on this card.

Generated by Claude Code

Claim: PM loop round 1 · 2026-10-27T06:39Z
Session: session_01WGufzfhobWEgUUrjz4rrbh
Account: os-support-ai
Branch: claude/project-thread-3c836y (card thread session_01WGufziVp7Y4ARxehhrEJbM. The platform assigns the thread's branch and the thread can push only that one, so the branch is written as measured instead of claude/issue-26464-<slug>.)
Worktree: objectstack-issue-26464
Domain: domain:spec
Seat: domain:spec#1
File surface: packages/spec/src/ai/mcp.zod.ts (one metadata:write scope constant plus its consent copy) and the spec artifacts check:generated regenerates; packages/mcp/src/mcp-server-runtime.ts (an optional host-injected authoring ToolRegistry in handleHttpRequest, scope-gated list and call, door provenance in the tool context), packages/mcp/src/mcp-http-tools.ts where the scope refusal lives, and packages/mcp/src/skill-md.ts (names the authoring tools only under the scope); tests under packages/mcp; changesets for @objectstack/spec and @objectstack/mcp. ⛔ No stdio-path change, and no change to the existing data or action tools' behaviour. Stop on a breach and explain it in the report.
Container & model: S, mode:thread, model: CONTRACT_REVIEW_TIER (reason: the seat's per-card judgment call, which dispatch-gates --tier leaves to the PM because no path-derived mandate exists; this is a p1 security card adding a new OAuth scope that gates authoring tools across spec and mcp), effort xhigh
Clause-②: yes (widening)
Metadata-protocol: to be measured by the dev on the head. The seat expects none unless an authorable-surface shard moves; if it moves, declare added with minor.
Responsibility: n/a. This is a maintainer-directed protocol addition (gate ③), not a defect card.
Thread-read: none
Premise: holds (read at origin/main: mcp.zod.ts:128-132 declares exactly data:read, data:write and actions:execute, and handleHttpRequest serves data and action tools only). The governing ADR-0112 and authoring-whitelist.ts named on the card are objectstack-ai/cloud files (here ADR-0112 is error-code vocabulary). They are cited as cloud ADR-0112, and the card's five numbered changes are the build contract.
Serial constraints cleared: yes. No open PR or claim names these files. The consumer is objectstack-ai/cloud#3302, which carries Blocked-by: on this card.
Ruling-ref: maintainer os-zhuang, 2026-10-27, verbatim on the card's Provenance (「真审批 + MCP build」, 「同意」 04:07Z); triage 6434128092; re-lane 6434722524

os-dev-report

{
  "issue": 26464,
  "status": "done",
  "branch": "claude/project-thread-3c836y (harness-pinned; worktree /home/claude/objectstack-issue-26464, base 3fcafcd3)",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/26550",
  "session": "session_01WGufziVp7Y4ARxehhrEJbM",
  "premise_still_valid": true,
  "summary": "spec: `MCP_OAUTH_SCOPE_METADATA_WRITE` (`metadata:write`) joins `MCP_OAUTH_SCOPES` in `packages/spec/src/ai/mcp.zod.ts`, with `MCP_OAUTH_SCOPE_CONSENT_COPY` (one consent sentence per scope, keyed by `McpOauthScope` so a scope cannot ship without its copy); the authorization server's `scopes_supported` and the runtime's up-front 403 read the array, so they are its first readers; `scopesToAgentPermissionSets` maps it alone to the floor (no data ceiling change). mcp: `handleHttpRequest(request, { authoring })` takes a host-injected `McpAuthoringToolRegistry` plus the token principal and environment; `registerAuthoringTools` registers its tools on the per-request server only when `grantedScopes` names `metadata:write` (`grantsAuthoringTools`; the undefined grant of an API key or session gets none, fail-closed). Refusal is by non-registration, so `tools/call` without the scope gets the same SDK unknown-tool answer `create_record` gets without `data:write`. Every call carries a fresh `McpAuthoringToolContext` `{ door: 'mcp', actor: { id }, principal, environmentId }` built from host inputs only; no request header reaches it. `renderSkillMarkdown({ grantedScopes, authoringTools })` renders a Build section only under the scope. stdio `bridgeTools` still calls its registry with one argument (pinned). Runtime stays door-agnostic; `packages/runtime` and `ui/` untouched per the seat's fence. Premise: the card's ADR-0112 / authoring-whitelist.ts are objectstack-ai/cloud files, cited as cloud ADR-0112 (agreed in the claim). Changeset: spec patch, mcp patch; Clause-②: yes (widening); Metadata-protocol: none (check:generated --fix moved only api-surface/ai.json and export-origins/ai.json; authorable surface unchanged). Hardening round after seat 1's contract review (PASS, 6436633646), head 7fb21ede: the principal (and its `scopes`) in the tool context is a frozen per-call copy, so a tool that writes into its context taints neither the next call nor the host's object (pinned with four hostile writes); the SKILL.md Build section names `describe_object` only when the grant also carries `data:read` (the predicate that registers it) and otherwise points at the authoring tools' own verify step; a pin records that the SDK throws on a duplicate tool name. For cloud#3302: the gate reads `toolOptions.grantedScopes`, so the host must derive that list and `authoring.principal` from the same token; a registry name that collides with the native surface (or repeats) throws at registration and fails the request.",
  "tests": "All under `OS_VERIFY_LOCK_SLOT=issue-26464 bash scripts/pm/os-verify-lock.sh -c ...`, VERDICT lines read. At head 7fb21ede: `pnpm --filter @objectstack/mcp typecheck` (tsc + check:test-typecheck) → VERDICT command-exit 0; `pnpm --filter @objectstack/mcp test` → `Test Files 45 passed (45)` · `Tests 567 passed (567)` · VERDICT command-exit 0; repo lint `eslint --no-inline-config` on the changed .ts files → exit 0. (At cf3ec268 the same three were 0 / 562 passed / 0.) (includes the new `mcp-server-runtime.authoring-scope.test.ts`, `skill-md.authoring.test.ts`, extended `skill-md-surface-guard.test.ts`). At 9c3a187a (head differs by a two-line comment deletion in one test file): `pnpm --filter @objectstack/spec exec vitest run src/ai/mcp-oauth-scopes.test.ts src/contracts/auth-service.test.ts` → 2 files, 15 passed, VERDICT 0; `pnpm --filter @objectstack/core exec vitest run src/security/assemble-execution-context.test.ts src/security/request-execution-context.test.ts` → 230 passed, VERDICT 0; after a closure build of the two readers (`--filter '@objectstack/plugin-auth^...' --filter '@objectstack/runtime^...'`, VERDICT 0, 258s): `plugin-auth src/auth-manager.mcp-oauth.test.ts` → 77 passed, VERDICT 0; `runtime src/http-dispatcher.mcp-oauth.test.ts` → 9 passed, VERDICT 0; `pnpm --filter @objectstack/spec typecheck` → VERDICT 0. Security pins: a data:write token and an actions:execute token can neither list nor call an authoring tool (registry never touched); the refusal text equals create_record's without data:write once the tool name is swapped; seven spoofed provenance headers (x-objectstack-door, x-door, x-principal, x-user-id, x-environment-id, x-organization-id, x-client-id with distinct victim values) never reach the context; stdio one-argument call pinned through a real PassThrough stdio session. Ablation (on-disk mutation, then restored, `git status` clean): `grantsAuthoringTools` body replaced by `return true` → `vitest run` on the three new/changed files: `Test Files 3 failed (3)` · `Tests 10 failed | 15 passed (25)`, the ten reds being every gate pin (data:write, actions:execute, undefined grant, empty grant, refusal parity, registerAuthoringTools returns [], surface-guard with registry, two byte-identical skill renders). Second ablation at 7fb21ede (freeze removed and the describe_object condition forced true on disk, then restored): `Test Files 3 failed (3)` · `Tests 3 failed | 27 passed (30)`, the three reds being exactly the new negative pins (frozen principal; Build section without data:read names no describe_object; surface guard: Build section names no unregistered native tool).",
  "gates": "Local: `node scripts/pm/dispatch-gates.mjs --commands` derived 104 families (identical set at 9c3a187a and cf3ec268); every exit captured before any pipe into gates-ran.txt. First pass 100 × exit 0 plus four environment answers: `check-plugin-teardown-shape.mjs --self-test` exit 3 (fixture pinned to commit 621a4876 unreachable on the shallow clone; after `git fetch origin` of that SHA → exit 0, 48 cases), `check:dual-build-cjs-loads` exit 3 and `spec check:skill-examples` exit 3 (no built dist; after full `pnpm build`, 118/118 tasks, VERDICT 0 → both exit 0; skill-examples 265 marked examples / 3 surfaces), `check:lean-entry-closure` exit 1 (spec dist wiped mid-gate by my own concurrent closure build; re-run on the finished build → exit 0). Reconciliation `dispatch-gates.mjs --ran gates-ran-final.txt` → `104 derived, 104 run, 0 NOT-MEASURED, 0 UNRUN`, exit 0. Also: `check:generated --fix` then `check:generated` 14/14 up to date (VERDICT 0); `check-platform-checklist --changed-from origin/main` OK (2 anchored files, 6 anchors judged, 0 lost); `check-nul-bytes` OK (21342 files); repo lint `eslint --no-inline-config` on the ten changed .ts files exit 0, 0 problems. Second derived run at 7fb21ede (no build in flight this time, fixture commit fetched, full dist present): 104/104 exit 0 on the first pass, command set identical to the first derivation, `dispatch-gates.mjs --ran` → `104 derived, 104 run, 0 NOT-MEASURED, 0 UNRUN`, exit 0. CI on PR #26550 at 7fb21ede (49 check runs, read via pull_request_read get_check_runs): success — Lint & Repo Gates, TypeScript Type Check, Type Check · workspace / source gates / consumer gates / debt ledger, Lint · ESLint / repo & tooling gates / docs & code guards / CI, release & engine gates / PM dispatch-gates / scoped · slot lookup & corpus / scoped · query-options erasure / scoped · tooling self-tests, Build Core, Build Docs, Build UI Deps, Build & E2E UI, Type Check UI, Plan Test Core shards, Test Core 1/8 2/8 3/8 4/8 6/8 7/8 8/8, Dogfood Regression Gate, Check Changeset, Check PR Size, Check Documentation Links, Flag docs affected by code changes, Spec property liveness, Governed Surface Queue Guard, Auto Label, The card this PR closes must claim this branch, No other open PR may claim the same issue, No other open PR may claim the same single-writer path, Part-of PR must not also close its card; skipped (path/opt-in) — Lint UI, Test UI matrix, Temporal Conformance, Dogfood Verify CLI, Dogfood Regression Gate matrix, Packed-tarball smoke, 18.x upgrade harness; Test Core 5/8 and the Test Core aggregate concluded success at 08:33Z, so all 49 check runs are completed: 42 success, 7 skipped, 0 failed. No Claude Approvals check run is posted on this PR.",
  "dogfood_battery": "n/a — no `!` in the PR title and no (narrowing) arm",
  "mcp_calls": "7 — mcp__github__issue_read ×4 (#26464 body and comments: triage 6434128092, re-lane 6434722524, claim 6435524505; the fourth confirmed the card assignee for pr_create), mcp__github__pull_request_read get_check_runs ×3 (#26550 CI at cf3ec268, and twice at 7fb21ede until every run concluded). No MCP write tool used.",
  "api_writes": "2 via the fleet-write relay (`scripts/pm/fleet-write/dispatch.mjs`, landing as objectstack-fleet[bot]): pr_create → objectstack-ai/objectstack#26550 (relay run 40468938355, read-back identical, 13639 bytes, assignees os-support-ai; no labels, skip-changeset not applicable), comment → this os-dev-report on #26464. git push ×4 to claude/project-thread-3c836y (f7164244 feat, 9c3a187a test fixes, cf3ec268 lint cleanup, 7fb21ede hardening round from the contract review; not REST). No PATCH, no reviewer-request stroke (kept to the three-stroke budget).",
  "open_questions": [
    {
      "question": "Should the undefined grant (API key / session over HTTP) be served the injected authoring tools, as it is served the full native surface?",
      "options": [
        "A keep fail-closed (shipped): authoring only for a token whose consent names metadata:write",
        "B widen: treat an undefined grant like the native families and register authoring for keys and sessions too"
      ],
      "recommendation": "A, because the card's acceptance is literal (without the scope it lists none), authoring is a build-door consent rather than a data ceiling, and widening to the headless track is a product decision for its own card; the predicate `grantsAuthoringTools` carries the reasoning so B is a one-line change."
    }
  ],
  "out_of_scope_findings": [
    "class: a (user-visible copy) · reach: public door = the Console OAuth consent screen for a client requesting metadata:write; NOT browser-measured here (ui/ outside this card's fence), code-read: `ui/apps/console/src/pages/auth/OAuthConsentPage.tsx` `describeScope` switches on the three agent scopes and its default returns the raw scope string, so the new scope renders as the literal text `metadata:write` on an OSS consent page · fix shape: read `MCP_OAUTH_SCOPE_CONSENT_COPY` from @objectstack/spec instead of the switch · dedupe: OAuthConsentPage describeScope metadata:write consent copy · carrier: none (ui lane card)",
    "prose drift, below the filing bar (noted in PR Acceptance notes, not filed): `docs/qa/platform-checklist/areas/ai.json` ai.mcp-http-surface says the up-front 403 challenge names 'all three scopes'; `WWW-Authenticate` now lists four. `check-platform-checklist --changed-from` is green (anchors intact); for the QA sweep that re-derives the clause · dedupe: platform-checklist ai.mcp-http-surface three scopes · carrier: none",
    "for cloud#3302 (consumer notes, not findings): the gate reads `toolOptions.grantedScopes`, so the host must derive that list and `authoring.principal` from the same verified token (TSDoc on `McpAuthoringInjection` now says so); a registry tool whose name collides with the native surface, or repeats within the registry, throws at `registerTool` and the request fails — check names before injecting (pinned in `mcp-server-runtime.authoring-scope.test.ts`) · carrier: cloud"
  ],
  "pr_body_edits_for_the_seat": "The body was written once at cf3ec268 (dev does not PATCH). Two lines to update: the Tests intro's head reference (`cf3ec268` → `7fb21ede`, `562` → `567` tests, plus the five pins named in the hardening commit) and, in Verification, 'the command set is identical at `9c3a187a` and at the head `cf3ec268`' → add `7fb21ede` once the second gate run is cited in `gates` above."
}

Generated by Claude Code

Landed · domain:spec seat 1 (#6017) · session session_01WGufzfhobWEgUUrjz4rrbh · 2026-10-27T09:49Z

PR #26550 merged at 9bf65989 (merged 2026-10-27T09:49Z). 9bf65989 is an ancestor of origin/main. On all 15 paths the PR touched, the merge tree matches the accepted head 7fb21ede byte for byte.

The OAuth scope metadata:write is now in MCP_OAUTH_SCOPES, with consent copy for every scope in MCP_OAUTH_SCOPE_CONSENT_COPY. handleHttpRequest(request, { authoring }) lists and serves a host's authoring tools only under a verified metadata:write grant. Every call gets a fresh, frozen door/actor/principal/environment context built from the host's inputs alone. The OSS runtime injects no authoring registry, so it serves no authoring tool on any path. That injection is cloud#3302's.

Carried on: #26587 (the Console consent page renders metadata:write raw, plus the ai.json "all three scopes" prose). The host notes for cloud#3302 are in the injection TSDoc. The card closed through Fixes #26464, and this seat removes pm:dispatched.

Navigation Menu

Repository navigation

mcp: bridge the authoring ToolRegistry through the hosted HTTP MCP runtime behind a `metadata:write` OAuth scope — today `handleHttpRequest` exposes only data/action tools, so a hosted environment can be read and run over MCP but never built #26464

Context

The change

Why

Reader

Acceptance

Provenance

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:ai` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T04:57Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

mcp: bridge the authoring ToolRegistry through the hosted HTTP MCP runtime behind a metadata:write OAuth scope — today handleHttpRequest exposes only data/action tools, so a hosted environment can be read and run over MCP but never built #26464

Description

Context

The change

Why

Reader

Acceptance

Provenance

Activity

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

Triage: first grade — enhancement · security · priority:p1 · domain:server · area:ai · pm:queue · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-27T04:57Z

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

mcp: bridge the authoring ToolRegistry through the hosted HTTP MCP runtime behind a `metadata:write` OAuth scope — today `handleHttpRequest` exposes only data/action tools, so a hosted environment can be read and run over MCP but never built #26464

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:ai` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T04:57Z