Unclassified

MCP Connector, MCP Pool and Plugin Publishing

Status: Proposed
Document type: Specification
Authority: Subordinate to INTEGRATEWISE_ARCHITECTURE.md
Canonical sections implemented: §15.1 (Profile-gated exposure) · §16.1 (Nineteen tools) · §16.2 (Distribution names) · §16.3 (Distribution) · §17 (Environments)
Owner: Platform
Version: 1.0
Last verified against: HEAD d941a422
Last verified date: 2026-07-31

1. Three things that are constantly confused

They all contain the letters M-C-P. They are not the same layer, and only one of them is
ever published.

	MCP Connector	MCP Pool	Plugin / MCP Marketplace
What it is	The public boundary. Hosts the exact 19 semantic tools plus the OAuth authorization server	The internal operator control plane. `register` · `unregister` · `capabilities` · `health` · `invoke` over internal MCPs	A distribution channel
Service	`services/mcp-connector`	`services/mcp-pool`	—
Endpoint	`mcp.integratewise.ai` (prod) · `mcp.test.integratewise.ai` (test)	Internal binding only	—
Audience	Every external consumer	Operators, in `development` and `customer_zero` only	Prospective customers
Published?	The endpoint is referenced by every published manifest. The service is deployed, never distributed	Never. Not a tool surface, not a public route, not a routing target in any manifest	Publishes a package that binds to the Connector endpoint

The rule, in one line:

Pool is a control plane. Connector is the boundary. Marketplace is a channel.
Nothing published ever names the Pool.

1.1 "Pool for Customer Zero, MCP for external" — the correct and incorrect readings

This framing recurs, so both readings are recorded here with the evidence that separates them.

Correct — exposure. Pool's administration surface is exposed in development and
customer_zero, and not exposed in external. This is §15.1 and it is right.

Incorrect — substitution. Pool as Customer Zero's tool surface in place of the public
MCP. Two reasons it fails, the second decisive:

It breaks parity. Customer Zero exists to exercise the exact external contract. Exercise a
different surface and it proves nothing about the external experience.

It is not possible. Verified at HEAD: services/mcp-pool/src contains zero of the 19
semantic tools. It exposes five lifecycle verbs — register · unregister · capabilities
· health · invoke — over nine platform-management namespaces: provider.* · apps.* ·
connections.* · oauth.* · connectors.* · sync.* · webhooks.* · schemas.* ·
tasks.*. A Customer Zero running on Pool could not use IntegrateWise. It could only
administer it.

They are two different jobs, not two sizes of one thing.

	Job	Surface	Available to
IW-Spine-Network MCP	Use the product	The 19 semantic tools	Everyone — `development`, `customer_zero`, `external` — byte-identical
MCP Pool	Operate the platform	5 lifecycle verbs over 9 admin namespaces	Operators only — `development` and `customer_zero`

External users do not receive "less MCP." They receive the whole product and no
operator plane, because they do not operate the platform. Customer Zero receives the same
whole product plus the operator plane, because it does.

The test, in one question: does Customer Zero call get_my_focus through
mcp.integratewise.ai, or through Pool? Only the first preserves parity — and per the code
above, only the first is possible.

1.2 Why the Pool can never be published

Two independent reasons, either sufficient:

It breaks Customer Zero parity. Customer Zero exists to exercise the exact external
contract. If Customer Zero routes through Pool while external routes through the public
surface, Customer Zero stops proving anything about the external experience — which is its
only purpose.

It is the wrong layer. Pool binds PROVIDER_MANAGEMENT, INTEGRATION_MANAGEMENT,
TASK_MANAGEMENT and SPINE and exposes lifecycle verbs over them. It is a registry and
router for internal MCPs. It is not a semantic tool surface and cannot substitute for one.

The correct statement, which resolves D6:

The public MCP surface is byte-identical across all three profiles. MCP Pool is an
operator control plane whose administration UI is exposed only in development and
customer_zero. Pool is never a tool surface and never a per-profile alternative to MCP.

