@mastra/mcp-docs-server 1.1.48 → 1.1.49-alpha.0

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

@@ -58,6 +58,76 @@ You get a stable API endpoint, environment variable management, custom domain su
 
 A deploy transitions through **queued → uploading → building → deploying → running** (or **failed**, **cancelled**, **crashed**, or **stopped**). Only one build runs per project at a time. If multiple deploys queue up, only the latest proceeds and the rest are cancelled. Builds running longer than 15 minutes are automatically failed. The first deploy provisions Railway infrastructure and seeds environment variables from your local `.env`. Your server URL remains stable across deploys.
 
+## Idle behavior
+
+Server on Mastra platform runs on Railway, which can sleep a service after a period of inactivity to save resources. Railway measures inactivity by outbound network traffic. A service is considered idle only after roughly 10 minutes with no outbound packets. Any recurring outbound traffic resets this timer and keeps the service awake.
+
+A server that never sleeps usually has a background task or a long-lived connection sending traffic on a timer. Check for the following common causes.
+
+### Persistent database connections
+
+A database client that stays open keeps the connection alive even when the server is idle. Many drivers also run a background health check that pings the database on an interval, which counts as outbound traffic. For example, a MongoDB client that's never closed keeps a monitoring socket open and sends a heartbeat about every 10 seconds.
+
+Connection pool settings that drain idle connections aren't enough on their own, because the driver's monitoring connection stays open and keeps pinging. To let the server sleep, close the client after a period of inactivity and reconnect on the next request.
+
+> **Note:** Closing the client adds a short reconnect delay to the first request after the server wakes. If your workload can't tolerate that delay, keep the connection open and don't rely on idle sleep.
+
+### Scheduled tasks and timers
+
+A `setInterval`, cron job, or polling loop that makes network calls keeps the server awake. If you need scheduled work, run it as a separate service or use an external scheduler that wakes the server with a request.
+
+### External pings and keep-alive checks
+
+An uptime monitor, health check, or keep-alive ping that hits the server on an interval resets the idle timer. Remove these checks or increase their interval beyond the idle window if you want the server to sleep.
+
+### Observability exporters
+
+An exporter that streams traces, logs, or metrics to a remote endpoint sends outbound traffic. Confirm the exporter batches and stops sending when the server is idle, rather than flushing on a fixed interval.
+
+### Long-lived streams
+
+An open server-sent events (SSE) stream, WebSocket, or other long-lived connection holds traffic open until it closes. A streaming response that stays subscribed in the background keeps the connection active. Confirm streams close when the client disconnects and that no stream stays open while the server is otherwise idle.
+
+### Chat integrations
+
+Some chat integrations hold a persistent connection and send a regular heartbeat, which keeps the server awake. For example, a Slack app in Socket Mode opens a WebSocket and pings about every 30 seconds, and a Discord bot keeps its gateway WebSocket open with a heartbeat on a timer. Both the open socket and the heartbeat prevent idle.
+
+If you want the server to sleep, receive events over HTTP webhooks instead of a persistent connection where the integration supports it. Slack apps, for example, can use the Events API with a request URL instead of Socket Mode. If your app needs a persistent connection, keep the service running with the **Persistent Server add-on** described below.
+
+### Inspect active connections
+
+To find what keeps the server awake, inspect the process's active handles during idle periods. A handle that remains after all requests finish is the cause to investigate. Open sockets point to a persistent connection that needs to close, and active timers point to a `setInterval` or self-rescheduling `setTimeout`.
+
+Drop the following helper into your app, then watch the log after traffic stops. Anything still listed once the server is idle is keeping it awake:
+
+```typescript
+export function logActiveHandles() {
+  // process._getActiveHandles is undocumented but useful for diagnosis.
+  const handles = (process as any)._getActiveHandles() as Array<any>
+
+  const summary = handles.map(handle => {
+    const type = handle?.constructor?.name ?? typeof handle
+    if (type === 'Socket') {
+      return `Socket -> ${handle.remoteAddress}:${handle.remotePort}`
+    }
+    return type
+  })
+
+  console.log(`[idle] ${handles.length} active handles:`, summary)
+}
+
+// Log every 30 seconds so you can see what persists while the server is idle.
+setInterval(logActiveHandles, 30_000).unref()
+```
+
+Call `unref()` on the diagnostic interval so the helper itself doesn't keep the server awake.
+
+### Keep a service running
+
+Some applications genuinely need the connections or tasks described above, such as a persistent database connection for low first-request latency, a background scheduler, or a long-lived stream. If your app requires any of these, don't force the service to sleep. Use the **Persistent Server add-on** to keep the service running continuously instead.
+
+With the **Persistent Server add-on** enabled, the service stays awake even with no traffic, so persistent connections, scheduled tasks, and open streams keep working without being interrupted by idle sleep.
+
 ## CI/CD
 
 Automate deployments from GitHub Actions, GitLab CI, or any CI provider. After your first interactive deploy, CI/CD needs two things: an API token and the `.mastra-project.json` file committed to your repository.

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # @mastra/mcp-docs-server
 
+## 1.1.49-alpha.0
+
+### Patch Changes
+
+- Security remediation for the 2026-06-17 "easy-day-js" supply-chain incident. Patch bump to publish clean versions and move the `latest` dist-tag forward, superseding the compromised versions that declared the malicious `easy-day-js` dependency. ([#18056](https://github.com/mastra-ai/mastra/pull/18056))
+
+- Updated dependencies [[`77a2351`](https://github.com/mastra-ai/mastra/commit/77a2351ee79296e360bce822cb3391f7cfd6489d)]:
+  - @mastra/core@1.43.1-alpha.0
+  - @mastra/mcp@1.10.1-alpha.0
+
 ## 1.1.47
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.1.48",
+  "version": "1.1.49-alpha.0",
   "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
   "type": "module",
   "main": "dist/index.js",
@@ -28,8 +28,8 @@
     "jsdom": "^26.1.0",
     "local-pkg": "^1.1.2",
     "zod": "^4.4.3",
-    "@mastra/core": "1.43.0",
-    "@mastra/mcp": "^1.10.0"
+    "@mastra/core": "1.43.1-alpha.0",
+    "@mastra/mcp": "^1.10.1-alpha.0"
   },
   "devDependencies": {
     "@hono/node-server": "^1.19.11",
@@ -46,8 +46,8 @@
     "typescript": "^6.0.3",
     "vitest": "4.1.8",
     "@internal/types-builder": "0.0.80",
-    "@internal/lint": "0.0.105",
-    "@mastra/core": "1.43.0"
+    "@mastra/core": "1.43.1-alpha.0",
+    "@internal/lint": "0.0.105"
   },
   "homepage": "https://mastra.ai",
   "repository": {