# isWebMCP enterprise and partner research pack Reviewed 2026-09-05. WebMCP remains experimental. Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. These five enterprises are selected platform scenarios, not the world’s largest or best customers. The partner list is a bounded editorial shortlist, not a market ranking. Figures below are proposed fit scores or measures to collect, never customer results. ## Available today [Developer toolkit and downloads](https://iswebmcp.com/developers) · [Supported implementation recipes](https://iswebmcp.com/developers/recipes) · [Privacy and hosted data handling](https://iswebmcp.com/privacy). Review these before any pilot request. Hosted sanitized URL/outcome analytics have a 90-day retention policy, with deletion during subsequent writes. Hosted bounded public-source scans; Node SDK/CLI; local GitHub Actions adapter; imported contract lint; two starter recipes; same-input source-summary comparisons. CLI scans still send approved inputs to the hosted service. No private runner, general connected-browser verification, SSO/RBAC, tenant history, configurable hosted retention, or SLA is included. ## Proposed pilot workflow 1. **Agree on one public workflow:** Use an already-public page owned by a consenting team. Agree on data handling, a named reviewer, and what counts as a useful finding. Never weaken access controls for a scan. 2. **Save a reviewed baseline:** Run the hosted source scan through the toolkit. Keep JSON in the team’s own controlled artifact store. A report ID is not durable evidence. 3. **Review and apply one relevant fix:** A developer checks the recommendation, chooses a supported recipe if appropriate, and implements through the normal change process. No automatic code edits or deployment. 4. **Compare and decide whether to continue:** Check the same URL with matching inputs, model and complete inventories. Review false alarms, setup effort, actionable findings, and voluntary repeat usage. Task success requires a separate browser trial. ## Enterprise opportunity case studies ### Cisco: Make public support discovery easier to maintain Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. An illustrative pilot for a Cisco digital-experience team: review a public product-support finder, improve supported interface gaps, and attach source evidence to its release. No Cisco deployment has been inspected or evaluated. #### Documented context - Cisco documents a REST/JSON Product Information API with lookups by product identifier and serial number; returned fields include a product-support-page URL. ([Cisco Support APIs: Product Information](https://developer.cisco.com/docs/support-apis/product-information/)) - Cisco Support APIs require bearer tokens obtained using application credentials. That authenticated API is distinct from a public page and is not accessible through our unauthenticated scanner. ([Cisco Support APIs: Authentication](https://developer.cisco.com/docs/support-apis/authentication/)) #### Proposed workflow - A proposed owner is the product-support web team, with an API/security reviewer. They choose one already-public, non-sensitive product-discovery page and a fixed URL that can be measured consistently across releases. - Save a source baseline, triage only findings supported by collected HTML, and adapt the accessible-controls recipe where relevant. A separate search-tool experiment could wrap an owner-controlled search function; it must not expose API credentials or customer serial-number queries. - After the team approves and deploys its own changes, run the same public URL and input context again. Attach the compatible source comparison to the release ticket. Existing Cisco APIs remain the execution layer; isWebMCP does not replace them. #### Available now - Bounded public-source collection, a saved findings inventory, supported starter recipes, and local CLI comparison of complete compatible reports. The remote MCP interface can explain recipes and compare supplied summaries. - Imported tool-contract review can flag declared interface issues in a sanitized proposed search contract; it does not verify Cisco permissions, live API responses, or successful searches. #### Requires development or agreement - Authenticated support workflows, private-network execution, credential delegation, and browser task verification are not provided. A Cisco-specific search adapter and any browser WebMCP compatibility require owner engineering and separate tests. #### Risks and unknowns - Rendered search behavior may be absent from fetched HTML. Existing accessibility or API tooling may already address the findings; duplication is a reason not to expand the pilot. #### Proposed deliverables - A baseline, a reviewed remediation patch, an after-report, and a decision log that separates confirmed source changes from untested runtime hypotheses. #### Measures to collect - Proposed acceptance: both releases produce complete, comparable reports; every prioritized finding receives a fix, documented exception, or reproducible false-positive report. - Record setup time and reviewer minutes per finding. Proceed only if the owner identifies at least one useful, non-duplicative release decision; no agent-success or cost-saving result is assumed. #### Stop conditions - Stop if the useful journey requires login, serial numbers, sensitive source content, weakened access controls, or an authenticated API call from isWebMCP. Pilot scope: Proposed two-week, owner-consented pilot: one public reference page, one web engineer, one security reviewer, and two approved releases. No network configuration, support-case creation, or customer data. Public brief: https://iswebmcp.com/enterprise/scenarios/cisco-support-discovery #### Source ledger - [Cisco Support APIs: Product Information](https://developer.cisco.com/docs/support-apis/product-information/) — publication date: not established; checked 2026-09-05. - [Cisco Support APIs: Authentication](https://developer.cisco.com/docs/support-apis/authentication/) — publication date: not established; checked 2026-09-05. ### Akamai: Keep source findings attached to edge releases Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. An illustrative pilot for Akamai web-platform engineering: check an owner-approved public reference property after releases and preserve comparable source evidence. This is not an Akamai security assessment or a built-in Akamai integration. #### Documented context - Akamai Property Manager CLI supports local property-configuration changes and promotion through a pipeline, including staging and production network activation. ([Akamai Property Manager CLI](https://akamai.github.io/cli-property-manager/)) - Akamai Sandbox is an isolated environment for testing development property configurations before CDN deployment. It is not a publicly reachable test URL supplied by isWebMCP. ([Akamai: Welcome to Sandbox](https://techdocs.akamai.com/sandbox/docs/introduction-sandbox)) #### Proposed workflow - A proposed owner is an Akamai developer-experience or web-platform team maintaining a public, synthetic reference application. Keep its existing configuration validation and Sandbox tests; add our CLI as an independent evidence step for the approved public URL. - Save a complete source baseline before an owner-controlled release. Recheck that same URL after activation and after the owner confirms the intended version is served. Do not compare a staging hostname with a production hostname: our comparison requires matching final URLs and input contexts. - If a source finding changes, the application owner investigates whether markup, content, delivery, or collection conditions explain it. Supported fixes belong in the application source; do not automatically inject browser tools through edge configuration or weaken bot protection. #### Available now - Hosted, bounded public-source checks plus a local comparison artifact that identifies new or worsened reported findings. The team retains reports in its own release artifacts rather than relying on durable isWebMCP tenant history. - Accessible-controls and search-tool starter recipes can inform an application patch. They are not EdgeWorkers packages, Property Manager behaviors, or a security-policy generator. #### Requires development or agreement - Private Sandbox connectivity, browser execution, cache-version attestation, and native Akamai pipeline integration remain unbuilt. Source comparisons cannot attribute a regression to the CDN or prove an agent completed a journey. #### Risks and unknowns - Cache variation, redirects, personalization, and incomplete HTML can invalidate comparisons. The scanner does not measure edge performance, bot-policy correctness, or security effectiveness. #### Proposed deliverables - A release-step example, two before/after report pairs from the same URL, and a triage record linking each changed finding to an investigated cause or an explicit unknown. #### Measures to collect - Proposed acceptance: both report pairs meet comparison requirements; every changed finding is triaged; a deliberately seeded source-level defect in the reference application is detected and then removed. - Measure completed versus blocked scans and reviewer time. Continue only if the owner finds useful application evidence beyond existing configuration checks; these are targets, not measured results. #### Stop conditions - Stop if collection requires bypassing a challenge, altering WAF or bot rules, routing into private origins, or making an isolated Sandbox publicly accessible. Pilot scope: Proposed two-week pilot on one consented public reference property with synthetic content, one application owner, and one release engineer. Preserve all existing security and activation approvals. Public brief: https://iswebmcp.com/enterprise/scenarios/akamai-edge-release-evidence #### Source ledger - [Akamai Property Manager CLI](https://akamai.github.io/cli-property-manager/) — publication date: not established; checked 2026-09-05. - [Akamai: Welcome to Sandbox](https://techdocs.akamai.com/sandbox/docs/introduction-sandbox) — publication date: not established; checked 2026-09-05. ### Microsoft: Add evidence to an already-public Power Pages release Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. An illustrative pilot for a Power Pages engineering or reference-solutions team: review anonymous-page source and check supported fixes after release. Private sites remain private, and no Microsoft product integration is claimed. #### Documented context - Microsoft documents Power Platform CLI support for putting Power Pages configuration in source control and moving it between environments as part of CI/CD. ([Microsoft: Power Platform CLI support for Power Pages](https://learn.microsoft.com/en-us/power-pages/configure/power-platform-cli)) - Power Pages sites are private by default. Developer-environment sites cannot be made public, and tenant governance can restrict non-production visibility changes. ([Microsoft: Site visibility in Power Pages](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)) #### Proposed workflow - A proposed owner is the Power Pages reference-solutions team, supported by a tenant administrator. Select an already-approved public reference site containing only synthetic content; do not expose a development tenant to make the scanner work. - Add a bounded source check after the existing deployment workflow. Save the page findings as a release artifact and route supported label or control issues to the page-template owner. Downloaded Power Pages YAML is not an input to our hosted URL scanner. - Let the owner review and publish its own fix, then repeat the same public URL, scanner model, and input context. Compare within that stable URL; separate environments or newly generated preview URLs need their own baselines. #### Available now - Public, unauthenticated source findings; accessible-controls guidance; and SDK/CLI source comparisons. A team using GitHub Actions can adapt the existing CI example, subject to approved hosted-service access. - The MCP server can return a supported implementation recipe or compare supplied source summaries. It has no Dataverse privileges and cannot change a site or publish a Power Pages solution. #### Requires development or agreement - Authenticated portal scans, private execution, Dataverse authorization evaluation, a native Power Platform adapter, and browser journey verification are not available. There is no enterprise SSO, tenant report history, or SLA commitment. #### Risks and unknowns - Anonymous HTML does not reveal authenticated forms, Dataverse permissions, or conditional interactions. Existing platform tooling may make the extra source check redundant; the pilot must establish incremental utility. #### Proposed deliverables - A page inventory, one baseline per URL, an owner-reviewed remediation change, and comparable after-reports retained in the team release system. #### Measures to collect - Proposed acceptance: all three pages yield complete reports or an explicit unsupported outcome; supported changed pages retain compatible baselines and a documented disposition for every prioritized finding. - Measure initial setup time and whether the team voluntarily reuses the check on a second release. Zero visibility or permission changes is a mandatory boundary, not an achieved result. #### Stop conditions - Stop if the target is private, requires session cookies, contains sensitive records, or needs tenant restrictions relaxed. Do not treat an inaccessible page as an agent-readiness failure. Pilot scope: Proposed two-week pilot: one already-public synthetic reference site, three named pages, a page-template engineer, and an administrator who approves scope and hosted data handling. Public brief: https://iswebmcp.com/enterprise/scenarios/microsoft-power-pages-release-check #### Source ledger - [Microsoft: Power Platform CLI support for Power Pages](https://learn.microsoft.com/en-us/power-pages/configure/power-platform-cli) — publication date: not established; checked 2026-09-05. - [Microsoft: Site visibility in Power Pages](https://learn.microsoft.com/en-us/power-pages/security/site-visibility) — publication date: not established; checked 2026-09-05. ### Adobe: Review form-template changes before repeating them Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. An illustrative pilot for an Adobe AEM Forms reference-team workflow: identify supported source issues in one public form template, review a reusable fix, and check later releases. No conversion improvement or Adobe endorsement is claimed. #### Documented context - Adobe describes Edge Delivery Services for AEM Forms as supporting multiple authoring approaches and developer customization using HTML, CSS, and JavaScript. ([Adobe: Edge Delivery Services for AEM Forms](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/edge-delivery/build-forms/overview)) - Adobe Cloud Manager documents external-repository integration and repository events for pull-request validation, pipeline triggers, and Edge Delivery Services code synchronization. ([Adobe: Add external repositories in Cloud Manager](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/managing-code/external-repositories)) #### Proposed workflow - A proposed owner is an AEM Forms developer-experience team maintaining a synthetic enrollment reference. Choose an already-public page and identify whether the actual controls appear in fetched HTML before deciding the scanner is useful. - Check that page after an owner-controlled template deployment, save the complete baseline, and review supported control-label findings. Adapt the accessible-controls recipe in the actual component source; preserve Adobe validation, submission handlers, and existing accessibility tests. - Repeat collection at the same approved URL after the owner ships its patch. Attach source differences to the template change. For a separate catalog-search example, the search-tool recipe is only a starting point; isWebMCP supplies no AEM form-submission adapter. #### Available now - A bounded public-source findings inventory, supported remediation examples, and a saved report comparison that can accompany an existing GitHub-based release process. - Evidence is about fetched markup and declared contracts only. The team can retain JSON artifacts in its own repository or artifact store; we do not provide a customer-specific Cloud Manager plugin or durable enterprise dashboard. #### Requires development or agreement - Native AEM lifecycle integration, author-instance access, browser evaluation of conditional forms, and verified submission outcomes require additional engineering. No completed-form data should be sent to the scanner. #### Risks and unknowns - A source-level fix is not accessibility conformance, form completion, conversion lift, or browser WebMCP support. Template reuse needs explicit owner review; one passing page does not validate a portfolio. #### Proposed deliverables - A source-coverage assessment, a template-level remediation patch if a supported issue exists, before/after JSON evidence, and a documented mapping to the team existing checks. #### Measures to collect - Proposed acceptance: a deliberately seeded, source-visible label defect in the reference template is detected, corrected, and absent from the subsequent complete report; existing owner tests still pass. - Record review effort and the number of template instances the owner could safely reuse. Continue only after a second release reuses the check without manual report reconstruction; these are pilot targets, not results. #### Stop conditions - Stop if useful controls exist only after unsupported browser execution, the reference cannot remain non-sensitive, or a proposed patch would bypass established validation or accessibility controls. Pilot scope: Proposed two-week pilot on one owner-approved public reference form, with a template engineer and an accessibility reviewer. Use synthetic labels and content; exclude production leads, signatures, uploads, and form submissions. Public brief: https://iswebmcp.com/enterprise/scenarios/adobe-public-form-template #### Source ledger - [Adobe: Edge Delivery Services for AEM Forms](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/edge-delivery/build-forms/overview) — publication date: not established; checked 2026-09-05. - [Adobe: Add external repositories in Cloud Manager](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/managing-code/external-repositories) — publication date: not established; checked 2026-09-05. ### Salesforce: Evaluate a public content-discovery component Illustrative proposal—not a customer case study. No company trial, endorsement, partnership, or measured outcome is established by this research. An illustrative pilot for an Experience Cloud reference-solutions team: review a public content-discovery page and its proposed search contract. Start with source coverage and platform compatibility, not claims about Agentforce or live CRM automation. #### Documented context - Salesforce documents custom Lightning Web Components for both Aura and Lightning Web Runtime Experience Cloud sites, including Experience Builder configuration. ([Salesforce: Experience Cloud Sites and Lightning Web Components](https://developer.salesforce.com/docs/platform/lwc/guide/use-experience-cloud-overview.html)) - Published Salesforce CMS content can be displayed in Experience Builder sites through standard components, LWR data binding, or custom Lightning Web Components. ([Salesforce: Display CMS Content in Experience Builder Sites](https://developer.salesforce.com/docs/platform/cms/guide/cms-dev-display-cms-content-in-sites.html)) - Lightning Web Security also protects components in LWR sites, using a site-specific instance rather than the organization setting. ([Salesforce: Experience Builder Sites and Lightning Web Security](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-lms-ec.html)) #### Proposed workflow - A proposed owner is an Experience Cloud developer-experience team maintaining a public CMS reference application. Select one anonymous, synthetic content-discovery page; first assess whether meaningful controls are present in its fetched HTML. - Save source evidence and review a sanitized proposed search contract. If appropriate, adapt our search-tool recipe to the owner-controlled content lookup. A plain JavaScript recipe is not an installable Lightning component and must pass the owner security and lifecycle review. - After an owner-reviewed component change is published, recheck the same public URL and comparison context. Keep existing component and permission tests. An agent would still need an authorized, compatible browser connection to test the actual task. #### Available now - Hosted public-source inspection, imported contract lint, accessible-controls and search-tool recipes, and complete compatible before/after source comparisons through the CLI or remote MCP server. #### Requires development or agreement - A Salesforce-specific component adapter, Lightning Web Security compatibility testing, authenticated tenant access, and runtime outcome verification remain unbuilt. We provide no managed package, Agentforce integration, CRM connector, or authorization assessment. #### Risks and unknowns - Source visibility and browser API access are unresolved until an owner-approved pilot. Linting a declared tool does not prove discovery, correct permissions, successful lookup, or compatibility with any Salesforce agent product. #### Proposed deliverables - A source-coverage decision, a reviewed contract proposal, a compatibility checklist, and paired source reports for any owner-approved page fix. Unsupported behavior is recorded, not scored as a completed task. #### Measures to collect - Proposed acceptance: the owner confirms meaningful source coverage, triages every prioritized finding, and obtains a complete compatible comparison after a supported change. - The security reviewer must accept the proposed adapter boundary before any runtime experiment. Proceed only if a second release reuses the evidence and the owner identifies utility beyond existing component checks. #### Stop conditions - Stop if the useful page is an opaque client-rendered shell, requires login, needs security isolation disabled, or exposes non-public CMS or CRM data. Pilot scope: Proposed two-week pilot: one public synthetic CMS reference page, one component engineer, and a security reviewer. Exclude CRM records, lead creation, case updates, and authenticated content. Public brief: https://iswebmcp.com/enterprise/scenarios/salesforce-public-experience-search #### Source ledger - [Salesforce: Experience Cloud Sites and Lightning Web Components](https://developer.salesforce.com/docs/platform/lwc/guide/use-experience-cloud-overview.html) — publication date: not established; checked 2026-09-05. - [Salesforce: Display CMS Content in Experience Builder Sites](https://developer.salesforce.com/docs/platform/cms/guide/cms-dev-display-cms-content-in-sites.html) — publication date: not established; checked 2026-09-05. - [Salesforce: Experience Builder Sites and Lightning Web Security](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-lms-ec.html) — publication date: not established; checked 2026-09-05. ## Five partner prospects GoDaddy, Lovable and Cloudflare were requested starting points. Vercel and Browserbase were selected from six additional candidates to cover release checks and future runtime evidence. This constrained shortlist does not claim GoDaddy outranks every alternate. Fit scores are equally weighted editorial judgments, 0–2 per criterion: 0 = weak/unestablished, 1 = conditional, 2 = strong documented fit. Total /10 is not adoption, endorsement, integration validation, or a company-quality score. Ties favor current product fit, then reusable integration, then company name. - Current product fit: Can today’s source-check tools provide useful evidence in the proposed workflow? - Documented integration path: Is there an official, concrete extension or automation surface? - Reusable integration: Could one integration serve multiple opt-in application teams? - Pilot feasibility: Can a small consented pilot run without major unbuilt infrastructure? - Future runtime fit: Is there a plausible path to independently verified browser-task evidence? ### Other candidates screened - **Webflow:** Strong alternative for designer distribution. A dedicated app and review are still needed. Revisit before Browserbase if near-term publishing utility is the only objective. [Official integration surface](https://developers.webflow.com/apps/docs/marketplace/submitting-your-app). Reviewed 2026-09-05. - **Shopify:** A plausible merchant-enabled theme integration. Defer until one safe storefront task and a theme-specific recipe are validated; checkout and customer records are outside an initial pilot. [Official integration surface](https://shopify.dev/docs/apps/build/online-store/theme-app-extensions). Reviewed 2026-09-05. - **Checkly:** A strong monitoring alternative. Our contribution would need to be distinct source/contract evidence and independent outcome assertions, not a duplicate monitor. Remains in the separate smaller-tool prospect pipeline. [Official integration surface](https://www.checklyhq.com/docs/api-reference/checks/create-a-browser-check/). Reviewed 2026-09-05. - **Trigger.dev:** A possible later orchestration layer. The existing CI adapter already supports bounded release checks; another scheduler does not supply missing runtime verification. [Official integration surface](https://trigger.dev/docs/config/extensions/playwright). Reviewed 2026-09-05. ### Vercel: Make source evidence part of a release Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. Proposed design partnership: help one team keep a public-page baseline with each release. Start with our existing CI workflow, not a claim of a native Marketplace integration. Editorial fit: 9/10. Editorial inference, 9/10: the existing CLI/CI path can support a narrow public deployment pilot now. A documented integration channel is reusable, but native onboarding and runtime evidence are additional work, not present capabilities. - Current product fit: 2/2 - Documented integration path: 2/2 - Reusable integration: 2/2 - Pilot feasibility: 2/2 - Future runtime fit: 1/2 #### Documented context - Vercel documents third-party integrations, including testing tools, and distinguishes native Marketplace integrations from connectable accounts. ([Vercel integrations](https://vercel.com/docs/integrations)) - Deployments can have commit-specific and stable branch URLs. Deployment Protection can require authentication, which our hosted scanner does not carry. ([Accessing deployments through generated URLs](https://vercel.com/docs/deployments/generated-urls); [Deployment Protection](https://vercel.com/docs/deployment-protection)) - Marketplace review has explicit installation, security, documentation, and support requirements; an existing command-line check does not meet them automatically. ([Integration approval checklist](https://vercel.com/docs/integrations/create-integration/approval-checklist)) #### Proposed integration - An owner chooses one already-public, stable URL with useful server-returned HTML. Run the isWebMCP CLI after the deployment becomes ready, then retain the summary JSON as their CI artifact. - After a reviewed fix reaches that same URL, compare complete reports with the same scanner model and input fingerprint. Treat commit-specific preview URLs as separate targets; never rewrite their identity to force a comparison. - Start in advisory mode. A later project-scoped integration could attach findings to deployment checks only after installation, deletion, authentication, and failure-handling flows are implemented and tested. #### Available now - Public HTML scans, supported starter recipes, and developer-controlled GitHub Actions jobs. - Local comparison of compatible saved JSON reports; no Vercel account credential is required for a public-page pilot. #### Requires development or agreement - Native project selection, signed webhook handling, durable tenant-scoped evidence, and a Marketplace review package. - An authorized private runner before protected previews are eligible; never disable protection to make an audit work. #### Risks and unknowns - Changing preview URLs, caching, redirects, or analysis inputs can invalidate comparisons. - Current service limits and lack of an SLA make broad release-blocking promises premature. #### Proposed deliverables - A reproducible CI example, baseline/current artifacts, and a finding-to-fix review note. - A small integration specification describing advisory failures, retries, and target identity. #### Measures to collect - Record setup time, complete-run count, and valid-comparison count with denominators. - Ask whether the owner used a finding in a reviewed change and voluntarily reran the check on the next release. #### Stop conditions - Stop if the only meaningful target is protected or client-rendered content absent from returned HTML. - Do not block a release on an uncalibrated score or equate fewer source findings with task success. Pilot scope: Proposed scope, not a commitment: one consenting application team, one stable public search or form page, and two successive releases. Public route (not contacted): [Official integration review route](https://vercel.com/docs/integrations/create-integration/approval-checklist). The official checklist publishes integrations@vercel.com for review requests. Use it only for a qualified integration inquiry; no application or email has been sent. Public brief: https://iswebmcp.com/enterprise/partners/vercel #### Source ledger - [Vercel integrations](https://vercel.com/docs/integrations) — publication date: not established; checked 2026-09-05. - [Accessing deployments through generated URLs](https://vercel.com/docs/deployments/generated-urls) — publication date: not established; checked 2026-09-05. - [Deployment Protection](https://vercel.com/docs/deployment-protection) — publication date: not established; checked 2026-09-05. - [Integration approval checklist](https://vercel.com/docs/integrations/create-integration/approval-checklist) — publication date: not established; checked 2026-09-05. ### Cloudflare: Keep source checks and experimental browser evidence distinct Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. Proposed design partnership: a remote-MCP workflow today, plus an explicitly experimental browser-verification protocol later. Cloudflare infrastructure would be optional; isWebMCP remains on native Next.js and Vercel. Editorial fit: 8/10. Editorial inference, 8/10: explicit MCP and lab WebMCP surfaces offer strong technical complementarity. Current usefulness is conditional on a connection test; experimental runtime work and partner approval reduce immediate pilot readiness. - Current product fit: 1/2 - Documented integration path: 2/2 - Reusable integration: 2/2 - Pilot feasibility: 1/2 - Future runtime fit: 2/2 #### Documented context - Cloudflare Agents can connect to external MCP servers and discover their tools. This is ordinary remote MCP, not proof of browser WebMCP support. ([Agents: MCP tools](https://developers.cloudflare.com/agents/tools/mcp/)) - Separately, Browser Run documents WebMCP Beta in an experimental Chrome-beta lab pool and explicitly says lab sessions should not serve production workloads. ([Browser Run: WebMCP Beta](https://developers.cloudflare.com/browser-run/features/webmcp/)) - Cloudflare has a Technology Partner Program covering developer services as well as other product areas. ([Technology Partner Program](https://www.cloudflare.com/partners/technology-partners/)) #### Proposed integration - Begin with a partner-controlled Agent calling our existing remote MCP server for a chosen public URL, implementation recipe, or compatible report comparison. Confirm transport compatibility in a sandbox before describing an integration as working. - For a later lab study, use an owned test application with one low-risk search task and independent result assertions. Record the browser build, API surface, inputs, cancellations, and failures instead of treating tool discovery as completion. - Keep source observations, browser observations, and task outcomes as different evidence records. Do not pass experimental browser results into the source-only comparator or change the hosting of isWebMCP. #### Available now - A hosted remote MCP endpoint with source audit, supplied-contract review, recipes, and strict source comparisons. - A testable starter search adapter whose integration and native-browser compatibility still require developer review. #### Requires development or agreement - A browser adapter, explicit execution authorization, independent task oracle, and versioned runtime-evidence schema. - A budget, session-retention policy, compatibility check, and release policy for any experimental browser pilot. #### Risks and unknowns - The documented lab example and newer WebMCP draft APIs may diverge; pin and verify rather than copying code blindly. - Browser hosting and ordinary MCP connectivity do not themselves validate task outcomes or tenant security. #### Proposed deliverables - A reviewed remote-MCP connection example and a lab-only protocol for the same visible search task. - An explicit source-versus-runtime evidence map and a list of unsupported API or browser combinations. #### Measures to collect - Measure reproducible connections, schema-valid outputs, and independently asserted task outcomes separately. - Report unsupported, failed, and cancelled runs in the denominator; publish no speed or ROI claim without controlled measurements. #### Stop conditions - Stop if the browser API differs from the adapter contract or the task needs production credentials. - No lab-to-production promotion, site-wide automation, security bypass, or consequential action. Pilot scope: Proposed scope: one engineering reviewer and one owned, non-sensitive search fixture. Treat the browser portion as research, not an enterprise production service. Public route (not contacted): [Technology Partner Program](https://www.cloudflare.com/partners/technology-partners/). Public program page provides an Apply route for technology integrations. Eligibility and acceptance have not been established; no application has been submitted. Public brief: https://iswebmcp.com/enterprise/partners/cloudflare #### Source ledger - [Agents: MCP tools](https://developers.cloudflare.com/agents/tools/mcp/) — publication date: not established; checked 2026-09-05. - [Browser Run: WebMCP Beta](https://developers.cloudflare.com/browser-run/features/webmcp/) — publication date: not established; checked 2026-09-05. - [Browser Run overview](https://developers.cloudflare.com/browser-run/) — publication date: not established; checked 2026-09-05. - [Technology Partner Program](https://www.cloudflare.com/partners/technology-partners/) — publication date: not established; checked 2026-09-05. ### Lovable: Turn an audit finding into a reviewed builder change Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. Proposed design partnership: let a builder request an evidence-backed check, review a supported starter fix, and check the published page again. Avoid promising visibility into an authenticated or client-only application. Editorial fit: 7/10. Editorial inference, 7/10: documented MCP and GitHub surfaces make a reusable builder workflow plausible, but source visibility and untested host compatibility limit immediate coverage. It wins the tie on reusable builder distribution, not company size. - Current product fit: 1/2 - Documented integration path: 2/2 - Reusable integration: 2/2 - Pilot feasibility: 1/2 - Future runtime fit: 1/2 #### Documented context - Lovable documents custom MCP chat connectors. Chat connectors provide building context and are distinct from capabilities embedded in the published application. ([Lovable connector types](https://docs.lovable.dev/integrations/introduction); [Connect a custom MCP server](https://docs.lovable.dev/integrations/custom-mcp)) - Lovable documents GitHub synchronization and publishing to a live URL, with access settings and optional custom domains. ([Connect a project to GitHub](https://docs.lovable.dev/integrations/github); [Publish a Lovable project](https://docs.lovable.dev/features/publish)) - Its public partnership page offers a solution-partner application. It does not establish isWebMCP as an approved connector or partner. ([Partner with Lovable](https://lovable.dev/partners)) #### Proposed integration - Ask one consenting builder to connect the existing isWebMCP MCP endpoint and test tool discovery. Use a deliberately public example whose relevant form markup is present in the HTTP response. - Return a scoped finding and the corresponding recipe to the builder. The builder or coding agent may propose a change, but the owner reviews, merges, and republishes it through the normal workflow. - Save reports outside the chat and compare only the same final URL, scanner model, complete collection, and input fingerprint. A new publish URL or custom-domain redirect requires a new baseline, not a manufactured improvement. #### Available now - Remote MCP audit, supplied-contract review, two starter recipes, and compatible before/after source comparisons. - A GitHub Actions option for a connected repository; the scanner still runs on our hosted service, not inside the builder session. #### Requires development or agreement - Verified Lovable connector compatibility and a small builder-specific onboarding guide. - Rendered-browser or authorized private execution before evaluating content absent from public HTML; no automatic repair integration exists today. #### Risks and unknowns - A successful request against an HTML shell can still provide little evidence about the usable application. - Builder permissions, connector availability, and generated code changes need owner review and real integration tests. #### Proposed deliverables - A connector setup note, a finding-to-recipe prompt, and owner-reviewed before/after artifacts. - A visibility checklist that tells builders when a source scan cannot assess their rendered application. #### Measures to collect - Record whether the builder can explain the finding, locate the suggested code, and complete a reviewed change. - Count complete and comparable scans, failed calls, and voluntary repeat use; no conversion or revenue outcome is assumed. #### Stop conditions - Stop if meaningful content appears only after browser JavaScript or login and therefore is outside the scanner evidence. - Do not treat adding an MCP chat connector as enabling native browser WebMCP in the published app. Pilot scope: Proposed scope: one builder-owned public demo, one supported form or search improvement, and a second voluntary check after republishing. Public route (not contacted): [Lovable partnership opportunities](https://lovable.dev/partners). Use the solution-partner route for a qualified design-pilot inquiry or request routing to integrations. This is not evidence of a self-service connector Marketplace approval path; no message has been sent. Public brief: https://iswebmcp.com/enterprise/partners/lovable #### Source ledger - [Lovable connector types](https://docs.lovable.dev/integrations/introduction) — publication date: not established; checked 2026-09-05. - [Connect a custom MCP server](https://docs.lovable.dev/integrations/custom-mcp) — publication date: not established; checked 2026-09-05. - [Connect a project to GitHub](https://docs.lovable.dev/integrations/github) — publication date: not established; checked 2026-09-05. - [Publish a Lovable project](https://docs.lovable.dev/features/publish) — publication date: not established; checked 2026-09-05. - [Partner with Lovable](https://lovable.dev/partners) — publication date: not established; checked 2026-09-05. ### Browserbase: Design independent evidence for what an agent actually did Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. Proposed research and integration partner: develop a bounded browser-evidence adapter. This addresses an important missing capability, but it is not an integration we can offer customers as complete today. Editorial fit: 7/10. Editorial inference, 7/10: selected for the missing independent-runtime-evidence layer, not immediate turnkey coverage. The explicit integration route is useful, but an adapter and privacy review are required; it ranks below Lovable on the distribution tie-break. - Current product fit: 1/2 - Documented integration path: 2/2 - Reusable integration: 1/2 - Pilot feasibility: 1/2 - Future runtime fit: 2/2 #### Documented context - Browserbase documents remote browser sessions usable with Playwright and other automation frameworks. ([Using a browser session](https://docs.browserbase.com/platform/browser/getting-started/using-browser-session)) - Its session-replay documentation describes default recording and an option to disable recording at session creation. Replay credentials must stay server-side. ([Session replay and recording controls](https://docs.browserbase.com/platform/browser/observability/session-replay)) - The public integration submission route requests an introduction draft, quickstart draft, and code link. Browserbase also documents a remote MCP server; that alone does not establish native browser WebMCP support. ([Partner with Browserbase](https://www.browserbase.com/partner); [Browserbase MCP server](https://docs.browserbase.com/integrations/mcp/introduction)) #### Proposed integration - Begin with an owned fixture and a developer-run browser harness, not arbitrary enterprise sites. Collect a source report separately, then assert the visible result of one low-risk search in the browser. - Design an evidence envelope containing task version, browser version, permitted origin, exact assertions, timestamps, and outcome. A recording explains behavior but cannot substitute for an independent correctness assertion. - Test browser feature availability before attempting native WebMCP execution. Browser automation exposed through an MCP server is a different mechanism; missing native support must be reported as unsupported, not silently emulated. #### Available now - Existing source baselines, supplied-contract lint, and starter recipes can seed a carefully scoped fixture experiment. - The current source comparator can compare eligible source artifacts only; it cannot consume replay files or certify a browser task. #### Requires development or agreement - A real browser adapter and independent outcome assertions, with cancellation, allowlisted origins, timeouts, and action approval. - Credential isolation, explicit recording consent, retention/deletion controls, cost caps, and a runtime evidence export format. #### Risks and unknowns - A future runtime adapter needs significant work; treating this prospect as a shipped feature would mislead users. - Recorded sessions may contain sensitive data. A browser vendor capability is not an isWebMCP governance guarantee. #### Proposed deliverables - A runnable adapter prototype with failing, passing, cancelled, and unsupported test cases. - A scrubbed example evidence record plus introduction and quickstart drafts for eventual integration review. #### Measures to collect - Check that deliberately wrong search results fail the independent assertion even when the tool call succeeds. - Measure assertion reproducibility, artifact completeness, run duration, and actual browser cost; do not invent savings. #### Stop conditions - Stop before execution if permission, recording policy, browser compatibility, or budget is unresolved. - Do not publish sessions, credentials, or third-party content; never enable anti-bot evasion to complete a test. Pilot scope: Proposed scope: a small technical spike on one owned search fixture, using a consenting partner account and a pre-agreed spending cap. No production customer sessions. Public route (not contacted): [Suggest a Browserbase integration](https://www.browserbase.com/partner). Public form asks for introduction, quickstart, and code links. Prepare those artifacts before a formal submission; no form has been filled or submitted. Public brief: https://iswebmcp.com/enterprise/partners/browserbase #### Source ledger - [Using a browser session](https://docs.browserbase.com/platform/browser/getting-started/using-browser-session) — publication date: not established; checked 2026-09-05. - [Session replay and recording controls](https://docs.browserbase.com/platform/browser/observability/session-replay) — publication date: not established; checked 2026-09-05. - [Get started with integrations](https://docs.browserbase.com/integrations/get-started) — publication date: not established; checked 2026-09-05. - [Partner with Browserbase](https://www.browserbase.com/partner) — publication date: not established; checked 2026-09-05. - [Browserbase MCP server](https://docs.browserbase.com/integrations/mcp/introduction) — publication date: not established; checked 2026-09-05. ### GoDaddy: Give agencies a repeatable public-page improvement service Researched prospect—not an existing partner. Integration fit is our inference from official sources. No outreach has been sent for this shortlist. Proposed channel pilot: an agency uses source findings and reviewed fixes in a client handoff. Start with owner-approved public pages, not a claim of an official GoDaddy dashboard extension or automatic site repair. Editorial fit: 5/10. Editorial inference, 5/10: a repeatable agency service is plausible, but builder customization and program eligibility constrain the route. Included as the requested agency-channel hypothesis, not because scale proves adoption or technical readiness. - Current product fit: 1/2 - Documented integration path: 1/2 - Reusable integration: 2/2 - Pilot feasibility: 1/2 - Future runtime fit: 0/2 #### Documented context - GoDaddy describes an Agency Partner Program and a central Hub for agency tools. Its stated entry requirements include being a GoDaddy customer using the Hub and showing agency service capability. ([Agency Partner Program and eligibility](https://www.godaddy.com/pro/agency-partners)) - Websites + Marketing documentation permits custom HTML, CSS, and JavaScript sections, while warning that embedded code can affect site behavior. ([Add HTML or custom code to a site](https://www.godaddy.com/en-ca/help/add-html-or-custom-code-to-my-site-27252)) - A developer platform provides domain and commerce APIs. That is not evidence of an API for rewriting website-builder pages or installing a browser WebMCP adapter. ([GoDaddy developer platform](https://developer.godaddy.com/en)) #### Proposed integration - An agency and its client approve a short list of already-public pages. Run bounded individual checks and present the exact source limitation with each recommendation; do not crawl a client portfolio. - The agency maps findings to changes supported by the actual product: an editable form label, a reviewed custom section, or a developer-owned component. Verify frame boundaries and script behavior before considering any search-tool adapter. - After the client approves publication, repeat the same URL and analysis inputs. Package the saved JSON and a plain-language change note into the agency handoff; do not sell a badge as certification. #### Available now - A public-page audit, supported starter code, and local before/after report comparison usable by an agency today. - A manual report-and-remediation workflow that does not need access to the client GoDaddy account. #### Requires development or agreement - Product-specific recipe validation; a custom-code section does not guarantee access to the main document or built-in application behavior. - A genuine agency design partner, explicit client consent, and any separately approved dashboard integration. No such integration has been built. #### Risks and unknowns - An agency program is not a technology Marketplace; isWebMCP eligibility and vendor-level sponsorship are unconfirmed. - Different GoDaddy products expose different customization surfaces. One working example must not become a universal support claim. #### Proposed deliverables - An agency checklist, client-readable findings, and a reviewed remediation handoff. - Baseline/current JSON plus an applicability matrix separating Websites + Marketing from developer-controlled hosting. #### Measures to collect - Measure agency setup time, supported versus unsupported recommendations, and accepted fixes with denominators. - Ask whether the agency repeats the workflow in a subsequent maintenance cycle; do not assume client leads or revenue increase. #### Stop conditions - Stop if the builder cannot safely apply the proposed change or important content is inside an inaccessible frame. - Do not change accounts, DNS, access settings, or client code without the owner’s separate approval. Pilot scope: Proposed scope: one consenting agency, one consenting client, and one public lead-generation page with a supported source-level improvement. Public route (not contacted): [GoDaddy Agency Partner Program](https://www.godaddy.com/pro/agency-partners). A public application route exists for qualified agencies using GoDaddy and the Hub. First establish fit or seek an existing agency collaborator; this is not a verified technology-integration intake. Public brief: https://iswebmcp.com/enterprise/partners/godaddy #### Source ledger - [Agency Partner Program and eligibility](https://www.godaddy.com/pro/agency-partners) — publication date: not established; checked 2026-09-05. - [Add HTML or custom code to a site](https://www.godaddy.com/en-ca/help/add-html-or-custom-code-to-my-site-27252) — publication date: not established; checked 2026-09-05. - [GoDaddy developer platform](https://developer.godaddy.com/en) — publication date: not established; checked 2026-09-05. # isWebMCP enterprise pilot worksheet Status: proposed pilot; no results collected. Complete and retain privately. ## Owner approval - Application owner and technical reviewer: - Approved public URL (no secrets in path or query): - One workflow and known expected result: - Data-processing approval, including hosted sanitized URL/outcome retention of 90 days, with deletion during subsequent writes: - Confirmation that no access controls will change for this pilot: - Allowed request budget, review window, and stop contact: ## Evidence files (owned by the adopting team) - Baseline artifact location and access policy: - Current artifact location: - Comparison artifact location: - Artifact retention and deletion owner: - Matching final URL, model version, input fingerprint, complete collection/inventory: ## Human review - Finding and supporting evidence: - Relevant recipe, or reason neither current recipe applies: - Authorized local change and deployment reference: - Is the finding actionable, a false alarm, or unresolved? Reviewer and rationale: - Did the same reported issue change? Missing evidence is not proof of a fix: ## Measures to collect, not promised results - Setup minutes and integration effort: - Number of reviewed findings, actionable findings, false alarms, and unresolved items: - Comparable / inconclusive check counts and reasons: - New or worsened source findings after changes: - Whether the team voluntarily retained and reused the check: - Browser task success / latency / interventions: NOT MEASURED unless a separate authorized trial exists: ## Stop / continue - Stop on sensitive inputs, incomplete evidence, unapproved requests, or no useful source visibility. - Continue only after a reviewer confirms concrete utility and accepts the operating limits. - Company name, quotation, logo, and result publication each require explicit written permission. - No security certification, WebMCP conformance, market-adoption claim, or ROI is inferred from these checks.