SparkLaunch Connected-Agent Packages

This repository builds SparkLaunch skills and native MCP package metadata for ChatGPT/Codex, Claude Code, Cursor, Gemini CLI, and Muse Code from one hand-edited source tree.

SparkLaunch helps founders select or create a business project, validate an idea, generate brand assets, publish measurable launch surfaces, review campaign and landing-page signals, operate private CRM workflows, and prepare entitlement-gated incorporation cases with person-specific Action Center tasks.

Host Support

Google's June 18, 2026 Gemini CLI notice is the source for the individual-account transition in this table. The Gemini adapter remains distinct from an Antigravity plugin.

All enabled packages connect to the same Streamable HTTP endpoint:

https://sparklaun.ch/api/mcp/

No package contains a bearer token, API key, client secret, authorization code, or static authorization header. Never add one as a workaround.

Repository Layout

• `src/skills/`: canonical, host-neutral skill source edited by hand
• `src/recipes/`: canonical multi-tool founder workflows edited by hand
• `adapters/`: native host manifests, connection recovery fragments, and distribution notes
• `contracts/tools.snapshot.json`: checked-in, runtime-derived 61-tool descriptors and input/output schemas
• `plugins/`: deterministic generated packages for all five hosts
• `sparklaunch-*/` and `recipes/`: generated OpenAI-compatible legacy mirrors retained for existing consumers
• `submission/`: ChatGPT review candidate evidence and portal-only gates
• `release-state.json`: explicit local-candidate, Registry, runtime, and distribution boundaries

Do not edit generated files under `plugins/`, the top-level `sparklaunch-*` folders, or the top-level `recipes/` folder. Edit `src/` or `adapters/`, then rebuild.

Build And Validate

Build every package and compatibility mirror:

python scripts/sync_plugin.py --write

Run standalone validation without the application repository:

python scripts/sync_plugin.py
python scripts/generate_submission.py --check
python scripts/validate_host_packages.py
python scripts/validate_submission.py
python -m pytest tests/test_host_packages.py tests/test_claude_adapter.py tests/test_cursor_adapter.py tests/test_gemini_adapter.py tests/test_muse_adapter.py -q

The checked-in tool snapshot makes a standalone `SparkLaunch-Skills` clone self-contained for package and ChatGPT submission validation. Clone the application and skills repositories as sibling directories when the MCP runtime contract changes, then refresh the snapshot from the isolated test-mode exporter. The default runtime source is `../SparkLaunch/backend`:

parent/
  SparkLaunch/
    backend/
  SparkLaunch-Skills/

python scripts/export_tool_contract_snapshot.py
python scripts/export_tool_contract_snapshot.py --check
python scripts/generate_submission.py

The exporter constructs the sibling runtime against a temporary SQLite database and records the resulting descriptors. It does not deploy the server or call a hosted SparkLaunch environment.

Portable Inputs

`incorporation.update_draft` accepts exactly one of two address-free sources:

• a closed structured `draft` object, portable across MCP hosts; or
• `draft_file`, only when the current host supplies a server-supported UTF-8 JSON file reference.

The same 256 KiB serialized limit, nested extra-field rejection, address-field rejection, expected-version check, and idempotency contract apply to both paths.

`crm.ingest_business_card` remains intentionally narrow. It accepts only a server-approved short-lived HTTPS host file reference; callers must not substitute arbitrary URLs, base64, or data URLs.

For hosts without supported attachment metadata, `crm.prepare_business_card_import` creates an expiring first-party handoff without importing anything. The founder signs in to SparkLaunch and explicitly chooses Upload and import; `crm.get_business_card_import` then reports safe status. The page, not the agent, supplies the single bounded image directly to the CRM ingestion path after current user/project access is rechecked. This service `1.4.0` contract is packaged locally; deployment and live host execution remain unverified.

OAuth portability has the same evidence boundary. Existing DCR is the production-verified registration path. Service `1.4.0` adds feature-gated Client ID Metadata Document support with bounded-fetch, SSRF, redirect, persistence/cache, and DCR-regression controls; the gate remains off in the checked-in deployment configuration, and hosted CIMD behavior is not claimed by this package build.

Shared Safety Contract

1. Authentication is managed by the host. Skills never collect credentials or transport headers.

2. `projects.list` is the source of truth for accessible projects, and project-scoped tools receive an explicit `project_id`.

3. Every write uses one stable `idempotency_key` for the exact mutation. An uncertain write is read back before any retry.

4. Project plan, project role, OAuth scope, and commercial entitlement are separate gates.

5. Destructive or public-state tools expose truthful annotations and use the runtime's governed preview/confirmation or version/idempotency boundary.

6. Generated files use short-lived HTTPS references, never raw base64 or data URLs.

7. Identifiers and concurrency versions remain opaque tool-call state; user-facing output uses human-readable names.

8. Configured assets, published state, traffic, conversion, CRM persistence, formation status, deployment, and marketplace publication are separate proof layers.

ChatGPT Candidate And MCP Registry

Build the ChatGPT portal ZIP with:

python scripts/build_submission_bundle.py

Portal-only prerequisites remain in `submission/portal-prerequisites.json`. Validate them with `python scripts/validate_portal_prerequisites.py --allow-pending` while the explicitly pending gates remain unresolved. A local package or test pass does not prove ChatGPT review, hosted deployment, OAuth behavior, or a real tool execution.

The root `server.json` is the MCP Registry descriptor for `io.github.SparkLaunch-Dev/sparklaunch`. Registry candidate version, last-known published version, runtime snapshot version, and publication status are recorded separately in `release-state.json`. Publishing an immutable Registry version requires its dedicated approved workflow and is not performed by package generation.

Current Skills

• `sparklaunch-platform`: broad founder-workflow router
• `sparklaunch-projects`: project discovery and management
• `sparklaunch-idea-validation`: market, competitor, and TAM/SAM/SOM analysis
• `sparklaunch-color-palettes`: palette generation and retrieval
• `sparklaunch-logo-generation`: logo generation and file handoff
• `sparklaunch-campaigns`: campaigns, short links, QR, attribution, and statistics
• `sparklaunch-landing-pages`: landing creation, publishing, analytics, and leads
• `sparklaunch-sales-crm`: lead, contact, deal, activity, and supported business-card workflows
• `sparklaunch-incorporation`: entitlement, address-free case preparation, private participant tasks, corrections, status, and internal Filing Operations submission

Support, Security, And License

• Support: support@sparklaun.ch
• Security reports: SECURITY.md
• Privacy: SparkLaunch Privacy Policy
• Terms: SparkLaunch Terms and Conditions
• License: SparkLaunch Proprietary License Notice

The proprietary license is preserved. In particular, generating a Cursor package does not satisfy Cursor's open-source requirement for public Marketplace submission.

Installed agent packages may be cached by plugin version. Any published package-content change therefore requires a new governed version; rebuilding a local candidate does not publish or invalidate an existing cache.