@mastra/mcp-docs-server 1.2.7-alpha.4 → 1.2.7-alpha.6

package/.docs/reference/file-based-agents/tools.md

@@ -0,0 +1,63 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Tools
+
+A file-based agent discovers tools from `.ts` and `.js` files directly under its `tools/` directory. Each discovered file is imported at build time, the file must default-export a [`createTool()`](https://mastra.ai/reference/tools/create-tool) result, and the filename without its extension becomes the tool key the model can call.
+
+Use this page for the file-based convention. For tool schemas, execution options, output shaping, and approval options, see the [`createTool()` reference](https://mastra.ai/reference/tools/create-tool).
+
+## Quickstart
+
+Place one tool per file under `tools/`. This file is exposed to the agent as `get_weather`.
+
+```typescript
+import { createTool } from '@mastra/core/tools'
+import { z } from 'zod'
+
+export default createTool({
+  id: 'get_weather',
+  description: 'Get the current weather for a city.',
+  inputSchema: z.object({
+    city: z.string(),
+  }),
+  outputSchema: z.object({
+    city: z.string(),
+    tempC: z.number(),
+  }),
+  execute: async ({ context }) => {
+    return { city: context.city, tempC: 21 }
+  },
+})
+```
+
+## Organizing tools
+
+Use one file per tool. Name the file after the action the model should take:
+
+- Use `get_weather.ts`, `search_docs.ts`, or `create_ticket.ts`.
+- Avoid vague names like `helper.ts`, `api.ts`, or `utils.ts`.
+- Co-locate tests next to the tool as `*.test.ts` or `*.spec.ts`; discovery ignores those files.
+- Keep shared helper code outside `tools/` or in files that don't match the discovered extensions under `tools/`.
+
+Because nested directories aren't discovered as tools, group related tools with clear filename prefixes instead of subfolders, such as `calendar_create_event.ts` and `calendar_list_events.ts`.
+
+## Tool options
+
+The file-based convention only controls where the tool lives and how it's registered. The tool API still comes from `createTool()`:
+
+- Use `description` to tell the model when to call the tool.
+- Use `inputSchema` and `outputSchema` for structured inputs and outputs.
+- Use `toModelOutput` when the model should see a different shape than the raw value returned from `execute`.
+- Use `requireApproval` when a tool needs human confirmation before execution.
+
+See the [`createTool()` reference](https://mastra.ai/reference/tools/create-tool) for all options and [tool approval](https://mastra.ai/docs/agent-controller/tool-approvals) for the approval flow.
+
+## Runtime boundary
+
+Tool code runs in your app/server runtime when the agent calls the tool. If a tool needs filesystem or shell isolation, call [workspace](https://mastra.ai/reference/file-based-agents/workspace) or sandbox APIs explicitly.
+
+## Precedence with config
+
+Discovered tools merge with any `tools` in [`config.ts`](https://mastra.ai/reference/file-based-agents/config). On a key collision, `config.tools` wins and a warning is logged.
+
+If `config.tools` is a function, discovered tools are ignored with a warning because function-valued tools can't be statically merged.

package/.docs/reference/file-based-agents/workflows.md

@@ -0,0 +1,52 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Workflows
+
+Mastra discovers project-level workflows from `.ts` and `.js` files under `src/mastra/workflows/`. This convention isn't scoped to one agent: every file with a default export becomes a registered workflow, and the filename becomes the workflow key.
+
+Use this page for the file-based convention. For steps, schemas, control flow, streaming, state, and workflow execution, see [Workflows overview](https://mastra.ai/docs/workflows/overview).
+
+## Quickstart
+
+Create a file under `src/mastra/workflows/`, build the workflow with [`createWorkflow()`](https://mastra.ai/reference/workflows/workflow), and default-export it.
+
+```typescript
+import { createStep, createWorkflow } from '@mastra/core/workflows'
+import { z } from 'zod'
+
+const collectInputs = createStep({
+  id: 'collect-inputs',
+  inputSchema: z.object({ topic: z.string() }),
+  outputSchema: z.object({ topic: z.string(), audience: z.string() }),
+  execute: async ({ inputData }) => ({
+    topic: inputData.topic,
+    audience: 'engineering',
+  }),
+})
+
+const writeSummary = createStep({
+  id: 'write-summary',
+  inputSchema: z.object({ topic: z.string(), audience: z.string() }),
+  outputSchema: z.object({ report: z.string() }),
+  execute: async ({ inputData }) => ({
+    report: `Daily report about ${inputData.topic} for ${inputData.audience}.`,
+  }),
+})
+
+const dailyReport = createWorkflow({
+  id: 'daily-report',
+  inputSchema: z.object({ topic: z.string() }),
+  outputSchema: z.object({ report: z.string() }),
+})
+  .then(collectInputs)
+  .then(writeSummary)
+  .commit()
+
+export default dailyReport
+```
+
+Mastra registers this workflow under the `daily-report` key.
+
+## Precedence with code
+
+File-based workflows merge with workflows registered in [`new Mastra()`](https://mastra.ai/reference/core/mastra-class). On a key collision, the code-registered workflow wins.

package/.docs/reference/file-based-agents/workspace.md

@@ -0,0 +1,74 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Workspace
+
+A [workspace](https://mastra.ai/docs/workspace/overview) gives an agent filesystem access and command execution. File-based agents get a default workspace automatically when discovered through `mastra dev` or `mastra build`, so they can read and write files and run shell commands without extra configuration.
+
+Use this page for the file-based convention. For workspace providers, tools, search, lifecycle, and sandbox details, see [Workspaces](https://mastra.ai/docs/workspace/overview).
+
+## Default workspace
+
+Without `workspace.ts`, a file-based agent gets a default [`Workspace`](https://mastra.ai/reference/workspace/workspace-class) when the build provides a per-agent workspace path. The default workspace uses:
+
+- [`LocalFilesystem`](https://mastra.ai/reference/workspace/local-filesystem) rooted at the agent's bundled workspace directory.
+- [`LocalSandbox`](https://mastra.ai/reference/workspace/local-sandbox) with the same working directory.
+
+This gives the agent file tools and shell tools automatically. The default workspace is per agent; subagents get nested workspace directories under their parent agent's workspace path.
+
+## Quickstart
+
+For the default workspace, don't add a file. Start with an agent directory like this:
+
+```text
+src/mastra/agents/weather/
+├── config.ts
+└── instructions.md
+```
+
+Add `workspace.ts` only when you need to customize the workspace:
+
+```typescript
+import { Workspace, LocalFilesystem, LocalSandbox } from '@mastra/core/workspace'
+
+export default new Workspace({
+  name: 'weather-workspace',
+  filesystem: new LocalFilesystem({ basePath: './data/weather' }),
+  sandbox: new LocalSandbox({ workingDirectory: './data/weather' }),
+})
+```
+
+Visit the [`Workspace` reference](https://mastra.ai/reference/workspace/workspace-class) for the full config.
+
+## When to customize the workspace
+
+Customize the workspace when the default local directory isn't enough. Common reasons include:
+
+- Point file tools at a different filesystem root.
+- Run shell commands in a different sandbox provider.
+- Add workspace search with BM25 or vector search.
+- Share one workspace across multiple agents.
+
+For provider patterns and runtime behavior, see the [workspace overview](https://mastra.ai/docs/workspace/overview), [sandbox guide](https://mastra.ai/docs/workspace/sandbox), and [workspace search](https://mastra.ai/docs/workspace/search).
+
+## Runtime boundary
+
+The workspace filesystem controls what file tools can read and write. The sandbox controls where shell commands run. Application runtime code, including code in [`tools/`](https://mastra.ai/reference/file-based-agents/tools), still runs in your app/server process unless it explicitly calls workspace or sandbox APIs.
+
+## Seed files
+
+Add a `workspace/` directory to ship starting files with the agent. Mastra mirrors files under `workspace/` into the agent's default runtime workspace at build time, so the agent starts with those files on disk.
+
+```text
+src/mastra/agents/weather/
+├── config.ts
+└── workspace/
+    ├── README.md
+    └── data/
+        └── cities.json
+```
+
+The files are copied into the bundled workspace path, where workspace file tools and sandbox commands can read them. Symlinked seed files are skipped during mirroring.
+
+## Precedence with config
+
+`config.workspace` wins over `workspace.ts`; otherwise the default file-based workspace is used. See [`config.ts` precedence](https://mastra.ai/reference/file-based-agents/config) for the full merge table.

package/.docs/reference/index.md

@@ -175,6 +175,19 @@ The Reference section provides documentation of Mastra's API, including paramete
 - [.startExperimentAsync()](https://mastra.ai/reference/datasets/startExperimentAsync)
 - [.update()](https://mastra.ai/reference/datasets/update)
 - [.updateItem()](https://mastra.ai/reference/datasets/updateItem)
+- [config.ts](https://mastra.ai/reference/file-based-agents/config)
+- [Instructions](https://mastra.ai/reference/file-based-agents/instructions)
+- [Memory](https://mastra.ai/reference/file-based-agents/memory)
+- [Observability](https://mastra.ai/reference/file-based-agents/observability)
+- [Processors](https://mastra.ai/reference/file-based-agents/processors)
+- [Server](https://mastra.ai/reference/file-based-agents/server)
+- [Skills](https://mastra.ai/reference/file-based-agents/skills)
+- [Storage](https://mastra.ai/reference/file-based-agents/storage)
+- [Studio](https://mastra.ai/reference/file-based-agents/studio)
+- [Subagents](https://mastra.ai/reference/file-based-agents/subagents)
+- [Tools](https://mastra.ai/reference/file-based-agents/tools)
+- [Workflows](https://mastra.ai/reference/file-based-agents/workflows)
+- [Workspace](https://mastra.ai/reference/file-based-agents/workspace)
 - [API Reference](https://mastra.ai/reference/mastra-platform/api)
 - [Cloned Thread Utilities](https://mastra.ai/reference/memory/clone-utilities)
 - [Memory Class](https://mastra.ai/reference/memory/memory-class)

package/.docs/reference/memory/memory-class.md

@@ -37,7 +37,7 @@ export const agent = new Agent({
 
 **options** (`MemoryConfig`): Memory configuration options.
 
-**options.lastMessages** (`number | false`): Number of most recent messages to include in context. Set to false to disable loading conversation history into context. Use Number.MAX\_SAFE\_INTEGER to retrieve all messages with no limit. To prevent saving new messages, use the readOnly option instead.
+**options.lastMessages** (`number | false`): Number of most recent messages to include in context. Set to false to disable the message history feature entirely (messages are not loaded into context or saved). Use Number.MAX\_SAFE\_INTEGER to retrieve all messages with no limit. To load messages without saving new ones, use the readOnly option.
 
 **options.readOnly** (`boolean`): When true, prevents memory from saving new messages and provides working memory as read-only context (without the updateWorkingMemory tool). Useful for read-only operations like previews, internal routing agents, or sub agents that should reference but not modify memory.
 

package/.docs/reference/memory/serialized-memory-config.md

@@ -38,7 +38,7 @@ new MastraEditor({
 
 **options.readOnly** (`boolean`): Treat memory as read-only — no new messages are stored.
 
-**options.lastMessages** (`number | false`): Number of recent messages to include in context, or false to disable.
+**options.lastMessages** (`number | false`): Number of recent messages to include in context, or false to disable message history entirely (messages are not loaded or saved).
 
 **options.semanticRecall** (`boolean | SemanticRecall`): Semantic recall configuration. See the Memory class reference for the full shape.
 

package/.docs/reference/project-structure.md

@@ -44,7 +44,7 @@ Mastra recommends organizing your code into the following folders:
 
 Mastra has two special folder conventions:
 
-- `src/mastra/agents/<name>`: You can define an agent by file convention instead of constructing it in code. Learn more in the [file-based agents](https://mastra.ai/docs/agents/file-based-agents) guide.
+- `src/mastra/agents/<name>`: You can define an agent by file convention instead of constructing it in code. Learn more in the [File-based Agents](https://mastra.ai/docs/getting-started/file-based-agents) docs.
 - `src/mastra/public`: Contents are copied into the `.build/output` directory during the build process, making them available for serving at runtime.
 
 ### Top-level files

package/.docs/reference/pubsub/lease-provider.md

@@ -130,4 +130,4 @@ When the configured pub/sub backend doesn't implement `LeaseProvider`, the runti
 - [PubSub](https://mastra.ai/reference/pubsub/base): The event delivery contract, separate from leasing
 - [RedisStreamsPubSub](https://mastra.ai/reference/pubsub/redis-streams): The built-in backend that implements `LeaseProvider`
 - [Signals](https://mastra.ai/docs/long-running-agents/signals): The runtime that uses leasing to coordinate thread runs across processes
-- [Channels](https://mastra.ai/docs/agents/channels): Uses leasing to coordinate agent runs in serverless and multi-instance deployments
+- [Channels](https://mastra.ai/docs/capabilities/channels/overview): Uses leasing to coordinate agent runs in serverless and multi-instance deployments

package/.docs/reference/storage/clickhouse.md

@@ -101,6 +101,38 @@ const observabilityStore = new ObservabilityStorageClickhouse({
 
 New projects should use `ObservabilityStorageClickhouseVNext` instead.
 
+### Migrating from legacy to vNext
+
+To migrate historical spans from the legacy `mastra_ai_spans` table to the vNext schema, run:
+
+**npm**:
+
+```bash
+npx mastra migrate
+```
+
+**pnpm**:
+
+```bash
+pnpm dlx mastra migrate
+```
+
+**Yarn**:
+
+```bash
+yarn dlx mastra migrate
+```
+
+**Bun**:
+
+```bash
+bun x mastra migrate
+```
+
+The migration copies span data from `mastra_ai_spans` into `mastra_span_events` in day-sized batches. It handles column mapping, deduplicates legacy rows, and preserves the original table as a backup. After migration, traces appear in Studio through the vNext adapter.
+
+> **Note:** The legacy table is not deleted. Drop it manually after verifying the migration.
+
 ### ClickHouse for every domain
 
 `ClickhouseStoreVNext` backs the `memory`, `workflows`, and `observability` domains with ClickHouse and uses the vNext observability adapter automatically. Use it when you want ClickHouse to back the entire application without wiring a composite store manually.

package/.docs/reference/storage/composite.md

@@ -156,6 +156,32 @@ export const mastra = new Mastra({
 })
 ```
 
+### Disabling a domain
+
+Set a domain to `false` to disable it. A disabled domain doesn't fall back to `default`, so data for that domain isn't persisted:
+
+```typescript
+import { MastraCompositeStore } from '@mastra/core/storage'
+import { PostgresStore } from '@mastra/pg'
+import { Mastra } from '@mastra/core'
+
+const pgStore = new PostgresStore({
+  id: 'pg',
+  connectionString: process.env.DATABASE_URL,
+})
+
+export const mastra = new Mastra({
+  storage: new MastraCompositeStore({
+    id: 'composite',
+    default: pgStore,
+    domains: {
+      // don't persist traces and spans
+      observability: false,
+    },
+  }),
+})
+```
+
 ## Options
 
 **id** (`string`): Unique identifier for this storage instance.
@@ -164,7 +190,7 @@ export const mastra = new Mastra({
 
 **disableInit** (`boolean`): When true, automatic initialization is disabled. You must call init() explicitly.
 
-**domains** (`object`): Individual domain overrides. Each domain can come from a different storage adapter. These take precedence over both editor and default storage.
+**domains** (`object`): Individual domain overrides. Each domain can come from a different storage adapter. These take precedence over both editor and default storage. Set a domain to false to disable it entirely; a disabled domain does not fall back to editor or default.
 
 **domains.memory** (`MemoryStorage`): Storage for threads, messages, and resources.
 

package/.docs/reference/storage/retention.md

@@ -105,6 +105,8 @@ Deletes rows older than their configured `maxAge` across every domain that has a
 
 `prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks — each batch is its own transaction — so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
 
+Pass `options.retention` to replace the configured policies for that call only — for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
+
 Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy — never at `init()` — so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build; subsequent prunes reuse the index.
 
 ```typescript
@@ -116,6 +118,13 @@ const results = await storage.prune({
 for (const r of results) {
   console.log(`${r.domain}.${r.table}: deleted ${r.deleted}, done=${r.done}`)
 }
+
+// One-off pass with different policies (configured retention untouched):
+await storage.prune({
+  retention: {
+    observability: { spans: { maxAge: '1d' } },
+  },
+})
 ```
 
 Returns: `Promise<PruneResult[]>`
@@ -130,6 +139,8 @@ Returns: `Promise<PruneResult[]>`
 
 **signal** (`AbortSignal`): Cooperative cancellation. The batch loop checks it between batches and stops cleanly, returning partial results with done: false.
 
+**retention** (`RetentionConfig`): Replaces the store's configured retention policies for this call only — e.g. to skip a domain or prune more aggressively. The configured retention is unchanged.
+
 ##### PruneResult
 
 Each result describes one table's progress:

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # @mastra/mcp-docs-server
 
+## 1.2.7-alpha.5
+
+### Patch Changes
+
+- Updated dependencies [[`e955965`](https://github.com/mastra-ai/mastra/commit/e955965dce575a903e37cf054d28ea99aa48785e), [`860ef7e`](https://github.com/mastra-ai/mastra/commit/860ef7e77d92b63469cbe5857aa1e626197e43e9), [`17e818c`](https://github.com/mastra-ai/mastra/commit/17e818c51a958ba90641b1a959dc38faf8c034e9), [`4451dfe`](https://github.com/mastra-ai/mastra/commit/4451dfe857428e7abcc0261a507a2e186dae6d47), [`1d39058`](https://github.com/mastra-ai/mastra/commit/1d39058e548efd691799985d5c8af2737f1c3bd2)]:
+  - @mastra/core@1.51.0-alpha.2
+
 ## 1.2.7-alpha.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.2.7-alpha.4",
+  "version": "1.2.7-alpha.6",
   "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
   "type": "module",
   "main": "dist/index.js",
@@ -28,8 +28,8 @@
     "jsdom": "^26.1.0",
     "local-pkg": "^1.1.2",
     "zod": "^4.4.3",
-    "@mastra/core": "1.50.2-alpha.1",
-    "@mastra/mcp": "^1.13.1"
+    "@mastra/mcp": "^1.13.1",
+    "@mastra/core": "1.51.0-alpha.2"
   },
   "devDependencies": {
     "@hono/node-server": "^1.19.11",
@@ -47,7 +47,7 @@
     "vitest": "4.1.9",
     "@internal/lint": "0.0.113",
     "@internal/types-builder": "0.0.88",
-    "@mastra/core": "1.50.2-alpha.1"
+    "@mastra/core": "1.51.0-alpha.2"
   },
   "homepage": "https://mastra.ai",
   "repository": {

package/.docs/docs/agents/channels.md

@@ -1,225 +0,0 @@
-> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
-
-# Channels
-
-**Added in:** `@mastra/core@1.22.0`
-
-Channels connect your agents to messaging platforms like Slack, Discord, and Telegram. When a user sends a message on a platform, the agent receives it, processes it through the normal agent pipeline, and streams the response back to the conversation.
-
-## When to use channels
-
-Use channels when you want your agent to:
-
-- Respond to messages in Slack workspaces, Discord servers, or Telegram chats
-- Handle both direct messages and mentions in group conversations
-
-## Quickstart
-
-Configure channels directly on your agent using adapters from the [Chat SDK](https://chat-sdk.dev/adapters):
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { createSlackAdapter } from '@chat-adapter/slack'
-
-export const supportAgent = new Agent({
-  id: 'support-agent',
-  name: 'Support Agent',
-  instructions: 'You are a helpful support assistant.',
-  model: 'openai/gpt-5.5',
-  channels: {
-    adapters: {
-      slack: createSlackAdapter(),
-    },
-  },
-})
-```
-
-Register the agent in your Mastra instance with storage so channel state persists across restarts:
-
-```typescript
-import { Mastra } from '@mastra/core'
-import { LibSQLStore } from '@mastra/libsql'
-import { supportAgent } from './agents/support-agent'
-
-export const mastra = new Mastra({
-  agents: { supportAgent },
-  storage: new LibSQLStore({
-    url: process.env.DATABASE_URL,
-  }),
-})
-```
-
-Each adapter reads credentials from environment variables by default.
-
-## Platform setup
-
-Each platform requires credentials and event configuration. See the Chat SDK adapter docs for full setup: [Slack](https://chat-sdk.dev/adapters/slack), [Discord](https://chat-sdk.dev/adapters/discord), [Telegram](https://chat-sdk.dev/adapters/telegram).
-
-Mastra generates a webhook route for each platform at:
-
-```text
-/api/agents/{agentId}/channels/{platform}/webhook
-```
-
-For example: `/api/agents/support-agent/channels/slack/webhook`
-
-Point your platform's webhook or interactions URL to this path.
-
-### Local development
-
-Platform webhooks need a public URL to reach your local server. Use a tunnel to expose `localhost:4111`:
-
-```bash
-# ngrok
-ngrok http 4111
-
-# cloudflared
-npx cloudflared tunnel --url http://localhost:4111
-```
-
-Copy the generated URL and use it as the base for your webhook paths (e.g. `https://abc123.ngrok.io/api/agents/support-agent/channels/slack/webhook`).
-
-## Thread context
-
-When a user mentions the agent mid-conversation in a channel thread, the agent may not have prior context. By default, Mastra fetches the last 10 messages from the platform on the first mention.
-
-1. On the **first mention** in a thread, the agent fetches recent messages from the platform.
-2. These messages are prepended to the user's message as conversation context.
-3. After responding, the agent subscribes to the thread and has full history via Mastra's memory.
-4. Subsequent messages in that thread **don't** re-fetch from the platform.
-
-Set `threadContext: { maxMessages: 0 }` to disable this behavior. This only applies to non-DM threads.
-
-Mastra also adds a short system message telling the agent which channel and platform the request came from (DM vs public channel, platform name, bot display name). Set `threadContext: { addSystemMessage: false }` to skip it.
-
-## Tool approval
-
-Tools with `requireApproval: true` render as interactive cards with Approve and Deny buttons:
-
-```typescript
-import { createTool } from '@mastra/core/tools'
-import { z } from 'zod'
-
-const deleteFile = createTool({
-  id: 'delete-file',
-  description: 'Delete a file from the system',
-  inputSchema: z.object({
-    path: z.string().describe('Path to the file to delete'),
-  }),
-  requireApproval: true,
-  execute: async ({ path }) => {
-    await fs.unlink(path)
-    return { deleted: path }
-  },
-})
-```
-
-When the agent calls this tool, users see a card with the tool name, arguments, and Approve/Deny buttons. The tool only executes after approval.
-
-Set `toolDisplay: 'text'` on an adapter to render tool calls as plain text instead of interactive cards. In `'hidden'` mode the agent uses `autoResumeSuspendedTools` to let the LLM decide based on the conversation context, since hidden mode doesn't post approval buttons.
-
-## Multi-user awareness
-
-In group conversations, Mastra automatically prefixes each message with the sender's name and platform ID so the agent can distinguish between speakers:
-
-```text
-[Alice (@U123ABC)]: Can you help me with this?
-[Bob (@U456DEF)]: I have a question too.
-```
-
-## Multimodal content
-
-Models like Gemini can natively process images, video, and audio. Combine `inlineMedia` and `inlineLinks` to let users share rich content with your agent across platforms:
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { createDiscordAdapter } from '@chat-adapter/discord'
-import { google } from '@ai-sdk/google'
-
-export const visionAgent = new Agent({
-  id: 'vision-agent',
-  name: 'Vision Agent',
-  instructions: 'You can see images, watch videos, and listen to audio.',
-  model: google('gemini-3.1-flash-image-preview'),
-  channels: {
-    adapters: {
-      discord: createDiscordAdapter(),
-    },
-    inlineMedia: ['image/*', 'video/*', 'audio/*'],
-    inlineLinks: [
-      // Gemini treats YouTube URLs as native video file parts
-      { match: 'youtube.com', mimeType: 'video/*' },
-      { match: 'youtu.be', mimeType: 'video/*' },
-      'imgur.com', // HEAD-check imgur links; inline as file part if mimeType matches inlineMedia
-    ],
-  },
-})
-```
-
-With this configuration:
-
-- A user uploads a screenshot and the agent describes what it sees
-- A user uploads an `.mp4` clip and the agent summarizes the video
-- A user pastes a YouTube link and the agent watches and discusses the video
-- A user pastes an imgur link and the agent sees the image directly
-
-By default, only images are sent inline (`inlineMedia: ['image/*']`). Unsupported types are described as text summaries so the agent knows about the file without crashing models that reject them.
-
-> **Note:** See [Channels reference](https://mastra.ai/reference/agents/channels) for all `inlineMedia` patterns and [inlineLinks reference](https://mastra.ai/reference/agents/channels) for domain matching, HEAD detection, and forced mime types.
-
-## Serverless deployment
-
-On serverless platforms like Vercel, each request runs in a separate, short-lived instance. Channels need two things to work reliably in that environment: a way to keep the function alive while the agent responds, and a shared pub/sub so instances can coordinate.
-
-### Keep the function alive with `waitUntil`
-
-A channel webhook returns a `200` response right away, then the agent runs in the background to post its reply. On most serverless platforms the function is frozen as soon as it responds, which kills the run before the agent answers. Pass a `waitUntil` function so the platform keeps the instance alive until the run finishes.
-
-On Vercel, pass `waitUntil` from `@vercel/functions`:
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { createSlackAdapter } from '@chat-adapter/slack'
-import { waitUntil } from '@vercel/functions'
-
-export const agent = new Agent({
-  id: 'agent',
-  channels: {
-    adapters: {
-      slack: createSlackAdapter(),
-    },
-    waitUntil,
-  },
-})
-```
-
-Vercel and AWS Lambda require `waitUntil`, since they freeze the function as soon as the response is sent. Cloudflare Workers and Netlify Functions are detected automatically from the request context, so they don't need it. For runtimes where `waitUntil` lives on the request context but isn't detected automatically, use `resolveWaitUntil`. See the [Channels reference](https://mastra.ai/reference/agents/channels) for details.
-
-### Coordinate instances with a shared pub/sub
-
-Channels route messages through the agent's signal pipeline, and each run acquires a lease on its thread so a single run owns the conversation at a time. The default in-memory pub/sub can't cross instance boundaries, so on serverless a follow-up message can land on a different instance than the one running the agent. Without a shared pub/sub, that instance can't reach the active run and starts its own, leaving the original run untouched and the thread processed twice.
-
-Configure a shared pub/sub backed by Redis Streams on the `Mastra` instance so leases and signals coordinate across instances:
-
-```typescript
-import { Mastra } from '@mastra/core'
-import { RedisStreamsPubSub } from '@mastra/redis-streams'
-
-export const mastra = new Mastra({
-  agents: { agent },
-  pubsub: new RedisStreamsPubSub({
-    url: process.env.REDIS_URL,
-    keyPrefix: 'mastra:my-app',
-  }),
-})
-```
-
-Vercel's managed Redis integration and Upstash Redis both work well. For more on when a distributed pub/sub is needed, see the [PubSub guide](https://mastra.ai/docs/server/pubsub) and the [`RedisStreamsPubSub` reference](https://mastra.ai/reference/pubsub/redis-streams).
-
-## Related
-
-- [Guide: Building a Slack assistant](https://mastra.ai/guides/guide/slack-assistant)
-- [Agent overview](https://mastra.ai/docs/agents/overview)
-- [Tool approval](https://mastra.ai/docs/agents/agent-approval)
-- [Channels reference](https://mastra.ai/reference/agents/channels)
-- [Chat SDK adapters](https://chat-sdk.dev/adapters)