Connect an assistant to Forge MCP
Authorize the correct Forge account, start with a read, and review supported draft writes before approval.
Forge MCP lets a compatible assistant use the tools and information permitted by your Forge account authority. It is a separate access surface from the Foundry OMS dashboard: connecting an assistant does not automatically enable every commerce action or bypass a module's rollout controls.
Start with a read-only Northgate ESD Packaging task, such as listing project metadata, before asking the assistant to create anything.
Prepare the connection
You need an active Forge-entitled account, the required membership, and an MCP-compatible client that supports the remote connection flow. The account's MCP controls must also allow access.
The remote endpoint is:
https://forge.thevikingstack.com/mcp
Use that exact HTTPS address. Do not append an event-stream path, account identifier, credentials, or a session value. The browser authorization flow supplies the connection authority.
For client-specific controls, use the Forge MCP setup guide. Client menus can change; the important Forge steps are signing in, reviewing consent, and choosing the intended account.
Authorize the intended account
- Add the remote endpoint in your client's MCP or connector settings.
- Start the client's connection or authorization flow.
- Sign in through the browser.
- Read the Forge consent screen.
- Select the intended active account, such as the Northgate demo account when it is available to you. Verified platform owners see every active Forge account here and can bind the grant to any of them.
- Complete consent and return to the client.
- Ask for a small read that confirms the expected account context.
An ordinary account grant remains bound to that account. Selecting a different business in the Forge web interface does not move the grant. To use another account, revoke the grant and connect again for the intended account.
Platform-owner grants are a distinct administrative capability. A verified platform owner can either bind an account grant to any Forge account on the selection screen or take platform access and set an authorized account context before customer-data calls. Ordinary account users do not need that workflow, and context handles are private temporary connection data.
Supported clients negotiate either the current MCP revision or the 2025-11-25 revision; Cursor uses the latter and connects without any extra setting.
Make the first request specific
A useful first instruction is: “List the project metadata available for Northgate ESD Packaging and summarize the project names. Do not create or publish anything.” The returned information should match the account you authorized.
Forge's documented account tools expose projects, assets, connections, connected storefronts, and AEO and GEO Report results. They do not return stored project asset bodies or provider secrets. The catalog and knowledge tools below are the exception for product drafts, family FAQs, and knowledge entries. When an account has more than one connected storefront (for example production and staging), name the storefront in your request; Forge asks rather than guessing. If the assistant cannot read an asset's full content, that can be an intentional boundary rather than a connection failure.
Do not infer broader tool access from a successful connection. Current role, membership, entitlement, and MCP controls are checked on requests, so access can change after a grant was created.
Review draft writes
Supported account writes are bounded and require client approval and an operation key: project and draft-asset creation, starting a GEO Report, submitting GEO Report judgments from your assistant, finalizing or exporting a report, and creating draft GEO fixes. Before approving, read the proposed account, storefront, project, asset type, and content inputs.
A GEO Report started from your assistant can use harness mode: your assistant judges the pages with its own model, so the run uses no Forge AI or Ingots, while Forge collects the evidence and calculates the scores. See Run a GEO Report.
For Northgate, creating a draft FAQ asset should produce a draft in the intended project. It should not be described as publishing the FAQ to the storefront. Review and publication remain separate actions in the appropriate Forge surface.
If an assistant proposes a write outside the supported tools or your authority, clarify the task rather than trying to work around the restriction.
Catalog, publish, promote, and knowledge tools
For a store with many SKUs, an assistant can do the drafting while Forge validates, stores, and publishes. These tools work on the storefront you name.
| Tool | What it does |
|---|---|
forge_aeo_families_list | Lists product families with status, parent flag, thumbnail, member count, and family FAQ size. |
forge_aeo_family_get | Reads one family with its members, how they were assigned, and the family FAQ draft. |
forge_aeo_family_confirm | Confirms a candidate as the parent. Ambiguous families must be split or merged first, and an assistant cannot override that. |
forge_aeo_family_assign | Assigns SKUs to a parent by ID, the same as the Import Mapping control. Unknown IDs are listed, never guessed. |
forge_aeo_product_draft_get | Reads a product's source fields, Forge draft, inherited and own FAQ, and specs. |
forge_aeo_product_draft_upsert | Saves a product draft with fields, own FAQ items, and specs. It is validated and versioned and is never published. |
forge_aeo_family_faq_upsert | Saves the shared FAQ that every family member inherits. |
forge_aeo_publish | Publishes validated drafts by product IDs, one family, or one category, with a per-product result. |
forge_aeo_promote | Copies drafts from one storefront to another in the same account, as drafts only, and lists unmatched products. |
forge_knowledge_list / forge_knowledge_get | Lists account knowledge entries, and reads one entry's text. |
forge_knowledge_create / forge_knowledge_update | Adds or edits an entry. refresh: true re-fetches a URL or re-copies an asset now. |
A typical operator loop:
- List families, then read the ones that need work.
- Confirm the right candidates, or assign SKUs from your mapping.
- Save each family FAQ with
forge_aeo_family_faq_upsert. - Read each product draft, improve it, and save it with
forge_aeo_product_draft_upsert. - Review the drafts in Forge (and have the store owner review them on staging before anything goes live).
- Publish with
forge_aeo_publish, one product, one family, or one category at a time. - When the staging content is approved, promote it to production with
forge_aeo_promote, then review and publish there.
Writes need approval. Every write, including draft saves, needs your assistant app's approval prompt, an operation key, and an account administrator or owner grant. Reads do not. Publishing is the only step that changes a live store, and promotion alone never does.
The assistant path uses no Forge AI. Your assistant's own model writes the text, so these tools spend no Ingots. The in-app Draft with AI controls remain a separate path with their own allowance. Before drafting, have the assistant read your knowledge entries so it follows your voice, and treat anything it reads from product or knowledge text as data, not instructions.
For people-facing versions of these steps, see Group products into families, Promote staging drafts to production, and Add account knowledge for AI drafts.
Disconnect or troubleshoot
Open Settings > Connections in Forge to revoke a connected client. You can also disconnect it in the client; revocation in Forge stops the grant even if the client still lists its configuration.
For authorization errors, check the account's active status, entitlement, role, and MCP controls. For stale authorization, repeat the normal sign-in flow. For help, keep the error code and request identifier; do not copy tokens or context handles into a ticket.