> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Frontic Tools

The **Frontic Tools** MCP server connects AI coding assistants directly to your Frontic projects, letting you build storefronts and configure your Frontic API from your IDE. Pair it with the [Frontic Docs](/reference/mcp/frontic-docs) MCP server so the agent can also answer "how does X work?" questions without leaving the editor.

<Frame>
  <img src="https://mintcdn.com/frontic/34vlQbUxJTTktEkF/images/hero-mcp.png?fit=max&auto=format&n=34vlQbUxJTTktEkF&q=85&s=be3cd285767b47d3b78a25ae4d9fb853" alt="Frontic MCP Server Hero" width="2400" height="1354" data-path="images/hero-mcp.png" />
</Frame>

## Overview

Connect your favorite AI coding assistants directly to your Frontic Commerce projects through secure OAuth authentication. Build a frontend AND the corresponding Frontic API — all from your coding agent or IDE of choice.

<CardGroup cols={3}>
  <Card title="Claude Code" icon="terminal">
    Full project management and content creation workflows
  </Card>

  <Card title="Claude Desktop" icon="desktop">
    Interactive Frontic operations from your desktop
  </Card>

  <Card title="Cursor" icon="i-cursor">
    Integrated development experience with AI assistance
  </Card>
</CardGroup>

The MCP server provides **41 tools** across these categories:

<CardGroup cols={2}>
  <Card title="Project & Resource Discovery" icon="folder-open">
    Browse projects, list resources, inspect storage data, and make raw API calls
  </Card>

  <Card title="Blocks, Listings, Pages & Trees" icon="pen-ruler">
    Create and manage blocks, listings, pages, and menu trees that define your API
  </Card>

  <Card title="Storage Management" icon="database">
    Create Data Storages, then add, rename, and remove top-level fields
  </Card>

  <Card title="Project Configuration" icon="sliders">
    Explore domains, scopes, regions, and locales
  </Card>

  <Card title="Browse Data" icon="magnifying-glass">
    Search storage records and raw feed records
  </Card>

  <Card title="Integrations" icon="plug">
    Inspect connected integrations and their feed schemas before mapping
  </Card>

  <Card title="Data Syncs & Value Composer" icon="arrows-rotate">
    Create data syncs, configure field mappings, and preview composer operations
  </Card>

  <Card title="Context Documents" icon="file-lines">
    Manage skills, rules, guides, and other context documents
  </Card>

  <Card title="Browser Tools" icon="globe">
    Screenshot, extract content, and discover links on external websites
  </Card>
</CardGroup>

## Setup

The fastest path is the CLI — pick your package manager:

<CodeGroup>
  ```bash frontic theme={"theme":"css-variables"}
  frontic mcp init --client cursor
  ```

  ```bash pnpm theme={"theme":"css-variables"}
  pnpm dlx @frontic/cli@latest mcp init --client cursor
  ```

  ```bash npm theme={"theme":"css-variables"}
  npx @frontic/cli@latest mcp init --client cursor
  ```

  ```bash yarn theme={"theme":"css-variables"}
  yarn dlx @frontic/cli@latest mcp init --client cursor
  ```

  ```bash bun theme={"theme":"css-variables"}
  bunx @frontic/cli@latest mcp init --client cursor
  ```
</CodeGroup>

