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

package/.docs/integrations/channels/github.md

@@ -74,7 +74,7 @@ export const mastra = new Mastra({
 })
 ```
 
-After the agent has created a memory thread, subscribe that thread to a PR. Passing `owner` and `repo` works from any directory:
+After the agent has created a memory thread, subscribe that thread to a PR. Choose `review` mode when the thread only needs code revisions, authorized latest PR comments, and observable review-thread-state updates:
 
 ```typescript
 await githubSignals.subscribeThreadToPR({
@@ -85,19 +85,66 @@ await githubSignals.subscribeThreadToPR({
     repo: 'web-app',
     number: 42,
   },
+  mode: 'review',
 })
 ```
 
 The provider syncs the PR immediately, stores the subscription, and starts polling every five minutes. Set `pollIntervalMs` in the `GithubSignals` constructor to change the interval. If the process restarts, call `startPollingForThread()` for each persisted thread subscription to resume polling.
 
-## Pull request notifications
+A thread has one current GitHub Signals subscription. Subscribing it to another PR replaces the existing subscription.
 
-GitHub Signals notifies the agent when a subscribed PR has:
+## Subscription modes
 
-- A new authorized comment, commit, or other pull request activity.
-- A change in unresolved review threads.
-- Continuous integration (CI) checks that start, fail, or recover.
-- Merge conflicts that appear or are resolved.
-- A state change to closed, reopened, or merged.
+GitHub Signals supports two subscription modes:
 
-The initial sync sends a baseline notification with the current PR state. A merge automatically removes the thread's subscription to that PR.
+- `review`: Follows new head revisions, authorized latest PR comments, and observable review-thread-state changes, including when all review threads become resolved.
+- `working`: Follows all actionable PR activity detected by the provider. Comment-bearing notifications remain subject to existing authorization gates. This is the default when `mode` is omitted and for stored subscriptions without a valid mode.
+
+The following table shows the observable behavior of each mode:
+
+| Pull request activity                                 | `working`                                             | `review`                                                                                                          |
+| ----------------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
+| First observation                                     | Sends a baseline notification                         | Saves all cursors without notifying unless the PR is closed or merged; then notifies and removes the subscription |
+| New commit or force-push                              | Notifies when the latest comment author is authorized | Notifies without requiring a comment author                                                                       |
+| New authorized latest PR comment                      | Notifies                                              | Notifies                                                                                                          |
+| Observable review-thread-state change                 | Notifies while unresolved threads remain              | Notifies, including when all review threads become resolved                                                       |
+| Continuous integration checks start, fail, or recover | Notifies                                              | Saves the new state without notifying                                                                             |
+| Merge conflicts appear or resolve                     | Notifies                                              | Saves the new state without notifying                                                                             |
+| Other actionable aggregate PR activity                | Notifies when applicable authorization checks pass    | Saves the new state without notifying                                                                             |
+| PR closes without merging                             | Notifies and keeps the subscription                   | Notifies and removes the subscription                                                                             |
+| PR reopens                                            | Notifies                                              | Doesn't notify because the earlier close removed the subscription                                                 |
+| PR merges                                             | Notifies and removes the subscription                 | Notifies and removes the subscription                                                                             |
+
+Review mode uses the latest generic PR comment exposed by `gitcrawl`. The snapshot doesn't distinguish general PR conversation from inline review comments. Comment notifications require an authorized author because they include comment content. Review-state notifications contain only provider-generated state summaries and aren't author-gated.
+
+The review-state cursor includes the unresolved thread count and the latest unresolved thread timestamp. It reports when the count reaches zero, but it can't report replies on threads that are already resolved.
+
+During subscription, a PR already known to be closed or merged isn't stored and doesn't send an activity notification. Otherwise, review mode silently saves its first available non-terminal snapshot, including when the subscribe-time snapshot fails and a later poll supplies the first observation. If the first available poll snapshot or a later snapshot is closed or merged, the provider sends a terminal notification and removes the subscription. It doesn't follow a later reopen unless you subscribe again.
+
+## Subscription tools
+
+The provider adds `github_subscribe_pr` and `github_unsubscribe_pr` tools to the agent. Pass `mode` when subscribing:
+
+```json
+{
+  "owner": "acme",
+  "repo": "web-app",
+  "number": 42,
+  "mode": "review"
+}
+```
+
+Omitting `mode` selects `working`. Don't subscribe for a one-off PR inspection.
+
+## MastraCode commands
+
+In MastraCode, use the spaced `--mode` flag with a PR number, `owner/repo#number`, or full GitHub PR URL:
+
+```text
+/github subscribe 42 --mode review
+/github acme/web-app#42 --mode working
+/github unsubscribe 42
+/github debug
+```
+
+MastraCode rejects `--mode=review`, missing or repeated mode values, unknown modes, and mode flags on unsubscribe. `/github debug` shows the stored mode and displays absent or invalid legacy values as `working`.

package/.docs/integrations/channels/imessage.md

@@ -2,10 +2,19 @@
 
 # iMessage
 
-iMessage channels let a Mastra agent receive direct messages and group messages from iMessage. Mastra handles the agent wiring, the webhook route, and the gateway listener; the Photon iMessage adapter docs cover number provisioning, credentials, and webhook registration.
+iMessage channels let a Mastra agent receive direct messages and group messages from iMessage. Two vendor-maintained adapters connect Mastra to iMessage: [Photon](https://app.photon.codes) and [Linq](https://linqapp.com). Mastra handles the agent wiring and the webhook route; the adapter docs cover number provisioning, credentials, and webhook registration.
+
+## Choose an adapter
+
+Both adapters follow the same Mastra wiring, so pick the provider first:
+
+- **Photon**: Hosted or self-hosted iMessage service. Supports webhooks and a [gateway listener](#gateway-listener) that streams messages over an open connection.
+- **Linq**: Hosted iMessage, RCS, and SMS API. Webhook-driven, with tapback reactions and media mapped in both directions.
 
 ## Install the adapter
 
+**Photon**:
+
 Install the Photon iMessage adapter:
 
 **npm**:
@@ -32,9 +41,87 @@ yarn add @photon-ai/chat-adapter-imessage
 bun add @photon-ai/chat-adapter-imessage
 ```
 
+**Linq**:
+
+```bash
+npm install @photon-ai/chat-adapter-imessage
+```
+
+**Tab 3**:
+
+```bash
+pnpm add @photon-ai/chat-adapter-imessage
+```
+
+**Tab 4**:
+
+```bash
+yarn add @photon-ai/chat-adapter-imessage
+```
+
+**Tab 5**:
+
+```bash
+bun add @photon-ai/chat-adapter-imessage
+```
+
+**Tab 6**:
+
+Install the Linq Chat SDK adapter:
+
+**npm**:
+
+```bash
+npm install @linqapp/chat-sdk-adapter
+```
+
+**pnpm**:
+
+```bash
+pnpm add @linqapp/chat-sdk-adapter
+```
+
+**Yarn**:
+
+```bash
+yarn add @linqapp/chat-sdk-adapter
+```
+
+**Bun**:
+
+```bash
+bun add @linqapp/chat-sdk-adapter
+```
+
+**Tab 7**:
+
+```bash
+npm install @linqapp/chat-sdk-adapter
+```
+
+**Tab 8**:
+
+```bash
+pnpm add @linqapp/chat-sdk-adapter
+```
+
+**Tab 9**:
+
+```bash
+yarn add @linqapp/chat-sdk-adapter
+```
+
+**Tab 10**:
+
+```bash
+bun add @linqapp/chat-sdk-adapter
+```
+
 ## Agent configuration
 
-Add `createiMessageAdapter()` to the agent's `channels.adapters` object:
+Add the adapter factory to the agent's `channels.adapters` object:
+
+**Photon**:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -57,6 +144,35 @@ export const imessageAgent = new Agent({
 })
 ```
 
+`threadContext: { maxMessages: 0 }` skips the platform history lookup Mastra runs when an agent is first mentioned in a group chat, which the Photon adapter can't perform.
+
+**Linq**:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { createLinqAdapter } from '@linqapp/chat-sdk-adapter'
+
+export const imessageAgent = new Agent({
+  id: 'imessage-agent',
+  name: 'iMessage Agent',
+  instructions: 'Answer questions and help with tasks over iMessage.',
+  model: 'openai/gpt-5.6-sol',
+  channels: {
+    adapters: {
+      imessage: {
+        adapter: createLinqAdapter({
+          apiKey: process.env.LINQ_API_KEY!,
+          signingSecret: process.env.LINQ_WEBHOOK_SECRET!,
+        }),
+        toolDisplay: 'text',
+      },
+    },
+  },
+})
+```
+
+`createLinqAdapter()` takes the credentials directly: `apiKey` is your Linq API key and `signingSecret` comes from the [webhook subscription](#webhook-url). The Linq adapter can fetch thread history, so the default `threadContext` behavior works.
+
 Register the agent on the Mastra instance:
 
 ```typescript
@@ -70,10 +186,14 @@ export const mastra = new Mastra({
 
 Use `imessage` as the adapter key. Mastra derives the webhook path and the `platform` value on `requestContext` from this key.
 
-`toolDisplay: 'text'` describes tool calls in the message, since iMessage has no interactive cards for Approve and Deny actions. `threadContext: { maxMessages: 0 }` skips the platform history lookup Mastra runs when an agent is first mentioned in a group chat, which the adapter can't perform. Both override defaults that assume platform features iMessage lacks.
+`toolDisplay: 'text'` describes tool calls in the message, since iMessage has no interactive cards for Approve and Deny actions. Both adapters need it: Photon has no card rendering, and Linq flattens cards to plain text where buttons show their labels but can't trigger actions.
+
+> **Warning:** Text rendering can't submit approval decisions. A tool with `requireApproval: true` stays suspended until a UI or API action, such as Studio, submits an explicit approval or decline, so avoid approval-gated tools on iMessage agents unless another surface handles the decision. See [Tool approval](https://mastra.ai/docs/channels).
 
 ## Adapter setup
 
+**Photon**:
+
 Follow the [Photon iMessage adapter docs](https://github.com/photon-hq/vercel-chat-adapter-imessage) for iMessage-specific setup, including number provisioning, hosted and self-hosted modes, and webhook registration. The adapter picks its mode from the environment variables you set.
 
 For the hosted service, create a project at [app.photon.codes](https://app.photon.codes) and use the project credentials:
@@ -94,6 +214,17 @@ IMESSAGE_PHONE=+15551234567
 
 `IMESSAGE_PHONE` is optional and routes messages when a self-hosted server has several numbers. You can also pass these values to `createiMessageAdapter()` directly, including a `credentials` function that resolves the project ID and secret at first use from a secret store.
 
+**Linq**:
+
+Follow the [Linq API docs](https://docs.linqapp.com/) for Linq-specific setup, including phone number provisioning and API keys. Create a Linq account, copy your API key, and set the credentials the agent configuration reads:
+
+```bash
+LINQ_API_KEY=your-linq-api-key
+LINQ_WEBHOOK_SECRET=your-webhook-signing-secret
+```
+
+`LINQ_WEBHOOK_SECRET` is the signing secret returned when you create a webhook subscription in the next section. The adapter also accepts a `baseURL` option to target a different Linq API base URL, such as a sandbox.
+
 ## Webhook URL
 
 Mastra generates the iMessage webhook route from the agent ID and adapter key:
@@ -108,13 +239,25 @@ Use your public Mastra server URL as the base URL:
 https://your-app.example.com/api/agents/imessage-agent/channels/imessage/webhook
 ```
 
+**Photon**:
+
 Register this URL in the [Photon dashboard](https://app.photon.codes), then set the signing secret it returns as `IMESSAGE_WEBHOOK_SECRET`. The secret is shown once at registration. The adapter verifies the signature on every delivery and rejects requests that don't match. Webhooks are available in hosted mode only.
 
-> **Note:** Photon delivers to public HTTPS endpoints only. It won't deliver to `http://`, to private addresses like `localhost`, or through a redirect. For local development, use a tunnel as described in the [Channels overview](https://mastra.ai/docs/channels).
+**Linq**:
+
+Create a [webhook subscription](https://docs.linqapp.com/guides/webhooks/subscriptions/) with this URL as the target and subscribe to at least these events:
+
+- `message.received`
+- `reaction.added`
+- `reaction.removed`
+
+Set the `signing_secret` the subscription returns as `LINQ_WEBHOOK_SECRET`. The secret is shown once at creation and can't be retrieved later. The adapter verifies the HMAC signature on every delivery, checks for replayed requests, and rejects requests that don't match.
+
+> **Note:** Both providers deliver to public HTTPS endpoints only, not to `http://` or private addresses like `localhost`. For local development, use a tunnel as described in the [Channels overview](https://mastra.ai/docs/channels).
 
 ## Duplicate deliveries
 
-Photon retries failed deliveries with backoff and delivers at least once, so the same message can arrive twice. Chat SDK drops the repeat using the channel state adapter, and Mastra's default keeps those dedup keys in memory. That covers a single long-running server.
+Photon and Linq retry failed deliveries with backoff and deliver at least once, so the same message can arrive twice. Chat SDK drops the repeat using the channel state adapter, and Mastra's default keeps those dedup keys in memory. That covers a single long-running server.
 
 A repeat can still reach the agent after a restart, or on serverless where the retry is routed to a different instance. Pass a shared state adapter on `channels.state` so dedup keys are visible everywhere. Install one alongside the adapter:
 
@@ -154,7 +297,6 @@ channels: {
       toolDisplay: 'text',
     },
   },
-  threadContext: { maxMessages: 0 },
   state: createRedisState(),
 },
 ```
@@ -163,13 +305,13 @@ This matters most for tools with side effects, where handling the same message t
 
 ## Read receipts
 
-iPhone Messages sends a read receipt for every message the agent posts, and the adapter delivers those receipts as inbound messages with no text and no attachments. Mastra skips them, so the agent doesn't answer its own reply in a loop. Their message IDs carry a `:read:` suffix, and they show up as skipped messages at `debug` log level.
+iPhone Messages sends a read receipt for every message the agent posts, and the Photon adapter delivers those receipts as inbound messages with no text and no attachments. Mastra skips them, so the agent doesn't answer its own reply in a loop. Their message IDs carry a `:read:` suffix, and they show up as skipped messages at `debug` log level.
 
 The same rule applies to every adapter: an inbound message with neither text nor attachments never starts an agent run. A custom `onDirectMessage`, `onMention`, or `onSubscribedMessage` handler still receives it and can act on it before calling `defaultHandler`.
 
 ## Gateway listener
 
-The adapter can hold an open connection and stream messages in real time instead of receiving webhooks. This works in both hosted and self-hosted modes.
+The Photon adapter can hold an open connection and stream messages in real time instead of receiving webhooks. This works in both hosted and self-hosted modes. The Linq adapter is webhook-driven and has no gateway mode.
 
 Mastra starts this listener during initialization and reconnects it if it drops, so no cron job or extra route is needed on a long-running server. Set `gateway: false` on the adapter config to turn it off when you use webhooks:
 

package/.docs/integrations/databases/elasticsearch.md

@@ -0,0 +1,156 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Elasticsearch
+
+The Elasticsearch storage implementation provides agent memory, workflow snapshot, and score storage on top of an Elasticsearch cluster using the official [`@elastic/elasticsearch`](https://github.com/elastic/elasticsearch-js) client. It shares the same connection configuration as `ElasticSearchVector`, so a single cluster (and even a single client instance) can serve both agent memory and semantic recall.
+
+`ElasticSearchStore` currently implements the `memory`, `workflows`, and `scores` storage domains.
+
+## Installation
+
+```bash
+npm install @mastra/elasticsearch
+```
+
+## Usage
+
+### Using a URL
+
+```typescript
+import { ElasticSearchStore } from '@mastra/elasticsearch'
+
+const storage = new ElasticSearchStore({
+  id: 'elasticsearch-storage',
+  url: 'http://localhost:9200',
+})
+
+await storage.init()
+```
+
+### Using authentication
+
+```typescript
+import { ElasticSearchStore } from '@mastra/elasticsearch'
+
+const storage = new ElasticSearchStore({
+  id: 'elasticsearch-storage',
+  url: 'https://my-cluster.example.com:9200',
+  auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
+})
+```
+
+`auth` also accepts `{ username, password }` or `{ bearer }`.
+
+### Using a pre-configured client
+
+For advanced configurations (cloud IDs, TLS options, custom transport), pass a pre-configured client. The same client can be shared with `ElasticSearchVector`:
+
+```typescript
+import { Client } from '@elastic/elasticsearch'
+import { ElasticSearchStore, ElasticSearchVector } from '@mastra/elasticsearch'
+
+const client = new Client({
+  node: 'https://my-cluster.example.com:9200',
+  auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
+})
+
+const storage = new ElasticSearchStore({ id: 'elasticsearch-storage', client })
+const vector = new ElasticSearchVector({ id: 'elasticsearch-vector', client })
+```
+
+When you provide your own client, `storage.close()` does not close it — you remain responsible for its lifecycle.
+
+## Parameters
+
+**id** (`string`): Unique identifier for the storage instance
+
+**url** (`string`): Elasticsearch node URL (e.g., http\://localhost:9200)
+
+**auth** (`ElasticSearchAuth`): Authentication options: { apiKey }, { username, password }, or { bearer }
+
+**client** (`Client`): Pre-configured Elasticsearch client (from @elastic/elasticsearch) for advanced setups
+
+**disableInit** (`boolean`): Disable automatic initialization; call storage.init() explicitly before use
+
+> **Note:** You must provide either `url` or `client`. These options are mutually exclusive.
+
+## Additional Notes
+
+### Index Structure
+
+Each Mastra storage table maps to one Elasticsearch index of the same name (for example `mastra_threads`, `mastra_messages`, `mastra_workflow_snapshot`, `mastra_scorers`). Records are stored as opaque JSON documents with a keyword `key` field, so no index mappings need to be managed manually — indexes are created on first use.
+
+### Consistency
+
+Elasticsearch search is near-real-time. All writes are performed with an immediate refresh so subsequent reads and searches observe them, and point reads use real-time get-by-ID lookups.
+
+### Closing Connections
+
+When shutting down your application, close the connection:
+
+```typescript
+await storage.close()
+```
+
+This only closes clients created by `ElasticSearchStore` from a `url`; user-provided clients are left open.
+
+## Usage Example
+
+### Adding memory to an agent
+
+```typescript
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+import { ElasticSearchStore } from '@mastra/elasticsearch'
+
+export const elasticsearchAgent = new Agent({
+  id: 'elasticsearch-agent',
+  name: 'Elasticsearch Agent',
+  instructions:
+    'You are an AI agent with the ability to automatically recall memories from previous interactions.',
+  model: 'openai/gpt-5.6-sol',
+  memory: new Memory({
+    storage: new ElasticSearchStore({
+      id: 'elasticsearch-agent-storage',
+      url: process.env.ELASTICSEARCH_URL!,
+      auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
+    }),
+    options: {
+      lastMessages: 10,
+    },
+  }),
+})
+```
+
+### Using with Mastra instance
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { ElasticSearchStore } from '@mastra/elasticsearch'
+
+const storage = new ElasticSearchStore({
+  id: 'mastra-storage',
+  url: 'http://localhost:9200',
+})
+
+const mastra = new Mastra({
+  storage, // init() called automatically
+})
+```
+
+If using storage directly without Mastra, call `init()` explicitly:
+
+```typescript
+import { ElasticSearchStore } from '@mastra/elasticsearch'
+
+const storage = new ElasticSearchStore({
+  id: 'elasticsearch-storage',
+  url: 'http://localhost:9200',
+})
+
+await storage.init()
+
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory')
+const thread = await memoryStore?.getThreadById({ threadId: '...' })
+```

package/.docs/integrations/databases/libsql.md

@@ -89,12 +89,28 @@ storage: new LibSQLStore({
 
 > **Warning:** In-memory storage resets when the process changes. Only suitable for development.
 
+Embedded replica synced with a remote primary (for example Turso):
+
+```typescript
+storage: new LibSQLStore({
+  id: 'libsql-storage',
+  url: 'file:./replica.db',
+  syncUrl: 'libsql://your-db-name.aws-ap-northeast-1.turso.io',
+  authToken: process.env.TURSO_AUTH_TOKEN,
+  syncInterval: 60,
+})
+```
+
 ## Options
 
 **url** (`string`): Database URL. Use :memory: for in-memory database, file:filename.db for a file database, or a libSQL connection string (e.g., libsql://your-database.turso.io) for remote storage.
 
 **authToken** (`string`): Authentication token for remote libSQL databases.
 
+**syncUrl** (`string`): URL of the remote primary database to sync from, enabling an embedded replica. Requires a local file: url.
+
+**syncInterval** (`number`): Interval in seconds for automatic sync with the remote primary. Only applies when syncUrl is set.
+
 ## Managed tables
 
 The storage implementation creates the core storage tables automatically, including `mastra_notifications` for notification inbox records and delivery metadata.

package/.docs/integrations/databases/mongodb.md

@@ -32,7 +32,7 @@ bun add @mastra/mongodb@latest
 
 ## Usage
 
-Ensure you have a [MongoDB Atlas Local (via Docker)](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-docker/) or [MongoDB Atlas Cloud](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-getting-started/) instance with Atlas Search enabled. MongoDB 7.0+ is recommended.
+Ensure you have a [MongoDB Atlas Local (via Docker)](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-docker/) or [MongoDB Atlas Cloud](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-getting-started/) instance with MongoDB Search enabled. MongoDB 7.0+ is recommended.
 
 ```typescript
 import { MongoDBStore } from '@mastra/mongodb'

package/.docs/integrations/databases/postgresql.md

@@ -146,6 +146,32 @@ PostgreSQL supports observability and can handle low trace volumes. Throughput c
 - Setting up table partitioning for efficient data retention
 - Migrating observability to [ClickHouse via composite storage](https://mastra.ai/reference/storage/composite) if you need to scale further
 
+`PostgresStoreVNext` uses the `event-sourced` [tracing strategy](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage) instead. It writes one row when a span starts and another when it ends, never updating a row in place, and collapses those rows when a trace is read. Writes stay append-only, and traces appear in Studio while the run is still executing.
+
+#### Filter suggestions
+
+Studio's Traces, Logs, and Metrics pages offer filter values (tags, service names, environments, entity names, metric names and labels) discovered from your observability data. Those values are cached in the database and recomputed in the background when the cache goes stale.
+
+To keep the refresh cheap on large datasets, it only scans events from the last 30 days. Values that appear exclusively in older events won't be suggested, though filtering by them still works. Use `discovery` to change the window or how often it refreshes:
+
+```typescript
+import { PostgresStoreVNext } from '@mastra/pg'
+
+const storage = new PostgresStoreVNext({
+  id: 'pg-storage',
+  connectionString: process.env.DATABASE_URL,
+  observability: {
+    connectionString: process.env.OBSERVABILITY_DATABASE_URL,
+    discovery: {
+      lookbackSeconds: 7 * 24 * 60 * 60, // scan the last 7 days; 0 scans all history
+      ttlSeconds: 15 * 60, // refresh at most every 15 minutes
+    },
+  },
+})
+```
+
+Lower `lookbackSeconds` if refreshes are slow, and raise `ttlSeconds` if they run more often than your filter values change. Only one process refreshes a given cache entry at a time, so adding server instances doesn't multiply the work.
+
 ### Initialization
 
 When you pass storage to the Mastra class, `init()` is called automatically before any storage operation:

package/.docs/integrations/databases/valkey.md

@@ -0,0 +1,99 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Valkey
+
+The Valkey storage implementation provides persistent storage and server-side caching through the [Valkey GLIDE](https://github.com/valkey-io/valkey-glide) client. Use it when your deployment runs Valkey or needs GLIDE features such as native Valkey configuration and authentication.
+
+Use [`@mastra/redis`](https://mastra.ai/integrations/databases/redis) for Redis deployments that use the official `redis` client. The packages are tested independently against their respective servers.
+
+## Installation
+
+**npm**:
+
+```bash
+npm install @mastra/valkey
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/valkey
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/valkey
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/valkey
+```
+
+## Usage
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { ValkeyStore } from '@mastra/valkey'
+
+export const mastra = new Mastra({
+  storage: new ValkeyStore({
+    id: 'valkey-storage',
+    host: 'localhost',
+    port: 6379,
+    password: process.env.VALKEY_PASSWORD,
+  }),
+})
+```
+
+You can also provide a native GLIDE configuration:
+
+```typescript
+import { ValkeyStore } from '@mastra/valkey'
+
+const storage = new ValkeyStore({
+  id: 'valkey-storage',
+  config: {
+    addresses: [{ host: 'localhost', port: 6379 }],
+    useTLS: true,
+  },
+})
+```
+
+For an existing `GlideClient`, connect it before passing it to `ValkeyStore`. The caller remains responsible for closing injected clients.
+
+## Constructor parameters
+
+**id** (`string`): Unique identifier for the storage instance.
+
+**host** (`string`): Valkey host address. Use with the direct connection fields.
+
+**port** (`number`): Valkey port. (Default: `6379`)
+
+**username** (`string`): Valkey authentication username. (Default: `default`)
+
+**password** (`string`): Valkey authentication password.
+
+**db** (`number`): Valkey database number. (Default: `0`)
+
+**useTLS** (`boolean`): Enables TLS for direct connections.
+
+**config** (`GlideClientConfiguration`): Native GLIDE standalone client configuration.
+
+**client** (`GlideClient`): Preconfigured GLIDE standalone client.
+
+**disableInit** (`boolean`): Disables automatic storage initialization.
+
+Provide exactly one connection form: `client`, `config`, or `host` with its optional direct connection fields.
+
+## Closing connections
+
+Close clients created by `ValkeyStore` during graceful shutdown:
+
+```typescript
+await storage.close()
+```
+
+`close()` doesn't close an injected `GlideClient`.