Quickstart

This walkthrough takes you from a terminal agent to a live, identity-gated MCP server. Local development needs no Noodle account; an app that declares customer auth still asks you to use that customer sign-in.

Start with Claude Code, Codex, or Cursor

The fastest path is the Noodle Seed plugin: install it once and your coding agent knows the whole workflow (scaffold, author, validate, run, deploy) from the very first prompt, in any directory.

See the developer plugin guide for Cursor, authentication, the live build-readiness widget, Noodle Cloud inspection, security boundaries, and update or removal steps.

/plugin marketplace add NoodleSeed-com/plugins
/plugin install noodle-seed@noodleseed

Codex reads the same marketplace:

codex plugin marketplace add NoodleSeed-com/plugins
codex plugin add noodle-seed@noodleseed

Cursor users can install from the Cursor Marketplace when listed, or from an administrator-configured team marketplace before listing. Then describe what you want to build, for example "Create a Claude connector for my SaaS". Sign in through OAuth when deployment needs Noodle Cloud; never paste a token into chat.

No plugin yet? Paste this prompt into your coding agent instead:

Use Noodle Seed in this project.

For a new project, run `npx --yes @noodleseed/one@latest init my-app --json`. Inspect setup.ready and any failed stage, then read the generated project-local skill and its requested reference. Resume failures with the reported command, never --force. For an existing project, reconcile with `noodle setup --write --json`; preserve unrelated files and the existing package manager.

Build a Noodle Seed server for: [describe the ChatGPT app, Claude connector, or MCP app for Codex or Claude Code I want].

Rules:
- Work inside the initialized project directory. Run every noodle command through its package-manager-local CLI (for npm: `npm exec -- noodle`); do not assume a global installation.
- Author TypeScript with the `@noodleseed/one` SDK.
- Do not hand-write manifest JSON or YAML.
- Do not hard-code secrets. Use `secret("NAME")` and tell me which `noodle secrets set` commands I need.
- Keep the implementation focused in `server.ts` unless the project already has a Noodle Seed layout.
- Reuse maintained host scaffolds, recipes and acceptance tests. Change business-specific seams, not the generated safety infrastructure.
- After every meaningful change, run the generated `agent:check` script and repair the specific failures. Synthetic checks do not prove customer authentication or real backend writes.
- Then run `noodle dev` for local testing.
- With existing sign-in and the intended target, use `noodle deploy preflight --json` to inspect setup blockers without publishing. Fixing hosted configuration still requires my approval.
- When I approve, run `noodle deploy` and show me the MCP endpoint and the `noodle connect` command for Claude, ChatGPT, Codex, or Claude Code.

The agent should install or run the CLI, create or reconcile the project, author TypeScript, validate until clean, and start local testing with noodle dev. Approve hosted deploy only when you are ready.

Manual commands

Prefer to drive it yourself? Run the same loop directly.

1. Bootstrap a project

npx --yes @noodleseed/one@latest init my-app
cd my-app

2. Inspect the starter

npm run agent:check

noodle init creates an embedded-first SaaS starter: typed tools, MCP App UI, a context-provider read, resource, prompt, caller-scoped state, branding, an authenticated website assistant and project-local agent guidance. No placeholder identity provider is created. npm test proves compilation, tool discovery, a synthetic read and invalid-input rejection without customer credentials. Demo previews do not save changes. Managed values are references—no credential value is written to source. Use --template widget, hello, or http-api only when that narrower profile is intentional.

The last command reruns checks after your edits. Failed bootstrap reports the exact stage and a safe resume command; it preserves edited files and secrets. Interactive setup can offer a fresh installed coding-agent session after verification. JSON/plugin runs never launch another agent. An existing agent must explicitly read the new project skill; generated context is not automatically loaded into its current session.

The commands below use the project's npm-installed CLI. For pnpm projects, use that manager's equivalent local execution and script commands. Global installation remains optional.

3. Validate

noodle validate compiles your server locally and checks schemas, expressions, and connector references. No account, no network.

npm run validate

4. Run it locally

noodle dev boots an in-process MCP runtime on src/server.ts with hot reload. It always binds loopback. Apps without customer auth stay open locally. Direct/federated OIDC and Firebase apps protect the MCP endpoint and show Sign in to test in Devtools; credentials remain in the local Node process. See customer auth.

npm exec -- noodle variables set ASSISTANT_ORIGIN --runtime local --scope env --org local --app my-app --env dev --from-env ASSISTANT_ORIGIN
npm run dev

First export ASSISTANT_ORIGIN with your application's exact origin. This binds local configuration only; the fixture tests use their own isolated origin. To install the existing application's maintained session route, identity seam, mount and tests, follow embedded assistant. Keep direct hosted MCP access owner-only until the separate customer-auth recipe is verified.

If your project already has a .env, matching declared secret("NAME") and variable("NAME") keys work as a read-only local fallback. Scoped .env.noodle values override them; generated projects ignore both files in git.

For a one-shot check without a client, noodle test compiles and runs a loopback MCP smoke:

npm exec -- noodle test --tool show_preferences --args '{}'

5. Connect a client

Point any MCP client at the dev endpoint. The CLI can wire up common clients for you:

npm exec -- noodle connect claude-code   # or: codex, cursor, vscode, gemini

npx @modelcontextprotocol/inspector

6. Deploy

When you are ready to share it, sign in and deploy. Hosted deploy uses your default org, the project name as the app, and the prod environment unless you override them.

npm exec -- noodle login
npm run deploy

noodle deploy compiles your server, uploads the portable artifact, and prints a governed, identity-gated MCP URL that works across assistants. Access defaults to owner-only; open it up with --access org-members (or manage it later with noodle access set).

Next steps