@mastra/mcp-docs-server 0.0.0-studio-deploy-20260404184540 → 0.0.0-studio-cli-20260504022012

package/.docs/docs/deployment/mastra-server.md

@@ -116,7 +116,7 @@ NODE_OPTIONS="--max-old-space-size=4096" mastra build
 
 ## Related
 
-- [Server Overview](https://mastra.ai/docs/server/mastra-server) - Configure server behavior, middleware, and authentication
-- [Server Adapters](https://mastra.ai/docs/server/server-adapters) - Use Express or Hono instead of `mastra build`
-- [Custom API Routes](https://mastra.ai/docs/server/custom-api-routes) - Add custom HTTP endpoints
-- [Configuration Reference](https://mastra.ai/reference/configuration) - Full configuration options
+- [Server Overview](https://mastra.ai/docs/server/mastra-server): Configure server behavior, middleware, and authentication
+- [Server Adapters](https://mastra.ai/docs/server/server-adapters): Use Express or Hono instead of `mastra build`
+- [Custom API Routes](https://mastra.ai/docs/server/custom-api-routes): Add custom HTTP endpoints
+- [Configuration Reference](https://mastra.ai/reference/configuration): Full configuration options

package/.docs/docs/deployment/monorepo.md

@@ -131,6 +131,6 @@ If you see type errors from uncompiled workspace packages, either:
 
 ## Related
 
-- [Deploy a Mastra Server](https://mastra.ai/docs/deployment/mastra-server) - Core build and deployment guide
-- [Configuration Reference](https://mastra.ai/reference/configuration) - `bundler.transpilePackages` and other options
-- [CLI Reference](https://mastra.ai/reference/cli/mastra) - Build command flags
+- [Deploy a Mastra Server](https://mastra.ai/docs/deployment/mastra-server): Core build and deployment guide
+- [Configuration Reference](https://mastra.ai/reference/configuration): `bundler.transpilePackages` and other options
+- [CLI Reference](https://mastra.ai/reference/cli/mastra): Build command flags

package/.docs/docs/deployment/overview.md

@@ -1,6 +1,6 @@
 # Deployment overview
 
-Mastra applications can be deployed to any Node.js-compatible environment. You can deploy a Mastra server, integrate with an existing web framework, deploy to cloud providers, or use Mastra Cloud for managed hosting.
+Mastra applications can be deployed to any Node.js-compatible environment. You can deploy a Mastra server, integrate with an existing web framework, deploy to cloud providers, or use [Mastra platform](https://mastra.ai/docs/mastra-platform/overview) for Studio and server deployment.
 
 ## Runtime support
 
@@ -13,7 +13,7 @@ Mastra can run against any of these runtime environments:
 
 ## Deployment options
 
-### Mastra Server
+### Mastra server
 
 Mastra provides a [server](https://mastra.ai/docs/server/mastra-server) powered by Hono that can be deployed independently. Use the `mastra build` command to build your application and deploy the output to your preferred VM, container, or PaaS platform.
 
@@ -25,6 +25,15 @@ Deploy a Mastra server as part of a monorepo setup, following the same approach
 
 Read about [monorepo deployment](https://mastra.ai/docs/deployment/monorepo).
 
+### Mastra platform
+
+The [Mastra platform](https://mastra.ai/docs/mastra-platform/overview) provides two products for deploying and managing AI applications built with the Mastra framework:
+
+- **Studio**: A hosted visual environment for testing agents, running workflows, and inspecting traces
+- **Server**: A production deployment target that runs your Mastra application as an API server
+
+Learn more in the [Studio deployment guide](https://mastra.ai/docs/studio/deployment) and [Server deployment guide](https://mastra.ai/guides/deployment/mastra-platform).
+
 ### Cloud Providers
 
 Mastra applications can be deployed to cloud providers and serverless platforms. Mastra includes optional built-in deployers for Vercel, Netlify, and Cloudflare to automate the build and deployment process.
@@ -49,12 +58,6 @@ Use these guides when adding Mastra to an existing Next.js or Astro application.
 - [With Astro on Vercel](https://mastra.ai/docs/deployment/web-framework)
 - [With Astro on Netlify](https://mastra.ai/docs/deployment/web-framework)
 
-### Mastra Cloud
-
-We're building Mastra Cloud to be the easiest place to deploy and observe your Mastra agents. It's currently in beta.
-
-Learn more in the [Mastra Cloud docs](https://mastra.ai/docs/mastra-cloud/overview).
-
 ## Workflow runners
 
 Mastra workflows run using the built-in execution engine by default. For production workloads requiring managed infrastructure, workflows can also be deployed to specialized platforms like [Inngest](https://www.inngest.com) that provide step memoization, automatic retries, and real-time monitoring.

package/.docs/docs/editor/overview.md

@@ -0,0 +1,290 @@
+# Editor overview
+
+The editor is a CMS-style system that separates agent configuration from code. Subject-matter experts, prompt engineers, and product teams can iterate on agents directly while developers keep the codebase stable.
+
+The editor manages two types of resources alongside agents:
+
+- [**Prompts**](https://mastra.ai/docs/editor/prompts): Reusable, versioned instruction templates with template variables and display conditions.
+- [**Tools**](https://mastra.ai/docs/editor/tools): Add tools from integration providers, MCP servers, and override tool descriptions at runtime.
+
+## When to use the editor
+
+Use the editor when you want to:
+
+- **Let non-developers iterate**: Give subject-matter experts and prompt engineers a way to tune agent behavior without touching code or waiting for deploys.
+- **Version everything**: Every save creates a snapshot so you can compare changes, roll back instantly, and audit what changed and when.
+- **Run experiments**: Route different users or requests to different agent versions for A/B testing, canary rollouts, or prompt experimentation.
+- **Target specific versions**: Pin a version per request, per user, or per environment so production stays stable while new versions are tested.
+- **Manage tools at runtime**: Add integration tools from Composio or Arcade, or connect MCP servers, without updating code.
+- **Override code agents**: Change the instructions, tools, or variables of a code-defined agent while keeping the original code as the baseline.
+
+For building agents entirely in code, see the [Agents overview](https://mastra.ai/docs/agents/overview).
+
+## Quickstart
+
+Add `@mastra/editor` to your project:
+
+**npm**:
+
+```bash
+npm install @mastra/editor
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/editor
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/editor
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/editor
+```
+
+Pass a `MastraEditor` instance to your Mastra configuration with your existing agents:
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { MastraEditor } from '@mastra/editor'
+
+export const mastra = new Mastra({
+  agents: {
+    /* your existing agents */
+  },
+  editor: new MastraEditor(),
+})
+```
+
+Once registered, you can manage agents through [Studio](https://mastra.ai/docs/studio/overview) or programmatically through the server API and Client SDK.
+
+> **Note:** See the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for all configuration options.
+
+## Studio
+
+Go to the **Agents** tab in Studio and select an agent to edit. Select the **Editor** tab. You'll be taken to the editor interface, where you can modify the agent's instructions, tools, and variables.
+
+Modify the system prompt and save a new draft version. Afterwards, publish the draft to make it the active version.
+
+## Programmatic control
+
+Everything you can do in Studio is also available programmatically through [`mastra.getEditor()`](https://mastra.ai/reference/core/getEditor). This is useful for scripting bulk updates, seeding stored configurations from code, or building automation that tunes agents based on evaluation results.
+
+Call `mastra.getEditor()` from anywhere you have access to the `Mastra` instance. It returns the `MastraEditor` instance you registered, with namespaces for each resource type:
+
+```typescript
+import { mastra } from '../mastra'
+
+const editor = mastra.getEditor()
+if (!editor) throw new Error('Editor is not registered on Mastra')
+
+// Create a stored agent override for an existing code-defined agent
+await editor.agent.create({
+  id: 'support-agent',
+  instructions: 'You are a friendly support agent for Acme Inc.',
+  tools: {
+    search_kb: { description: 'Search the Acme knowledge base' },
+  },
+})
+```
+
+Use `editor.agent.update()` to change an existing stored configuration. Every update creates a new draft version automatically:
+
+```typescript
+import { mastra } from '../mastra'
+
+const editor = mastra.getEditor()!
+
+await editor.agent.update({
+  id: 'support-agent',
+  instructions:
+    "You are a friendly support agent for Acme Inc. Always respond in the user's language.",
+})
+```
+
+The `editor.agent` namespace also exposes `getById`, `list`, `listResolved`, and `delete`. The `editor.prompt` namespace exposes the same CRUD methods for prompt blocks. See [Prompts](https://mastra.ai/docs/editor/prompts) for examples.
+
+### Server endpoints
+
+The same operations are available over HTTP through the Mastra server. Use these when you want to manage stored agents from a separate service or from a non-TypeScript client:
+
+| Method   | Path                            | Description               |
+| -------- | ------------------------------- | ------------------------- |
+| `GET`    | `/stored/agents`                | List all stored agents.   |
+| `POST`   | `/stored/agents`                | Create a stored agent.    |
+| `GET`    | `/stored/agents/:storedAgentId` | Get a stored agent by ID. |
+| `PATCH`  | `/stored/agents/:storedAgentId` | Update a stored agent.    |
+| `DELETE` | `/stored/agents/:storedAgentId` | Delete a stored agent.    |
+
+The Client SDK wraps these endpoints with `client.listStoredAgents()`, `client.createStoredAgent()`, and `client.getStoredAgent()`. Version management endpoints live under `/stored/agents/:storedAgentId/versions`, see [version management](https://mastra.ai/reference/client-js/agents) for the full list.
+
+### Automated experimentation
+
+Because stored agents are just data, you can build automation loops that tune agents without human involvement. A common pattern is to pair the editor API with [datasets](https://mastra.ai/docs/evals/datasets/overview) and [experiments](https://mastra.ai/docs/evals/datasets/running-experiments):
+
+- Run a dataset through the current version of an agent and score the results.
+- Have another agent read the failing cases and propose changes to the instructions or tools.
+- Apply those changes with `editor.agent.update()` to create a new draft.
+- Re-run the experiment against the draft and compare scores to the baseline.
+- Promote the draft to the published version when the scores improve.
+
+This turns agent tuning into a closed feedback loop. One agent owns the production configuration, another agent iterates on it, and every change is versioned so you can roll back if a round of automated edits makes things worse. Combine this with [version targeting](#version-targeting-and-experimentation) to keep production traffic on the published version while the draft is being tested.
+
+> **Note:** See the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for the full namespace API.
+
+## What can be overridden
+
+When you edit a code-defined agent through the editor, only specific fields can be changed:
+
+| Field        | Description                                                                                                   |
+| ------------ | ------------------------------------------------------------------------------------------------------------- |
+| Instructions | Replace or extend the agent's system prompt using [prompt blocks](https://mastra.ai/docs/editor/prompts).     |
+| Tools        | Add tools from the tool registry, integration providers, or MCP clients. Code-defined tools remain available. |
+
+Fields like the agent's `id`, `name`, and `model` come from your code and can't be changed through the editor for code-defined agents. The variables are also read-only.
+
+## Versioning
+
+Every time you save changes to an agent or prompt block, a new version snapshot is created. Versions give you a full history of your agent's configuration. You can roll back to any previous state, compare what changed between two snapshots, and target specific versions per request for A/B testing or gradual rollouts.
+
+Version management is available through the server Studio, REST API, the Client SDK, and the React SDK. See the [Client SDK agents reference](https://mastra.ai/reference/client-js/agents) for endpoints, SDK methods, and code examples.
+
+### Version lifecycle
+
+Each version has one of three statuses:
+
+| Status    | Description                                                                         |
+| --------- | ----------------------------------------------------------------------------------- |
+| Draft     | The latest working copy. Every save creates a new draft version.                    |
+| Published | The active version used in production. Only one version can be published at a time. |
+| Archived  | A previous version that is no longer active. You can restore any archived version.  |
+
+The typical flow is: Edit the draft, test it, then activate it to make it the published version. The previously published version becomes archived so you can restore it if needed. You can do this through Studio or programmatically through the API.
+
+This lifecycle makes it safe to experiment. Non-technical team members can iterate on a draft without affecting production traffic, then publish when ready. If something goes wrong, restoring a previous version is a single API call.
+
+### Version targeting and experimentation
+
+Because every version has a unique ID, you can route different requests to different agent configurations. This opens up several patterns:
+
+- **A/B testing**: Split traffic between two published versions and compare performance metrics.
+- **Canary rollouts**: Send a small percentage of requests to a new version before promoting it.
+- **Per-user targeting**: Pin specific users or accounts to a version while others use the default.
+- **Environment separation**: Use the draft version in staging and the published version in production.
+
+Pass a `versionId` or `status` when calling the agent through the Client SDK, server query parameters, or React SDK `requestContext`, and the correct version is loaded automatically.
+
+### Version selection
+
+By default, [`mastra.getAgentById()`](https://mastra.ai/reference/core/getAgentById) loads the published (active) version of the stored override. You can request a specific version, which is useful for testing a draft before publishing, running A/B experiments, or pinning a user to a known-good configuration:
+
+```typescript
+// Load the published version (default)
+const agent = mastra.getAgentById('support-agent')
+
+// Load the latest draft
+const agent = mastra.getAgentById('support-agent', {
+  status: 'draft',
+})
+
+// Load a specific version
+const agent = mastra.getAgentById('support-agent', {
+  versionId: 'abc-123',
+})
+```
+
+When calling the agent through the Mastra server, pass version parameters as query strings:
+
+```bash
+# Published version (default)
+curl http://localhost:4111/agents/support-agent
+
+# Latest draft
+curl http://localhost:4111/agents/support-agent?status=draft
+
+# Specific version
+curl http://localhost:4111/agents/support-agent?versionId=abc-123
+```
+
+See the [Client SDK agents reference](https://mastra.ai/reference/client-js/agents) for API methods.
+
+### Sub-agent versioning
+
+When a [supervisor agent](https://mastra.ai/docs/agents/supervisor-agents) delegates to sub-agents, version overrides determine which stored version of each sub-agent to use instead of the code-defined default. This lets you iterate on sub-agent prompts and tools through the editor without redeploying the supervisor.
+
+Set version overrides at three levels, with later levels taking priority:
+
+1. **Mastra instance config** — global defaults that apply to every `generate()` and `stream()` call.
+2. **Per-invocation options** — overrides passed directly to `generate()` or `stream()`.
+3. **Server request body** — overrides sent in the `versions` field of an API request.
+
+Resolution order: **per-invocation > request body > Mastra instance defaults > code-defined agent**.
+
+#### Mastra instance config
+
+Set global defaults when creating the `Mastra` instance. Every supervisor call inherits these overrides:
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { MastraEditor } from '@mastra/editor'
+
+export const mastra = new Mastra({
+  agents: { supervisor, researchAgent, writerAgent },
+  editor: new MastraEditor(),
+  versions: {
+    agents: {
+      'research-agent': { status: 'published' },
+      'writer-agent': { versionId: 'abc-123' },
+    },
+  },
+})
+```
+
+#### Per-invocation overrides
+
+Override versions for a single call to `generate()` or `stream()`. These take priority over Mastra instance defaults:
+
+```typescript
+const result = await supervisor.generate('Research and write an article about AI safety', {
+  versions: {
+    agents: {
+      'research-agent': { versionId: 'draft-456' },
+    },
+  },
+})
+```
+
+#### Server request body
+
+When calling agents through the Mastra server, pass version overrides in the request body:
+
+```bash
+curl -X POST http://localhost:4111/agents/supervisor/generate \
+  -H "Content-Type: application/json" \
+  -d '{
+    "messages": [{ "role": "user", "content": "Research AI safety" }],
+    "versions": {
+      "agents": {
+        "research-agent": { "versionId": "draft-456" }
+      }
+    }
+  }'
+```
+
+#### How propagation works
+
+Version overrides propagate automatically through sub-agent delegation via `requestContext`. When a supervisor delegates to a sub-agent, the framework checks if a version override exists for that sub-agent's ID. If one is found, it resolves the stored version from the editor and uses it instead of the code-defined default.
+
+If version resolution fails (for example, when the editor is not configured or the version ID doesn't exist), the framework logs a warning and falls back to the code-defined agent.
+
+## Next steps
+
+- Set up [prompts](https://mastra.ai/docs/editor/prompts) to build reusable instruction templates.
+- Add [tools](https://mastra.ai/docs/editor/tools) from integration providers and MCP servers.
+- Explore the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for all configuration options.

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

@@ -0,0 +1,134 @@
+# 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 prompt content, test different phrasings, and publish changes. Every edit is versioned, so you can compare prompt variations, roll back, and track 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 appears 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 dynamic 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, syncing blocks between environments, or 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.' },
+  ],
+})
+```
+
+> **Note:** 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. This means 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

@@ -0,0 +1,152 @@
+# 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, add tools to agents, and test different tool combinations without code changes. Tool configurations are versioned alongside the rest of the agent, so you can roll back tool changes, compare versions, and 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 are not 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 an API key from your Composio dashboard.
+
+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`. Tool calls are scoped to a `userId` passed through request context for per-user authentication.
+
+### 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 tool called `search` from a server named `docs` becomes `docs_search`.
+
+### Conditional activation
+
+MCP client references in an agent can have display conditions, just 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.
+
+> **Note:** 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.