@mastra/mcp-docs-server 1.3.7-alpha.9 → 1.3.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -374,10 +374,13 @@ Enforcement of the claim depends on the workflows store. When the store supports
374
374
  - `@mastra/convex`
375
375
  - `@mastra/mongodb`, on a replica set or sharded cluster
376
376
  - `@mastra/dynamodb`
377
+ - `@mastra/redis`
378
+ - `@mastra/upstash`
379
+ - `@mastra/valkey`
377
380
 
378
381
  On Convex, run fencing runs in the Mastra server functions you deploy. Redeploy your Convex functions after upgrading `@mastra/convex`. Until you do, durable agent runs fail with an error asking you to redeploy, while other writes keep working.
379
382
 
380
- Stores that support run fencing keep one claim record per run, plus one memory fence record per run with memory. Stores with retention support prune them with the `workflows.runOwnership` and `memory.runFences` [retention keys](https://mastra.ai/reference/storage/retention). A run's first generation comes from the store's clock, so a run that reuses a `runId` after its records were pruned still outranks the fences and stream events of its earlier executions.
383
+ Stores that support run fencing keep one claim record per run, plus one memory fence record per run with memory. Stores with retention support prune them with the `workflows.runOwnership` and `memory.runFences` [retention keys](https://mastra.ai/reference/storage/retention). Redis, Upstash, and Valkey expire them on their own instead: a claim 7 days after its last claim, renewal, or release, and a fence 7 days after it's retired. A run's first generation comes from the store's clock, so a run that reuses a `runId` after its records were pruned still outranks the fences and stream events of its earlier executions.
381
384
 
382
385
  With any other workflows store, the claim is a lease on the [PubSub](https://mastra.ai/docs/server/pubsub) backend. The lease keeps two executions from claiming the run at once, but writes from an execution that lost the run aren't rejected. A run taken over while its previous execution was still live can end with that execution's output. When an execution loses its lease and no other execution has taken the run, the run stays held for up to 15 more seconds. Until then, `recover()` without `force` throws `DURABLE_AGENT_RUN_ACTIVE` with `retryAt` set to when the hold is sure to have ended. Mastra logs a warning when it recovers runs against a workflows or memory store without run fencing.
383
386
 
@@ -4,7 +4,7 @@
4
4
 
5
5
  # Redis
6
6
 
7
- The Redis storage implementation provides a high-performance storage solution using direct Redis connections via [`node-redis`](https://github.com/redis/node-redis) (the official Redis client for Node.js). It supports standalone Redis, and through custom client configuration, Redis Sentinel and Cluster deployments.
7
+ The Redis storage implementation provides a high-performance storage solution using direct Redis connections via [`node-redis`](https://github.com/redis/node-redis) (the official Redis client for Node.js). It supports standalone Redis and, through a custom client, Redis Sentinel. Redis Cluster isn't supported.
8
8
 
9
9
  ## Installation
10
10
 
@@ -45,7 +45,7 @@ await storage.init()
45
45
 
46
46
  ### Using Pre-configured Client
47
47
 
48
- For advanced configurations like Sentinel or Cluster, you can pass a pre-configured Redis client:
48
+ For advanced configurations such as Sentinel, you can pass a pre-configured Redis client:
49
49
 
50
50
  ```typescript
51
51
  import { RedisStore } from '@mastra/redis'
@@ -122,27 +122,7 @@ const storage = new RedisStore({
122
122
 
123
123
  ### Redis Cluster
124
124
 
125
- For Redis Cluster deployments, use the cluster client:
126
-
127
- ```typescript
128
- import { RedisStore } from '@mastra/redis'
129
- import { createCluster } from 'redis'
130
-
131
- const cluster = createCluster({
132
- rootNodes: [
133
- { url: 'redis://node-1:6379' },
134
- { url: 'redis://node-2:6379' },
135
- { url: 'redis://node-3:6379' },
136
- ],
137
- })
138
-
139
- await cluster.connect()
140
-
141
- const storage = new RedisStore({
142
- id: 'redis-cluster-storage',
143
- client: cluster,
144
- })
145
- ```
125
+ Redis Cluster isn't supported. `RedisStore` accepts only a standalone client from `createClient()`, and several operations read or write keys that hash to different slots, which Redis Cluster rejects with a `CROSSSLOT` error.
146
126
 
147
127
  ### Accessing the Underlying Client
148
128
 
@@ -66,6 +66,8 @@ const storage = new ValkeyStore({
66
66
 
67
67
  For an existing `GlideClient`, connect it before passing it to `ValkeyStore`. The caller remains responsible for closing injected clients.
68
68
 
69
+ `ValkeyStore` needs a standalone Valkey server. Valkey Cluster and `GlideClusterClient` aren't supported.
70
+
69
71
  ## Constructor parameters
70
72
 
71
73
  **id** (`string`): Unique identifier for the storage instance.
@@ -2006,15 +2006,24 @@ Prints help message and exits.
2006
2006
 
2007
2007
  ## Telemetry
2008
2008
 
2009
- By default, Mastra collects anonymous information about your project like your OS, Mastra version or Node.js version. You can read the [source code](https://github.com/mastra-ai/mastra/blob/main/packages/cli/src/analytics/index.ts) to check what's collected.
2009
+ By default, Mastra collects telemetry about your project, including your OS, Mastra version, and Node.js version. Server events also include the project identifiers described below. You can read the [CLI telemetry source code](https://github.com/mastra-ai/mastra/blob/main/packages/cli/src/analytics/index.ts) to check what's collected by the CLI.
2010
2010
 
2011
- When a server started with `mastra dev` or `mastra start` has observability metrics enabled, Mastra also sends anonymous, aggregated model usage at startup: input and output token counts per provider and model, plus the command (`dev` or `start`) and `NODE_ENV`. No prompts, responses, or other message content is ever sent. You can read the [source code](https://github.com/mastra-ai/mastra/blob/main/packages/core/src/telemetry/usage-telemetry.ts) to check what's collected.
2011
+ When a server started with `mastra dev` or `mastra start` has observability metrics enabled, Mastra sends aggregated model usage at startup: input and output token counts per provider and model, plus the command (`dev` or `start`) and `NODE_ENV`. No prompts, responses, or other message content is sent. You can read the [model usage telemetry source code](https://github.com/mastra-ai/mastra/blob/main/packages/core/src/telemetry/usage-telemetry.ts) to check what's collected.
2012
2012
 
2013
- At server startup, Mastra also sends an anonymous project-surface snapshot: counts of registered agents, agent controllers, workflows, tools, processors, vector stores, scorers, workspaces, MCP servers, gateways, and channels, plus booleans for memory, voice, editor, and observability usage and the coarse storage backend category. It doesn't send names or identifiers. You can read the [source code](https://github.com/mastra-ai/mastra/blob/main/packages/core/src/telemetry/feature-telemetry.ts) to check what's collected.
2013
+ At server startup, Mastra sends a project-surface snapshot with component counts, feature flags, and the coarse storage backend category, but no component names or component identifiers. You can read the [feature telemetry source code](https://github.com/mastra-ai/mastra/blob/main/packages/core/src/telemetry/feature-telemetry.ts) to check what's collected.
2014
+
2015
+ The server events `mastra_feature_usage` and `mastra_model_token_usage` include:
2016
+
2017
+ - `project_id`: The first 16 hexadecimal characters of the SHA-256 hash of `MASTRA_PROJECT_ROOT`, or the current working directory when unset. This identifier also keys the local model-usage cursor.
2018
+ - `project_id2`: An optional identifier for correlation across machines and deployments. If the trimmed `MASTRA_PROJECT_ID` value has UUID format, the value is sent **unhashed**, prefixed with `mp_`. Search for `mp_<platform-project-id>` to find that project's telemetry. Names, slugs, and other non-UUID values aren't sent as Platform identifiers.
2019
+
2020
+ When no UUID-shaped Platform ID is available, `project_id2` uses the first 16 hexadecimal characters of the SHA-256 hash of the normalized Git `origin` remote. Normalization keeps the lowercase host and repository path, excluding the scheme, credentials, port, query, fragment, trailing slashes, and `.git` suffix. Equivalent SSH and HTTPS remotes produce the same identifier. Remotes with the same host and path share an identifier even if different ports or SSH users refer to different repositories. Local filesystem remotes aren't used. Git discovery runs asynchronously and is cached for the process, including when unavailable. If neither source is available, `project_id2` is omitted.
2021
+
2022
+ These server events aren't anonymous: a Platform ID links them to that project, and a known repository URL can be normalized and hashed to match Git-derived events. Hashing the Git identity avoids sending the raw repository URL or credentials, but doesn't prevent correlation with public or otherwise known repositories.
2014
2023
 
2015
2024
  The Studio UI also collects anonymous browser-side usage analytics, such as page views and UI interactions. You can read the [source code](https://github.com/mastra-ai/mastra/blob/main/packages/playground/src/lib/analytics.tsx) to check what's collected. Setting `MASTRA_TELEMETRY_DISABLED` disables this too: the value is injected into the served page, so it applies to `mastra dev` and self-hosted builds alike.
2016
2025
 
2017
- You can opt out of all CLI and usage analytics by setting an environment variable:
2026
+ You can opt out of CLI, server, and Studio usage analytics by setting this environment variable before starting Mastra. When disabled, server telemetry doesn't look up the Git remote or send either project identifier:
2018
2027
 
2019
2028
  ```bash
2020
2029
  MASTRA_TELEMETRY_DISABLED=1
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mastra/mcp-docs-server",
3
- "version": "1.3.7-alpha.9",
3
+ "version": "1.3.7",
4
4
  "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -26,8 +26,8 @@
26
26
  "@mastra/mcp-legacy": "npm:@mastra/mcp@^1.18.0",
27
27
  "local-pkg": "^1.1.2",
28
28
  "zod": "^4.6.4",
29
- "@mastra/mcp": "^2.4.0-alpha.0",
30
- "@mastra/core": "1.77.0-alpha.4"
29
+ "@mastra/mcp": "^2.4.0",
30
+ "@mastra/core": "1.77.0"
31
31
  },
32
32
  "devDependencies": {
33
33
  "@hono/node-server": "^2.0.0",
@@ -43,9 +43,9 @@
43
43
  "tsx": "^4.23.1",
44
44
  "typescript": "^7.0.2",
45
45
  "vitest": "4.1.11",
46
- "@internal/lint": "0.0.142",
47
- "@internal/types-builder": "0.0.117",
48
- "@mastra/core": "1.77.0-alpha.4"
46
+ "@internal/lint": "0.0.143",
47
+ "@mastra/core": "1.77.0",
48
+ "@internal/types-builder": "0.0.118"
49
49
  },
50
50
  "homepage": "https://mastra.ai",
51
51
  "repository": {