@mastra/mcp-docs-server 1.3.8-alpha.2 → 1.3.8-alpha.4

package/.docs/reference/processors/provider-history-compat.md

@@ -29,7 +29,7 @@ A supplied `ProviderHistoryCompat` is used instead of the default. The default i
 
 The placement decides which half of the processor works:
 
-- **Reactive rules need `errorProcessors`.** On the standard loop, `processAPIError` runs from any of the three lists, so an input-processor registration does repair the message list, but the retry it asks for is only honored when the agent has a retry budget. With the default error processors in place the resolved list is non-empty, so a safety cap of `3` applies. The budget is left `undefined` only when the caller runs with no error processors at all (`errorProcessorDefaults: false` with none configured) and doesn't set `maxProcessorRetries` explicitly. Registered only as an input processor in that no-budget state, a reactive rule repairs the history and the request still fails. On the durable path the API-error pass additionally requires a non-empty `errorProcessors` list. If that list is empty, an input-processor registration can't trigger reactive recovery there at all, even with `maxProcessorRetries` set.
+- **Reactive rules need `errorProcessors`.** An agent wraps its input processors in a single processor workflow, and the API-error pass only runs `processAPIError` on error processors, so an instance registered only in `inputProcessors` never runs its reactive rules.
 - **Preemptive rules run from either list.** `processLLMRequest` runs over the input processors and over the resolved error processors, so a `ProviderHistoryCompat` in `errorProcessors` gets its prompt rewrites as well as its reactive recovery. An instance registered in `inputProcessors` runs once, in its input position.
 
 Registering in `errorProcessors` alone, as the example above does, covers both halves. Double registration can't cause a double retry: the runner stops at the first processor that asks for one, and each reactive rule bails once `retryCount` is above zero, so a repaired turn is attempted exactly once more.

package/.docs/reference/processors/stream-error-retry-processor.md

@@ -28,7 +28,7 @@ export const agent = new Agent({
 
 Set `maxProcessorRetries` alongside a `maxRetries` above `3`, because the agent stops error-processor retries at `3` when it's unset. See [Retry limits](#retry-limits).
 
-To run only the processors you configure, with none of the defaults merged in, set `errorProcessorDefaults: false`. Without an `errorProcessors` list, the agent then runs no error processors. An empty `errorProcessors` list still gets the defaults. Supplying your own processor for all three default ids replaces every default with your own implementation.
+To run only the processors you configure, with none of the defaults merged in, set `errorProcessorDefaults: false`. Without an `errorProcessors` list, the agent then runs only the error processors its memory contributes, if any. When memory contributes one, the retry cap of `3` applies. See [Error processors are enabled by default](https://mastra.ai/docs/agents/processors). An empty agent-level `errorProcessors` list still gets the defaults. A call-time `errorProcessors: []` replaces the resolved list instead, though the agent still runs the error processors its memory contributes. Supplying your own processor for all three default ids replaces every default with your own implementation.
 
 ## How it works
 

package/.docs/reference/processors/tool-search-processor.md

@@ -41,7 +41,7 @@ const toolSearch = new ToolSearchProcessor({
 
 **options.search.autoLoad** (`boolean`): When true, tools returned by search\_tools are activated immediately as part of the search. The load\_tool meta-tool is not exposed, collapsing the two-step search then load flow into a single search step. Discovered tools become available on the next turn. Keep topK conservative since every match is activated.
 
-**options.storage** (`'in-memory' | 'context'`): Where loaded-tool state lives. 'in-memory' (default) tracks loaded tools in an in-memory map per thread with TTL cleanup (see ttl); state is lost on restart and anonymous requests share a 'default' entry. 'context' derives loaded state from the conversation messages — a tool is loaded while a search\_tools/load\_tool result naming it remains in the messages; it is restart-safe, requires no memory, and de-loads automatically once that result is no longer present in the messages. The 'context' store is opt-in.
+**options.storage** (`'in-memory' | 'context'`): Where loaded-tool state lives. 'in-memory' (default) tracks loaded tools in an in-memory map per thread with TTL cleanup (see ttl); state is lost on restart and anonymous requests share a 'default' entry. 'context' derives loaded state from the conversation messages — a tool is loaded while a search\_tools/load\_tool result naming it remains in the messages; it works without memory (same-process only, and only for requests with a real thread ID), survives a restart whenever the messages are available again (memory with message history, or the caller resending the conversation), and de-loads automatically once that result is no longer present in the messages. The 'context' store is opt-in.
 
 **options.ttl** (`number`): Time-to-live for in-memory thread state, in milliseconds. Only applies to the default storage: 'in-memory' store; after this duration of inactivity thread state is cleaned up. Set to 0 to disable cleanup. Ignored by the 'context' store.
 
@@ -238,8 +238,8 @@ Use `clearState`, `clearAllState`, `getStateStats`, and `cleanupNow` to inspect
 
 Loaded state is derived from the conversation messages: a tool is loaded while a `search_tools` or `load_tool` result naming it remains in the messages. This mode:
 
-- Requires no memory configuration.
-- Is restart-safe: the durable record is the persisted message history.
+- Works without memory configuration. Without memory, loaded tools are kept for the current process only, and only for requests with a real thread ID; anonymous requests retain nothing between calls unless the caller resends the relevant messages.
+- Survives a restart whenever the messages are available again: from memory with message history, or because the caller resends the conversation. Without memory, a restart restores only what's in the messages the caller sends.
 - De-loads a tool automatically once that result is no longer present in the messages.
 
 ```typescript

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.3.8-alpha.2",
+  "version": "1.3.8-alpha.4",
   "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
   "type": "module",
   "main": "dist/index.js",
@@ -26,8 +26,8 @@
     "@mastra/mcp-legacy": "npm:@mastra/mcp@^1.18.0",
     "local-pkg": "^1.1.2",
     "zod": "^4.6.4",
-    "@mastra/mcp": "^2.4.1-alpha.0",
-    "@mastra/core": "1.78.0-alpha.1"
+    "@mastra/core": "1.78.0-alpha.3",
+    "@mastra/mcp": "^2.4.1-alpha.0"
   },
   "devDependencies": {
     "@hono/node-server": "^2.0.0",
@@ -43,9 +43,9 @@
     "tsx": "^4.23.1",
     "typescript": "^7.0.2",
     "vitest": "4.1.11",
-    "@internal/lint": "0.0.143",
     "@internal/types-builder": "0.0.118",
-    "@mastra/core": "1.78.0-alpha.1"
+    "@internal/lint": "0.0.143",
+    "@mastra/core": "1.78.0-alpha.3"
   },
   "homepage": "https://mastra.ai",
   "repository": {