@mastra/mcp-docs-server 1.2.19-alpha.15 → 1.2.19-alpha.18

package/.docs/docs/channels.md

@@ -82,7 +82,7 @@ For example, a Slack adapter on an agent with the `your-agent` ID uses:
 /api/agents/your-agent/channels/slack/webhook
 ```
 
-Point the platform's webhook, event, or interactions URL to this path. Follow the guide for your platform or the [Chat SDK docs](https://chat-sdk.dev/adapters).
+Point the platform's webhook, event, or interactions URL to this path. Follow the guide for your platform or the [Chat SDK docs](https://chat-sdk.dev/adapters). The webhook acknowledges the request before the agent finishes responding. See [Error handling and delivery](#error-handling-and-delivery) for what happens when verification or a handler fails.
 
 During local development, platform webhooks need a public URL to reach your local server. Use a tunnel like [cloudflared](https://github.com/cloudflare/cloudflared) or [ngrok](https://ngrok.com/) to expose your server, `localhost:4111` by default:
 
@@ -215,6 +215,32 @@ Add only JSON-serializable, non-sensitive values. Signal metadata may be stored
 
 Use `requestContext` for run-scoped configuration, such as credentials for a message that starts a run. Use `signalMetadata` for context that must stay attached to one message, including messages delivered to an active run.
 
+## Error handling and delivery
+
+A channel webhook acknowledges the platform before the agent finishes, so a `200` response means "received", not "answered". Before that acknowledgment, the adapter rejects bad requests synchronously (`401` for failed verification, `400` for an unparseable body, `503` for transient state failures) and the platform redelivers on non-`2xx` responses per its own policy. After the `200`, the platform never retries and Mastra owns errors. The default handler catches agent-run failures and posts an error message to the thread (customize it with `formatError`, which defaults to `❌ Error: {message}`). A custom handler that throws is only logged by Chat SDK, so nothing is posted or retried. Catch failures in custom handlers yourself:
+
+```typescript
+channels: {
+  adapters: {
+    slack: createSlackAdapter(),
+  },
+  handlers: {
+    onDirectMessage: async (thread, message, defaultHandler, ctx) => {
+      try {
+        ctx.signalMetadata.ticketId = await lookupTicket(message)
+      } catch (error) {
+        ctx.mastra?.getLogger().error('Ticket lookup failed', { error })
+        await thread.post('Something went wrong looking up your ticket. Try again in a moment.')
+        return
+      }
+      await defaultHandler(thread, message)
+    },
+  },
+},
+```
+
+Platform retries also mean the same event can arrive more than once. Adapters deduplicate redelivered events using channel state, so configure [storage](https://mastra.ai/docs/storage) to keep deduplication reliable across restarts. Deduplication is best effort, so keep side effects in custom handlers idempotent so a duplicate that slips through doesn't repeat work like creating a ticket.
+
 ## Multimodal content
 
 Models like Gemini can process images, video, and audio natively. Combine `inlineMedia` and `inlineLinks` to let users share rich content with your agent across platforms:

package/.docs/docs/mastra-platform/api.md

@@ -105,6 +105,60 @@ The root URL for the endpoints below is: `/v1/gateway`
 | GET    | `/projects/:id/memory/threads/:threadId/observations/history` | Observation history (dashboard)             |
 | GET    | `/models`                                                     | List available models                       |
 
+## Observability feedback query API
+
+The hosted feedback query API lists and analyzes feedback exported to Mastra Platform Observability. Because the API is unversioned, backwards compatibility isn't guaranteed. Rate limits, retention, and ingestion-to-query freshness aren't published contracts.
+
+Use the root URL for your environment's data-residency region:
+
+| Region         | Root URL                                               |
+| -------------- | ------------------------------------------------------ |
+| United States  | `https://observability.mastra.ai/api/observability`    |
+| European Union | `https://observability.eu.mastra.ai/api/observability` |
+
+Telemetry stays in its residency region. Querying the other region returns no records for the environment. See [Observability co-location](https://mastra.ai/docs/mastra-platform/regions) for the environment-to-region mapping.
+
+### Authentication and project scope
+
+Every request requires a platform access token. Create one in [Mastra Platform](https://projects.mastra.ai), or use the token written to `.env` during Platform setup.
+
+Include `X-Mastra-Project-Id` to limit results to one project. If you omit it, the query covers feedback in every project available to the token's organization.
+
+```bash
+curl -sS "https://observability.mastra.ai/api/observability/feedback?page=0&perPage=20&feedbackType=rating" \
+  -H "Authorization: Bearer $MASTRA_PLATFORM_ACCESS_TOKEN" \
+  -H "X-Mastra-Project-Id: $MASTRA_PROJECT_ID" | jq
+```
+
+Use an organization-scoped Platform access token. Gateway inference keys such as `mk_*` keys aren't accepted. Queries remain constrained to the token's organization even when you supply a project ID.
+
+### Endpoints
+
+| Method | Endpoint                | Description                  |
+| ------ | ----------------------- | ---------------------------- |
+| GET    | `/feedback`             | List feedback records        |
+| POST   | `/feedback/aggregate`   | Return one aggregate value   |
+| POST   | `/feedback/breakdown`   | Group feedback by dimensions |
+| POST   | `/feedback/timeseries`  | Bucket feedback by interval  |
+| POST   | `/feedback/percentiles` | Return percentile series     |
+
+The list endpoint accepts page-mode parameters such as `page`, `perPage`, `field`, and `direction`, plus feedback filters as query parameters. It also supports delta polling with `mode=delta`, `after`, and `limit`. Responses contain a `feedback` array and page or delta metadata.
+
+Analytics endpoints accept the same JSON request shapes and return types as the [feedback reference](https://mastra.ai/reference/observability/feedback). Analytics operate only on numeric feedback values.
+
+```bash
+curl -sS "https://observability.mastra.ai/api/observability/feedback/aggregate" \
+  -X POST \
+  -H "Authorization: Bearer $MASTRA_PLATFORM_ACCESS_TOKEN" \
+  -H "X-Mastra-Project-Id: $MASTRA_PROJECT_ID" \
+  -H "Content-Type: application/json" \
+  --data '{"feedbackType":"rating","feedbackSource":"user","aggregation":"avg"}' | jq
+```
+
+The API returns `401` for invalid credentials, `403` for organization authorization failures, and `400` for malformed query arguments or JSON bodies.
+
+Hosted observability doesn't provide a feedback creation route. Export feedback from the application as described in [Export feedback to Mastra Platform](https://mastra.ai/docs/observability/feedback).
+
 ## Gateway proxy endpoints
 
 Visit the [Gateway documentation](https://gateway.mastra.ai/docs) for more details.

package/.docs/docs/mastra-platform/observability.md

@@ -130,7 +130,7 @@ See [Mastra storage exporter](https://mastra.ai/docs/observability/integrations/
 
 ## View observability data
 
-Open your project in [Mastra Platform](https://projects.mastra.ai) to inspect exported traces, logs, metrics, scores, and feedback. A Studio or Server deployment isn't required.
+Open your project in [Mastra Platform](https://projects.mastra.ai) to inspect exported traces, logs, metrics, and scores. A Studio or Server deployment isn't required. Query exported feedback through the hosted feedback API described below.
 
 Use a consistent `serviceName` to filter data from a specific application or deployment.
 
@@ -164,6 +164,8 @@ bun x mastra api trace list
 
 The CLI can infer platform credentials from your project environment. See the [`mastra api` CLI reference](https://mastra.ai/reference/cli/mastra) for available commands, filtering, pagination, credential resolution, and `curl` examples.
 
+You can query exported feedback over HTTP. See the [observability feedback query API](https://mastra.ai/docs/mastra-platform/api) for its current status, regional endpoints, authentication, and project scoping.
+
 ## Next steps
 
 - 📹 [Mastra observability and Studio workshop](https://www.youtube.com/watch?v=dKO_a3RPra0)

package/.docs/docs/memory/semantic-recall.md

@@ -350,6 +350,25 @@ const agent = new Agent({
 })
 ```
 
+FastEmbed also exposes the multilingual E5 model for non-English content. E5 is asymmetric, so it's exposed as two models: `multilingualE5LargePassage` for text you index and `multilingualE5LargeQuery` for search text.
+
+```ts
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+import { fastembed } from '@mastra/fastembed'
+
+const agent = new Agent({
+  id: 'agent',
+  memory: new Memory({
+    embedder: fastembed.multilingualE5LargePassage,
+  }),
+})
+```
+
+Memory uses a single embedder for both storing and recalling messages, so pick one of the two models and use it consistently. Use the paired `multilingualE5LargeQuery` model only where you control both sides of the pipeline, such as a RAG workflow that indexes with the passage model and searches with the query model.
+
+Multilingual E5 produces 1024-dimensional vectors. Your vector index must be created with matching dimensions, and E5 vectors can't be mixed with vectors from another embedder in the same index.
+
 ## PostgreSQL index optimization
 
 When using PostgreSQL as your vector store, you can optimize semantic recall performance by configuring the vector index. This is particularly important for large-scale deployments with thousands of messages.

package/.docs/docs/observability/feedback.md

@@ -33,6 +33,10 @@ await mastra.observability.addFeedback({
 })
 ```
 
+When you pass only `traceId` and `spanId`, `addFeedback()` rehydrates the target from configured observability storage before emitting the feedback event. Configure [`MastraStorageExporter`](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage) when feedback is added after the traced execution has finished. If the trace isn't available in storage, Mastra logs a warning and drops the feedback event.
+
+During a live traced execution, you can pass its `correlationContext` to emit feedback without rehydrating the trace from storage. This path is useful when the active request collects feedback before its tracing context ends.
+
 ## Find the trace for a message
 
 Feedback is usually collected against a message a user has already read, so you need the `traceId` for that message. Assistant messages carry it in `content.metadata`, both in the stream result and when the message is recalled later from memory:
@@ -143,6 +147,16 @@ const ratingsOverTime = await observability!.getFeedbackTimeSeries({
 
 See the [feedback reference](https://mastra.ai/reference/observability/feedback) for all fields, filters, return types, and percentile query parameters.
 
+The local runtime exposes the list route at `/api/observability/feedback` and analytics under its related paths. See the [HTTP routes table](https://mastra.ai/reference/observability/feedback). Mastra Platform provides a separate, unversioned hosted query API. See the [observability feedback query API](https://mastra.ai/docs/mastra-platform/api) for regional endpoints, authentication, and project scoping.
+
+## Export feedback to Mastra Platform
+
+[`MastraPlatformExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-platform-exporter) forwards emitted feedback events to Mastra Platform automatically because the hosted query API doesn't provide a creation route.
+
+If your application adds feedback after an agent or workflow response using only its `traceId`, configure `MastraStorageExporter` alongside `MastraPlatformExporter`. The storage exporter keeps the trace available for `addFeedback()` to rehydrate, and the Platform exporter forwards the resulting feedback event. Exporting a trace to Platform doesn't make it available to the application's local storage.
+
+See [Observability on Mastra Platform](https://mastra.ai/docs/mastra-platform/observability) for the combined exporter configuration.
+
 ## Export feedback to external platforms
 
 Feedback flows through the observability event bus, so exporters that support feedback forward it automatically. The [PostHog exporter](https://mastra.ai/reference/observability/tracing/exporters/posthog) sends feedback as native `$ai_feedback` events that appear on the linked trace in PostHog.

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/server/middleware.md

@@ -58,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
@@ -466,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
 
@@ -607,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
 
@@ -643,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/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