diff --git a/plugins/major-build/.claude-plugin/plugin.json b/plugins/major-build/.claude-plugin/plugin.json index e8636e4..9351601 100644 --- a/plugins/major-build/.claude-plugin/plugin.json +++ b/plugins/major-build/.claude-plugin/plugin.json @@ -7,5 +7,6 @@ }, "repository": "https://github.com/major-technology/cli", "license": "MIT", - "skills": "./skills/" + "skills": "./skills/", + "mcpServers": "./.mcp.json" } diff --git a/plugins/major-build/.mcp.json b/plugins/major-build/.mcp.json new file mode 100644 index 0000000..2d02771 --- /dev/null +++ b/plugins/major-build/.mcp.json @@ -0,0 +1,10 @@ +{ + "major": { + "type": "http", + "url": "${MAJOR_MCP_URL:-https://mcp.major.build/mcp}", + "headers": { + "x-major-jwt": "${MAJOR_RESOURCES_API_TOKEN:-}" + }, + "alwaysLoad": true + } +} diff --git a/plugins/major-build/skills/agent-builder/SKILL.md b/plugins/major-build/skills/agent-builder/SKILL.md index 0a2708e..53f6f46 100644 --- a/plugins/major-build/skills/agent-builder/SKILL.md +++ b/plugins/major-build/skills/agent-builder/SKILL.md @@ -15,36 +15,36 @@ prompt.md the system prompt — the file IS the prompt, no wrapper If you don't have enough information to write a good system prompt or pick connectors, ask the user — it is better to ask than to guess. -Orchestrator tools are `mcp__orchestrator-platform__*` (`list_editable_agents`, `mount`, `create_agent`, `get_agent`, `publish`). File editing and sync go through the sandbox tools `mcp__sandbox__*` (`read_file`, `edit_file`, `write_file`, `pull`, `push`, `validate`), each called with `agent: ""` as the target. `publish` takes the same `agent` argument. +Finding, creating, and opening agents is on `mcp__plugin_major-build_major__*` (`list_agents`, `create_agent`, `start_sandbox`); orchestrator tools are `mcp__orchestrator-platform__*` (`get_agent`, `publish`). File editing and sync go through the sandbox tools `mcp__plugin_major-build_major__sandbox_*` (`sandbox_read_file`, `sandbox_edit_file`, `sandbox_write_file`, `sandbox_pull`, `sandbox_push`, `sandbox_validate`), each called with `agent: ""` as the target. `publish` takes the same `agent` argument. ## The working files, saving, and publishing The working copy lives on the agent's sandbox under the workspace root. Two separate steps take it off the sandbox: -- **Save** (`push`) validates the bundle and writes it as a new immutable version. Nothing the agent runs changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** +- **Save** (`sandbox_push`) validates the bundle and writes it as a new immutable version. Nothing the agent runs changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** - **Publish** (`publish`) points the agent at its latest saved version. This makes the agent live. An agent with no published version can't be run deployed at all — starting a session against it fails with "no published version yet". So a brand-new agent needs one `publish` before anyone can use it. -Always use an `agentId` returned by `list_editable_agents` or `create_agent` — never invent one. If this chat is pinned to an agent, the "Working with this agent" section of your system prompt carries the bound-chat rules (omit ids to target it). +Always use an `agentId` returned by `list_agents` or `create_agent` — never invent one. If this chat is pinned to an agent, the "Working with this agent" section of your system prompt carries the bound-chat rules (omit ids to target it). ## Save discipline -- **Never `pull` routinely** — it overwrites the sandbox files with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover corrupted files or on the user's explicit ask to discard. -- **Always `push` before you finish a turn in which you edited files.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about what the agent runs. +- **Never `sandbox_pull` routinely** — it overwrites the sandbox files with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover corrupted files or on the user's explicit ask to discard. +- **Always `sandbox_push` before you finish a turn in which you edited files.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about what the agent runs. - **Publish only when the user asks for it.** That is the moment the agent's behaviour changes for everyone. ## Lifecycle -- **Edit existing**: `list_editable_agents` to find it, then `mount({agent: ""})` — it mounts (or joins) the agent's sandbox. Edit the two files with the sandbox tools, saving as you finish each round. +- **Edit existing**: `list_agents` to find it, then `start_sandbox({agent: ""})` — it mounts (or joins) the agent's sandbox. Edit the two files with the sandbox tools, saving as you finish each round. - **New**: `create_agent({name, description})` — creates the agent (server-minted `agentId`), mounts its sandbox seeded with a scaffold bundle, and returns where the files live. -- **Check a draft**: `validate` — parses `agent.jsonc` against the schema without saving. Saving validates too (and additionally checks that every referenced skill/connector/app exists in the org); on failure nothing is saved and the error list comes back. -- **Save**: `push({notes})` — every save writes a new immutable version. -- **Publish**: `publish({agent})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `agentId` you passed to `push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. +- **Check a draft**: `sandbox_validate` — parses `agent.jsonc` against the schema without saving. Saving validates too (and additionally checks that every referenced skill/connector/app exists in the org); on failure nothing is saved and the error list comes back. +- **Save**: `sandbox_push({notes})` — every save writes a new immutable version. +- **Publish**: `publish({agent})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `agentId` you passed to `sandbox_push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. ## `agent.jsonc` -The definition shape — fields, the allowed model ids, permission decisions — is the JSON Schema the Major API serves at `GET https://api.prod.major.build/public/agent.schema.json`, the single source of truth. YOU MUST CURL THIS SCHEMA BEFORE WRITING `agent.jsonc`; its `x-validatorRules` carry the rules beyond shape (membership grants access, ids must exist in the org, bundle is exactly the two files). `validate` and every `push` enforce all of it, with errors naming the offending path. +The definition shape — fields, the allowed model ids, permission decisions — is the JSON Schema the Major API serves at `GET https://api.prod.major.build/public/agent.schema.json`, the single source of truth. YOU MUST CURL THIS SCHEMA BEFORE WRITING `agent.jsonc`; its `x-validatorRules` carry the rules beyond shape (membership grants access, ids must exist in the org, bundle is exactly the two files). `sandbox_validate` and every `sandbox_push` enforce all of it, with errors naming the offending path. ## Tool permissions @@ -66,8 +66,8 @@ On Slack there is no panel. Tell the user to open the agent in the web app to fi ## Picking connectors and applications -- Use `mcp__resources__execute_resource_tool` with `toolName: "mcp__resources__list_resources"` to list the org's connectors; `mcp__orchestrator-platform__list_edit_apps` lists attachable apps. **Use `list_edit_apps`, not `list_use_apps`** — an agent can only be granted apps the user can edit. -- If no existing connector matches, call `mcp__interactions__request_resource_setup` to prompt the user to create one inline. `connectorId` is required — pass one you already know (e.g. `"postgresql"`, `"snowflake"`) or use `mcp__resources__execute_resource_tool` with `toolName: "mcp__resources__search_connector_types"` to discover the connectors you can set up; ask if unsure. The tool blocks until the user finishes or declines; on success add the returned `resourceId` to `connectors` in `agent.jsonc`. +- Use `mcp__plugin_major-build_major__execute_resource_tool` with `toolName: "mcp__resources__list_resources"` to list the org's connectors; `mcp__plugin_major-build_major__list_apps` lists attachable apps. **Use `list_apps`, not `list_use_apps`** — an agent can only be granted apps the user can edit. +- If no existing connector matches, call `mcp__interactions__request_resource_setup` to prompt the user to create one inline. `connectorId` is required — pass one you already know (e.g. `"postgresql"`, `"snowflake"`) or use `mcp__plugin_major-build_major__execute_resource_tool` with `toolName: "mcp__resources__search_connector_types"` to discover the connectors you can set up; ask if unsure. The tool blocks until the user finishes or declines; on success add the returned `resourceId` to `connectors` in `agent.jsonc`. - Slack is provisioned automatically when the user installs the Major Slack integration (Settings → Integrations) and is intentionally not a creatable connector — if it's missing from `list_resources`, tell them to install the integration. - If an existing connector needs more configuration to be usable (e.g. selecting a Google Sheets spreadsheet), call `mcp__interactions__request_resource_update` with the `resourceId` and what's missing. - After adding skills, call `list_suggested_connectors` — it returns connectors the attached skills' scripts actually use that the agent can't access yet. Propose them to the user and add accepted ones to `connectors`; a skill whose connector is missing will fail at runtime. Entries with `canAdd=false` need access the current user doesn't have — tell them to ask an admin. @@ -77,7 +77,7 @@ On Slack there is no panel. Tell the user to open the agent in the web app to fi A good system prompt names the actual tables, endpoints, and fields the agent will use — not "query the database". Probe what you attached before writing: -- **Connectors:** pass the matching canonical `mcp__resources__*` tool name to `mcp__resources__execute_resource_tool` — `information_schema` + a few sample rows for SQL databases, object/property lists for CRMs, bucket/key listings for S3, an introspection or health call for APIs. Canonical resource tools are execution targets, not directly callable tools. Stop once you can write a confident prompt — you're not building a data dictionary. +- **Connectors:** pass the matching canonical `mcp__resources__*` tool name to `mcp__plugin_major-build_major__execute_resource_tool` — `information_schema` + a few sample rows for SQL databases, object/property lists for CRMs, bucket/key listings for S3, an introspection or health call for APIs. Canonical resource tools are execution targets, not directly callable tools. Stop once you can write a confident prompt — you're not building a data dictionary. - **Applications:** call `get_app_skill({applicationId})` first (it returns the endpoints and request/response shapes — usually enough). Probe live endpoints with `do_get_request` only if something is still unclear, and never issue writes via `do_requests` just to learn a shape — ask the user first. Then cite what you found in `prompt.md`: "query `analytics.daily_sessions` filtered by `user_id`", not "ask the database about sessions". A good prompt is 5–20 lines — if the user gives you a one-liner, draft a proper prompt yourself, after the research, not before. diff --git a/plugins/major-build/skills/app-builder/SKILL.md b/plugins/major-build/skills/app-builder/SKILL.md index dcef88e..bca0183 100644 --- a/plugins/major-build/skills/app-builder/SKILL.md +++ b/plugins/major-build/skills/app-builder/SKILL.md @@ -9,16 +9,16 @@ An _app_ on Major is a full-stack Next.js app: frontend and backend API routes, Treat apps as **compute**. Whenever you need to run code, use an app. Apps also visualize results for the user. Offload deterministic behavior into the app; agents and workflows call it. -The main way to work on an app is to mount its sandbox onto this chat and edit it yourself. Orchestrator tools are `mcp__orchestrator-platform__*` (`list_edit_apps`, `create_app`, `mount`, `list_sandboxes`, `unmount_app_sandbox`). File and shell work go through the `mcp__sandbox__*` tools — the "Working with sandboxes" section of your system prompt covers the tools, argument conventions, provisioning, shared-sandbox etiquette, and local-file uploads; an app's target argument is `slug`. Run `major` CLI commands through `mcp__sandbox__bash` inside the mounted app workspace; they infer the app from the working directory, so do not pass an app ID or run them in the agent's local filesystem. Deployment and app-to-agent wiring still use major-app MCP tools. +The main way to work on an app is to mount its sandbox onto this chat and edit it yourself. Finding, creating, opening, and closing apps is on `mcp__plugin_major-build_major__*` (`list_apps`, `create_app`, `list_sandboxes` for what is mounted, `start_sandbox`, `stop_sandbox`). File and shell work go through the `mcp__plugin_major-build_major__sandbox_*` tools — the "Working with sandboxes" section of your system prompt covers the tools, argument conventions, provisioning, shared-sandbox etiquette, and local-file uploads; an app's target argument is `slug`. Run `major` CLI commands through `mcp__plugin_major-build_major__sandbox_bash` inside the mounted app workspace; they infer the app from the working directory, so do not pass an app ID or run them in the agent's local filesystem. Deployment and app-to-agent wiring still use major-app MCP tools. -You are in general chat — **nothing is bound to this thread**, and a sandbox is not always mounted. Always use an `applicationId` returned by `list_edit_apps` or `create_app` — never invent one. If the app you need is not in `list_sandboxes`, mount it (`mount({app: ""})`) or create it (`create_app`) before using `mcp__sandbox__*` tools. +You are in general chat — **nothing is bound to this thread**, and a sandbox is not always mounted. Always use an `applicationId` or `slug` returned by `list_apps` or `create_app` — never invent one. If the app you need is not in `list_sandboxes`, start it (`start_sandbox({slug: ""})`, or `app: ""`) or create it (`create_app`) before using `mcp__plugin_major-build_major__sandbox_*` tools. If this chat is already pinned to an app (the "Working with this app" section of your system prompt), its sandbox is auto-mounted — skip create/mount and edit that app through the sandbox tools with its slug. ## Lifecycle -- **Edit existing**: `list_edit_apps` to find it, then `mount({app: ""})`. This wakes the app's sandbox, attaches it to this chat, and starts a live preview. A `locked` result means another user holds the app — tell the user who; do not retry in a loop. -- **New**: `create_app({name, description})` with a short name and a one-sentence description. It returns the new `applicationId` and automatically mounts the sandbox — you do **not** need to call `mount`. For a brand-new app's first iteration, load the `new-project` skill and follow it before writing code. +- **Edit existing**: `list_apps` to find it, then `start_sandbox({slug: ""})`. This wakes the app's sandbox, attaches it to this chat, and starts a live preview. A `locked` result means another user holds the app — tell the user who; do not retry in a loop. +- **New**: `create_app({name, description})` with a short name and a one-sentence description. It returns the new `applicationId` and automatically mounts the sandbox — you do **not** need to call `start_sandbox`. For a brand-new app's first iteration, load the `new-project` skill and follow it before writing code. - **Save**: commit and push on `main` using the sandbox shell tool. Stage only the files you changed (`git add `) — never `git add -A` or `git add .`: other chat sessions may be editing the same workspace. Never run `git stash` (or `git stash push` / `git stash pop` / `git stash apply`). Never create feature branches. - **Deploy**: a separate, explicit step — do **not** call `deploy_app` unless the user asked to deploy/publish/ship in this conversation. Finishing an edit means committing and pushing on `main`, then telling the user the change is ready to deploy. When they do ask, batch all finished changes into a single deploy. A deploy builds for ~2 minutes — tell the user it is building and end your turn; never poll `major app info` in a loop. @@ -30,10 +30,10 @@ The preview dev server is ALREADY running in the sandbox and hot-reloads on save - NEVER run `next build`, `pnpm build`, `npm run build`, or `yarn build`. Only run a build if you are specifically debugging a build issue. - NEVER delete or remove the `.next` directory — it crashes the preview server and the entire session. -- To check for errors, run lint (through `mcp__sandbox__bash`) instead of building. After you finish editing, always run a lint check and fix what it reports — lint failures will fail a deploy. Lint ONCE per finished change, not after every file edit. +- To check for errors, run lint (through `mcp__plugin_major-build_major__sandbox_bash`) instead of building. After you finish editing, always run a lint check and fix what it reports — lint failures will fail a deploy. Lint ONCE per finished change, not after every file edit. - When using parallel subagents, each subagent should ONLY write code and run lint. Do NOT have subagents run build commands. -The preview/sandbox runtime has these environment variables available — use `mcp__sandbox__bash` with curl to hit the APIs you write: +The preview/sandbox runtime has these environment variables available — use `mcp__plugin_major-build_major__sandbox_bash` with curl to hit the APIs you write: - `MAJOR_API_BASE_URL` — the base url of the Major API - `MAJOR_JWT_TOKEN` — the JWT token for the Major API @@ -43,7 +43,7 @@ The preview/sandbox runtime has these environment variables available — use `m Every tool result you pull into this chat is re-read on each later step, so keep results small: -- Don't re-read files you just read or wrote — the content is already in your context. For large files, page with `mcp__sandbox__read_file`'s offset/limit instead of re-reading the whole file. +- Don't re-read files you just read or wrote — the content is already in your context. For large files, page with `mcp__plugin_major-build_major__sandbox_read_file`'s offset/limit instead of re-reading the whole file. - Push bulk lookups to subagents and have them return conclusions only: database verification queries (postgresql_psql), broad code exploration, and log digging. Don't run row-dump queries in the main chat. - Do not verify the UI unless explicitly asked. Playwright verification is costly and should be used sparingly. - When dispatching a subagent (or running a workflow of subagents), explicitly select its model instead of leaving it unset. Prefer a smaller/cheaper model (e.g. haiku) for routine work — bulk lookups, log digging, simple code exploration, mechanical edits — and reserve a larger model for tasks that genuinely need deeper reasoning (architecture decisions, tricky debugging, ambiguous requirements). @@ -69,7 +69,7 @@ Run `major app theme get` in the app workspace before frontend work. It returns Two playbooks — use the relevant one before you start: - Load the `debug-issue` skill whenever you're investigating a failure, regression, or broken/blank/errored behavior in the app (covers the preview, app errors, logs, and browser inspection). -- Read [references/using-agents.md](references/using-agents.md) (in this skill's directory) when wiring the app's runtime code to trigger Major agents (run / sendMessage / stop / approvals; `add-agent-client` generates the typed client, same pattern as resource clients). +- Read [references/using-agents.md](references/using-agents.md) (in this skill's directory) when wiring the app's runtime code to trigger Major agents (run / sendMessage / stop / approvals; `sandbox_add-agent-client` generates the typed client, same pattern as resource clients). ## Recurring work @@ -81,7 +81,7 @@ App code can call LLMs through Major's AI proxy — no API key needed, spend is ## Inspecting -Run these commands in the mounted app workspace through `mcp__sandbox__bash`: +Run these commands in the mounted app workspace through `mcp__plugin_major-build_major__sandbox_bash`: - `major app info --json` — deployment status, the deployed URL, and visibility - `major app logs --preview` — preview/dev-server output diff --git a/plugins/major-build/skills/app-builder/references/using-agents.md b/plugins/major-build/skills/app-builder/references/using-agents.md index 98649ee..759d8a0 100644 --- a/plugins/major-build/skills/app-builder/references/using-agents.md +++ b/plugins/major-build/skills/app-builder/references/using-agents.md @@ -8,9 +8,9 @@ A **run is a chat thread.** The `chatThreadId` returned by `run()` is the `runId ## Generated clients — never hand-write them -Always call `add-agent-client` first (find the id with the `list_agents` tool). It generates a typed singleton into `clients/` and returns the import line — **use that import VERBATIM**. Do not `createAgentsClient()`, do not `getAgentId()`, do not bake a uuid. The generated client already binds the agent id. +Always call `sandbox_add-agent-client` first (find the id with the `list_agents` tool). It generates a typed singleton into `clients/` and returns the import line — **use that import VERBATIM**. Do not `createAgentsClient()`, do not `getAgentId()`, do not bake a uuid. The generated client already binds the agent id. -To stop triggering an agent, delete the code that references it and call `remove-agent-client`. +To stop triggering an agent, delete the code that references it and call `sandbox_remove-agent-client`. ## If the agent should post back into the app @@ -83,7 +83,7 @@ The package throws typed errors — branch on them rather than parsing messages: - **`AgentRunNotActiveError`** (from `sendMessage` on a finished run): the run has completed and the pod is gone. Start a fresh run with `run()` rather than retrying the message. - **`AgentNotFoundError`**: unknown run/agent id — also thrown by `respondToApproval` when the approval is no longer pending (already answered, or it expired and auto-denied). Re-fetch with `listPendingApprovals` and re-render. -- **`AgentsAuthError`**: the runner lacks `agent:use`, or the generated client is missing / stale. Re-run `add-agent-client`. +- **`AgentsAuthError`**: the runner lacks `agent:use`, or the generated client is missing / stale. Re-run `sandbox_add-agent-client`. - **`AgentsValidationError`**: bad input (missing `prompt` / `message`). ```typescript diff --git a/plugins/major-build/skills/debug-issue/SKILL.md b/plugins/major-build/skills/debug-issue/SKILL.md index df309c2..cd4f813 100644 --- a/plugins/major-build/skills/debug-issue/SKILL.md +++ b/plugins/major-build/skills/debug-issue/SKILL.md @@ -33,15 +33,15 @@ Prefer direct evidence over guesses. Use the most relevant tools below. The app's preview is always served at `http://localhost:3000`. There is no other port or host to discover — navigate, screenshot, and read logs against that URL every time. -Always check app errors and app logs before opening Playwright. `major app errors list` and `major app logs` explain almost every server, route handler, and runtime failure without needing the browser. Run these CLI commands through `mcp__sandbox__bash` in the mounted app workspace; load `app-builder` if you need to mount it first. Only open the browser when the bug is purely visual, layout-related, or only observable from the rendered page. +Always check app errors and app logs before opening Playwright. `major app errors list` and `major app logs` explain almost every server, route handler, and runtime failure without needing the browser. Run these CLI commands through `mcp__plugin_major-build_major__sandbox_bash` in the mounted app workspace; load `app-builder` if you need to mount it first. Only open the browser when the bug is purely visual, layout-related, or only observable from the rendered page. When you do use Playwright, you are limited to **looking at the page**, not driving it: -- ✅ `mcp__sandbox__browser_navigate` — open a URL on `http://localhost:3000`. -- ✅ `mcp__sandbox__browser_take_screenshot` — capture the rendered page. Always save under `/workspace/.session-files/`; never use `/workspace/app`, repo paths, or relative paths. -- ✅ `mcp__sandbox__browser_snapshot` — accessibility snapshot for reading text/structure. -- ✅ `mcp__sandbox__browser_wait_for` — wait briefly for a pending/loading state to settle before re-screenshotting. -- ✅ `mcp__sandbox__browser_console_messages` — read the browser console when investigating client-side errors. +- ✅ `mcp__plugin_major-build_major__sandbox_browser_navigate` — open a URL on `http://localhost:3000`. +- ✅ `mcp__plugin_major-build_major__sandbox_browser_take_screenshot` — capture the rendered page. Always save under `/workspace/.session-files/`; never use `/workspace/app`, repo paths, or relative paths. +- ✅ `mcp__plugin_major-build_major__sandbox_browser_snapshot` — accessibility snapshot for reading text/structure. +- ✅ `mcp__plugin_major-build_major__sandbox_browser_wait_for` — wait briefly for a pending/loading state to settle before re-screenshotting. +- ✅ `mcp__plugin_major-build_major__sandbox_browser_console_messages` — read the browser console when investigating client-side errors. Do **not** click, type, drag, hover, resize, fill forms, press keys, evaluate JavaScript, or otherwise interact with or mutate the page. If the bug only reproduces through user interaction, describe the reproduction steps and ask the user to perform them — do not attempt to drive the page yourself. @@ -76,8 +76,8 @@ Use logs when behavior depends on server startup, route handlers, background wor After collecting runtime evidence, trace the responsible code path. -- Search for the route, component, handler, resource client, env var, or error text using `mcp__sandbox__grep` / `mcp__sandbox__glob`. -- Read nearby code with `mcp__sandbox__read_file` before editing with `mcp__sandbox__edit_file` or `mcp__sandbox__write_file`. +- Search for the route, component, handler, resource client, env var, or error text using `mcp__plugin_major-build_major__sandbox_grep` / `mcp__plugin_major-build_major__sandbox_glob`. +- Read nearby code with `mcp__plugin_major-build_major__sandbox_read_file` before editing with `mcp__plugin_major-build_major__sandbox_edit_file` or `mcp__plugin_major-build_major__sandbox_write_file`. - Follow the app-specific conventions provided to you as context. - If data shape is involved, inspect the relevant MCP resource or generated client before changing UI assumptions. - If an external API, connector, auth provider, or resource appears unavailable, verify that dependency before patching app code. Report dependency failures as uncertainty instead of looping on frontend fixes. diff --git a/plugins/major-build/skills/skill-builder/SKILL.md b/plugins/major-build/skills/skill-builder/SKILL.md index 0e02a4a..60e5bba 100644 --- a/plugins/major-build/skills/skill-builder/SKILL.md +++ b/plugins/major-build/skills/skill-builder/SKILL.md @@ -7,37 +7,37 @@ description: Create and manage Major agent skills — versioned file bundles (SK A _skill_ is a versioned bundle — `SKILL.md` (required) + optional `references/*.md` + optional `scripts/*.{js,ts}` — that an attached agent loads on demand. Turn the user's intent into a focused bundle. Pure-instruction skills are fine; when a skill does real work it's a **script** that talks to a resource through the proxy or a generated client (never hand-written client/auth code). You author the bundle on the skill's sandbox and edit it through the sandbox tools (the "Working with sandboxes" section of your system prompt covers addressing, provisioning, and sharing). -Orchestrator tools are `mcp__orchestrator-platform__*` (`list_editable_skills`, `mount`, `create_skill`, `publish`, `get_skill`). File editing and sync go through the sandbox tools `mcp__sandbox__*` (`read_file`, `edit_file`, `write_file`, `pull`, `push`, `validate`), each called with `skill: ""` as the target. `publish` takes the same `skill` argument. +Finding, creating, and opening skills is on `mcp__plugin_major-build_major__*` (`list_skills`, `create_skill`, `start_sandbox`); orchestrator tools are `mcp__orchestrator-platform__*` (`get_skill`, `publish`). File editing and sync go through the sandbox tools `mcp__plugin_major-build_major__sandbox_*` (`sandbox_read_file`, `sandbox_edit_file`, `sandbox_write_file`, `sandbox_pull`, `sandbox_push`, `sandbox_validate`), each called with `skill: ""` as the target. `publish` takes the same `skill` argument. ## The working files, saving, and publishing Each skill's working copy lives on its own sandbox under the workspace root. Two separate steps take it off the sandbox: -- **Save** (`push`) validates the bundle and writes it as a new immutable version. Nothing about what attached agents load changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** +- **Save** (`sandbox_push`) validates the bundle and writes it as a new immutable version. Nothing about what attached agents load changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** - **Publish** (`publish`) points the skill at its latest saved version. This is the only thing that changes what attached agents load. So a saved-but-unpublished draft is inert to attached agents — the agent that has it attached is the one that loads `SKILL.md`, at the last **published** version. Scripts are different: run them on this sandbox before saving. -Always use a `skillId` returned by `list_editable_skills` or `create_skill` — never invent one. If this chat is pinned to a skill, the "Working with this skill" section of your system prompt carries the bound-chat rules (its id, recovery, discard) — those win. +Always use a `skillId` returned by `list_skills` or `create_skill` — never invent one. If this chat is pinned to a skill, the "Working with this skill" section of your system prompt carries the bound-chat rules (its id, recovery, discard) — those win. ## Save discipline -- **Never `pull` routinely** — it overwrites the sandbox folder with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover a corrupted folder or on the user's explicit ask to discard. -- **Always `push` before you finish a turn in which you edited files.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about what attached agents load. +- **Never `sandbox_pull` routinely** — it overwrites the sandbox folder with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover a corrupted folder or on the user's explicit ask to discard. +- **Always `sandbox_push` before you finish a turn in which you edited files.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about what attached agents load. - **Publish only when the user asks for it.** That is the moment attached agents start seeing your changes. ## Lifecycle -- **Edit existing**: `list_editable_skills` to find it, then `mount({skill: ""})` — it mounts (or joins) the skill's sandbox. Edit the files with the sandbox tools, saving as you finish each round. +- **Edit existing**: `list_skills` to find it, then `start_sandbox({skill: ""})` — it mounts (or joins) the skill's sandbox. Edit the files with the sandbox tools, saving as you finish each round. - **New**: `create_skill({})` — it creates an empty draft (server-minted `skillId`), mounts its sandbox seeded with a scaffold, and returns where the files live. Build the bundle in that folder. -- **Check a draft**: `validate` — validates the sandbox bundle against the platform's rules without saving. Saving also validates; on failure nothing is saved and the error list comes back — fix the files and save again. -- **Test scripts**: `tsx` and `@major-tech/resource-client` are on the sandbox (same as the agent pod). From the workspace root, `tsx scripts/.ts` via the sandbox `bash` tool — env already has `MAJOR_GO_RESOURCE_URL` / `MAJOR_RESOURCES_API_TOKEN`. Extra `package.json` deps: `npm install` first (`node_modules` isn't saved). `validate` only checks bundle shape (frontmatter, file rules), not script correctness. -- **Save**: `push({notes})` — every save writes a new immutable version. -- **Publish**: `publish({skill})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `skillId` you passed to `push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. +- **Check a draft**: `sandbox_validate` — validates the sandbox bundle against the platform's rules without saving. Saving also validates; on failure nothing is saved and the error list comes back — fix the files and save again. +- **Test scripts**: `tsx` and `@major-tech/resource-client` are on the sandbox (same as the agent pod). From the workspace root, `tsx scripts/.ts` via the `sandbox_bash` tool — env already has `MAJOR_GO_RESOURCE_URL` / `MAJOR_RESOURCES_API_TOKEN`. Extra `package.json` deps: `npm install` first (`node_modules` isn't saved). `sandbox_validate` only checks bundle shape (frontmatter, file rules), not script correctness. +- **Save**: `sandbox_push({notes})` — every save writes a new immutable version. +- **Publish**: `publish({skill})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `skillId` you passed to `sandbox_push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. ## Bundle rules -- Frontmatter needs `name` (lowercase kebab-case — publishing claims it as the skill's slug) and `description`. Any file type is allowed, binaries included; `validate` and every `push` enforce the path and size rules with errors naming what to fix. +- Frontmatter needs `name` (lowercase kebab-case — publishing claims it as the skill's slug) and `description`. Any file type is allowed, binaries included; `sandbox_validate` and every `sandbox_push` enforce the path and size rules with errors naming what to fix. - The `description` is the catalog line the SDK injects so the model can decide whether to load the skill — write `[what it does] + [when to use it] + [key capabilities]`, third person, with user trigger phrases. Good: "Fetches and summarises Stripe charges and refunds. Use when the user asks to summarise charges, look up a refund, or mentions a Stripe customer id." Bad: "helper for Stripe" (vague) or "Fetch and summarise Stripe charges; expects a stripe customer id" (function signature, no triggers). - Keep the body task-focused and link long detail to `references/*.md`. - `package.json` (`type: module`) is scaffolded for you — never author it. Add `dependencies` to it for extra npm packages. Never write `node_modules` (excluded from the saved version). @@ -67,7 +67,7 @@ process.stdout.write( Read `references/http-proxy.md` in the `using-connectors` skill for the full proxy reference. -**Non-proxyable resources** (databases, non-HTTP connectors) — generate a typed client; don't hand-write it. The sandbox tool `add-resource-client({resourceId, resourceName, resourceType, resourceDescription, skill: ""})` writes a `.ts` client into `clients/` and returns the import line — use it VERBATIM (it may end in `.ts`; never rewrite to `.js`). `remove-resource-client` (same target) deletes one. +**Non-proxyable resources** (databases, non-HTTP connectors) — generate a typed client; don't hand-write it. The `sandbox_add-resource-client({resourceId, resourceName, resourceType, resourceDescription, skill: ""})` writes a `.ts` client into `clients/` and returns the import line — use it VERBATIM (it may end in `.ts`; never rewrite to `.js`). `sandbox_remove-resource-client` (same target) deletes one. ```ts import { ordersDbClient } from "../clients/ordersDb.ts"; // use the import the tool returned, verbatim diff --git a/plugins/major-build/skills/using-apps/SKILL.md b/plugins/major-build/skills/using-apps/SKILL.md index 018552c..a770ca2 100644 --- a/plugins/major-build/skills/using-apps/SKILL.md +++ b/plugins/major-build/skills/using-apps/SKILL.md @@ -7,7 +7,7 @@ description: Use for ANY call against a deployed Major app — listing apps the A deployed Major app is compute you call over HTTP. Major handles auth and plumbing. This skill is for **invoking** an existing deployed app — not for creating, editing, mounting, or deploying one (load `app-builder` for that). -Always use an `applicationId` returned by `list_use_apps` — never invent one. `list_use_apps` is the catalog of apps you can call. `list_edit_apps` is a different list (apps the user can edit or grant to an agent); do not use it to pick a call target. +Always use an `applicationId` returned by `list_use_apps` — never invent one. `list_use_apps` is the catalog of apps you can call. `list_apps` is a different list (apps the user can edit or grant to an agent); do not use it to pick a call target. ## Steps @@ -20,5 +20,5 @@ Do not issue writes via `do_requests` just to learn a shape — `get_app_skill` ## Related - To change the app itself (sandbox, preview, deploy), load `app-builder`. -- To grant an agent access to an app, load `agent-builder` — attach via `list_edit_apps`, not `list_use_apps`. +- To grant an agent access to an app, load `agent-builder` — attach via `list_apps`, not `list_use_apps`. - For a scheduled or event-driven call, load `workflow-builder` and use an `app_call` node. diff --git a/plugins/major-build/skills/using-connectors/SKILL.md b/plugins/major-build/skills/using-connectors/SKILL.md index eae0d8b..61928ce 100644 --- a/plugins/major-build/skills/using-connectors/SKILL.md +++ b/plugins/major-build/skills/using-connectors/SKILL.md @@ -24,7 +24,7 @@ For each resource you plan to use: ## Step 3: Read the connector's reference -Find the connector's row below and read its reference file (in this skill's `references/` directory) **before** writing any query, tool call, or client code. Match on the resource's `subtype` (or, for Pipedream-backed connectors, its app slug), comparing case-insensitively and ignoring `-` and `_`. Each reference documents the connector's MCP tools (called through `mcp__resources__execute_resource_tool`), its generated clients, and the underlying API. +Find the connector's row below and read its reference file (in this skill's `references/` directory) **before** writing any query, tool call, or client code. Match on the resource's `subtype` (or, for Pipedream-backed connectors, its app slug), comparing case-insensitively and ignoring `-` and `_`. Each reference documents the connector's MCP tools (called through `mcp__plugin_major-build_major__execute_resource_tool`), its generated clients, and the underlying API. ### Connectors diff --git a/plugins/major-build/skills/using-connectors/references/ai-proxy.md b/plugins/major-build/skills/using-connectors/references/ai-proxy.md index fa140ac..9f49af9 100644 --- a/plugins/major-build/skills/using-connectors/references/ai-proxy.md +++ b/plugins/major-build/skills/using-connectors/references/ai-proxy.md @@ -4,7 +4,7 @@ Major provides a built-in AI proxy that lets apps call Anthropic, OpenAI, and Ge ## Workflow -Run these commands in the app workspace (through `mcp__sandbox__bash` when working in a hosted sandbox). +Run these commands in the app workspace (through `mcp__plugin_major-build_major__sandbox_bash` when working in a hosted sandbox). 1. Run `major app ai-proxy status` to see if the proxy is enabled for this app 2. If enabled: use it directly with the env vars below diff --git a/plugins/major-build/skills/using-connectors/references/attio.md b/plugins/major-build/skills/using-connectors/references/attio.md index bd6405a..59f81df 100644 --- a/plugins/major-build/skills/using-connectors/references/attio.md +++ b/plugins/major-build/skills/using-connectors/references/attio.md @@ -7,7 +7,7 @@ **Three ways to interact with Attio:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Attio API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** After generating a client, ALWAYS read the generated client file to discover the exact API. Different resource types have completely different methods and calling conventions. diff --git a/plugins/major-build/skills/using-connectors/references/bigquery.md b/plugins/major-build/skills/using-connectors/references/bigquery.md index d3e3eac..6305003 100644 --- a/plugins/major-build/skills/using-connectors/references/bigquery.md +++ b/plugins/major-build/skills/using-connectors/references/bigquery.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/clerk.md b/plugins/major-build/skills/using-connectors/references/clerk.md index 4ed593b..1d566c0 100644 --- a/plugins/major-build/skills/using-connectors/references/clerk.md +++ b/plugins/major-build/skills/using-connectors/references/clerk.md @@ -7,7 +7,7 @@ **Three ways to interact with Clerk:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Clerk API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/clickhouse.md b/plugins/major-build/skills/using-connectors/references/clickhouse.md index 3119cc9..9d4afab 100644 --- a/plugins/major-build/skills/using-connectors/references/clickhouse.md +++ b/plugins/major-build/skills/using-connectors/references/clickhouse.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/cosmosdb.md b/plugins/major-build/skills/using-connectors/references/cosmosdb.md index 76d9eba..a52a166 100644 --- a/plugins/major-build/skills/using-connectors/references/cosmosdb.md +++ b/plugins/major-build/skills/using-connectors/references/cosmosdb.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/custom-api.md b/plugins/major-build/skills/using-connectors/references/custom-api.md index 2260424..57e9db4 100644 --- a/plugins/major-build/skills/using-connectors/references/custom-api.md +++ b/plugins/major-build/skills/using-connectors/references/custom-api.md @@ -7,7 +7,7 @@ **Three ways to interact with Custom API:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Custom API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/dynamodb.md b/plugins/major-build/skills/using-connectors/references/dynamodb.md index 9bec5f3..ae73b50 100644 --- a/plugins/major-build/skills/using-connectors/references/dynamodb.md +++ b/plugins/major-build/skills/using-connectors/references/dynamodb.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/fireflies.md b/plugins/major-build/skills/using-connectors/references/fireflies.md index f497202..c386c27 100644 --- a/plugins/major-build/skills/using-connectors/references/fireflies.md +++ b/plugins/major-build/skills/using-connectors/references/fireflies.md @@ -7,7 +7,7 @@ **Three ways to interact with Fireflies:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Fireflies API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/github.md b/plugins/major-build/skills/using-connectors/references/github.md index 7296e74..e714466 100644 --- a/plugins/major-build/skills/using-connectors/references/github.md +++ b/plugins/major-build/skills/using-connectors/references/github.md @@ -4,7 +4,7 @@ GitHub uses a GitHub App installation. When the user asks to connect GitHub: -1. Call `mcp__resource-setup__request-resource-setup` with `subtype: "github"`. +1. Call `mcp__interactions__request_resource_setup` with `connectorId: "github"`. 2. Ask the user to finish the GitHub installation flow and select the repositories the app may access. 3. After setup completes, call `mcp__resources__list_resources` and use the connected GitHub resource's `resourceId` and mounted MCP slug. @@ -20,7 +20,7 @@ GitHub uses a GitHub App installation. When the user asks to connect GitHub: 1. **Mounted GitHub MCP tools** (direct, preferred): The connected GitHub MCP server exposes tools as `mcp____`. Use `mcp__resources__list_resources` to discover the resource and its slug. The hosted tool catalog covers repositories, files, issues, pull requests, branches, commits, and releases. 2. **Git token tool** (git CLI only): Call `mcp__resources__github_get_git_token` with the GitHub `resourceId`. Optionally downscope it to repository names and permissions. -3. **Generated TypeScript client** (app code): Call `mcp__resource-tools__add-resource-client` with the `resourceId`. The generated client is created in `/clients/` (Next.js) or `/src/clients/` (Vite). +3. **Generated TypeScript client** (app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and the `resourceId`. The generated client is created in `/clients/` (Next.js) or `/src/clients/` (Vite). 4. **HTTP proxy** (Next.js app code or direct MCP calls): Use `createProxyFetch` from `@major-tech/resource-client/next`, or `mcp__resources__http_proxy_get` / `mcp__resources__http_proxy_invoke`, for GitHub REST or GraphQL endpoints not covered by a mounted MCP tool. See [using-http-proxy](http-proxy.md). **Do not guess tool names or argument shapes.** Mounted tools come from GitHub's hosted MCP server and may change. Inspect the tools available under the connector's actual slug before calling them. After generating a TypeScript client, read its source to verify exact methods and signatures. diff --git a/plugins/major-build/skills/using-connectors/references/gmail.md b/plugins/major-build/skills/using-connectors/references/gmail.md index 91f0374..d5e0a8b 100644 --- a/plugins/major-build/skills/using-connectors/references/gmail.md +++ b/plugins/major-build/skills/using-connectors/references/gmail.md @@ -6,7 +6,7 @@ Gmail requires OAuth authentication before use. ### When the user asks you to set up Gmail or connect their email: -1. Call `mcp__resource-setup__request-resource-setup` with `subtype: "gmail"` — this prompts the user to authenticate with Google +1. Call `mcp__interactions__request_resource_setup` with `connectorId: "gmail"` — this prompts the user to authenticate with Google 2. Once setup completes, the resource is ready to use --- @@ -20,7 +20,7 @@ Gmail requires OAuth authentication before use. **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/google-analytics.md b/plugins/major-build/skills/using-connectors/references/google-analytics.md index 18d2e35..62952de 100644 --- a/plugins/major-build/skills/using-connectors/references/google-analytics.md +++ b/plugins/major-build/skills/using-connectors/references/google-analytics.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/googlecalendar.md b/plugins/major-build/skills/using-connectors/references/googlecalendar.md index 6659923..3e67894 100644 --- a/plugins/major-build/skills/using-connectors/references/googlecalendar.md +++ b/plugins/major-build/skills/using-connectors/references/googlecalendar.md @@ -6,7 +6,7 @@ Google Calendar requires OAuth authentication before use. ### When the user asks you to set up Google Calendar or connect their calendar: -1. Call `mcp__resource-setup__request-resource-setup` with `subtype: "googlecalendar"` — this prompts the user to authenticate with Google +1. Call `mcp__interactions__request_resource_setup` with `connectorId: "googlecalendar"` — this prompts the user to authenticate with Google 2. Once setup completes, the resource is ready to use --- @@ -20,7 +20,7 @@ Google Calendar requires OAuth authentication before use. **Three ways to interact with Google Calendar:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Google Calendar API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/googledrive.md b/plugins/major-build/skills/using-connectors/references/googledrive.md index 4b3bedf..2c2beab 100644 --- a/plugins/major-build/skills/using-connectors/references/googledrive.md +++ b/plugins/major-build/skills/using-connectors/references/googledrive.md @@ -6,7 +6,7 @@ Google Drive requires OAuth authentication before use. ### When the user asks you to set up Google Drive or connect their files: -1. Call `mcp__resource-setup__request-resource-setup` with `subtype: "googledrive"` — this prompts the user to authenticate with Google +1. Call `mcp__interactions__request_resource_setup` with `connectorId: "googledrive"` — this prompts the user to authenticate with Google 2. Once setup completes, the resource is ready to use --- @@ -20,7 +20,7 @@ Google Drive requires OAuth authentication before use. **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/googlesearchconsole.md b/plugins/major-build/skills/using-connectors/references/googlesearchconsole.md index 9908056..2e10650 100644 --- a/plugins/major-build/skills/using-connectors/references/googlesearchconsole.md +++ b/plugins/major-build/skills/using-connectors/references/googlesearchconsole.md @@ -9,7 +9,7 @@ Google Search Console is an OAuth-only connector. It accesses verified Search Co **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/googlesheets.md b/plugins/major-build/skills/using-connectors/references/googlesheets.md index d22b05e..b1b7263 100644 --- a/plugins/major-build/skills/using-connectors/references/googlesheets.md +++ b/plugins/major-build/skills/using-connectors/references/googlesheets.md @@ -6,8 +6,8 @@ Google Sheets requires a two-step setup: (1) OAuth authentication, (2) spreadshe ### When the user asks you to set up Google Sheets or connect a spreadsheet: -1. Call `mcp__resource-setup__request-resource-setup` with `subtype: "googlesheets"` — this prompts the user to authenticate with Google -2. After setup completes, call `mcp__resource-setup__request-resource-update` with the returned `resourceId` and `message: "Please select your spreadsheet. Click 'Configure Resource' below, then use the spreadsheet picker to choose your sheet."` — this prompts them to select their spreadsheet +1. Call `mcp__interactions__request_resource_setup` with `connectorId: "googlesheets"` — this prompts the user to authenticate with Google +2. After setup completes, call `mcp__interactions__request_resource_update` with the returned `resourceId` and `message: "Please select your spreadsheet. Click 'Configure Resource' below, then use the spreadsheet picker to choose your sheet."` — this prompts them to select their spreadsheet 3. Once both steps complete, the resource is ready to use ### When the user sends a Google Sheets link: @@ -20,7 +20,7 @@ If the user shares a Google Sheets URL (e.g., `https://docs.google.com/spreadshe ### When a Google Sheets resource exists but has no spreadsheet selected: -If you call a Google Sheets MCP tool and get an error indicating no spreadsheet is configured, use `mcp__resource-setup__request-resource-update` to prompt the user to select one. +If you call a Google Sheets MCP tool and get an error indicating no spreadsheet is configured, use `mcp__interactions__request_resource_update` to prompt the user to select one. --- @@ -31,7 +31,7 @@ If you call a Google Sheets MCP tool and get an error indicating no spreadsheet **Three ways to interact with Google Sheets:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Google Sheets API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/graphql.md b/plugins/major-build/skills/using-connectors/references/graphql.md index 234c80c..de216f4 100644 --- a/plugins/major-build/skills/using-connectors/references/graphql.md +++ b/plugins/major-build/skills/using-connectors/references/graphql.md @@ -7,7 +7,7 @@ **Three ways to interact with this resource:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **Apollo Client via the HTTP proxy** (GraphQL-specific): Pass `createProxyFetch({ resourceId, ... })` as Apollo's `fetch` so the proxy resolves the endpoint and injects auth at request time. Use this when the app needs Apollo's normalized cache, optimistic updates, or fragments. See "Apollo Client via the HTTP Proxy" below. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/hubspot.md b/plugins/major-build/skills/using-connectors/references/hubspot.md index a85287e..ed16f90 100644 --- a/plugins/major-build/skills/using-connectors/references/hubspot.md +++ b/plugins/major-build/skills/using-connectors/references/hubspot.md @@ -7,7 +7,7 @@ **Three ways to interact with HubSpot:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the HubSpot API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/lambda.md b/plugins/major-build/skills/using-connectors/references/lambda.md index 7e5b54c..cfdefbd 100644 --- a/plugins/major-build/skills/using-connectors/references/lambda.md +++ b/plugins/major-build/skills/using-connectors/references/lambda.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/linkedin.md b/plugins/major-build/skills/using-connectors/references/linkedin.md index d6cbf97..5775749 100644 --- a/plugins/major-build/skills/using-connectors/references/linkedin.md +++ b/plugins/major-build/skills/using-connectors/references/linkedin.md @@ -9,7 +9,7 @@ Reference: https://learn.microsoft.com/en-us/linkedin/marketing/ **Three ways to interact with LinkedIn:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources__linkedin_`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the LinkedIn Marketing API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and exact signatures before writing app code. diff --git a/plugins/major-build/skills/using-connectors/references/linkedinads.md b/plugins/major-build/skills/using-connectors/references/linkedinads.md index cded3d0..05a6974 100644 --- a/plugins/major-build/skills/using-connectors/references/linkedinads.md +++ b/plugins/major-build/skills/using-connectors/references/linkedinads.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/majorauth.md b/plugins/major-build/skills/using-connectors/references/majorauth.md index 7ab0a5e..c099626 100644 --- a/plugins/major-build/skills/using-connectors/references/majorauth.md +++ b/plugins/major-build/skills/using-connectors/references/majorauth.md @@ -5,7 +5,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. @@ -22,7 +22,7 @@ The Major Auth Connector is a **managed resource** that exists by default in every organization. To use it: 1. Call `mcp__resources__list_resources` to discover available resources — look for the one with subtype `majorauth` (named "Major Auth Connector"). -2. Call `mcp__resource-tools__add-resource-client` with that `resourceId` to generate a typed `MajorAuthResourceClient`. +2. Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and that `resourceId` to generate a typed `MajorAuthResourceClient`. 3. Use the generated client in your app code to share or revoke access. ## MCP Tools diff --git a/plugins/major-build/skills/using-connectors/references/managed-database.md b/plugins/major-build/skills/using-connectors/references/managed-database.md index be7a3f8..e0ac870 100644 --- a/plugins/major-build/skills/using-connectors/references/managed-database.md +++ b/plugins/major-build/skills/using-connectors/references/managed-database.md @@ -33,7 +33,7 @@ After setup completes and you have the resource ID: - `mcp__orchestrator-platform__run_migration` — DDL/DML migrations (managed databases only). Args: `applicationId`, `migration`, `description` 2. **Generated TypeScript clients** (for app code): - - Call `mcp__resource-tools__add-resource-client` with the `resourceId` to generate a typed PostgreSQL client + - Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and the `resourceId` to generate a typed PostgreSQL client - Use the client for read/write operations in your application code ## Identifying Managed Databases diff --git a/plugins/major-build/skills/using-connectors/references/managed-file-storage.md b/plugins/major-build/skills/using-connectors/references/managed-file-storage.md index 5c602ab..a96cff6 100644 --- a/plugins/major-build/skills/using-connectors/references/managed-file-storage.md +++ b/plugins/major-build/skills/using-connectors/references/managed-file-storage.md @@ -10,7 +10,7 @@ Customers see a flat key namespace (e.g. `user/avatar.png`); the underlying buck ## Setting It Up -Managed file storage is **not** offered through `request-resource-setup` — that tool only covers connectors set up via the standard Add-Connector dialog, and file storage is provisioned differently. Do not try to set it up that way; it will not appear. Use the dedicated tools instead: +Managed file storage is **not** offered through `mcp__interactions__request_resource_setup` — that tool only covers connectors set up via the standard Add-Connector dialog, and file storage is provisioned differently. Do not try to set it up that way; it will not appear. Use the dedicated tools instead: - `mcp__resources__list_managed_file_stores` — list existing file stores in the org. **Always call this first** — reuse an existing store if one fits the use case. - `mcp__resources__provision_managed_file_store` — create a new org-level file store. Synchronous; returns `{ resourceId, name }` immediately. Args: `name`. The caller is auto-granted `Resource:Admin`; the All Builders group gets `Resource:Builder`, so any builder in the org can use it. @@ -26,7 +26,7 @@ Once you have a `resourceId`, use it directly with the tools and client below. - `mcp__resources__blob_del` — delete an object. Args: `resourceId`, `key` 2. **Generated TypeScript client** (for app code): - - Call `mcp__resource-tools__add-resource-client` with the `resourceId` to generate a typed client into `/clients/` (Next.js) or `/src/clients/` (Vite). + - Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and the `resourceId` to generate a typed client into `/clients/` (Next.js) or `/src/clients/` (Vite). - **The `resourceType` you pass MUST be `"blob"`** — that is the underlying resource subtype. It is NOT `"managed_file_store"` / `"managed-file-storage"`; those are only the product name and will fail with `Invalid type`. The generated client class is `BlobResourceClient`. **CRITICAL: Do NOT guess client method names or signatures.** ALWAYS read the actual generated client source (or the `@major-tech/resource-client` package) before writing client code. diff --git a/plugins/major-build/skills/using-connectors/references/metamarketing.md b/plugins/major-build/skills/using-connectors/references/metamarketing.md index a4db535..0f59671 100644 --- a/plugins/major-build/skills/using-connectors/references/metamarketing.md +++ b/plugins/major-build/skills/using-connectors/references/metamarketing.md @@ -7,7 +7,7 @@ **Three ways to interact with Meta Marketing:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Meta Marketing API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/mssql.md b/plugins/major-build/skills/using-connectors/references/mssql.md index b774f87..80c7f12 100644 --- a/plugins/major-build/skills/using-connectors/references/mssql.md +++ b/plugins/major-build/skills/using-connectors/references/mssql.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/mysql.md b/plugins/major-build/skills/using-connectors/references/mysql.md index e3d8915..05523b5 100644 --- a/plugins/major-build/skills/using-connectors/references/mysql.md +++ b/plugins/major-build/skills/using-connectors/references/mysql.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/neo4j.md b/plugins/major-build/skills/using-connectors/references/neo4j.md index 659b48c..8341c09 100644 --- a/plugins/major-build/skills/using-connectors/references/neo4j.md +++ b/plugins/major-build/skills/using-connectors/references/neo4j.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/notion.md b/plugins/major-build/skills/using-connectors/references/notion.md index 873f159..b4e0d6c 100644 --- a/plugins/major-build/skills/using-connectors/references/notion.md +++ b/plugins/major-build/skills/using-connectors/references/notion.md @@ -7,7 +7,7 @@ **Three ways to interact with Notion:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Notion API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/outreach.md b/plugins/major-build/skills/using-connectors/references/outreach.md index 467a093..cdd9670 100644 --- a/plugins/major-build/skills/using-connectors/references/outreach.md +++ b/plugins/major-build/skills/using-connectors/references/outreach.md @@ -7,7 +7,7 @@ **Three ways to interact with Outreach:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Outreach API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/postgresql.md b/plugins/major-build/skills/using-connectors/references/postgresql.md index 6f765fc..62daaca 100644 --- a/plugins/major-build/skills/using-connectors/references/postgresql.md +++ b/plugins/major-build/skills/using-connectors/references/postgresql.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/quickbooks.md b/plugins/major-build/skills/using-connectors/references/quickbooks.md index e71d1f4..5d7225a 100644 --- a/plugins/major-build/skills/using-connectors/references/quickbooks.md +++ b/plugins/major-build/skills/using-connectors/references/quickbooks.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/s3.md b/plugins/major-build/skills/using-connectors/references/s3.md index c72b9fe..727d8f4 100644 --- a/plugins/major-build/skills/using-connectors/references/s3.md +++ b/plugins/major-build/skills/using-connectors/references/s3.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/salesforce.md b/plugins/major-build/skills/using-connectors/references/salesforce.md index 7dc4164..037d773 100644 --- a/plugins/major-build/skills/using-connectors/references/salesforce.md +++ b/plugins/major-build/skills/using-connectors/references/salesforce.md @@ -7,7 +7,7 @@ **Three ways to interact with Salesforce:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Salesforce API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/sharepoint.md b/plugins/major-build/skills/using-connectors/references/sharepoint.md index 86e2a61..5be68ee 100644 --- a/plugins/major-build/skills/using-connectors/references/sharepoint.md +++ b/plugins/major-build/skills/using-connectors/references/sharepoint.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** Always read the actual client source code to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/slack.md b/plugins/major-build/skills/using-connectors/references/slack.md index 220dfc8..79a1a02 100644 --- a/plugins/major-build/skills/using-connectors/references/slack.md +++ b/plugins/major-build/skills/using-connectors/references/slack.md @@ -7,7 +7,7 @@ **Three ways to interact with Slack:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the Slack API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/snowflake.md b/plugins/major-build/skills/using-connectors/references/snowflake.md index 4167e83..8ccbf91 100644 --- a/plugins/major-build/skills/using-connectors/references/snowflake.md +++ b/plugins/major-build/skills/using-connectors/references/snowflake.md @@ -7,7 +7,7 @@ **Two ways to interact with resources:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/sqs.md b/plugins/major-build/skills/using-connectors/references/sqs.md index 940e96d..3cd0b10 100644 --- a/plugins/major-build/skills/using-connectors/references/sqs.md +++ b/plugins/major-build/skills/using-connectors/references/sqs.md @@ -8,7 +8,7 @@ 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/stripe.md b/plugins/major-build/skills/using-connectors/references/stripe.md index dcd54ea..9919b73 100644 --- a/plugins/major-build/skills/using-connectors/references/stripe.md +++ b/plugins/major-build/skills/using-connectors/references/stripe.md @@ -7,7 +7,7 @@ **Three ways to interact with Stripe:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources___`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **Official Stripe SDK via the HTTP proxy** (Next.js apps): Pass `createProxyFetch` into `Stripe.createFetchHttpClient(...)`. See the **Stripe SDK via the HTTP proxy** section below — preferred when you want full Stripe SDK ergonomics (typed methods, autocomplete, automatic pagination). **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and their exact signatures before writing any client code. diff --git a/plugins/major-build/skills/using-connectors/references/tiktokads.md b/plugins/major-build/skills/using-connectors/references/tiktokads.md index 6be80c1..d13a6e7 100644 --- a/plugins/major-build/skills/using-connectors/references/tiktokads.md +++ b/plugins/major-build/skills/using-connectors/references/tiktokads.md @@ -9,7 +9,7 @@ Reference: https://business-api.tiktok.com/portal/docs **Three ways to interact with TikTok Ads:** 1. **MCP tools** (direct, no code needed): Tools follow the pattern `mcp__resources__tiktokads_`. Use `mcp__resources__list_resources` to discover available resources and their IDs. -2. **Generated TypeScript clients** (for app code): Call `mcp__resource-tools__add-resource-client` with a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). +2. **Generated TypeScript clients** (for app code): Call `mcp__plugin_major-build_major__sandbox_add-resource-client` with the app's `slug` and a `resourceId` to generate a typed client. Clients are created in `/clients/` (Next.js) or `/src/clients/` (Vite). 3. **HTTP proxy** (Next.js apps): Use `createProxyFetch` from `@major-tech/resource-client/next` to call the TikTok Marketing API directly with automatic auth injection. See [using-http-proxy](http-proxy.md) for setup and usage — preferred when you need to hit endpoints not covered by MCP tools or the typed client, or when using an official SDK that accepts a custom `fetch`. **CRITICAL: Do NOT guess client method names or signatures.** The TypeScript clients in `@major-tech/resource-client` have strongly typed inputs and outputs. ALWAYS read the actual client source code in the generated `/clients/` directory (or the package itself) to verify available methods and exact signatures before writing app code. diff --git a/plugins/major-build/skills/webhooks/SKILL.md b/plugins/major-build/skills/webhooks/SKILL.md index 033bccf..cb9ccec 100644 --- a/plugins/major-build/skills/webhooks/SKILL.md +++ b/plugins/major-build/skills/webhooks/SKILL.md @@ -15,7 +15,7 @@ Major apps are protected by an authentication gateway by default. Enabling **Web ## Checking & Enabling Webhooks -Run `major app info --json` from the app workspace to check the current app status, including `webhooksEnabled`. In a hosted sandbox, run it through `mcp__sandbox__bash`. +Run `major app info --json` from the app workspace to check the current app status, including `webhooksEnabled`. In a hosted sandbox, run it through `mcp__plugin_major-build_major__sandbox_bash`. If webhooks are not enabled, instruct the user to enable them from the **Major dashboard → App Settings → Webhook Access** toggle. diff --git a/plugins/major-build/skills/workflow-builder/SKILL.md b/plugins/major-build/skills/workflow-builder/SKILL.md index 8fab98e..16bbb71 100644 --- a/plugins/major-build/skills/workflow-builder/SKILL.md +++ b/plugins/major-build/skills/workflow-builder/SKILL.md @@ -7,13 +7,13 @@ description: Create and manage Major workflows — JSONC graphs of agent calls, A _workflow_ is a graph of steps executed by Major's workflow engine: agents run with prompts, deployed apps get called over HTTP, routers branch on state, loops fan over collections, humans approve over Slack, and schedules, connector events, or authenticated webhooks start the graph. You author the definition as a JSONC file (JSON with comments) on the workflow's sandbox and edit it through the sandbox tools (the "Working with sandboxes" section of your system prompt covers addressing, provisioning, and sharing). -Orchestrator tools are `mcp__orchestrator-platform__*` (`list_workflows`, `mount`, `create_workflow`, `publish`, `run_workflow`, `list_workflow_runs`, `get_workflow_run`, `delete_workflow`, `list_connector_event_types`). File editing and sync go through the sandbox tools `mcp__sandbox__*` (`read_file`, `edit_file`, `write_file`, `pull`, `push`, `validate`), each called with `workflow: ""` as the target. `publish` takes the same `workflow` argument. +Finding, creating, and opening workflows is on `mcp__plugin_major-build_major__*` (`list_workflows`, `create_workflow`, `start_sandbox`). Orchestrator tools are `mcp__orchestrator-platform__*` (`publish`, `run_workflow`, `list_workflow_runs`, `get_workflow_run`, `delete_workflow`, `list_connector_event_types`). File editing and sync go through the sandbox tools `mcp__plugin_major-build_major__sandbox_*` (`sandbox_read_file`, `sandbox_edit_file`, `sandbox_write_file`, `sandbox_pull`, `sandbox_push`, `sandbox_validate`), each called with `workflow: ""` as the target. `publish` takes the same `workflow` argument. ## The working file, saving, and publishing Each workflow's working copy lives on its own sandbox at `.jsonc` (workspace-relative). Two separate steps take it off the sandbox: -- **Save** (`push`) writes the file as a new immutable version. Nothing about the workflow's behaviour changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** +- **Save** (`sandbox_push`) writes the file as a new immutable version. Nothing about the workflow's behaviour changes — saving is free. **The sandbox is torn down once it goes idle and comes back seeded from the last saved version, so anything unsaved is lost.** - **Publish** (`publish`) points the workflow at its latest saved version. This is the only thing that changes live trigger behavior: schedules begin firing, connector endpoints are reconciled, and webhook URLs are materialized. So triggers sitting in a saved-but-unpublished draft are inert, and `run_workflow` runs the last **saved** version — you never have to publish to test. @@ -22,22 +22,22 @@ Always use a `workflowId` returned by `list_workflows` or `create_workflow` — ## Save discipline -- **Never `pull` routinely** — it overwrites the sandbox file with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover a corrupted file or on the user's explicit ask to discard. -- **Always `push` before you finish a turn in which you edited the file.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about how the workflow runs. +- **Never `sandbox_pull` routinely** — it overwrites the sandbox file with the last saved version and destroys any unsaved edits, the user's included. Pull only to recover a corrupted file or on the user's explicit ask to discard. +- **Always `sandbox_push` before you finish a turn in which you edited the file.** Unsaved work dies with the sandbox. Saving needs no permission and changes nothing about how the workflow runs. - **Publish only when the user asks for it.** That is the moment the workflow starts acting on its own. ## Lifecycle - **Edit existing**: `list_workflows` to find it, then `mount({workflow: ""})` — it mounts (or joins) the workflow's sandbox and returns the file name. Edit the file with the sandbox tools, saving as you finish each round. - **New**: `create_workflow({})` — it creates a skeleton workflow (server-minted `workflowId`), mounts its sandbox, and returns the file name. Build the definition in that file; there is no push-a-loose-draft path. -- **Check a draft**: `validate` — validates the sandbox file against the server's rules without saving. Saving also validates; on failure nothing is saved and the error list comes back — fix the file and save again. -- **Save**: `push` — every save writes a new immutable version; comments are preserved verbatim. +- **Check a draft**: `sandbox_validate` — validates the sandbox file against the server's rules without saving. Saving also validates; on failure nothing is saved and the error list comes back — fix the file and save again. +- **Save**: `sandbox_push` — every save writes a new immutable version; comments are preserved verbatim. - **Test**: `run_workflow` (save first — it runs the last saved version), then `get_workflow_run` — it returns the per-node trace (status, resolved input, output, errors). App calls use deployed apps by default. Pass `appTarget: "sandbox"` to test `app_call` nodes against the acting user's live app sandboxes (spun up on demand) before deploying; a sandbox held by another user fails that node with the holder's name. -- **Publish**: `publish({workflow})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `workflowId` you passed to `push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. +- **Publish**: `publish({workflow})` — makes the latest saved version live. Name the target the same way the sandbox tools do: pass the `workflowId` you passed to `sandbox_push`. Only on the user's explicit go-ahead. Add `versionId` to roll back to an earlier version. ## The definition format -The definition shape AND the enforced graph rules are the workflow-definition JSON Schema the Major API serves at `GET https://api.prod.major.build/public/workflow.schema.json` — the single source of truth (the graph rules are its `x-validatorRules`). YOU MUST CURL THIS SCHEMA BEFORE BUILDING A WORKFLOW. `validate` (and every push) enforces all of it, with errors naming the offending path. +The definition shape AND the enforced graph rules are the workflow-definition JSON Schema the Major API serves at `GET https://api.prod.major.build/public/workflow.schema.json` — the single source of truth (the graph rules are its `x-validatorRules`). YOU MUST CURL THIS SCHEMA BEFORE BUILDING A WORKFLOW. `sandbox_validate` (and every push) enforces all of it, with errors naming the offending path. Runtime semantics the schema can't express: @@ -89,9 +89,9 @@ Node outputs by type: ## Workflow -1. Ask what the workflow should do, which agents/apps it touches (`list_agents`, `list_use_apps` / `list_edit_apps` to discover ids), and the cadence. When an `app_call` needs endpoints or request/response shapes, load the `using-apps` skill. -2. `create_workflow` (or `mount` for an existing one) — the builder panel opens so the user can see the graph. -3. Draft the JSONC. Iterate with the sandbox file tools, `validate` as you go, and `push` at the end of every turn you edited in. +1. Ask what the workflow should do, which agents/apps it touches (`list_agents` / `list_apps` with `include_read_only: true`, or `list_use_apps`, to discover ids), and the cadence. When an `app_call` needs endpoints or request/response shapes, load the `using-apps` skill. +2. `create_workflow` (or `start_sandbox` for an existing one) — the builder panel opens so the user can see the graph. +3. Draft the JSONC. Iterate with the sandbox file tools, `sandbox_validate` as you go, and `sandbox_push` at the end of every turn you edited in. 4. Test with `run_workflow` (it runs what you last saved), then inspect with `get_workflow_run`. 5. Write the requested cron, connector event, or webhook into the file once its configuration is known. An unpublished trigger is inert, so it costs nothing to save. Never invent an automated trigger the user didn't ask for. 6. Once the user confirms it's ready, publish it. For a newly added webhook, ask the user to open the workflow editor after publish and click **View credential** so the browser can show its one-time setup details. For other changes, `publish({workflow})` makes the saved version live. @@ -100,7 +100,7 @@ To pause a live workflow, remove or comment out its trigger, save, and publish. ## Approvals (Slack-only) -Two distinct approval surfaces, both needing a connected Slack resource. Check first: `mcp__resources__execute_resource_tool` with `toolName: "mcp__resources__list_resources"` — if no Slack resource exists, Slack isn't connected; say so (it's provisioned by installing the Major Slack integration under Settings → Integrations) instead of asking them to pick a channel. To find a channel id, execute the Slack resource's `mcp__resources__slack_list_channels` the same way. +Two distinct approval surfaces, both needing a connected Slack resource. Check first: `mcp__plugin_major-build_major__execute_resource_tool` with `toolName: "mcp__resources__list_resources"` — if no Slack resource exists, Slack isn't connected; say so (it's provisioned by installing the Major Slack integration under Settings → Integrations) instead of asking them to pick a channel. To find a channel id, execute the Slack resource's `mcp__resources__slack_list_channels` the same way. - A **`human_approval` node** is a first-class step: it posts `config.message` to `config.channel` (`{"type": "slack", "channel_id": ...}`) with `options` as buttons and the run waits for the click (or `on_timeout`). Use it whenever the user wants a person to sign off mid-flow. - An `agent_call`'s `approval_channel` (`{"type": "slack", "channel_id": ..., "channel_name": ...}`) routes that agent session's tool-approval requests to Slack; omitted/null keeps approvals in the app. Don't pitch Slack routing unprompted. diff --git a/plugins/shared/skills/resources_ai-proxy/SKILL.md b/plugins/shared/skills/resources_ai-proxy/SKILL.md index 6c1cdc4..e867ac1 100644 --- a/plugins/shared/skills/resources_ai-proxy/SKILL.md +++ b/plugins/shared/skills/resources_ai-proxy/SKILL.md @@ -9,7 +9,7 @@ Major provides a built-in AI proxy that lets apps call Anthropic, OpenAI, and Ge ## Workflow -Run these commands in the app workspace (through `mcp__sandbox__bash` when working in a hosted sandbox). +Run these commands in the app workspace (through `mcp__plugin_major-build_major__sandbox_bash` when working in a hosted sandbox). 1. Run `major app ai-proxy status` to see if the proxy is enabled for this app 2. If enabled: use it directly with the env vars below diff --git a/plugins/shared/skills/webhooks/SKILL.md b/plugins/shared/skills/webhooks/SKILL.md index 033bccf..cb9ccec 100644 --- a/plugins/shared/skills/webhooks/SKILL.md +++ b/plugins/shared/skills/webhooks/SKILL.md @@ -15,7 +15,7 @@ Major apps are protected by an authentication gateway by default. Enabling **Web ## Checking & Enabling Webhooks -Run `major app info --json` from the app workspace to check the current app status, including `webhooksEnabled`. In a hosted sandbox, run it through `mcp__sandbox__bash`. +Run `major app info --json` from the app workspace to check the current app status, including `webhooksEnabled`. In a hosted sandbox, run it through `mcp__plugin_major-build_major__sandbox_bash`. If webhooks are not enabled, instruct the user to enable them from the **Major dashboard → App Settings → Webhook Access** toggle.