IW-Spine-Network Plugin and MCP Marketplace Contract
Status: Current derived publication and host-surface contract
Date: 2026-07-29
Authority: ARCHITECTURE_LOCK.md, IMPLEMENTATION_CONTRACT_v1.1.md and CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md
1. Locked identity
The public distribution identity is IW-Spine-Network.
It is published as two channel-native artifacts backed by one Platform and one
semantic tool contract:
| Distribution lane | Published artifact | User experience |
|---|---|---|
| Plugin marketplace / directory | IW-Spine-Network Plugin | An MCP-backed app with a focused embedded control surface, workflow skills and optional templates. The host remains the conversational controller. |
| MCP marketplace / registry / directory | IW-Spine-Network MCP | A remote MCP exposing the exact IW Spine Tools 19-tool contract, text/JSON fallback, optional focused MCP App UI and a launch path to the full browser Workbench. |
The Plugin and MCP packages are separate marketplace artifacts, but they do not
create separate backends, truth stores, tool semantics or governance paths.
Current OpenAI terminology calls the discovery surface the Plugin Directory: a plugin may include apps, skills and app templates. An app uses MCP-backed tools and may provide interactive UI inside ChatGPT. See Plugins in ChatGPT and Codex, Apps in ChatGPT and Build with the Apps SDK.
2. Shared Platform rule
Both artifacts use the deployed IntegrateWise Platform:
Host or browser
→ Descope / marketplace identity hand-off
→ Gateway tenant and membership resolution
→ Configuration + Integration + Activation
→ Operational Spine
→ Governed Canonical Spine
→ Projection / Capability contracts
→ Governance approval
→ Hermes execution
→ provider outcome and reconciliation
Installation does not copy Fortress, Gateway, Pipeline, Triage, Governance,
Hermes or the internal MCP Pool into the host.
The Customer Zero setup is the reference activation profile used to prove
the package. For an external user, installation creates or resolves an isolated
customer tenant and instantiates the same configuration/runtime shape. It never
shares Customer Zero data, credentials, memory, queues, cache or audit history.
Ordinary tenants run on shared stateless Platform Workers with strict tenant
isolation. A separate physical deployment is created only when an approved
isolation policy requires it. “Quick deploy” means tenant activation,
configuration compilation and host-surface instantiation—not an uncontrolled
clone of the Platform for every click.
3. Plugin marketplace runtime
3.1 Package contents
The IW-Spine-Network Plugin contains:
- the OAuth/identity and tenant activation contract;
- an MCP-backed app with focused interactive UI resources for tables, pickers, approvals, progress,
network status and Workbench launch; - IW workflow skills and, where supported, app templates;
- the exact 19-tool IW Spine Tools manifest;
- privacy, terms, support, screenshots, tool descriptions and reviewer
instructions.
The public MCP tool inventory behind the Plugin remains exactly 19 tools. UI
resources are additive metadata/resources; they do not expand the public tool
count.
3.2 Installation sequence
User selects IW-Spine-Network Plugin in a Plugin marketplace/directory
→ host/workspace policy permits installation
→ user reviews capabilities and connects the IW app
→ OAuth resolves existing IW identity or creates onboarding session
→ Gateway resolves or creates the isolated tenant/workspace
→ Activation applies the Customer Zero-proven reference profile
→ Spine Network discovery resolves authorised IW connections/capabilities
→ host renders the controlled IW surface above its conversation/agent runtime
→ user works through the host conversation and the IW embedded surface
ChatGPT control surface: when ChatGPT is the host, ChatGPT remains the
conversational and agent controller. The IW-created surface is a focused
controlled interface through which ChatGPT may request declared IW tools. It
does not receive IW credentials, internal pools or direct provider access.
The surface is an MCP App UI rendered in a host sandbox. It may appear above or
alongside the host experience, but it is not a DOM patch, browser extension or
replacement for ChatGPT. It cannot read the host page's DOM, cookies, local
storage or private app registry.
The host decides when to call approved IW tools. The widget may send user intent to the host, update bounded model context or call declared IW server tools through the host bridge. It never calls Neon, D1/KV, credentials, providers, Hermes or internal MCP Pool directly.
3.3 Controlling applications already connected to the host
If ChatGPT is connected to ten or twenty applications, IW-Spine-Network does
not automatically inherit those credentials or receive an unrestricted list of
them.
Applications can participate in an IW-controlled workflow through three
explicit paths:
| Path | Requirement | Persistence |
|---|---|---|
| Host composition | The host exposes the other app in the same conversation and is allowed to orchestrate it with IW | Host/session-scoped unless an outcome is explicitly stored |
| Delegated capability binding | The host provides a supported discovery/delegation contract and the user/admin grants IW the capability | Recorded as a tenant-scoped Spine Network binding with source and authority |
| Direct IW connector | The user connects the provider through IntegrateWise Connector Marketplace / Integration Manager | Persistent IW connection, synchronization, health and governed capabilities |
Discovery is therefore capability discovery, not credential scraping.
Duplicate connections to the same provider/account are grouped only after
provider workspace, account, user, tenant, authority and provenance match. The
UI shows every origin and the selected precedence/merge policy.
3.4 Controller and approval boundary
Inside ChatGPT, ChatGPT is the conversational controller and may coordinate
declared apps. IW-Spine-Network remains the continuity, context, capability and
governance boundary for IW operations.
User intent in ChatGPT
→ ChatGPT selects an approved IW tool/widget
→ IW prepares context or a proposal
→ embedded UI shows evidence, affected systems and plan
→ user explicitly approves the exact action
→ Governance mints a scoped approval token
→ Hermes executes through the authorised connector/capability
→ outcome returns to ChatGPT and re-enters the Spine lifecycle
No host, model, skill, widget or confidence threshold bypasses human approval.
4. MCP marketplace and browser Workbench runtime
The IW-Spine-Network MCP is the remote MCP package for MCP marketplaces,
registries and compatible clients. The browser Workbench is its full
standalone control surface when a host cannot or should not render the complete
product experience.
User discovers IW-Spine-Network MCP in an MCP marketplace/registry
→ connects the remote MCP server
→ completes IW authentication, tenant selection and consent
→ Activation resolves the Customer Zero-proven reference profile
→ client receives the permitted 19-tool catalog
→ ordinary MCP clients receive text/JSON results
→ compatible hosts may render focused MCP App widgets
→ Open Workbench launches the full IntegrateWise browser application
The browser Workbench communicates with Gateway through the typed frontend client and does not depend on ChatGPT to operate. Twin remains silent and contextual within that Workbench.
The MCP listing does not publish the internal 55-tool MCP Pool, raw provider
tools, credentials, internal topology or autonomous write access.
5. Provider and developer marketplace packages
Provider and developer marketplaces such as Vercel, Notion, Coda and GitHub
receive a channel-native IW package only when that marketplace requires its own
installation, OAuth, webhook, lifecycle or agent-tool semantics. These packages
do not replace the Plugin or MCP artifacts.
For the Vercel channel, publish a provider integration called
IW-Spine-Network with a native product called IW-Spine-Network MCP when
the intended user experience is to install IntegrateWise in Vercel and use its
governed Spine tools through Vercel Agent Tools.
| Published component | Why it exists | Platform implementation |
|---|---|---|
| IW-Spine-Network listing | Marketplace discovery, legal/support metadata, install entry point | Listing metadata, documentation, privacy policy, EULA, support contact, configuration and redirect URLs |
| IW-Spine-Network MCP native product | Makes the approved IW MCP tool surface available to an installed Vercel team through Agent Tools | Cloudflare-hosted native-integration server plus the OAuth-protected public IW Spine Tools MCP contract |
| Vercel connector | Brings authorized Vercel project/deployment/operational context into IntegrateWise | Integration Manager connector; it normalizes Vercel data through Pipeline and exposes governed Vercel capabilities |
| Installation and configuration surface | Lets a team choose the IW tenant/workspace, permitted Vercel projects, sync policy, and activation scope | Cloudflare-hosted configuration application; invokes Configuration, Integration, and Activation Managers |
| Webhook endpoint | Receives Vercel installation, lifecycle, and allowed resource events | Verified ingress → Gateway → Integration Manager/Pipeline; no browser-mediated secrets |
| MCP tool manifest | Declares the semantic tools exposed in Vercel Agent Tools | Maps only to the frozen public IW Spine Tools; never exposes internal Pool/provider/credential tools |
The Marketplace product and Vercel connector are two directions of one connection:
Vercel Agent Tools → IW-Spine-Network MCP native product → Gateway → permitted Spine context/capabilities
Vercel project events/data → Vercel connector → Pipeline → Spine → Workbench/Twin
5.1 Vercel installation, consent, and identity
Vercel team installs IW-Spine-Network MCP
→ Vercel installation identity is verified server-to-server
→ user signs in to IntegrateWise or creates an IW tenant
→ administrator selects target IW tenant/workspace and permitted Vercel projects
→ consent records scopes, source access, policy, and data-sharing purpose
→ Installation ↔ IW tenant/workspace ↔ Vercel connection is recorded
→ MCP tools and Vercel connector are enabled through Discovery
Required records are: Vercel installation/team reference, IW tenant/workspace reference, connection id, allowed project/resource scope, granted capabilities, consent/policy version, credential reference, and audit lineage. Secrets and access tokens remain in the credential wall; they are never published to the listing, browser, or MCP tool result.
6. Surface responsibility matrix
| Responsibility | Host surface | Browser Workbench | IntegrateWise Platform |
|---|---|---|---|
| Conversation and model interaction | Host | Optional frontend interaction only | Model/provider routing policy |
| Render focused IW controls | Host sandbox + IW UI resource | Product frontend | Supplies typed data/resources |
| Full tables/pages/canvas | Launch or bounded widget only | Owns full experience | Projection contracts |
| Identity hand-off | Host + OAuth | Descope | Gateway resolves tenant/membership |
| Capability discovery | Host-visible apps plus IW response | IW discovery response | Spine Network resolver |
| Connector credentials | Never | Never | Credential wall |
| Canonical truth | Never | Never | Neon through Governed Spine Writers |
| Proposal and approval | Shows exact plan and captures user decision | Shows exact plan and captures user decision | Governance validates and mints token |
| External execution | Never direct | Never direct | Hermes through authorised capabilities |
7. Connector marketplace distinction
The IntegrateWise Connector Marketplace is not either public distribution
lane. It is the in-product tray used to choose and authorize provider
connections.
Plugin Marketplace → install IW-Spine-Network Plugin + embedded host UI
MCP Marketplace → connect IW-Spine-Network MCP + optional widget /
standalone browser Workbench
Connector Marketplace → choose provider connectors inside IntegrateWise
Provider Marketplace → install a provider-native IW package only when provider
OAuth/webhook/installation semantics require it
8. Publication gates
Neither public artifact is publishable until Customer Zero proves:
- clean install into a new tenant;
- OAuth, consent, tenant isolation and revocation;
- exactly 19 public tools;
- embedded UI sandbox/CSP behavior and no-UI fallback;
- capability discovery with partial/failure states;
- duplicate-connection grouping and provenance;
- action evidence, explicit approval and Hermes execution;
- Operational-to-Canonical promotion and outcome reconciliation;
- privacy, support, screenshots, reviewer instructions and version rollback;
- Development, Customer Zero and Customer Production isolation.
9. Required public copy
Plugin marketplace / directory
Name: IW-Spine-Network
Package: IW-Spine-Network Plugin
Type: Plugin with MCP-backed app, focused interactive UI, workflow skills and
optional templates
Action: Install and connect
Promise: Run an IntegrateWise control surface inside the AI host while the host
remains the conversation and agent controller.
MCP marketplace / registry
Name: IW-Spine-Network
Package: IW-Spine-Network MCP
Type: Remote MCP server + optional MCP App UI
Technical surface: IW Spine Tools (exactly 19 tools)
Action: Connect MCP / Open Workbench
Promise: Connect any compatible MCP client to one governed tenant Spine Network
and open the full standalone browser Workbench when needed.
The repository, Customer Zero/external audience, deployment and promotion split
is governed by
CUSTOMER_ZERO_TO_EXTERNAL_PRODUCT_AND_MARKETPLACE_SPEC.md.