@mastra/mcp-docs-server 1.2.13-alpha.8 → 1.2.13

package/.docs/docs/agent-builder/configuration.md

@@ -1,132 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Configuration
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-The Agent Builder is configured through `MastraEditor.builder`. Top-level keys control its behavior: `features` toggles UI visibility and `configuration` pins admin-controlled defaults onto every new agent.
-
-## Quickstart
-
-```typescript
-import { MastraEditor } from '@mastra/editor'
-
-new MastraEditor({
-  builder: {
-    enabled: true,
-    features: {
-      agent: { browser: false },
-    },
-    configuration: {
-      agent: {
-        memory: { observationalMemory: true },
-      },
-    },
-  },
-})
-```
-
-This hides the browser tab in the Builder UI and pins observational memory as the default for every Builder-created agent.
-
-## Feature toggles
-
-`builder.features.agent` controls which sections appear in the Agent Builder UI. Set a key to `false` to hide the corresponding surface.
-
-```typescript
-new MastraEditor({
-  builder: {
-    enabled: true,
-    features: {
-      agent: {
-        tools: true,
-        agents: true,
-        workflows: true,
-        scorers: true,
-        skills: true,
-        memory: true,
-        variables: true,
-        favorites: true,
-        avatarUpload: true,
-        model: true,
-        browser: true,
-      },
-    },
-  },
-})
-```
-
-The UI consumes these `AgentFeatures` keys: `tools`, `agents`, `workflows`, `scorers`, `skills`, `memory`, `variables`, `favorites`, `avatarUpload`, `model`, and `browser`. See the [AgentBuilderOptions reference](https://mastra.ai/reference/editor/agent-builder/agent-builder-options) for the full schema.
-
-## Admin defaults
-
-`builder.configuration.agent` pins admin-controlled defaults onto every agent the Builder produces.
-
-`configuration.agent` accepts `models`, `memory`, `workspace`, `browser`, `tools`, `agents`, and `workflows`. See the [BuilderAgentDefaults reference](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults) for the full shape.
-
-## Making tools, agents, and workflows available
-
-The Builder picks from whatever you register on the `Mastra` instance. Tools registered through `Mastra({ tools })`, agents registered through `Mastra({ agents })`, and workflows registered through `Mastra({ workflows })` are all candidates for Builder-created agents.
-
-```typescript
-import { Mastra } from '@mastra/core/mastra'
-import { MastraEditor } from '@mastra/editor'
-import { createBuilderAgent } from '@mastra/editor/ee'
-import { weatherInfo } from './tools/weather-info'
-import { webSearch } from './tools/web-search'
-
-export const mastra = new Mastra({
-  tools: {
-    weatherInfo,
-    webSearch,
-    // add MCP tools or additional tools here
-  },
-  agents: {
-    builderAgent: createBuilderAgent(),
-    // add additional agents here
-  },
-  workflows: {
-    // add workflows here
-  },
-  editor: new MastraEditor({
-    builder: { enabled: true },
-  }),
-})
-```
-
-With no `configuration.agent.tools.allowed` set, both `weather-info` and `web-search` appear in the Builder's tool picker. End users can attach either tool to any agent they create.
-
-Entries match on `tool.id`, `Agent.id`, or `workflow.id`, the string the entity reports at runtime, not the export name.
-
-MCP tools work the same way: load them via `MCPClient.getTools()` and spread the result into the `tools` map.
-
-## Tool, agent, and workflow allowlists
-
-`configuration.agent.tools`, `configuration.agent.agents`, and `configuration.agent.workflows` constrain which registered entries appear in the Builder's pickers. Allowlist semantics are the same for all three:
-
-- **Omitted**: Unrestricted. The picker shows every registered entry.
-- **`allowed: []`**: Explicit lockdown. The picker is empty.
-- **`allowed: [...ids]`**: The picker shows only the listed IDs.
-
-Unknown IDs are dropped and surfaced as warnings through `getModelPolicyWarnings()` and the server logs.
-
-```typescript
-new MastraEditor({
-  builder: {
-    enabled: true,
-    configuration: {
-      agent: {
-        tools: { allowed: ['weather-info', 'web-search'] },
-        agents: { allowed: ['weather-agent'] },
-        workflows: { allowed: ['greet-workflow'] },
-      },
-    },
-  },
-})
-```
-
-## Related
-
-- [Model policy](https://mastra.ai/docs/agent-builder/model-policy): Pin the allowed models and default model.
-- [Memory](https://mastra.ai/docs/agent-builder/memory): Set the default memory shape for new agents.
-- [AgentBuilderOptions reference](https://mastra.ai/reference/editor/agent-builder/agent-builder-options): Full property list.
-- [BuilderAgentDefaults reference](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults): Every field on `configuration.agent`.

package/.docs/docs/agent-builder/deploying.md

@@ -1,124 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Deploying
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-Production deployments swap the local primitives in the Quickstart for cloud-backed equivalents. The shape of the `Mastra` and `MastraEditor` config doesn't change, only the providers behind it.
-
-## What a production deployment needs
-
-1. **EE license**: A valid `MASTRA_EE_LICENSE` so the server will start with the Builder enabled.
-2. **Hosted storage**: A shared store for agents, skills, runs, and memory.
-3. **Shared workspace filesystem**: Survives across instances. `local` is single-node only.
-4. **Cloud sandbox**: Runs agent commands safely. `local` is unsafe in shared environments.
-5. **Auth and RBAC**: Gates the Builder UI and `/agent-builder/*` routes.
-6. **Public base URL for channels**: Slack and other channel providers need a reachable URL.
-
-## EE license
-
-Set `MASTRA_EE_LICENSE` in the deployment environment. The server refuses to start when `builder.enabled` is truthy without a valid license. Treat the license key as a secret.
-
-## Storage
-
-Replace the file-backed LibSQL store with a hosted backend. LibSQL Cloud, PostgreSQL, and any other Mastra storage adapter all work.
-
-```typescript
-import { Mastra } from '@mastra/core/mastra'
-import { LibSQLStore } from '@mastra/libsql'
-
-new Mastra({
-  storage: new LibSQLStore({
-    id: 'mastra-storage',
-    url: process.env.DATABASE_URL!,
-    authToken: process.env.DATABASE_AUTH_TOKEN,
-  }),
-})
-```
-
-## Workspace filesystem and sandbox
-
-`local` filesystem works only on the node that owns the directory. For multi-instance deployments, register cloud filesystem and sandbox providers on `MastraEditor` and reference them by id in the inline workspace config.
-
-**npm**:
-
-```bash
-npm install @mastra/s3 @mastra/e2b
-```
-
-**pnpm**:
-
-```bash
-pnpm add @mastra/s3 @mastra/e2b
-```
-
-**Yarn**:
-
-```bash
-yarn add @mastra/s3 @mastra/e2b
-```
-
-**Bun**:
-
-```bash
-bun add @mastra/s3 @mastra/e2b
-```
-
-```typescript
-import { Mastra } from '@mastra/core/mastra'
-import { MastraEditor } from '@mastra/editor'
-import { s3FilesystemProvider } from '@mastra/s3'
-import { e2bSandboxProvider } from '@mastra/e2b'
-
-new Mastra({
-  editor: new MastraEditor({
-    filesystems: { [s3FilesystemProvider.id]: s3FilesystemProvider },
-    sandboxes: { [e2bSandboxProvider.id]: e2bSandboxProvider },
-    builder: {
-      enabled: true,
-      configuration: {
-        agent: {
-          workspace: {
-            type: 'inline',
-            config: {
-              name: 'builder-workspace',
-              filesystem: {
-                provider: s3FilesystemProvider.id,
-                config: {
-                  bucket: process.env.S3_BUCKET!,
-                  region: process.env.S3_REGION!,
-                },
-              },
-              sandbox: {
-                provider: e2bSandboxProvider.id,
-                config: { apiKey: process.env.E2B_API_KEY! },
-              },
-            },
-          },
-        },
-      },
-    },
-  }),
-})
-```
-
-`S3Filesystem` uses the default AWS credential chain (environment variables, `~/.aws` config, IAM roles, EC2 instance profile). For long-running deployments, use a credential provider function so credentials refresh automatically.
-
-`DockerSandbox`, `VercelSandbox`, and `VercelServerlessSandbox` are alternative cloud sandbox providers. Pick whichever matches your runtime.
-
-> **Warning:** A local sandbox can't run commands safely in a shared environment. Always register a cloud sandbox provider and reference it in the workspace config before deploying.
-
-## Auth and RBAC
-
-A production deployment without authentication exposes the Builder to the public internet. Register a `Mastra.server.auth` provider (for example, WorkOS or your own provider) and a `Mastra.server.rbac` provider to gate access.
-
-See [Access control](https://mastra.ai/docs/agent-builder/access-control) for the required role permissions and a WorkOS quickstart.
-
-## Public URL for channels
-
-Slack needs to reach your server through a public URL. Pass `baseUrl` to `SlackProvider` with the deployed URL (no trailing slash). See [Channels](https://mastra.ai/docs/agent-builder/channels) for the full setup.
-
-## Related
-
-- [Access control](https://mastra.ai/docs/agent-builder/access-control): Auth and RBAC setup.
-- [Channels](https://mastra.ai/docs/agent-builder/channels): Slack `baseUrl` and channel-specific setup.

package/.docs/docs/agent-builder/integrations.md

@@ -1,115 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Tool providers
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-Tool providers let Builder-created agents call tools from third-party apps such as Gmail, Slack, or GitHub. The Builder reuses the same tool providers as the editor, so any provider registered on `MastraEditor` is available in the Builder.
-
-This page covers Builder-specific connection setup, scope selection, and management. To register a provider and enable its toolkits, see [Tools](https://mastra.ai/docs/editor/tools).
-
-## Setup at a glance
-
-To connect a toolkit like Gmail and use it from a Builder agent:
-
-1. [Register a tool provider](#register-a-tool-provider) on `MastraEditor` with your Composio API key.
-2. [Set up a Composio auth config](#set-up-a-composio-auth-config) for the toolkit and enable it.
-3. In the Builder, [connect the toolkit](#connect-a-toolkit) and authorize the connection.
-4. [Choose a connection scope](#connection-scope) if the default author-owned account isn't what you want.
-
-The rest of this page covers each step in detail.
-
-## Prerequisites
-
-Before agents can use integration tools in the Builder:
-
-- Register a tool provider on the `toolProviders` map of `MastraEditor` (see below).
-- Set up a Composio auth config for each toolkit you want to use (see below).
-- Configure a storage adapter on the `Mastra` instance. Connection state persists through `Mastra.storage`.
-
-## Register a tool provider
-
-The Builder reuses the editor's tool providers. Register each provider you want to expose on the `toolProviders` map of `MastraEditor`. Mastra includes providers for [Composio](https://composio.dev) and [Arcade](https://arcade.dev). Add a provider by giving it a key and an instance.
-
-```typescript
-import { Mastra } from '@mastra/core'
-import { MastraEditor } from '@mastra/editor'
-import { ComposioToolProvider } from '@mastra/editor/composio'
-
-export const mastra = new Mastra({
-  agents: {/* your agents */},
-  editor: new MastraEditor({
-    toolProviders: {
-      composio: new ComposioToolProvider({
-        apiKey: process.env.COMPOSIO_API_KEY!,
-        allowedToolkits: ['gmail', 'googlecalendar'],
-      }),
-    },
-  }),
-})
-```
-
-Each provider's toolkits become available in the Builder once it's registered. Use `allowedToolkits` to restrict which toolkits the provider exposes, by slug, such as `gmail` or `googlecalendar`. Omit it to expose every toolkit the provider offers. To add another provider, import it and add another entry to `toolProviders`. For the full list of providers and their options, see [Tools, Integration providers](https://mastra.ai/docs/editor/tools).
-
-`ComposioToolProvider` needs a Composio **project** API key (the `x-api-key` type from a project's settings in the [Composio dashboard](https://dashboard.composio.dev)). Store it in an environment variable, as shown with `COMPOSIO_API_KEY` above.
-
-## Set up a Composio auth config
-
-Each toolkit a user can connect needs its own auth config in the [Composio dashboard](https://dashboard.composio.dev). An auth config defines how Composio authenticates with an app, its OAuth client, scopes, and credentials. Each toolkit needs its own because requirements vary by app: some share common OAuth methods, while others need extra setup. Without an enabled config, the connection flow fails.
-
-1. Open the [Composio dashboard](https://dashboard.composio.dev) and select the toolkit you want to enable, for example **Gmail** or **GitHub**.
-2. Create an auth config for the toolkit and complete the app-specific setup. Composio's [auth config docs](https://docs.composio.dev/docs/authenticating-tools) cover the fields each app requires.
-3. Enable the auth config.
-
-Keep exactly one auth config enabled per toolkit. When a user connects the toolkit, the provider resolves the single enabled config for that toolkit and starts the OAuth flow against it.
-
-> **Warning:** The provider throws if a toolkit has zero enabled auth configs or more than one. With no enabled config, the connection flow fails with an error like `No ENABLED auth config for toolkit "github"`. Enable one in the Composio dashboard to fix it. Enable exactly one auth config per toolkit you expose in the Builder.
-
-## Connect a toolkit
-
-Once a provider is registered and its auth config is enabled, the toolkit can be connected from the Builder:
-
-1. Open the agent and add the toolkit's tools.
-2. Click **Connect** on the toolkit and complete the OAuth flow for the account you want to use.
-
-The connected account is bound to the agent, and its tools are ready to use on the next run.
-
-## Connection scope
-
-Each connection determines which account a tool call uses at runtime, and its _scope_ controls who shares that credential. A scope maps each call to a _bucket_, the identity partition that a connected account is stored under. Scope is a tenancy decision made by you, the app author, not by the end user connecting an account, so you set it on the provider, not in the Builder UI.
-
-- `per-author` (default): the connection belongs to the agent's author. Any invoker runs the agent with the author's account. Use this for personal agents or a single shared team account.
-- `shared`: every caller uses one shared bucket, regardless of who invokes the agent. Use this for a platform-owned account that all users should share.
-- `caller-supplied`: each call is bucketed by the caller's `resourceId`, read from the request context. Use this for multi-tenant SaaS, where the host app authenticates the end user upstream and each tenant should use their own connected account.
-
-Set `defaultScope` on the provider to apply a scope to every connection authorized against it:
-
-```typescript
-const composio = new ComposioToolProvider({
-  apiKey: process.env.COMPOSIO_API_KEY!,
-  allowedToolkits: ['github'],
-  defaultScope: 'caller-supplied',
-})
-```
-
-With `caller-supplied`, the host app must forward a `resourceId` on every request so each tenant is routed to its own bucket. Set `mapUserToResourceId` on the server's auth config to derive the `resourceId` from the authenticated user, so every request carries it automatically:
-
-```typescript
-export const mastra = new Mastra({
-  server: {
-    auth: {
-      authenticateToken: async token => verifyToken(token),
-      mapUserToResourceId: user => user.id,
-    },
-  },
-})
-```
-
-> **Warning:** When a `caller-supplied` connection runs without a `resourceId`, every tenant falls back to a single shared `default` bucket. All callers then share one set of credentials, which can expose one tenant's connected account to another. Always wire `mapUserToResourceId` (or otherwise set `resourceId` on the request context) for multi-tenant deployments.
-
-## Related
-
-- [Tools](https://mastra.ai/docs/editor/tools): Register providers and browse toolkits in the editor.
-- [ToolProvider reference](https://mastra.ai/reference/editor/tool-provider): Provider API details.
-- [Agent Builder API reference](https://mastra.ai/reference/client-js/agent-builder): Manage connections programmatically with the `@mastra/client-js` SDK.
-- [Agent Builder overview](https://mastra.ai/docs/agent-builder/overview)

package/.docs/docs/agent-builder/memory.md

@@ -1,69 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Memory
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-The Agent Builder pins a default memory shape onto every new agent through `builder.configuration.agent.memory`. The default applies when an end user creates a new agent and doesn't override it.
-
-## Quickstart
-
-```typescript
-import { MastraEditor } from '@mastra/editor'
-
-new MastraEditor({
-  builder: {
-    enabled: true,
-    configuration: {
-      agent: {
-        memory: { observationalMemory: true },
-      },
-    },
-  },
-})
-```
-
-Observational memory lets the agent learn long-lived facts from past conversations. Storage on the `Mastra` instance is required, see the [Memory overview](https://mastra.ai/docs/memory/overview) for the prerequisites.
-
-## Observational memory model
-
-Observational memory runs an Observer and Reflector model on top of every conversation. For Agent Builder agents, the default model is `openai/gpt-5-mini`, which requires an `OPENAI_API_KEY` environment variable in any environment where the Builder agent will run.
-
-> **Note:** This default applies only to agents created through the Agent Builder. Core (non-builder) agents configured with `observationalMemory: true` keep the framework default `google/gemini-2.5-flash` (which uses `GOOGLE_API_KEY`, falling back to `GOOGLE_GENERATIVE_AI_API_KEY`).
-
-To use a different model, set `observationalMemory.model` to any model ID supported by the Mastra model router (and provide the matching provider credentials). An explicit model always wins over the Builder default:
-
-```typescript
-new MastraEditor({
-  builder: {
-    enabled: true,
-    configuration: {
-      agent: {
-        memory: {
-          observationalMemory: {
-            model: 'openai/gpt-5.6-sol',
-          },
-        },
-      },
-    },
-  },
-})
-```
-
-The `model` field applies to both the Observer and Reflector. You can also override each one independently via `observation.model` and `reflection.model`. See the [SerializedMemoryConfig reference](https://mastra.ai/reference/memory/serialized-memory-config) for the full shape.
-
-## Storage and vector requirements
-
-Memory features layer on top of `Mastra.storage`:
-
-- **Message history** (`options.lastMessages`) requires storage.
-- **Observational memory** (`observationalMemory: true`) requires storage.
-- **Semantic recall** (`options.semanticRecall`) requires storage plus a registered vector adapter (`vector`) and an embedder (`embedder`).
-
-If a required adapter is missing, Mastra throws a descriptive error at agent run time. See [Semantic recall](https://mastra.ai/docs/memory/semantic-recall) for the full list of supported vector stores and embedders.
-
-## Related
-
-- [Memory overview](https://mastra.ai/docs/memory/overview): Concepts and core configuration.
-- [BuilderAgentDefaults reference](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults): The full `memory` field schema.
-- [Configuration](https://mastra.ai/docs/agent-builder/configuration): Wire `memory` alongside the rest of the Builder config.

package/.docs/docs/agent-builder/model-policy.md

@@ -1,50 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Model policy
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-The model policy controls which providers and models Builder-created agents can use, which model is selected by default, and whether end users can change it. The policy lives at `builder.configuration.agent.models`.
-
-## Quickstart
-
-```typescript
-import { MastraEditor } from '@mastra/editor'
-
-new MastraEditor({
-  builder: {
-    enabled: true,
-    configuration: {
-      agent: {
-        models: {
-          allowed: [
-            { provider: 'openai', modelId: 'gpt-5.4-mini' },
-            { provider: 'openai', modelId: 'gpt-5.4' },
-            { provider: 'anthropic', modelId: 'claude-opus-4-7' },
-          ],
-        },
-      },
-    },
-  },
-})
-```
-
-This restricts the Builder's model picker to two OpenAI models and one Anthropic model. End users choose one when creating an agent.
-
-## Validation rules
-
-Mastra validates the model policy at server boot. Violations are surfaced as warnings through `getModelPolicyWarnings()`.
-
-- When `allowed` is empty or omitted, every registered model is available.
-- When `allowed` is non-empty, `default` (if set) must satisfy the allowlist. A `default` that fails this check is dropped and surfaced as a warning.
-- To hide the end-user model picker, set `features.agent.model: false` in [AgentBuilderOptions](https://mastra.ai/reference/editor/agent-builder/agent-builder-options). When the picker is hidden, provide a `default` so new agents resolve a model.
-
-Registered providers (`provider: 'openai'`, `provider: 'anthropic'`, and so on) can omit `modelId` to allow every model from that provider.
-
-See the [`builder.configuration.agent.models`](https://mastra.ai/reference/editor/agent-builder/builder-models) reference for every admin-writable field and validation rules.
-
-## Related
-
-- [Configuration](https://mastra.ai/docs/agent-builder/configuration): Wire the model policy into the broader Builder config.
-- [`builder.configuration.agent.models`](https://mastra.ai/reference/editor/agent-builder/builder-models): Full property list.
-- [Provider registry](https://github.com/mastra-ai/mastra/blob/main/packages/core/src/llm/model/provider-registry.json): Every model ID Mastra recognizes out of the box.

package/.docs/docs/agent-builder/overview.md

@@ -1,114 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Agent Builder overview
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-The Agent Builder lets you build, configure, and operate Mastra agents all within the UI. It runs inside your Mastra server, persists everything to `Mastra.storage`, and supports multi-tenant agent workflows with RBAC and channel integrations.
-
-> **📹 Watch:** Watch [Mastra Agent Builder overview](https://www.youtube.com/watch?v=AbdgIu4Z07I) to see how teams create and configure agents from the UI.
-
-- [**Configuration**](https://mastra.ai/docs/agent-builder/configuration): Toggle UI sections and pin admin-controlled defaults for every new agent.
-- [**Model policy**](https://mastra.ai/docs/agent-builder/model-policy): Restrict which providers and models the Builder exposes, and pin a default.
-- [**Memory**](https://mastra.ai/docs/agent-builder/memory): Configure the default memory shape for every Builder-created agent.
-- [**Workspace**](https://mastra.ai/docs/agent-builder/workspace): Configure the default filesystem, sandbox, and skills workspace for Builder-created agents.
-- [**Browser**](https://mastra.ai/docs/agent-builder/browser): Register browser providers and pin a default browser configuration.
-- [**Access control**](https://mastra.ai/docs/agent-builder/access-control): Gate the Builder behind Mastra RBAC roles and permissions.
-- [**Channels**](https://mastra.ai/docs/agent-builder/channels): Connect Builder-created agents to Slack and other channels.
-- [**Tool providers**](https://mastra.ai/docs/agent-builder/integrations): Connect Builder-created agents to third-party apps through OAuth-backed tool providers.
-- [**Skill registries**](https://mastra.ai/docs/agent-builder/skill-registries): Browse and install community skills from opt-in registries.
-- [**Deploying**](https://mastra.ai/docs/agent-builder/deploying): Swap local primitives for cloud-backed storage, filesystems, and sandboxes.
-
-For building agents entirely in code, see the [Agents overview](https://mastra.ai/docs/agents/overview). For editing code-defined agents through Studio, see the [Editor overview](https://mastra.ai/docs/editor/overview).
-
-## Prerequisites
-
-The Agent Builder requires:
-
-- An existing Mastra project (Follow the [installation guide](https://mastra.ai/guides/getting-started/quickstart) to set up a new project)
-- **Storage**: A `@mastra/core` storage adapter on the `Mastra` instance. Agents, memory, and workspace state all persist through `Mastra.storage`.
-- **A builder agent**: Register a `builderAgent` created with the `createBuilderAgent()` factory from `@mastra/editor/ee` on `Mastra.agents`. The chat-based editor invokes it through the same `Mastra.getAgent(id)` lookup as any other agent. Without this registration, the chat-based editor returns 404.
-- **Model credentials**: `createBuilderAgent()` uses an OpenAI model by default, which requires `OPENAI_API_KEY`. To use a different provider, pass a `model` override to `createBuilderAgent({ model })` and set that provider's credentials instead.
-
-## Get started
-
-Install `@mastra/editor` alongside a storage adapter. This example uses `@mastra/libsql`:
-
-**npm**:
-
-```bash
-npm install @mastra/editor @mastra/libsql
-```
-
-**pnpm**:
-
-```bash
-pnpm add @mastra/editor @mastra/libsql
-```
-
-**Yarn**:
-
-```bash
-yarn add @mastra/editor @mastra/libsql
-```
-
-**Bun**:
-
-```bash
-bun add @mastra/editor @mastra/libsql
-```
-
-The example below defines a storage adapter and registers a builder agent, plus enables the editor as explained in the prerequisites:
-
-```typescript
-import { Mastra } from '@mastra/core/mastra'
-import { MastraEditor } from '@mastra/editor'
-import { createBuilderAgent } from '@mastra/editor/ee'
-import { LibSQLStore } from '@mastra/libsql'
-
-export const mastra = new Mastra({
-  storage: new LibSQLStore({ id: 'mastra-storage', url: 'file:./mastra.db' }),
-  agents: { builderAgent: createBuilderAgent() },
-  editor: new MastraEditor({
-    builder: {
-      enabled: true,
-      configuration: {
-        agent: {
-          memory: { observationalMemory: true },
-        },
-      },
-    },
-  }),
-})
-```
-
-Start Mastra's development server:
-
-```bash
-npx mastra dev
-```
-
-For Agent Builder development, you can also use `mastra factory dev`, which uses the same dev runtime and flags as `mastra dev` and writes to the same `.mastra/output` directory. Both commands share a dev lock and can't run simultaneously in the same project. See the [CLI reference](https://mastra.ai/reference/cli/mastra) for details.
-
-The Agent Builder is mounted at `http://localhost:4111/agent-builder`.
-
-## Disabling the Builder
-
-Set `enabled: false` to keep the config in place but turn the surface off:
-
-```typescript
-new MastraEditor({
-  builder: {
-    enabled: false,
-  },
-})
-```
-
-Omitting the `builder` field has the same effect.
-
-## Next steps
-
-- [Configuration](https://mastra.ai/docs/agent-builder/configuration): Toggle Builder surfaces and pin defaults for new agents.
-- [Access control](https://mastra.ai/docs/agent-builder/access-control): Gate the Builder with authentication and role-based access control.
-- [Deploying](https://mastra.ai/docs/agent-builder/deploying): Replace local development primitives with production-ready storage, filesystems, and sandboxes.
-- 📹 [Mastra Agent Builder workshop](https://www.youtube.com/watch?v=p2p_wb-rUPg\&t=666s)

package/.docs/docs/agent-builder/skill-registries.md

@@ -1,31 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Skill registries
-
-> **Note:** The Agent Builder is part of the Mastra Enterprise Edition. Production deployments require a valid EE license. [Contact sales](https://mastra.ai/contact) for more information.
-
-Registries let the Agent Builder browse and install community skills directly from the UI. All registries are opt-in. When no registry is enabled, the Builder hides registry browse UI entirely.
-
-## Quickstart
-
-Enable the [skills.sh](https://skills.sh) registry:
-
-```typescript
-import { MastraEditor } from '@mastra/editor'
-
-new MastraEditor({
-  builder: {
-    enabled: true,
-    registries: {
-      skillsSh: { enabled: true },
-    },
-  },
-})
-```
-
-The Builder library tab now exposes a **Browse** view backed by skills.sh. End users can preview a skill, then install it into an agent. See the [AgentBuilderOptions reference](https://mastra.ai/reference/editor/agent-builder/agent-builder-options) for the full `registries` schema.
-
-## Related
-
-- [Configuration](https://mastra.ai/docs/agent-builder/configuration): Wire registries alongside the rest of the Builder config.
-- [AgentBuilderOptions reference](https://mastra.ai/reference/editor/agent-builder/agent-builder-options): Every field on `builder`.