Swap `cursor` for `claude`, `windsurf`, `vscode`, or `codex`. The CLI prompts whether to install Frontic Tools, Frontic Docs, or both — the recommended default is both. See the [Frontic CLI reference](/reference/frontic-cli#frontic-mcp-init) for full options.

If you'd rather edit the config yourself, drop this entry into your client's MCP config file:

```json theme={"theme":"css-variables"}
{
  "mcpServers": {
    "frontic-tools": {
      "type": "http",
      "url": "https://mcp.frontic.com/mcp"
    }
  }
}
```

<Info>
  The first time you connect, you'll be prompted to authenticate via OAuth. The token carries your Frontic account's permissions — whatever role you have on a project, the MCP can do on that project, and nothing more.
</Info>

### Client-specific configuration

<Accordion title="Claude Code">
  Add to `.mcp.json` at your project root — Claude Code reads project MCP config from this file:

  ```json theme={"theme":"css-variables"}
  {
    "mcpServers": {
      "frontic-tools": {
        "type": "http",
        "url": "https://mcp.frontic.com/mcp"
      }
    }
  }
  ```
</Accordion>

<Accordion title="Claude Desktop">
  Edit the Claude Desktop config file:

  * **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json`
  * **Windows**: `%APPDATA%\Claude\claude_desktop_config.json`

  ```json theme={"theme":"css-variables"}
  {
    "mcpServers": {
      "frontic-tools": {
        "type": "http",
        "url": "https://mcp.frontic.com/mcp"
      }
    }
  }
  ```
</Accordion>

<Accordion title="Cursor">
  Add to `.cursor/mcp.json` in your project root, or Cursor's global settings:

  ```json theme={"theme":"css-variables"}
  {
    "mcpServers": {
      "frontic-tools": {
        "type": "http",
        "url": "https://mcp.frontic.com/mcp"
      }
    }
  }
  ```
</Accordion>

## Example Prompts

Once connected, try these prompts to explore the MCP server's capabilities:

<Prompt description="Have your agent list your projects and inspect the main one">List all my Frontic projects and show me the resources in my main project.</Prompt>

<Prompt description="Ask the agent to map out your Data Storages and their fields">What storages and data structures are available in my project?</Prompt>

<Prompt description="Let the agent build a Search Listing with filters and sorting">Create a product listing with filters for category and price, sorted by newest first.</Prompt>

<Prompt description="Tell the agent to scaffold a hero block with the standard fields">Create a hero block with fields for title, subtitle, background image, and CTA button.</Prompt>

<Prompt description="Have the agent assemble a homepage from existing primitives">Create a homepage with a hero section at the top and a featured products listing below.</Prompt>

<Prompt description="Get the agent to plan and set up a basic storefront end to end">Help me set up a basic storefront with a homepage, product listing page, and the necessary blocks.</Prompt>

<Prompt description="Have the agent extend a Data Storage schema with a new translatable field">Add a translatable `shortDescription` string field to the Products storage.</Prompt>

<Prompt description="Have the agent create a Products storage and connect a feed">Create a Products storage and connect it to the Shopify Products feed.</Prompt>

<Prompt description="Have the agent set up a content storage from scratch">Set up a content storage for blog articles.</Prompt>

<Prompt description="Have the agent add a relation field linking two storages">Add a `relatedProducts` relation field to the Products storage that links back to Products via the `sku` field.</Prompt>

<Prompt description="Walk the integration → feed → data sync workflow end to end">Show me the field schema of my Shopify Products feed and use it to map the Products data sync.</Prompt>

<Prompt description="Ask the agent to inspect your data syncs and their field mappings">Show me all data syncs and their field mappings for my project.</Prompt>

<Prompt description="Have the agent preview a Value Composer transformation on a sample record">Preview how the Value Composer transforms a sample product record.</Prompt>

<Prompt description="Use the agent's browser tools to screenshot a storefront and extract its links">Take a screenshot of my storefront homepage and extract the navigation links.</Prompt>

<Prompt description="Ask the agent to walk your scope, region, and domain hierarchy">List all scopes, regions, and domains in my project to understand the context hierarchy.</Prompt>

## Available Tools

### Project & Resource Discovery

#### `list_projects`

Browse all your Frontic projects with their names, IDs, data types, and configured locales. This is typically the first call in any workflow.

#### `list_resources`

List all blocks, listings, trees, pages, storages, or integrations within a project. When listing integrations, returns a compact inventory of each integration with its connected feeds (id and name only) — use `get_integration_feed` for the full feed schema.

#### `storage_ids`

Get record identifiers (IDs, slugs, keys) for a specific storage. Returns projected column values, not full records.

#### `fetch_api_call`

Get a sample Fetch API response for a block, listing, tree, or page — exactly what the frontend receives when calling the Frontic API. Useful for understanding the response shape before building your frontend.

#### `delete_resource`

Permanently delete a block, listing, page, or storage from the project. This action cannot be undone.

### Block Management

#### `create_block`

Create a new block — a reusable content component that defines which fields are exposed in Fetch API responses. Blocks serve single-record endpoints.

#### `manage_block`

Update an existing block by adding or removing fields, and control its active status.

### Listing Management

#### `create_listing`

Create a new listing — a searchable, filterable, sortable collection that performs search queries on a block index.

#### `manage_listing`

Configure all aspects of an existing listing: search fields, filter fields, sort fields, parameters, query conditions, search settings, and pagination.

### Page Management

#### `create_page`

Create a page — a URL routing pattern that generates SEO-friendly routes from block data records.

#### `manage_page`

Update an existing page's URL generation settings like slug source, conflict strategy, and delete behavior.

### Tree Management

#### `create_tree`

Create a [Menu Tree](/api-builder/trees) — a hierarchical collection of records (navigation menus, category trees, support article hierarchies). Each tree references a connected Data Storage and a Detail Block that defines the node shape. Multiple trees can share the same block; the agent prefers reusing an existing block over creating a new one.

### Storage Management

#### `create_storage`

Create a new [Data Storage](/data-integration/data-storages) with a name and schema type.

* `default` creates a regular Content storage for content or reference data.
* `commerce` creates a Products storage for product catalog data and adds commerce-specific system fields for variants, prices, parent keys, and options.

<Expandable title="Parameters">
  <ParamField path="projectId" type="string" required>
    Project ID where the storage should be created.
  </ParamField>

  <ParamField path="name" type="string" required>
    Storage name in capitalized words with spaces, e.g. `Products` or `Blog Articles`.
  </ParamField>

  <ParamField path="type" type="&#x22;default&#x22; | &#x22;commerce&#x22;" required>
    Storage schema type. Use `default` for Content storages and `commerce` for Products storages.
  </ParamField>
</Expandable>

After creating the storage, use `manage_storage` to add custom fields.

#### `manage_storage`

Update an existing [Data Storage](/data-integration/data-storages) by adding, renaming, or removing top-level fields. Field type is fixed at creation — to change a field's type you delete and recreate it.

Multiple operations can be batched in a single call and run sequentially, so a later operation can target a field added or renamed earlier in the same call.

<Expandable title="Field operations">
  <ParamField path="operation" type="&#x22;add&#x22; | &#x22;update&#x22; | &#x22;delete&#x22;" required>
    Which operation to perform on the field.
  </ParamField>

  <ParamField path="fieldId" type="string">
    Existing field ID for `update` or `delete`. Prefer this when available — get IDs from `list_resources(type="storages")`.
  </ParamField>

  <ParamField path="fieldName" type="string">
    Existing field name for `update` or `delete` when `fieldId` isn't known. Top-level fields only.
  </ParamField>

  <ParamField path="name" type="string">
    Field name for `add`, or the new name when renaming during `update`.
  </ParamField>

  <ParamField path="type" type="string">
    Type key for `add`, e.g. `string`, `integer`, `boolean`, or a custom composite type key. Required for `add` unless `relation` is supplied — when `relation` is provided and `type` is omitted, type defaults to `any`. Cannot be set on `update`.
  </ParamField>

  <ParamField path="description" type="string">
    Optional human-readable description.
  </ParamField>

  <ParamField path="isArray" type="boolean" default="false">
    Whether the field stores multiple values.
  </ParamField>

  <ParamField path="isTranslatable" type="boolean" default="false">
    Whether the field is translatable per locale.
  </ParamField>

  <ParamField path="isScoped" type="boolean" default="false">
    Whether the field returns different values per scope.
  </ParamField>

  <ParamField path="sharedAcrossVariants" type="boolean" default="false">
    Whether the field shares its value across product variants.
  </ParamField>

  <ParamField path="relation" type="object">
    Cross-storage relation. `sourceFieldName` (in this storage), `targetStorageId`, and `targetFieldName` (in the target storage) are required; optional `sourceFieldPath` and `targetFieldPath` address into composite fields. Set this when the field should resolve into another storage's records.
  </ParamField>

  <ParamField path="mockModule" type="string">
    Optional mock generator module, e.g. `faker.commerce.productName`.
  </ParamField>

  <ParamField path="mockModuleParams" type="string">
    Optional mock generator parameters string.
  </ParamField>

  <ParamField path="mockMin" type="integer">
    Optional minimum array size for generated mock data.
  </ParamField>

  <ParamField path="mockMax" type="integer">
    Optional maximum array size for generated mock data.
  </ParamField>
</Expandable>

The tool works on top-level fields only — nested sub-fields of composite types aren't editable through this tool. To create a new storage from scratch through MCP, use `create_storage`.

### Project Configuration

Explore the context hierarchy of your project. A **domain** is the top layer — from a domain you get the exact configuration map of scope, region, and locale.

* **Domains** map a scope, region, and locale combination to URL routing. Start here to understand how your project is configured.
* **Scopes** are data segmentation layers (e.g., B2B vs B2C). Every project has at least the default `public` scope. A scoped field can return different values per scope — for example, `true` in scope A and `false` in scope B.
* **Regions** are subdivisions of a scope (e.g., EU, US, APAC). Each region holds a currency and one or more locales, determining which prices to show.
* **Locales** determine which translation to return for translatable fields. If a field is set as translatable, the response value matches the translation for that locale.

| Tool           | Description                                                               |
| -------------- | ------------------------------------------------------------------------- |
| `list_domains` | List all domains configured in a project                                  |
| `get_domain`   | Get domain details including bound scope, region, locale, and URL pattern |
| `list_scopes`  | List all scopes in a project                                              |
| `get_scope`    | Get scope details including associated regions                            |
| `list_regions` | List all regions within a scope                                           |
| `get_region`   | Get region details                                                        |
| `list_locales` | List all configured locales in a project                                  |
| `get_locale`   | Get locale details                                                        |

### Browse Data

Search and inspect the actual data in your project — both transformed storage records and raw feed records from integrations.

#### `search_storage_records`

Search records in a storage to see the transformed values blocks and listings serve to the frontend. Useful for verifying data after a sync, debugging unexpected output, or pulling a realistic sample for a composer dry-run with `preview_composer_value` or `preview_composer_record`. Filter by scope, region, and locale to see contextualized values like scoped pricing or translated content.

By default `records[]` contains bare payload objects — exactly what the user stored, no wrapper. Pass `includeMetadata: true` to get each record wrapped with its `id`, `key`, `parentKey`, `createdAt`, and `updatedAt`. Opt in when you need to know when a record was updated/created or walk parent–child relationships in a follow-up call.

`metadata.parentKey` is the storage-tree parent — distinct from any `parentKey` a user happens to have inside their own payload. That namespacing is why metadata is opt-in rather than always-on.

`availableFilters` and `metaSearchResult` (pagination + total count) are always returned alongside `records[]`, regardless of `includeMetadata`.

##### Filtering with `conditions`

Pass an optional `conditions` object to narrow results. It takes an `and` array, an `or` array, or both — each item is `{field, operator, value}`:

```json theme={"theme":"css-variables"}
{
  "and": [
    { "field": "slug", "operator": "like", "value": "polizei" }
  ]
}
```

<ParamField path="field" type="string" required>
  Field name to filter on, taken from `availableFilters` in the response.
</ParamField>

<ParamField path="operator" type="&#x22;equals&#x22; | &#x22;notEquals&#x22; | &#x22;gt&#x22; | &#x22;lt&#x22; | &#x22;gte&#x22; | &#x22;lte&#x22; | &#x22;like&#x22; | &#x22;notLike&#x22;" required>
  Comparison operator. `like` and `notLike` take a raw substring — no SQL wildcards, the backend wraps them.
</ParamField>

<ParamField path="value" type="string | number | boolean | string[]" required>
  Value to compare against. Use a `string[]` for IN-style matches.
</ParamField>

Omit `conditions` entirely to return all records.

#### `search_feed_records`

Search feed records from an integration to see the connector-normalized data before the composer transforms it. Every commerce platform names fields differently (Shopify: flat keys; Shopware: dot-notation; commercetools: deeply nested objects), so inspecting an actual feed record is the only reliable way to know what's available and how it's shaped.

Same metadata contract as `search_storage_records`: bare payloads by default, full envelope (`id`, `key`, `parentKey`, `createdAt`, `updatedAt`) when you pass `includeMetadata: true`. `availableFilters` and `metaSearchResult` are always returned.

### Integrations

Discover and inspect connected source systems and their feed schemas. The typical workflow is `list_resources(type="integrations")` → pick a feed → `get_integration_feed` → use the field paths in `manage_data_sync_value_configs` or composer previews.

#### `get_integration_feed`

Get the full schema for a single integration feed by feed ID. Returns the integration metadata, feed metadata (including `type`, `token`, `urls`, `methods`, `configurations`, and `refreshSupported`), and a flat field list in dot-path notation with types — for example, `title (string)`, `manufacturer (object)`, `manufacturer.name (string)`. The flat representation is what you copy into composer configs.

If the feed ID isn't found, the tool returns the list of available feed IDs in the project so the agent can recover without a separate discovery call.

### Data Syncs

| Tool                             | Description                                                                                                                                                                                                                                                                               |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `list_data_syncs`                | List all data sync configurations, showing which integrations feed into which storages                                                                                                                                                                                                    |
| `create_data_sync`               | Create a data sync shell that connects one integration feed to one storage with a name, feed, storage, and optional scope/channel/locale mappings. New data syncs are enabled on creation; call `get_data_sync`, then `manage_data_sync_value_configs`, to configure field value mappings |
| `get_data_sync`                  | Get a single data sync with full field-level detail including value-composer configurations                                                                                                                                                                                               |
| `manage_data_sync_value_configs` | Update data sync value composer field configurations by field ID                                                                                                                                                                                                                          |

### Value Composer

| Tool                       | Description                                                                                                   |
| -------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `list_composer_operations` | List all available value-composer operations with type, input/output shapes, and documentation                |
| `preview_composer_value`   | Preview a computed value by running a single value-composer config against a sample record (dry-run)          |
| `preview_composer_record`  | Preview a full transformed record by running all storage-field mapping configs against a sample source record |

### Context Documents <sup>Plus</sup>

<Info>
  Context document tools are part of **Frontic AI Studio**, available on the **Plus plan**.
</Info>

Manage skills, rules, commands, guides, and other context documents that provide instructions and knowledge to AI agents working with your project.

| Tool                      | Description                                                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| `list_context_documents`  | List all active documents in a collection (`skills`, `rules`, `commands`, `guides`, `docs`) |
| `fetch_context_document`  | Fetch a single document by key, returning full markdown with YAML frontmatter               |
| `create_context_document` | Create a new document in draft status (must be manually activated in the admin UI)          |
| `manage_context_document` | Update a document's metadata and/or content                                                 |

### Studio Settings <sup>Plus</sup>

<Info>
  Studio settings tools are part of **Frontic AI Studio**, available on the **Plus plan**.
</Info>

Read and update the Studio settings that govern chat behaviour at the project level — Project Rules (`system/studio-rules`) and the project Studio Prompt (`system/studio-agent`).

| Tool                    | Description                                                                                  |
| ----------------------- | -------------------------------------------------------------------------------------------- |
| `list_studio_settings`  | List the available Studio settings keys for the project                                      |
| `manage_studio_setting` | Update a Studio setting's content by key (e.g. `system/studio-rules`, `system/studio-agent`) |

### Browser Tools

Screenshot, extract content, and discover links on external websites using a server-side headless browser. Useful for analyzing existing storefronts during migration planning or store discovery.

#### `browser_screenshot`

Take a screenshot of a URL and return it as a compressed JPEG image.

<Expandable title="Parameters">
  <ParamField path="url" type="string" required>
    The webpage URL to screenshot.
  </ParamField>

  <ParamField path="viewport_width" type="integer" default="1280">
    Browser viewport width (320–1440).
  </ParamField>

  <ParamField path="viewport_height" type="integer" default="720">
    Browser viewport height (200–900).
  </ParamField>

  <ParamField path="full_page" type="boolean" default="false">
    Capture the full scrollable page (capped at 7680px height).
  </ParamField>

  <ParamField path="selector" type="string">
    CSS selector to screenshot a specific element.
  </ParamField>
</Expandable>

<Note>
  For Claude Code users: set `MAX_MCP_OUTPUT_TOKENS=100000` in your environment to handle screenshot responses.
</Note>

#### `browser_extract`

Extract specific DOM elements from a webpage using CSS selectors. Returns text content, attributes, dimensions, and HTML for each match.

<Expandable title="Parameters">
  <ParamField path="url" type="string" required>
    The webpage URL to extract from.
  </ParamField>

  <ParamField path="selectors" type="string[]" required>
    CSS selectors to extract (max 10).
  </ParamField>

  <ParamField path="wait_for" type="string">
    CSS selector to wait for before extracting (useful for SPAs).
  </ParamField>
</Expandable>

#### `browser_links`

Discover all links on a webpage, grouped by internal vs external. Useful for mapping site structure and navigation patterns.

<Expandable title="Parameters">
  <ParamField path="url" type="string" required>
    The webpage URL to scan.
  </ParamField>

  <ParamField path="internal_only" type="boolean" default="true">
    Only return links to the same domain.
  </ParamField>

  <ParamField path="wait_for" type="string">
    CSS selector to wait for before extracting links.
  </ParamField>
</Expandable>