@mastra/mcp-docs-server 1.2.19-alpha.4 → 1.2.19

package/.docs/docs/observability/metrics/overview.md

@@ -2,30 +2,38 @@
 
 # Metrics
 
-Mastra automatically emits performance and usage metrics from traced execution. There's no manual instrumentation needed. Metrics are derived from spans as they complete.
+Mastra automatically derives metrics from spans as traced operations complete. No separate metric instrumentation is required.
 
-These categories of metrics are emitted automatically:
+Mastra emits:
 
-- **Duration metrics**: Execution time for agents, workflows, tools, model calls, and processors.
-- **Token usage metrics**: Input and output token counts broken down by type (text, cache, audio, image, reasoning).
-- **Cost estimation**: Estimated cost per model call based on an embedded pricing registry.
+- **Duration metrics** for agent runs, workflows, tools, model calls, and processors
+- **Token usage metrics** for model input and output, including detailed token categories when the provider reports them
+- **Cost estimates** calculated from token usage, provider, model, and an embedded pricing registry
 
-> **Note:** Metrics require an analytics-capable store for observability. Most relational databases (LibSQL, MSSQL) aren't supported for metrics. In-memory storage resets on restart.
->
-> For local development, use [DuckDB](https://duckdb.org/) through `@mastra/duckdb`. For production, use [ClickHouse](https://clickhouse.com/) through `@mastra/clickhouse`. `PostgresStoreVNext` with the observability domain enabled also supports metrics, but always provide a time range to avoid full partition scans.
->
-> Google Cloud Spanner supports metrics, but it's not recommended for heavy metrics workloads. The Spanner adapter disables metrics by default because metrics are write-heavy and scan-heavy. Set `disableMetrics: false` only for light workloads, or route metrics to an OLAP store.
+Metrics retain trace correlation context, so you can investigate a change in a chart by finding the related span. See the [Automatic metrics reference](https://mastra.ai/reference/observability/metrics/automatic-metrics) for metric names, labels, and cost fields.
 
 ## When to use metrics
 
 - Monitor latency across agents, tools, workflows, and model calls
-- Track token consumption and cost trends over time
-- Identify error-heavy agents or tools by comparing success and error rates
-- Compare performance before and after prompt, model, or code changes
+- Track token consumption and estimated cost over time
+- Compare success and error rates across agents or tools
+- Measure the effect of prompt, model, or code changes
 
-## Get started
+## Storage support
 
-Install the required packages:
+Metrics require an analytics-capable observability store:
+
+- **DuckDB** through `@mastra/duckdb` is recommended for local development.
+- **ClickHouse** through `@mastra/clickhouse` is recommended for high-volume production workloads.
+- **PostgresStoreVNext** supports metrics when its observability domain is enabled.
+- **In-memory storage** supports metrics, but its data is lost when the process restarts.
+- **Google Cloud Spanner** disables metrics by default. Set `disableMetrics: false` only for light workloads, or route metrics to a dedicated OLAP store.
+
+Other storage adapters, including LibSQL, MSSQL, and MongoDB, can store other observability signals but don't implement metric storage and queries.
+
+## Set up local metrics
+
+Install the observability, application storage, and DuckDB packages:
 
 **npm**:
 
@@ -51,7 +59,7 @@ yarn add @mastra/observability @mastra/libsql @mastra/duckdb
 bun add @mastra/observability @mastra/libsql @mastra/duckdb
 ```
 
-Then configure observability with a composite store that routes the observability domain to DuckDB:
+Configure a composite store that routes the observability domain to DuckDB:
 
 ```ts
 import { Mastra } from '@mastra/core/mastra'
@@ -83,37 +91,16 @@ export const mastra = new Mastra({
 })
 ```
 
-## Studio
-
-The Studio metrics dashboard visualizes all automatic metrics with KPI cards, detailed breakdowns, token usage timelines, and configurable time ranges. See [Studio observability](https://mastra.ai/docs/studio/observability) for a full walkthrough.
-
-## What Mastra measures
-
-Mastra emits three categories of metrics automatically:
+`MastraStorageExporter` persists metrics to the configured observability store and makes them available to Studio. Use `MastraPlatformExporter` instead, or alongside it, to send metrics to Mastra Platform.
 
-- **Duration**: Execution time in milliseconds for agents, workflows, tools, model calls, and processors.
-- **Token usage**: Input and output token counts, broken down by type (text, cache, audio, image, reasoning).
-- **Cost estimation**: Estimated cost per model call, based on an embedded pricing registry.
+## View and query metrics
 
-Each metric carries trace correlation context so you can drill from a dashboard spike to the exact span that caused it.
+Use the [Studio observability dashboard](https://mastra.ai/docs/studio/observability) to inspect KPI cards, breakdowns, and time-series charts. For custom dashboards and analysis, use the observability store, `@mastra/client-js`, HTTP endpoints, or CLI described in the [Metric queries reference](https://mastra.ai/reference/observability/metrics/queries).
 
-For the full list of metric names, labels, and cost fields, see the [Automatic metrics reference](https://mastra.ai/reference/observability/metrics/automatic-metrics).
+In production, always include a timestamp range in metric queries. Time bounds limit the data scanned and allow partitioned backends to skip unrelated partitions or chunks.
 
-## How automatic metrics work
+## Related
 
-Mastra auto-instruments agent runs, workflow steps, tool calls, and model generations as spans. When a span ends, the observability layer extracts metrics from it:
-
-1. **Duration**: Calculated from the span's start and end timestamps.
-2. **Token usage**: Extracted from the `usage` attribute on model generation spans.
-3. **Cost estimation**: Runs each token metric through an embedded pricing registry that matches by provider and model name.
-
-Before storage, all metric labels pass through a cardinality filter that blocks known high-cardinality values (such as trace IDs and UUIDs) to keep storage efficient. Metrics are then batched by an internal event buffer and flushed to storage by the `MastraStorageExporter`.
-
-## Next steps
-
-- [Automatic metrics reference](https://mastra.ai/reference/observability/metrics/automatic-metrics)
-- [Querying metrics](https://mastra.ai/docs/observability/metrics/querying)
-- [Tracing overview](https://mastra.ai/docs/observability/tracing/overview)
-- [Studio observability](https://mastra.ai/docs/studio/observability)
 - [Observability overview](https://mastra.ai/docs/observability/overview)
-- [MastraStorageExporter reference](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage)
+- [Tracing overview](https://mastra.ai/docs/observability/tracing/overview)
+- [MastraStorageExporter](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage)

package/.docs/docs/sandbox/overview.md

@@ -73,6 +73,48 @@ Set `{ enabled: false }` on one tool to remove it, or set the top-level `enabled
 
 See the [sandbox tools reference](https://mastra.ai/reference/workspace/workspace-class) for all generated tools and the [tool configuration reference](https://mastra.ai/reference/workspace/workspace-class) for approvals, output limits, and hooks.
 
+### Computer-use tools
+
+Sandboxes that run a desktop environment can expose screenshot, mouse, and keyboard control. The workspace registers these tools when a statically configured sandbox supports the computer capability:
+
+| Tool                       | Does                                                                             |
+| -------------------------- | -------------------------------------------------------------------------------- |
+| `computer_screenshot`      | Captures the desktop as a PNG image and returns it to the model as native media. |
+| `computer_click`           | Presses and releases the left mouse button at pixel coordinates.                 |
+| `computer_double_click`    | Presses the left mouse button twice at pixel coordinates.                        |
+| `computer_right_click`     | Presses and releases the right mouse button at pixel coordinates.                |
+| `computer_move_mouse`      | Moves the cursor to pixel coordinates without pressing a button.                 |
+| `computer_drag`            | Presses, drags, and releases between two points.                                 |
+| `computer_type`            | Types text into the focused element.                                             |
+| `computer_press_key`       | Presses a key or key combination, such as `Enter` or `ctrl+s`.                   |
+| `computer_scroll`          | Scrolls up or down.                                                              |
+| `computer_get_screen_info` | Gets the screen dimensions and cursor position.                                  |
+| `computer_wait`            | Waits for the interface to settle.                                               |
+
+[`DaytonaSandbox`](https://mastra.ai/integrations/sandboxes/daytona) and [`E2BDesktopSandbox`](https://mastra.ai/integrations/sandboxes/e2b-desktop) support this capability. Other sandbox backends don't register the computer tools. Resolver-backed sandboxes don't register them because the workspace can't inspect the resolved sandbox's capabilities when it creates the tool list.
+
+Action tools take a screenshot after each action by default. Configure the screenshot behavior for each tool:
+
+```typescript
+import { Workspace, WORKSPACE_TOOLS } from '@mastra/core/workspace'
+import { E2BDesktopSandbox } from '@mastra/e2b-desktop'
+
+const workspace = new Workspace({
+  sandbox: new E2BDesktopSandbox(),
+  tools: {
+    [WORKSPACE_TOOLS.COMPUTER.CLICK]: {
+      screenshotAfterAction: true,
+      screenshotDelayMs: 1000,
+    },
+    [WORKSPACE_TOOLS.COMPUTER.TYPE]: {
+      requireApproval: true,
+    },
+  },
+})
+```
+
+Computer tools accept the same per-tool `enabled` and `requireApproval` configuration as other workspace tools.
+
 Authored runtime functions, including tools and workflow steps, can get the live sandbox from their execution context. Use it to execute commands, install dependencies, process files, or spawn a long-running process.
 
 ```typescript
@@ -136,6 +178,7 @@ Use a remote or container sandbox when commands need a stronger boundary from th
 - [Daytona](https://mastra.ai/integrations/sandboxes/daytona)
 - [Docker](https://mastra.ai/integrations/sandboxes/docker)
 - [E2B](https://mastra.ai/integrations/sandboxes/e2b)
+- [E2B Desktop](https://mastra.ai/integrations/sandboxes/e2b-desktop)
 - [Mastra](https://mastra.ai/reference/workspace/platform-sandbox)
 - [Modal](https://mastra.ai/integrations/sandboxes/modal)
 - [Railway](https://mastra.ai/integrations/sandboxes/railway)

package/.docs/docs/server/middleware.md

@@ -6,6 +6,10 @@ Mastra servers can execute custom middleware functions before or after an API ro
 
 A middleware receives the [Hono](https://hono.dev) `Context` (`c`) and a `next` function. If it returns a `Response` the request is short-circuited. Calling `next()` continues processing the next middleware or route handler.
 
+> **Note:** Middleware handlers use Hono's signature, so they run on Hono-based serving paths: `mastra dev` and `mastra build`, the [Hono adapter](https://mastra.ai/reference/server/hono-adapter), and adapters built on it such as `@mastra/next` and `@mastra/tanstack-start`. Adapters for other frameworks (Express, Fastify, Koa) can't run Hono handlers and log a warning at startup when middleware is configured. Register middleware through the framework's own API there instead.
+>
+> User middleware never runs on routes declared public with `requiresAuth: false`, so it can't block endpoints the framework needs to keep reachable, such as the Studio sign-in routes.
+
 ```typescript
 import { Mastra } from '@mastra/core'
 
@@ -54,6 +58,32 @@ registerApiRoute('/my-custom-route', {
 
 ## Common examples
 
+### Block built-in route groups
+
+Mastra doesn't provide a configuration option to remove or allowlist built-in routes. On Hono-based serving paths, you can make selected route groups unavailable by returning a response without calling `next()`:
+
+```typescript
+import { Mastra } from '@mastra/core'
+
+const notFound = async () => new Response('Not Found', { status: 404 })
+
+export const mastra = new Mastra({
+  server: {
+    middleware: [
+      { path: '/api/memory/*', handler: notFound },
+      { path: '/api/logs/*', handler: notFound },
+      { path: '/api/observability/*', handler: notFound },
+    ],
+  },
+})
+```
+
+Each wildcard pattern blocks both the route group itself and its nested routes. For example, `/api/logs/*` blocks `/api/logs` and `/api/logs/transports`. Other route groups remain available.
+
+Generated servers pass `server.apiPrefix` to the Hono adapter's [`prefix` constructor option](https://mastra.ai/reference/server/hono-adapter), which prefixes built-in routes. Middleware paths are registered unchanged, so they must explicitly include the configured prefix. For example, with `apiPrefix: '/api/v2'`, use `/api/v2/memory/*`. Custom API routes must live outside the configured API prefix and aren't blocked by these patterns.
+
+This approach can't block routes declared public with `requiresAuth: false`, because Mastra skips user middleware for those routes. With a non-Hono server adapter, register equivalent middleware through the server framework instead.
+
 ### Using `RequestContext`
 
 You can populate `RequestContext` in a runtime server middleware by extracting information from the request. In this example, the `temperature-unit` is set based on the Cloudflare `CF-IPCountry` header to ensure responses match the user's locale.

package/.docs/docs/server/server-adapters.md

@@ -20,6 +20,7 @@ Server adapters let you run Mastra with your own HTTP server instead of the Hono
 
 Mastra currently provides these official server adapters:
 
+- [@mastra/elysia](https://mastra.ai/reference/server/elysia-adapter)
 - [@mastra/express](https://mastra.ai/reference/server/express-adapter)
 - [@mastra/hono](https://mastra.ai/reference/server/hono-adapter)
 - [@mastra/fastify](https://mastra.ai/reference/server/fastify-adapter)
@@ -32,8 +33,58 @@ You can build your own adapter, read [custom adapters](https://mastra.ai/docs/se
 
 Install the adapter for the framework of your choice.
 
+**Elysia**:
+
+**npm**:
+
+```bash
+npm install @mastra/elysia@latest elysia
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/elysia@latest elysia
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/elysia@latest elysia
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/elysia@latest elysia
+```
+
 **Express**:
 
+```bash
+npm install @mastra/elysia@latest elysia
+```
+
+**Hono**:
+
+```bash
+pnpm add @mastra/elysia@latest elysia
+```
+
+**Fastify**:
+
+```bash
+yarn add @mastra/elysia@latest elysia
+```
+
+**Koa**:
+
+```bash
+bun add @mastra/elysia@latest elysia
+```
+
+**NestJS**:
+
 **npm**:
 
 ```bash
@@ -58,31 +109,31 @@ yarn add @mastra/express@latest
 bun add @mastra/express@latest
 ```
 
-**Hono**:
+**Tab 7**:
 
 ```bash
 npm install @mastra/express@latest
 ```
 
-**Fastify**:
+**Tab 8**:
 
 ```bash
 pnpm add @mastra/express@latest
 ```
 
-**Koa**:
+**Tab 9**:
 
 ```bash
 yarn add @mastra/express@latest
 ```
 
-**NestJS**:
+**Tab 10**:
 
 ```bash
 bun add @mastra/express@latest
 ```
 
-**Tab 6**:
+**Tab 11**:
 
 **npm**:
 
@@ -108,31 +159,31 @@ yarn add @mastra/hono@latest
 bun add @mastra/hono@latest
 ```
 
-**Tab 7**:
+**Tab 12**:
 
 ```bash
 npm install @mastra/hono@latest
 ```
 
-**Tab 8**:
+**Tab 13**:
 
 ```bash
 pnpm add @mastra/hono@latest
 ```
 
-**Tab 9**:
+**Tab 14**:
 
 ```bash
 yarn add @mastra/hono@latest
 ```
 
-**Tab 10**:
+**Tab 15**:
 
 ```bash
 bun add @mastra/hono@latest
 ```
 
-**Tab 11**:
+**Tab 16**:
 
 **npm**:
 
@@ -158,31 +209,31 @@ yarn add @mastra/fastify@latest
 bun add @mastra/fastify@latest
 ```
 
-**Tab 12**:
+**Tab 17**:
 
 ```bash
 npm install @mastra/fastify@latest
 ```
 
-**Tab 13**:
+**Tab 18**:
 
 ```bash
 pnpm add @mastra/fastify@latest
 ```
 
-**Tab 14**:
+**Tab 19**:
 
 ```bash
 yarn add @mastra/fastify@latest
 ```
 
-**Tab 15**:
+**Tab 20**:
 
 ```bash
 bun add @mastra/fastify@latest
 ```
 
-**Tab 16**:
+**Tab 21**:
 
 **npm**:
 
@@ -208,31 +259,31 @@ yarn add @mastra/koa@latest
 bun add @mastra/koa@latest
 ```
 
-**Tab 17**:
+**Tab 22**:
 
 ```bash
 npm install @mastra/koa@latest
 ```
 
-**Tab 18**:
+**Tab 23**:
 
 ```bash
 pnpm add @mastra/koa@latest
 ```
 
-**Tab 19**:
+**Tab 24**:
 
 ```bash
 yarn add @mastra/koa@latest
 ```
 
-**Tab 20**:
+**Tab 25**:
 
 ```bash
 bun add @mastra/koa@latest
 ```
 
-**Tab 21**:
+**Tab 26**:
 
 **npm**:
 
@@ -258,25 +309,25 @@ yarn add @mastra/nestjs@latest
 bun add @mastra/nestjs@latest
 ```
 
-**Tab 22**:
+**Tab 27**:
 
 ```bash
 npm install @mastra/nestjs@latest
 ```
 
-**Tab 23**:
+**Tab 28**:
 
 ```bash
 pnpm add @mastra/nestjs@latest
 ```
 
-**Tab 24**:
+**Tab 29**:
 
 ```bash
 yarn add @mastra/nestjs@latest
 ```
 
-**Tab 25**:
+**Tab 30**:
 
 ```bash
 bun add @mastra/nestjs@latest
@@ -286,6 +337,25 @@ bun add @mastra/nestjs@latest
 
 Initialize your app as usual, then create a `MastraServer` by passing in the `app` and your main `mastra` instance from `src/mastra/index.ts`. Calling `init()` automatically registers Mastra middleware and all available endpoints. You can continue adding your own routes as normal, either before or after `init()`, and they’ll run alongside Mastra’s endpoints.
 
+**Elysia**:
+
+```typescript
+import { Elysia } from 'elysia'
+import { MastraServer } from '@mastra/elysia'
+import { mastra } from './mastra'
+
+const app = new Elysia()
+const server = new MastraServer({ app, mastra })
+
+await server.init()
+
+app.listen(4111)
+
+console.log('Server running on http://localhost:4111')
+```
+
+> **Note:** See the [Elysia Adapter](https://mastra.ai/reference/server/elysia-adapter) documentation for full configuration options.
+
 **Express**:
 
 ```typescript
@@ -424,11 +494,12 @@ See the [NestJS Adapter](https://mastra.ai/reference/server/nestjs-adapter) docu
 
 ## Initialization flow
 
-Calling `init()` runs three steps in order. Understanding this flow helps when you need to insert your own middleware at specific points.
+Calling `init()` runs four steps in order. Understanding this flow helps when you need to insert your own middleware at specific points.
 
 1. `registerContextMiddleware()`: Attaches the Mastra instance, request context, tools, and abort signal to every request. This makes Mastra available to all subsequent middleware and route handlers.
 2. `registerAuthMiddleware()`: Runs the adapter auth hook during initialization. Official adapters enforce auth inline when Mastra registers built-in routes and `registerApiRoute()` routes, so raw framework routes should use the adapter's exported `createAuthMiddleware()` helper when they need Mastra auth.
-3. `registerRoutes()`: Registers all Mastra API routes for agents, workflows, and other features. Also registers MCP routes if MCP servers are configured.
+3. `registerUserMiddleware()`: Registers [middleware](https://mastra.ai/docs/server/middleware) from the `server.middleware` config and `mastra.setServerMiddleware()`. Middleware handlers use Hono's signature, so Hono-based adapters (`@mastra/hono` and the adapters built on it) mount them; other adapters log a warning instead of silently ignoring the config.
+4. `registerRoutes()`: Registers all Mastra API routes for agents, workflows, and other features. Also registers MCP routes if MCP servers are configured.
 
 ### Manual initialization
 
@@ -445,6 +516,9 @@ server.registerContextMiddleware();
 // Middleware that needs Mastra context
 app.use(customMiddleware);
 
+// Registers `server.middleware` and `setServerMiddleware()` middleware
+server.registerUserMiddleware();
+
 await server.registerRoutes();
 
 // Routes after Mastra
@@ -462,7 +536,7 @@ You can add your own routes to the app alongside Mastra's routes.
 - When you want Mastra-managed auth and route metadata such as `requiresAuth`, prefer `registerApiRoute()`.
 - When you mount routes directly on the framework app, use the adapter's exported `createAuthMiddleware()` helper if those routes need Mastra auth.
 
-Visit "Adding custom routes" for [Express](https://mastra.ai/reference/server/express-adapter) and [Hono](https://mastra.ai/reference/server/hono-adapter) for more information.
+Visit "Adding custom routes" for [Elysia](https://mastra.ai/reference/server/elysia-adapter), [Express](https://mastra.ai/reference/server/express-adapter), and [Hono](https://mastra.ai/reference/server/hono-adapter) for more information.
 
 ## Route prefixes
 
@@ -566,11 +640,12 @@ When using server adapters, configuration comes from two places: the Mastra `ser
 
 The adapter reads these settings from `mastra.getServer()`:
 
-| Option          | Description                                                                                                                                     |
-| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| `auth`          | Authentication config, used by `registerAuthMiddleware()`.                                                                                      |
-| `bodySizeLimit` | Default body size limit in bytes. Can be overridden per-adapter via `bodyLimitOptions`.                                                         |
-| `onError`       | Custom error handler called when an unhandled error occurs in a route handler. See [server.onError](https://mastra.ai/reference/configuration). |
+| Option          | Description                                                                                                                                                                                                       |
+| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `auth`          | Authentication config, used by `registerAuthMiddleware()`.                                                                                                                                                        |
+| `bodySizeLimit` | Default body size limit in bytes. Can be overridden per-adapter via `bodyLimitOptions`.                                                                                                                           |
+| `onError`       | Custom error handler called when an unhandled error occurs in a route handler. See [server.onError](https://mastra.ai/reference/configuration).                                                                   |
+| `middleware`    | User [middleware](https://mastra.ai/docs/server/middleware), registered by `registerUserMiddleware()`. Hono-based adapters run it; Express, Fastify, and Koa log a warning because Hono handlers can't run there. |
 
 ### Adapter constructor only
 
@@ -595,7 +670,6 @@ These `server` config options are only used by `mastra build` and have no effect
 | `cors`         | `mastra build` adds CORS middleware     |
 | `timeout`      | `mastra build`                          |
 | `apiRoutes`    | `registerApiRoute()` for `mastra build` |
-| `middleware`   | Middleware config for `mastra build`    |
 
 When using adapters, configure these features directly with your framework. For example, add CORS middleware using Hono's or Express's built-in CORS packages, and set the port when calling your framework's listen function.
 
@@ -603,7 +677,7 @@ When using adapters, configure these features directly with your framework. For
 
 Server adapters register MCP (Model Context Protocol) routes during `registerRoutes()` when MCP servers are configured in your Mastra instance. MCP allows external tools and services to connect to your Mastra server and interact with your agents.
 
-The adapter registers routes for both HTTP and SSE (Server-Sent Events) transports, enabling different client connection patterns.
+Most adapters register routes for both HTTP and SSE (Server-Sent Events) transports, enabling different client connection patterns. The Elysia adapter currently supports MCP HTTP transport only.
 
 ### Serverless mode
 
@@ -639,6 +713,7 @@ See [MCP](https://mastra.ai/docs/connections/mcp) for configuration details and
 
 ## Related
 
+- [Elysia Adapter](https://mastra.ai/reference/server/elysia-adapter) - Elysia-specific setup
 - [Hono Adapter](https://mastra.ai/reference/server/hono-adapter) - Hono-specific setup
 - [Express Adapter](https://mastra.ai/reference/server/express-adapter) - Express-specific setup
 - [NestJS Adapter](https://mastra.ai/reference/server/nestjs-adapter) - NestJS-specific setup

package/.docs/docs/storage.md

@@ -197,6 +197,7 @@ Each provider page includes installation instructions, configuration parameters,
 - [Convex](https://mastra.ai/integrations/databases/convex)
 - [DuckDB](https://mastra.ai/integrations/databases/duckdb)
 - [DynamoDB](https://mastra.ai/integrations/databases/dynamodb)
+- [Elasticsearch](https://mastra.ai/integrations/databases/elasticsearch)
 - [Google Cloud Spanner](https://mastra.ai/integrations/databases/spanner)
 - [LanceDB](https://mastra.ai/integrations/databases/lancedb)
 - [libSQL](https://mastra.ai/integrations/databases/libsql)
@@ -207,6 +208,7 @@ Each provider page includes installation instructions, configuration parameters,
 - [OracleDB](https://mastra.ai/integrations/databases/oracledb)
 - [PostgreSQL](https://mastra.ai/integrations/databases/postgresql)
 - [Redis](https://mastra.ai/integrations/databases/redis)
+- [Valkey](https://mastra.ai/integrations/databases/valkey)
 - [Upstash](https://mastra.ai/integrations/databases/upstash)
 
 ## Next steps

package/.docs/docs/subagents.md

@@ -159,12 +159,12 @@ const stream = await parentAgent.stream('Research AI trends', {
 
 The `context` object includes:
 
-| Property      | Description                              |
-| ------------- | ---------------------------------------- |
-| `primitiveId` | The ID of the subagent that ran          |
-| `result`      | The subagent's response                  |
-| `error`       | Error if the delegation failed           |
-| `bail()`      | Function to stop the parent agent's loop |
+| Property      | Description                                                                                   |
+| ------------- | --------------------------------------------------------------------------------------------- |
+| `primitiveId` | The ID of the subagent that ran                                                               |
+| `result`      | The subagent's response, including `text`, `usage`, `finishReason`, and `subAgentToolResults` |
+| `error`       | Error if the delegation failed                                                                |
+| `bail()`      | Function to stop the parent agent's loop                                                      |
 
 ### Hook errors