@mastra/mcp-docs-server 0.0.0-error-handler-fix-20251020202607 → 0.0.0-execa-dynamic-import-20260304221256

package/.docs/raw/mastra-cloud/dashboard.mdx

@@ -1,100 +0,0 @@
----
-title: Understanding the Mastra Cloud Dashboard
-description: Details of each feature available in Mastra Cloud
----
-
-import { MastraCloudCallout } from '@/components/mastra-cloud-callout'
-
-# Navigating the Dashboard
-
-This page explains how to navigate the Mastra Cloud dashboard, where you can configure your project, view deployment details, and interact with agents and workflows using the built-in [Playground](/docs/mastra-cloud/dashboard#playground).
-
-<MastraCloudCallout />
-
-## Overview
-
-The **Overview** page provides details about your application, including its domain URL, status, latest deployment, and connected agents and workflows.
-
-![Project dashboard](/image/mastra-cloud/mastra-cloud-project-dashboard.jpg)
-
-Key features:
-
-Each project shows its current deployment status, active domains, and environment variables, so you can quickly understand how your application is running.
-
-## Deployments
-
-The **Deployments** page shows recent builds and gives you quick access to detailed build logs. Click any row to view more information about a specific deployment.
-
-![Dashboard deployment](/image/mastra-cloud/mastra-cloud-dashboard-deployments.jpg)
-
-Key features:
-
-Each deployment includes its current status, the Git branch it was deployed from, and a title generated from the commit hash.
-
-## Logs
-
-The **Logs** page is where you'll find detailed information to help debug and monitor your application's behavior in the production environment.
-
-![Dashboard logs](/image/mastra-cloud/mastra-cloud-dashboard-logs.jpg)
-
-Key features:
-
-Each log includes a severity level and detailed messages showing agent, workflow, and storage activity.
-
-## Settings
-
-On the **Settings** page you can modify the configuration of your application.
-
-![Dashboard settings](/image/mastra-cloud/mastra-cloud-dashboard-settings.jpg)
-
-Key features:
-
-You can manage environment variables, edit key project settings like the name and branch, configure storage with LibSQLStore, and set a stable URL for your endpoints.
-
-> Changes to configuration require a new deployment before taking effect.
-
-## Playground
-
-### Agents
-
-On the **Agents** page you'll see all agents used in your application. Click any agent to interact using the chat interface.
-
-![Dashboard playground agents](/image/mastra-cloud/mastra-cloud-dashboard-playground-agents.jpg)
-
-Key features:
-
-Test your agents in real time using the chat interface, review traces of each interaction, and see evaluation scores for every response.
-
-### Workflows
-
-On the **Workflows** page you'll see all workflows used in your application. Click any workflow to interact using the runner interface.
-
-![Dashboard playground workflows](/image/mastra-cloud/mastra-cloud-dashboard-playground-workflows.jpg)
-
-Key features:
-
-Visualize your workflow with a step-by-step graph, view execution traces, and run workflows directly using the built-in runner.
-
-### Tools
-
-On the **Tools** page you'll see all tools used by your agents. Click any tool to interact using the input interface.
-
-![Dashboard playground tools](/image/mastra-cloud/mastra-cloud-dashboard-playground-tools.jpg)
-
-Key features:
-
-Test your tools by providing an input that matches the schema and viewing the structured output.
-
-## MCP Servers
-
-The **MCP Servers** page lists all MCP Servers included in your application. Click any MCP Server for more information.
-
-![Dashboard playground mcp servers](/image/mastra-cloud/mastra-cloud-dashboard-playground-mcpservers.jpg)
-
-Key features:
-
-Each MCP Server includes API endpoints for HTTP and SSE, along with IDE configuration snippets for tools like Cursor and Windsurf.
-
-## Next steps
-
-- [Understanding Tracing and Logs](/docs/mastra-cloud/observability)

package/.docs/raw/mastra-cloud/observability.mdx

@@ -1,52 +0,0 @@
----
-title: Observability in Mastra Cloud
-description: Monitoring and debugging tools for Mastra Cloud deployments
----
-
-import { MastraCloudCallout } from '@/components/mastra-cloud-callout'
-
-# Understanding Tracing and Logs
-
-Mastra Cloud captures execution data to help you monitor your application's behavior in the production environment.
-
-<MastraCloudCallout />
-
-## Logs
-
-You can view detailed logs for debugging and monitoring your application's behavior on the [Logs](/docs/mastra-cloud/dashboard#logs) page of the Dashboard.
-
-![Dashboard logs](/image/mastra-cloud/mastra-cloud-dashboard-logs.jpg)
-
-Key features:
-
-Each log entry includes its severity level and a detailed message showing agent, workflow, or storage activity.
-
-## Traces
-
-More detailed traces are available for both agents and workflows by using a [logger](/docs/observability/logging) or enabling [telemetry](/docs/observability/tracing) using one of our [supported providers](/reference/observability/providers).
-
-### Agents
-
-With a [logger](/docs/observability/logging) enabled, you can view detailed outputs from your agents in the **Traces** section of the Agents Playground.
-
-![observability agents](/image/mastra-cloud/mastra-cloud-observability-agents.jpg)
-
-Key features:
-
-Tools passed to the agent during generation are standardized using `convertTools`. This includes retrieving client-side tools, memory tools, and tools exposed from workflows.
-
-
-### Workflows
-
-With a [logger](/docs/observability/logging) enabled, you can view detailed outputs from your workflows in the **Traces** section of the Workflows Playground.
-
-![observability workflows](/image/mastra-cloud/mastra-cloud-observability-workflows.jpg)
-
-Key features:
-
-Workflows are created using `createWorkflow`, which sets up steps, metadata, and tools. You can run them with `runWorkflow` by passing input and options.
-
-## Next steps
-
-- [Logging](/docs/observability/logging)
-- [Tracing](/docs/observability/tracing)

package/.docs/raw/mastra-cloud/overview.mdx

@@ -1,71 +0,0 @@
----
-title: Mastra Cloud
-description: Deployment and monitoring service for Mastra applications
----
-
-import { MastraCloudCallout } from '@/components/mastra-cloud-callout'
-import { FileTree } from "nextra/components";
-
-# Mastra Cloud
-
-[Mastra Cloud](https://mastra.ai/cloud) is a platform for deploying, managing, monitoring, and debugging Mastra applications. When you [deploy](/docs/mastra-cloud/setting-up) your application, Mastra Cloud exposes your agents, tools, and workflows as REST API endpoints.
-
-<MastraCloudCallout />
-
-## Platform features
-
-Deploy and manage your applications with automated builds, organized projects, and no additional configuration.
-
-![Platform features](/image/mastra-cloud/mastra-cloud-platform-features.jpg)
-
-Key features:
-
-Mastra Cloud supports zero-config deployment, continuous integration with GitHub, and atomic deployments that package agents, tools, and workflows together.
-
-## Project Dashboard
-
-Monitor and debug your applications with detailed output logs, deployment state, and interactive tools.
-
-![Project dashboard](/image/mastra-cloud/mastra-cloud-project-dashboard.jpg)
-
-Key features:
-
-The Project Dashboard gives you an overview of your application's status and deployments, with access to logs and a built-in playground for testing agents and workflows.
-
-## Project structure
-
-Use a standard Mastra project structure for proper detection and deployment.
-
-<FileTree>
-  <FileTree.Folder name="src" defaultOpen>
-    <FileTree.Folder name="mastra" defaultOpen>
-      <FileTree.Folder name="agents" defaultOpen>
-        <FileTree.File name="agent-name.ts" />
-      </FileTree.Folder>
-      <FileTree.Folder name="tools" defaultOpen>
-        <FileTree.File name="tool-name.ts" />
-      </FileTree.Folder>
-      <FileTree.Folder name="workflows" defaultOpen>
-        <FileTree.File name="workflow-name.ts" />
-      </FileTree.Folder>
-      <FileTree.File name="index.ts" />
-    </FileTree.Folder>
-  </FileTree.Folder>
-  <FileTree.File name="package.json" />
-</FileTree>
-
-Mastra Cloud scans your repository for:
-
-- **Agents**: Defined using: `new Agent({...})`
-- **Tools**: Defined using: `createTool({...})`
-- **Workflows**: Defined using: `createWorkflow({...})`
-- **Steps**: Defined using: `createStep({...})`
-- **Environment Variables**: API keys and configuration variables
-
-## Technical implementation
-
-Mastra Cloud is purpose-built for Mastra agents, tools, and workflows. It handles long-running requests, records detailed traces for every execution, and includes built-in support for evals.
-
-## Next steps
-
-- [Setting Up and Deploying](/docs/mastra-cloud/setting-up)

package/.docs/raw/mastra-cloud/setting-up.mdx

@@ -1,92 +0,0 @@
----
-title: Setting Up a Project
-description: Configuration steps for Mastra Cloud projects
----
-
-import { MastraCloudCallout } from '@/components/mastra-cloud-callout'
-import { Steps } from "nextra/components";
-
-# Setting Up and Deploying
-
-This page explains how to set up a project on [Mastra Cloud](https://mastra.ai/cloud) with automatic deployments using our GitHub integration.
-
-<MastraCloudCallout />
-
-## Prerequisites
-
-- A [Mastra Cloud](https://mastra.ai/cloud) account
-- A GitHub account / repository containing a Mastra application
-
-> See our [Getting started](/docs/getting-started/installation) guide to scaffold out a new Mastra project with sensible defaults.
-
-## Setup and Deploy process
-
-<Steps>
-
-### Sign in to Mastra Cloud
-
-Head over to [https://cloud.mastra.ai/](https://cloud.mastra.ai) and sign in with either:
-
-- **GitHub**
-- **Google**
-
-### Install the Mastra GitHub app
-
-When prompted, install the Mastra GitHub app.
-
-![Install GitHub](/image/mastra-cloud/mastra-cloud-install-github.jpg)
-
-### Create a new project
-
-Click the **Create new project** button to create a new project.
-
-![Create new project](/image/mastra-cloud/mastra-cloud-create-new-project.jpg)
-
-### Import a Git repository
-
-Search for a repository, then click **Import**.
-
-![Import Git repository](/image/mastra-cloud/mastra-cloud-import-git-repository.jpg)
-
-### Configure the deployment
-
-Mastra Cloud automatically detects the right build settings, but you can customize them using the options described below.
-
-![Deployment details](/image/mastra-cloud/mastra-cloud-deployment-details.jpg)
-
-- **Importing from GitHub**: The GitHub repository name
-- **Project name**: Customize the project name
-- **Branch**: The branch to deploy from
-- **Project root**: The root directory of your project
-- **Mastra directory**: Where Mastra files are located
-- **Environment variables**: Add environment variables used by the application
-- **Build and Store settings**:
-   - **Install command**: Runs pre-build to install project dependencies
-   - **Project setup command**: Runs pre-build to prepare any external dependencies
-   - **Port**: The network port the server will use
-   - **Store settings**: Use Mastra Cloud's built-in [LibSQLStore](/docs/storage/overview) storage
-- **Deploy Project**: Starts the deployment process
-
-### Deploy project
-
-Click **Deploy Project** to create and deploy your application using the configuration you’ve set.
-
-</Steps>
-
-## Successful deployment
-
-After a successful deployment you'll be shown the **Overview** screen where you can view your project's status, domains, latest deployments and connected agents and workflows.
-
-![Successful deployment](/image/mastra-cloud/mastra-cloud-successful-deployment.jpg)
-
-## Continuous integration
-
-Your project is now configured with automatic deployments which occur whenever you push to the configured branch of your GitHub repository.
-
-## Testing your application
-
-After a successful deployment you can test your agents and workflows from the [Playground](/docs/mastra-cloud/dashboard#playground) in Mastra Cloud, or interact with them using our [Client SDK](/docs/client-js/overview).
-
-## Next steps
-
-- [Navigating the Dashboard](/docs/mastra-cloud/dashboard)

package/.docs/raw/memory/conversation-history.mdx

@@ -1,23 +0,0 @@
----
-title: "Conversation History | Memory | Mastra Docs"
-description: "Learn how to configure conversation history in Mastra to store recent messages from the current conversation."
----
-
-# Conversation History
-
-Conversation history is the simplest kind of memory. It is a list of messages from the current conversation.
-
-By default, each request includes the last 10 messages from the current memory thread, giving the agent short-term conversational context. This limit can be increased using the `lastMessages` parameter.
-
-You can increase this limit by passing the `lastMessages` parameter to the `Memory` instance.
-
-```typescript {3-7} showLineNumbers
-export const testAgent = new Agent({
-  // ...
-  memory: new Memory({
-    options: {
-      lastMessages: 20
-    },
-  })
-});
-```

package/.docs/raw/memory/memory-processors.mdx

@@ -1,136 +0,0 @@
----
-title: "Memory Processors | Memory | Mastra Docs"
-description: "Learn how to use memory processors in Mastra to filter, trim, and transform messages before they're sent to the language model to manage context window limits."
----
-
-# Memory Processors
-
-Memory Processors allow you to modify the list of messages retrieved from memory _before_ they are added to the agent's context window and sent to the LLM. This is useful for managing context size, filtering content, and optimizing performance.
-
-Processors operate on the messages retrieved based on your memory configuration (e.g., `lastMessages`, `semanticRecall`). They do **not** affect the new incoming user message.
-
-## Built-in Processors
-
-Mastra provides built-in processors:
-
-### `TokenLimiter`
-
-This processor is used to prevent errors caused by exceeding the LLM's context window limit. It counts the tokens in the retrieved memory messages and removes the oldest messages until the total count is below the specified `limit`.
-
-```typescript copy showLineNumbers {9-12}
-import { Memory } from "@mastra/memory";
-import { TokenLimiter } from "@mastra/memory/processors";
-import { Agent } from "@mastra/core/agent";
-import { openai } from "@ai-sdk/openai";
-
-const agent = new Agent({
-  model: openai("gpt-4o"),
-  memory: new Memory({
-    processors: [
-      // Ensure the total tokens from memory don't exceed ~127k
-      new TokenLimiter(127000),
-    ],
-  }),
-});
-```
-
-The `TokenLimiter` uses the `o200k_base` encoding by default (suitable for GPT-4o). You can specify other encodings if needed for different models:
-
-```typescript copy showLineNumbers {6-9}
-// Import the encoding you need (e.g., for older OpenAI models)
-import cl100k_base from "js-tiktoken/ranks/cl100k_base";
-
-const memoryForOlderModel = new Memory({
-  processors: [
-    new TokenLimiter({
-      limit: 16000, // Example limit for a 16k context model
-      encoding: cl100k_base,
-    }),
-  ],
-});
-```
-
-See the [OpenAI cookbook](https://cookbook.openai.com/examples/how_to_count_tokens_with_tiktoken#encodings) or [`js-tiktoken` repo](https://github.com/dqbd/tiktoken) for more on encodings.
-
-### `ToolCallFilter`
-
-This processor removes tool calls from the memory messages sent to the LLM. It saves tokens by excluding potentially verbose tool interactions from the context, which is useful if the details aren't needed for future interactions. It's also useful if you always want your agent to call a specific tool again and not rely on previous tool results in memory.
-
-```typescript copy showLineNumbers {5-14}
-import { Memory } from "@mastra/memory";
-import { ToolCallFilter, TokenLimiter } from "@mastra/memory/processors";
-
-const memoryFilteringTools = new Memory({
-  processors: [
-    // Example 1: Remove all tool calls/results
-    new ToolCallFilter(),
-
-    // Example 2: Remove only noisy image generation tool calls/results
-    new ToolCallFilter({ exclude: ["generateImageTool"] }),
-
-    // Always place TokenLimiter last
-    new TokenLimiter(127000),
-  ],
-});
-```
-
-## Applying Multiple Processors
-
-You can chain multiple processors. They execute in the order they appear in the `processors` array. The output of one processor becomes the input for the next.
-
-**Order matters!** It's generally best practice to place `TokenLimiter` **last** in the chain. This ensures it operates on the final set of messages after other filtering has occurred, providing the most accurate token limit enforcement.
-
-```typescript copy showLineNumbers {7-14}
-import { Memory } from "@mastra/memory";
-import { ToolCallFilter, TokenLimiter } from "@mastra/memory/processors";
-// Assume a hypothetical 'PIIFilter' custom processor exists
-// import { PIIFilter } from './custom-processors';
-
-const memoryWithMultipleProcessors = new Memory({
-  processors: [
-    // 1. Filter specific tool calls first
-    new ToolCallFilter({ exclude: ["verboseDebugTool"] }),
-    // 2. Apply custom filtering (e.g., remove hypothetical PII - use with caution)
-    // new PIIFilter(),
-    // 3. Apply token limiting as the final step
-    new TokenLimiter(127000),
-  ],
-});
-```
-
-## Creating Custom Processors
-
-You can create custom logic by extending the base `MemoryProcessor` class.
-
-```typescript copy showLineNumbers {5-20,24-27}
-import { Memory } from "@mastra/memory";
-import { CoreMessage, MemoryProcessorOpts } from "@mastra/core";
-import { MemoryProcessor } from "@mastra/core/memory";
-
-class ConversationOnlyFilter extends MemoryProcessor {
-  constructor() {
-    // Provide a name for easier debugging if needed
-    super({ name: "ConversationOnlyFilter" });
-  }
-
-  process(
-    messages: CoreMessage[],
-    _opts: MemoryProcessorOpts = {}, // Options passed during memory retrieval, rarely needed here
-  ): CoreMessage[] {
-    // Filter messages based on role
-    return messages.filter(
-      (msg) => msg.role === "user" || msg.role === "assistant",
-    );
-  }
-}
-
-// Use the custom processor
-const memoryWithCustomFilter = new Memory({
-  processors: [
-    new ConversationOnlyFilter(),
-    new TokenLimiter(127000), // Still apply token limiting
-  ],
-});
-```
-
-When creating custom processors avoid mutating the input `messages` array or its objects directly.

package/.docs/raw/memory/overview.mdx

@@ -1,119 +0,0 @@
----
-title: "Memory Overview | Memory | Mastra Docs"
-description: "Learn how Mastra's memory system works with working memory, conversation history, and semantic recall."
----
-
-import { Steps } from "nextra/components";
-
-# Memory overview
-
-Memory in Mastra helps agents manage context across conversations by condensing relevant information into the language model's context window.
-
-Mastra supports three types of memory: working memory, conversation history, and semantic recall. It uses a two-tier scoping system where memory can be isolated per conversation thread (thread-scoped) or shared across all conversations for the same user (resource-scoped).
-
-Mastra's memory system uses [storage providers](#memory-storage-adapters) to persist conversation threads, messages, and working memory across application restarts.
-
-## Getting started
-
-First install the required dependencies:
-
-```bash copy
-npm install @mastra/core @mastra/memory @mastra/libsql
-```
-
-Then add a storage adapter to the main Mastra instance. Any agent with memory enabled will use this shared storage to store and recall interactions.
-
-```typescript {6-8} filename="src/mastra/index.ts" showLineNumbers copy
-import { Mastra } from "@mastra/core/mastra";
-import { LibSQLStore } from "@mastra/libsql";
-
-export const mastra = new Mastra({
-  // ...
-  storage: new LibSQLStore({
-    url: ":memory:"
-  })
-});
-```
-
-Now, enable memory by passing a `Memory` instance to the agent's `memory` parameter:
-
-```typescript {3-5} filename="src/mastra/agents/test-agent.ts" showLineNumbers copy
-import { Memory } from "@mastra/memory";
-import { Agent } from "@mastra/core/agent";
-
-export const testAgent = new Agent({
-  // ...
-  memory: new Memory()
-});
-```
-
-That memory instance has options you can configure for working memory, conversation history, and semantic recall.
-
-## Different types of memory
-
-Mastra supports three types of memory: working memory, conversation history, and semantic recall. 
-
-[**Working memory**](./working-memory.mdx) stores persistent user-specific details such as names, preferences, goals, and other structured data. (Compare this to ChatGPT where you can ask it to tell you about yourself). This is implemented as a block of Markdown text that the agent is able to update over time (or alternately, as a Zod schema)
-
-[**Conversation history**](./conversation-history.mdx) captures recent messages from the current conversation, providing short-term continuity and maintaining dialogue flow.
-
-[**Semantic recall**](./semantic-recall.mdx) retrieves older messages from past conversations based on semantic relevance. Matches are retrieved using vector search and can include surrounding context for better comprehension.
-
-Mastra combines all memory types into a single context window. If the total exceeds the model’s token limit, use [memory processors](./memory-processors.mdx) to trim or filter messages before sending them to the model.
-
-## Scoping memory with threads and resources
-
-All memory types are [thread-scoped](./working-memory.mdx#thread-scoped-memory-default) by default, meaning they apply only to a single conversation. [Resource-scoped](./working-memory.mdx#resource-scoped-memory) configuration allows working memory and semantic recall to persist across all threads that use the same user or entity.
-
-## Memory Storage Adapters
-
-To persist and recall information between conversations, memory requires a storage adapter.
-
-Supported options include [LibSQL](/examples/memory/memory-with-libsql), [Postgres](/examples/memory/memory-with-pg), and [Upstash](/examples/memory/memory-with-upstash)
-
-We use LibSQL out of the box because it is file-based or in-memory, so it is easy to install and works well with the playground.
-
-## Dedicated storage
-
-Agents can be configured with their own dedicated storage, keeping tasks, conversations, and recalled information separate across agents.
-
-### Adding storage to agents
-
-To assign dedicated storage to an agent, install and import the required dependency and pass a `storage` instance to the `Memory` constructor:
-
-```typescript {3, 9-11} filename="src/mastra/agents/test-agent.ts" showLineNumbers copy
-import { Memory } from "@mastra/memory";
-import { Agent } from "@mastra/core/agent";
-import { LibSQLStore } from "@mastra/libsql";
-
-export const testAgent = new Agent({
-  // ...
-  memory: new Memory({
-    // ...
-    storage: new LibSQLStore({
-      url: "file:agent-memory.db"
-    })
-  // ...
-  })
-});
-```
-
-## Viewing retrieved messages
-
-If tracing is enabled in your Mastra deployment and memory is configured either with `lastMessages` and/or `semanticRecall`, the agent’s trace output will show all messages retrieved for context—including both recent conversation history and messages recalled via semantic recall.
-
-This is helpful for debugging, understanding agent decisions, and verifying that the agent is retrieving the right information for each request.
-
-For more details on enabling and configuring tracing, see [Tracing](../observability/tracing).
-
-## Local development with LibSQL
-
-For local development with `LibSQLStore`, you can inspect stored memory using the [SQLite Viewer](https://marketplace.visualstudio.com/items?itemName=qwtel.sqlite-viewer) extension in VS Code.
-
-![SQLite Viewer](/image/memory/memory-sqlite-viewer.jpg)
-
-## Next Steps
-
-Now that you understand the core concepts, continue to [semantic recall](./semantic-recall.mdx) to learn how to add RAG memory to your Mastra agents.
-
-Alternatively you can visit the [configuration reference](../../reference/memory/Memory.mdx) for available options.