2. What gets published, per channel

Channel	Published artifact	Binds to
MCP registries / directories	IW-Spine-Network MCP — remote server reference, exact 19-tool manifest, optional UI resources, browser Workbench launch	`mcp.integratewise.ai`
Plugin directories / AI app stores	IW-Spine-Network Plugin — MCP-backed app, focused UI resources, workflow skills	`mcp.integratewise.ai`
Vercel / developer marketplaces	Channel-native listing plus the inbound provider connector where required	Gateway + `mcp.integratewise.ai`
Provider marketplaces (GitHub, Notion, Coda)	Provider-native app only where provider OAuth, installation, webhook or sync semantics require it	Gateway as a tenant connection

Both primary artifacts are channel packages over one contract. Neither is a different
backend, and neither exposes a different tool set.

2.1 Connectors are not distribution packages

A provider connector (Notion, Slack, Salesforce) is a catalogue entry, not a published
distribution artifact. It appears in the connector marketplace inside the product. It is
not listed in an external MCP registry as though it were an IntegrateWise product.

This distinction is currently blurred in releases/ — see F4.

3. Blocking findings

Verified at HEAD d941a422 on 2026-07-31. Each of these blocks submission.

F1 · The public MCP domain has two claimants

services/mcp-connector/wrangler.toml:

name   = "integratewise-mcp-connector"                                    # line 1
routes = [{ pattern = "mcp.integratewise.ai", custom_domain = true }]     # line 6

[env.prod]
name   = "mcp-connector-prod"                                            # line 224
routes = [{ pattern = "mcp.integratewise.ai", custom_domain = true }]     # line 226

The top-level Worker and env.prod claim the same custom domain. Whichever deploys last
owns it. The URL a marketplace manifest would point at therefore has an ambiguous owner, and
a routine deploy of the default environment silently repoints the public endpoint.

validate-platform-deployment.sh asserts only that mcp-connector-test and
mcp-connector-prod both exist. Existence is not uniqueness — this collision passes the
check.

Fix: remove the top-level routes block; only env.test and env.prod bind domains.
Extend the validator to assert that no two Workers claim the same route pattern.

F2 · The published manifest advertises 23 tools; the contract is 19

marketplace/apps/iw-spine-network.json:

description : "…Installs the full 23-tool continuity network — 20 operational c…"
tools        : 19 entries

Verified independently: services/mcp-connector/src defines exactly 19 unique tool names.

The 23 comes from marketplace/index.json — 20 operational + 3 cognitive connectors.
Someone counted connectors and wrote "tools." The array is right; the sentence a reviewer
reads is wrong.

This is stop-ship invariant #2: "the public MCP lists anything other than the exact 19
tools." A manifest whose own description contradicts its own tool array will not survive
review, and shouldn't.

Fix: correct the description. Add a test asserting tools.length === 19 and that no
published string claims a different count.

F3 · The public manifest names MCP Pool as its routing target

"ownership": { "credentials": "provider", "metadata": "integratewise", "routing": "mcp-pool" }

The public artifact declares the internal operator control plane as its route. Either it
is accurate — in which case the public path runs through a plane that must never be public —
or it is inaccurate, since the real public route is mcp-connector. Both readings block
submission, and the second also leaks internal topology into a customer-facing file.

Fix: "routing": "mcp-connector". Add a manifest test that fails on any occurrence of
mcp-pool, spine-cache, worker names, service bindings or internal hostnames in any file
under marketplace/.

F4 · MCP Pool has no test surface, and dev binds production

services/mcp-pool/wrangler.toml declares [env.dev] and [env.prod] — no [env.test].
All environments, including dev, bind:

service = "integratewise-integration-management-mcp-prod"

The development control plane talks to a production service. This violates §17 environment
isolation on the component with the most privilege in the system, and there is no test
surface on which to prove otherwise.

