@mastra/mcp-docs-server 1.2.13-alpha.0 → 1.2.13-alpha.11

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`.

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

@@ -1,62 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Workspace
-
-> **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.
-
-A [workspace](https://mastra.ai/docs/workspace/overview) gives agents filesystem access, command execution, and skill loading. The Agent Builder pins a default workspace onto every new agent through `builder.configuration.agent.workspace`. End users can still override the workspace per agent through the Builder UI.
-
-## Quickstart
-
-Pin an inline workspace snapshot as the Builder default:
-
-```typescript
-import { Mastra } from '@mastra/core'
-import { MastraEditor } from '@mastra/editor'
-
-export const mastra = new Mastra({
-  editor: new MastraEditor({
-    builder: {
-      enabled: true,
-      configuration: {
-        agent: {
-          workspace: {
-            type: 'inline',
-            config: {
-              name: 'project-workspace',
-              filesystem: {
-                provider: 'local',
-                config: { basePath: './workspace' },
-              },
-            },
-          },
-        },
-      },
-    },
-  }),
-})
-```
-
-The Builder derives a deterministic id from the inline config and persists the snapshot, so identical inline configs are deduplicated across agents.
-
-## Workspace references
-
-`configuration.agent.workspace` accepts a `StorageWorkspaceRef`:
-
-- **`{ type: 'inline', config }`**: Embeds a serialized workspace snapshot directly on the agent. Useful for per-agent, ad-hoc configurations.
-- **`{ type: 'id', workspaceId }`**: References a workspace already registered on the `Mastra` instance via `new Mastra({ workspace })` or `mastra.addWorkspace(...)`. Use this for shared, named workspaces.
-
-See the [StorageWorkspaceRef reference](https://mastra.ai/reference/editor/storage-workspace-ref) for both variants.
-
-## Filesystem and sandbox
-
-A workspace combines a `filesystem` (file tools) and an optional `sandbox` (command execution). For local development, point both at the same directory so files written through the filesystem are immediately visible to commands in the sandbox.
-
-For cloud deployments, swap `LocalFilesystem` / `LocalSandbox` for managed providers (e.g., S3, E2B). See [Deploying](https://mastra.ai/docs/agent-builder/deploying) for the cloud-swap pattern.
-
-## Related
-
-- [Workspace overview](https://mastra.ai/docs/workspace/overview): The underlying workspace model.
-- [Filesystem](https://mastra.ai/docs/workspace/filesystem) and [Sandbox](https://mastra.ai/docs/workspace/sandbox): The building blocks.
-- [BuilderAgentDefaults reference](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults): The full `workspace` field schema.
-- [Configuration](https://mastra.ai/docs/agent-builder/configuration): Wire `workspace` alongside the rest of the Builder config.

package/.docs/docs/editor/prompts.md

@@ -1,140 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Prompts
-
-Prompt blocks are reusable instruction templates that you compose into an agent's system prompt. Each block can contain plain text, template variables, and display conditions.
-
-Non-technical team members can edit and test prompt content before publishing changes. Every edit is versioned, so you can compare prompt variations and roll back. The history also records what changed over time.
-
-You can create and manage prompt blocks through the Studio UI or programmatically through the server API, then reference them across multiple agents.
-
-## Quickstart
-
-1. Go to the **Prompts** tab in Studio.
-2. Select **Create prompt** and enter a name and your instruction text.
-3. Save the prompt block and publish it.
-4. Open an agent's **Instructions** section and select **Add block**.
-5. Pick the saved prompt block from the block picker dialog.
-
-The block is added as a reference in the agent's instruction list. Changes to the original prompt block update every agent that references it.
-
-## Block types
-
-An agent's instructions are made up of an ordered list of blocks. Each block is one of three types:
-
-| Type                   | Description                                                                                                                        |
-| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| Inline text            | Free-form text written directly in the agent's instruction list. Lives only on that agent.                                         |
-| Prompt block           | A standalone block with its own content, stored in the agent snapshot. You can save an inline block as a prompt block to reuse it. |
-| Prompt block reference | A pointer to a saved prompt block. The content is resolved at runtime from the referenced block.                                   |
-
-To turn an inline block into a reusable prompt block, open the block's menu and select **Save as prompt block**. To reference an existing prompt block, select **Add block** and pick one from the dialog.
-
-## Template variables
-
-Prompt blocks support `{{variable}}` syntax for runtime content. Variables are resolved at runtime from the agent's variables and request context.
-
-```text
-You are helping {{userName}} with their {{task || 'request'}}.
-```
-
-| Syntax                        | Behavior                                                                                    |
-| ----------------------------- | ------------------------------------------------------------------------------------------- |
-| `{{variableName}}`            | Replaced with the variable value. Left as-is if not found.                                  |
-| `{{nested.path.value}}`       | Resolves dot-notation paths in the context object.                                          |
-| `{{variable \|\| 'default'}}` | Uses the fallback value when the variable is missing. Single or double quotes are accepted. |
-
-Variables are passed through the agent's `variables` configuration or through [request context](https://mastra.ai/docs/server/request-context).
-
-## Display conditions
-
-Each block can have a **display condition**. A rule group that controls whether the block is included in the final prompt. Conditions are evaluated at runtime against the agent's variables and request context.
-
-A rule group uses `AND` or `OR` logic with one or more conditions. Each condition checks a context field against a value using an operator:
-
-| Operator                                       | Description                           |
-| ---------------------------------------------- | ------------------------------------- |
-| `equals` / `not_equals`                        | Exact match comparison.               |
-| `contains` / `not_contains`                    | String inclusion or array membership. |
-| `greater_than` / `less_than`                   | Numeric comparison.                   |
-| `greater_than_or_equal` / `less_than_or_equal` | Numeric comparison with equality.     |
-| `in` / `not_in`                                | Checks if a value is in an array.     |
-| `exists` / `not_exists`                        | Checks if the field is present.       |
-
-Rule groups can be nested, so you can combine `AND` and `OR` conditions for complex logic.
-
-In the Studio, open a block's **Display conditions** panel to set up rules visually. You can also configure conditions programmatically through the API. Blocks without conditions are always included.
-
-## Programmatic control
-
-Prompt blocks can be managed from code through [`mastra.getEditor().prompt`](https://mastra.ai/reference/editor/mastra-editor). This is useful for seeding a set of starter prompts or syncing blocks between environments, or alternatively generating prompt variants from a script.
-
-Create a new prompt block with `editor.prompt.create()`:
-
-```typescript
-import { mastra } from '../mastra'
-
-const editor = mastra.getEditor()!
-
-await editor.prompt.create({
-  id: 'brand-voice',
-  name: 'Brand voice',
-  description: 'Acme Inc. tone and style guidelines',
-  content:
-    'You write in a friendly, concise tone. Always address the user as {{userName || "there"}}.',
-})
-```
-
-Update an existing block with `editor.prompt.update()`. Each update creates a new draft version:
-
-```typescript
-import { mastra } from '../mastra'
-
-const editor = mastra.getEditor()!
-
-await editor.prompt.update({
-  id: 'brand-voice',
-  content: 'You write in a friendly, concise tone. Always greet the user by name when available.',
-})
-```
-
-Use `editor.prompt.list()` to paginate through stored blocks or `editor.prompt.getById()` to fetch a specific block. To preview an agent's full instructions with a set of prompt blocks applied, call `editor.prompt.preview()` with the draft content.
-
-The same operations are available over HTTP through the Mastra server:
-
-| Method   | Path                                         | Description                      |
-| -------- | -------------------------------------------- | -------------------------------- |
-| `GET`    | `/stored/prompt-blocks`                      | List all stored prompt blocks.   |
-| `POST`   | `/stored/prompt-blocks`                      | Create a stored prompt block.    |
-| `GET`    | `/stored/prompt-blocks/:storedPromptBlockId` | Get a stored prompt block by ID. |
-| `PATCH`  | `/stored/prompt-blocks/:storedPromptBlockId` | Update a stored prompt block.    |
-| `DELETE` | `/stored/prompt-blocks/:storedPromptBlockId` | Delete a stored prompt block.    |
-
-Once a prompt block is created, reference it from an agent's `instructions` field as a `prompt_block_ref`:
-
-```typescript
-import { mastra } from '../mastra'
-
-const editor = mastra.getEditor()!
-
-await editor.agent.update({
-  id: 'support-agent',
-  instructions: [
-    { type: 'prompt_block_ref', id: 'brand-voice' },
-    { type: 'text', content: 'Answer only questions about Acme products.' },
-  ],
-})
-```
-
-See the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for the full `editor.prompt` API.
-
-## Versioning
-
-Prompt blocks follow the same [versioning lifecycle](https://mastra.ai/docs/editor/overview) as agents. Each prompt block has a draft that you can edit and publish as a versioned snapshot. As a result, prompt content can be versioned and rolled back independently from the agent that uses it.
-
-When an agent references a prompt block, the resolved content comes from the block's active published version by default. During editing, draft content is used for previews. This separation makes it safe for non-technical team members to experiment with prompt wording. The published version stays stable until they explicitly activate a new one.
-
-## Related
-
-- [Editor overview](https://mastra.ai/docs/editor/overview): Setup and versioning.
-- [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor): Full configuration options for the editor.

package/.docs/docs/editor/tools.md

@@ -1,148 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Tools
-
-The editor gives you three ways to add tools to agents:
-
-- **Code tools**: Tools already registered in your Mastra instance.
-- **Integration providers**: Third-party tool platforms like Composio and Arcade.
-- **MCP clients**: Tools from MCP servers, configured as reusable client definitions.
-
-You can manage all three sources through the Studio UI or programmatically through the server API. Non-technical team members can browse tool catalogs and add tools to agents, plus test different tool combinations without code changes. Tool configurations are versioned alongside the rest of the agent, so you can roll back tool changes and compare versions, plus experiment safely.
-
-## Description overrides
-
-Every tool, regardless of source, can have its description overridden at the agent level. This changes the description the agent sees during tool selection without modifying the original tool definition.
-
-This is useful when you want to:
-
-- Tailor a generic tool's purpose for a specific agent's context.
-- Add instructions about when or how to use a tool.
-- Clarify ambiguous tool descriptions.
-
-In the Studio, select a tool in the agent's tool list and edit the **Description** field. The override applies only to that agent.
-
-## Display conditions
-
-Each tool in an agent can have display conditions, rule groups that control whether the tool is available at runtime. This uses the same rule system as [prompt blocks](https://mastra.ai/docs/editor/prompts).
-
-When a request comes in, the editor evaluates each tool's rules against the current context (agent variables and request context). Tools whose conditions aren't met are excluded from that run.
-
-Use display conditions to:
-
-- Restrict expensive tools to specific users or roles.
-- Enable tools based on feature flags or environment variables.
-- Conditionally include tools based on the conversation context.
-
-Tools without display conditions are always available.
-
-## Studio
-
-Go to the **Agents** tab in Studio and select an agent to edit. Select the **Editor** tab. Scroll to the **Tools** section.
-
-Here you are able to add tools and configure MCP clients.
-
-Once you've made the changes, be sure to save the agent configuration.
-
-## Integration providers
-
-Integration providers connect external tool platforms to the editor. Once registered, you can browse available tools in the Studio and add them to any agent.
-
-### Composio
-
-[Composio](https://composio.dev) gives access to hundreds of integration tools organized into toolkits (GitHub, Slack, Gmail, and others).
-
-1. Get a **project** API key (the `x-api-key` type) from your [Composio dashboard](https://dashboard.composio.dev).
-
-2. Register the provider in your Editor configuration:
-
-   ```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!,
-         }),
-       },
-     }),
-   })
-   ```
-
-   Composio tool slugs use a format like `GITHUB_CREATE_ISSUE`. By default, tool calls use the connection pinned by the agent's author. To route calls to each end user's own account instead, see [connection scope](https://mastra.ai/docs/agent-builder/integrations) in the Agent Builder docs.
-
-### Arcade
-
-[Arcade](https://arcade.dev) provides a curated catalog of tools with built-in authentication handling.
-
-1. Get an API key from your Arcade dashboard.
-
-2. Register the provider in your Editor configuration:
-
-   ```typescript
-   import { Mastra } from '@mastra/core'
-   import { MastraEditor } from '@mastra/editor'
-   import { ArcadeToolProvider } from '@mastra/editor/arcade'
-
-   export const mastra = new Mastra({
-     agents: {/* your agents */},
-     editor: new MastraEditor({
-       toolProviders: {
-         arcade: new ArcadeToolProvider({
-           apiKey: process.env.ARCADE_API_KEY!,
-         }),
-       },
-     }),
-   })
-   ```
-
-   Arcade tools use a `Toolkit.ToolName` format (for example, `Github.GetRepository`). The provider pre-seeds common toolkits to reduce API calls during browsing.
-
-## MCP clients
-
-The editor lets you create stored MCP client configurations that connect to MCP servers. Once created, you can reference these clients in any agent to give it access to the server's tools.
-
-### Transport types
-
-Stored MCP clients support two transport types:
-
-| Transport | Description                                                                                                       |
-| --------- | ----------------------------------------------------------------------------------------------------------------- |
-| **stdio** | Launches a local process and communicates over standard I/O. Specify the `command` and optional `args` and `env`. |
-| **HTTP**  | Connects to a remote MCP server over HTTP. Specify the server `url` and optional `headers`.                       |
-
-### Tool filtering
-
-You can filter MCP tools at two levels:
-
-1. **Client level**: On the MCP client itself, specify which tools from the server to include or exclude. This applies to every agent that references the client.
-2. **Agent level**: On the agent's MCP client reference, further limit which tools are available. This lets you use the same MCP client in multiple agents while exposing different tool subsets.
-
-### Tool namespacing
-
-Tools from MCP servers are namespaced as `serverName_toolName` to avoid conflicts. For example, a `search` tool from the `docs` server becomes `docs_search`.
-
-### Conditional activation
-
-MCP client references in an agent can have display conditions, like [prompt blocks](https://mastra.ai/docs/editor/prompts). This lets you conditionally include MCP tools based on request context or agent variables.
-
-## How tools are merged
-
-When an agent runs, tools from all sources are merged in this order:
-
-1. Code tools
-2. Integration tools
-3. MCP tools
-
-If a tool ID exists in multiple sources, later sources take precedence. Description overrides set at the agent level always take priority over the original tool description. See the [ToolProvider reference](https://mastra.ai/reference/editor/tool-provider) for the full provider API.
-
-## Related
-
-- [Editor overview](https://mastra.ai/docs/editor/overview): Setup and versioning.
-- [Prompts](https://mastra.ai/docs/editor/prompts): Display conditions reference for prompt blocks.
-- [ToolProvider reference](https://mastra.ai/reference/editor/tool-provider): Composio and Arcade API details.
-- [MCP overview](https://mastra.ai/docs/mcp/overview): General MCP documentation.