Noodle Seed developer plugin

The Noodle Seed developer plugin gives your existing coding agent the knowledge and tools to build, validate, deploy, inspect, and debug an MCP server or MCP App. Your agent still writes the application. Noodle Seed does not add a separate prompt-to-app or "vibe coding" layer.

Prerequisites

• Node.js 24 LTS or newer. Check with node --version.
• A current Claude Code, Codex, or Cursor installation with plugin support enabled.
• A Noodle Cloud account only when you are ready to deploy; local authoring, validation, and tests do not require sign-in.
• Permission to install a marketplace plugin in your host. Cursor team marketplaces may require an administrator.

Install in a coding agent

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

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

Your first prompt

Open the repository you want to use and ask:

Build an MCP app for this project with Noodle Seed. Validate it locally and show me the deployment plan before deploying.

For an existing application, describe the API or workflow the MCP app should expose. The coding agent should inspect the repository, author TypeScript, and use the plugin-managed lifecycle. It should not ask you to copy source into a separate builder.

ChatGPT and Claude use the remote Noodle Developer MCP connection. During development, connect it through the host's developer or connector flow. Once the Noodle Seed app or connector is accepted into that host's directory, users can install it from the directory without installing a terminal plugin.

What the plugin does

The boundaries are intentional:

• Your coding agent authors. Codex, Claude Code, or Cursor reads and edits server.ts and tests.
• The managed CLI operates locally. It runs a release-pinned @noodleseed/one version from an isolated plugin profile. It does not depend on or update a global noodle installation.
• The local readiness MCP explains build state. It exposes only fixed validate, test, check, and deploy operations for the current workspace. It cannot execute arbitrary shell commands.
• The remote Developer MCP operates Noodle Cloud. It reads selected organizations and environments, inspects deployments, returns redacted evidence, diagnoses failures, and performs only granted mutations.

Start a new or existing project

Ask the agent to use the installed Noodle Seed plugin and describe the MCP server or app you need.

For a new or empty directory, the plugin-managed CLI runs the logical equivalent of:

noodle init

For an existing repository, it reconciles Noodle Seed without overwriting unrelated files:

noodle setup --write
noodle agents setup --write

The generated project contains a fuller project-local noodle-seed skill. The global plugin defers to that local skill from then on, so project conventions and the installed SDK remain aligned.

Follow build readiness live

Every plugin install includes a local MCP server named noodle-readiness. It persists a sanitized, workspace-scoped state while the managed CLI executes. The Build readiness widget turns that state into one decision-first view:

• the current decision, such as blocked, needs attention, ready to deploy, or deployed;
• validate, test, MCP Apps check, and deploy stages for the current source fingerprint;
• bounded findings with the next valid action;
• active-run state and cancellation for the exact managed run.

The widget is not guessing from chat messages. Managed CLI invocations record their lifecycle in the same local store, and the widget reads that state through get_build_readiness. Its actions call fixed tools such as run_build_gate and deploy_build; they do not inject prose into the chat or open the console.

If a host does not render MCP Apps, the coding agent receives the same decision and stages as structured tool output and can continue headlessly.

Authenticate and select scope

The plugin uses the same Noodle Cloud identity as the Console and CLI. Sign in through the normal OAuth flow; never paste a bearer or refresh token into chat.

The remote connection receives a Developer Access Grant for the selected organization and environment, plus the selected application when relevant. Its capabilities are explicit, such as cloud read, deployment write, or rollback. Switching the selected organization or environment changes the grant; it does not give the plugin platform-wide access.

Local host profiles are isolated from each other. Credentials, CLI config, readiness state, and compatibility metadata are not bundled into projects or widget payloads.

Deploy, inspect, and debug

The normal autonomous loop is:

1. The coding agent edits TypeScript and tests.
2. The managed CLI runs validate --json, fixes specific structured errors, then runs test --json.
3. Widget projects also run check --json; ChatGPT targets use check --target chatgpt --json.
4. Build readiness reaches ready-to-deploy for the current source fingerprint.
5. The managed CLI deploys to the selected Noodle Cloud organization and environment.
6. The agent passes the returned deployment ID to noodle-developer.inspect_deployment.
7. When evidence indicates a fault, it calls diagnose_app and uses the cited logs, events, or metrics to guide a source fix.

A source change invalidates prior readiness evidence, so the agent must rerun the gates before another deploy. Rollback is a separate governed operation: it appears only for an eligible deployment and still passes through the grant, environment scope, compatibility check, owner recheck, and audit path.

Success criteria

You are ready to ship when all of these are true:

• the agent edited the project source and tests, not a hidden Noodle-owned copy;
• validation and tests pass for the current source fingerprint;
• MCP App projects pass the relevant noodle check target;
• Build readiness reports ready-to-deploy or returns the equivalent complete structured result;
• the agent shows the selected organization and environment before deployment;
• deploy returns a deployment ID and the Developer MCP successfully inspects it;
• no token, secret value, or raw credential appears in source, chat, logs, or widget data.

Operational widgets

The remote Developer MCP provides four responsive, self-contained MCP App resources:

The widgets use a closed content-security policy and receive only public tool results. They never receive an OAuth token, Developer Access Grant, managed credential, raw request body, or unrestricted log stream. Buttons invoke registered MCP tools through the host. They do not bypass policy, run arbitrary CLI text, or mutate cloud state directly from browser code.

See Apps & widgets for the MCP App authoring model used by your own app.

Update, repair, or remove

The marketplace release pins one compatible set of plugin, Agent Kit, CLI, and Developer MCP capability versions. Update the plugin through the host's marketplace UI or command, then restart the host session so its skill and MCP configuration are reloaded.

If a project-local skill is stale, ask the installed plugin to run:

noodle agents doctor --json
noodle agents setup --write

If the managed CLI reports a repair-safe installation problem, use noodle update --check --json first and run noodle update --yes --repair --json only when repairSafe is true. The plugin launcher itself remains release-pinned.

To remove access completely, uninstall the plugin in the host and revoke or delete its Noodle Cloud connection. Removing only the editor plugin does not revoke an independently authorized remote connection.

Troubleshooting

Compatibility and release evidence

The release archive binds the exact plugin, managed CLI, remote MCP capability, host manifests, and directory submission worksheets. Automated tests prove deterministic packaging, tamper detection, auth boundaries, headless fallbacks, and simulated Codex, Claude Code, and Cursor lifecycle behavior.

Those gates do not replace real-host evidence. Before claiming a release works in a particular ChatGPT, Claude, Codex, Claude Code, or Cursor version, run the published candidate through that exact host and record widget rendering, OAuth, deploy, inspect, and uninstall results.