Fix: add [env.test]; repoint each environment at its own suffixed target; include
mcp-pool in the binding-isolation assertion.

F5 · A retired product name is staged for publication

marketplace/apps/iw-continuity-bridge.json is present in the publishable directory.
IW Continuity Bridge is a retired public name (D9). Publishing it revives a superseded
identity in a permanent, externally-indexed location.

Fix: delete or move out of marketplace/. Resolve D9 first if the name is genuinely still
wanted.

F6 · Five release flavours against a two-package doctrine

releases/ contains iw-spine-network-v1.0.0-20260725 as: chatgpt-plugin ·
claude-connector · js-sdk · mcp-server · notion-integration.

Doctrine (§16.2) names two published packages plus the SDK. claude-connector and
notion-integration are either channel packages needing the canonical names, or provider
connectors being shipped as though they were distribution artifacts (§2.1). Five artifacts
under one version string with no stated mapping to the two-package model is how a reviewer —
or a customer — concludes there are five products.

Fix: map every flavour to exactly one of IW-Spine-Network Plugin,
IW-Spine-Network MCP, @integratewise/sdk, or catalogue connector — not published
externally. Delete what does not map.

4. Publishing gates

No submission to any marketplace until all of the following hold.

Contract

The deployed endpoint lists exactly 19 tools, verified against the live protected resource
The transport URL is verified from the deployed resource — never taken from a document
No manifest string claims a tool count other than 19
No published file references mcp-pool, internal worker names, service bindings, D1/KV/R2 names or internal hostnames

Routing and isolation

Exactly one Worker claims mcp.integratewise.ai (F1)
mcp-connector-test and mcp-connector-prod exist, with distinct routes and distinct bindings
mcp-pool has test and prod surfaces, each bound to its own suffixed targets (F4)
No env.test target equals any env.prod target, for any binding class

Behaviour

OAuth completes end to end against the deployed resource
The onboarding state machine reaches active, with consent_required enforced
A host without MCP App UI support receives meaningful text/JSON and can launch the browser Workbench
No automatic inheritance of unrelated host-app credentials
One governed action completes: proposal → approval token → execution → receipt → reconciliation

Persistence — the gate that currently fails

Canonical writes land in Neon and a failed or skipped write cannot return success (architecture S0)

Naming

Only IW-Spine-Network Plugin, IW-Spine-Network MCP and IW Spine Tools appear as published names
No retired name is present in marketplace/ (F5)
Every artifact in releases/ maps to exactly one canonical package (F6)

5. Publication invariants

MCP Pool is never published, referenced, routed to, or named in any external artifact.
The public surface is byte-identical across development, customer_zero and external.
Exactly 19 tools. UI resources are additive and add no tools.
Exactly one Worker owns each public route.
Installing a package never clones Customer Zero data, credentials, memory, cache, queues or audit.
A provider connector is a catalogue entry, not an external distribution artifact.
A manifest's transport URL is verified against the deployed resource before submission.
Listing copy is bound by the claims register and must state that consequential action requires approval.

6. Current state

Element	State
19-tool contract in code	Implemented — 19 unique tools verified in `services/mcp-connector/src`
Public endpoint routing	Broken — two claimants on `mcp.integratewise.ai` (F1)
Published manifest	Broken — claims 23 tools; names `mcp-pool` as routing (F2, F3)
MCP Pool isolation	Broken — no test surface; dev binds prod (F4)
Retired names in `marketplace/`	Present (F5)
`releases/` ↔ package doctrine	Unmapped — five flavours, two packages (F6)
Canonical persistence behind the endpoint	Broken — architecture S0

Nothing is submittable today. F1 through F4 are each a few lines of configuration or copy;
S0 is the substantive one. The cheap fixes are worth doing in one pass because every one of
them is the kind of defect a marketplace reviewer finds in the first ten minutes — and a
rejected submission costs a resubmission window, not just a patch.