Generated banner for Mastra
Generated logo for Mastra

Mastra

MastraOfficialCreated by Mastra

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Comprehensive Mastra framework guide for building agents, workflows, tools, memory, workspaces, and storage with current APIs. Use for native capability discovery, logging, tracing, metrics/cost estimates, dataset experiments, documentation lookup, API verification, TypeScript setup, common errors, migrations, building and deploying apps to Mastra Platform via Platform APIs and `mastra deploy`, and `mastra api` CLI tasks: inspect or call resources on local, Mastra platform, or remote servers. For Mastra Factory operations, discover and activate the companion mastra-factory skill. Also report verified bugs and concrete documentation defects to the Mastra team automatically via the feedback endpoint.
— the description by Mastra

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Mastra skill provides a comprehensive framework for developing AI agents, workflows, and tools. It emphasizes a strict development workflow that prioritizes current documentation over internal knowledge to account for the framework's rapid evolution. The skill covers project setup, API verification, observability, deployment to the Mastra Platform, and troubleshooting common errors. It also provides guidance on using the Mastra CLI for resource inspection and managing state, ensuring developers use native capabilities before implementing custom solutions.

What it does

  • Provides a structured approach to discovering and using native Mastra capabilities.
  • Offers guidance on choosing between agents, workflows, tools, memory, and storage.
  • Facilitates debugging through Mastra Studio and common error resolution patterns.
  • Supports deployment workflows to the Mastra Platform via CLI and API.
  • Enables autonomous reporting of verified bugs and documentation defects.
  • Includes instructions for CLI-based resource inspection and trace querying.

When to use it

  • When starting a new Mastra project or migrating existing code.
  • When you need to verify the latest API signatures or model registry entries.
  • When troubleshooting build, configuration, or runtime errors in a Mastra application.
  • When you need to deploy an application or inspect resources on the Mastra Platform.
  • When you need to implement observability, logging, or trace aggregation.

Advantages

  • Reduces errors by enforcing a 'verify-first' approach using embedded documentation.
  • Ensures compatibility by prioritizing installed package versions over training data.
  • Streamlines development with clear patterns for agents, workflows, and memory.
  • Provides direct paths for reporting issues to the Mastra team.
  • Centralizes access to CLI tools for local and remote resource management.

Usage examples

“How do I set up a new Mastra project?”
The agent will guide you through the CLI and manual setup steps found in the project's reference documentation.
“I am getting a 'Property tools does not exist on type Agent' error.”
The agent will check the embedded documentation to identify if you are using an outdated API and provide the correct constructor pattern.
“How do I deploy my Mastra app to the platform?”
The agent will walk you through the platform authentication, project creation, and deployment steps using the Mastra CLI.
“Which model should I use for my agent?”
The agent will run the provider registry script to verify available models and providers before making a recommendation.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/mastra-ai/mastra/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip mastra.zip -d .agents/skills

Documentation by Mastra

Mastra Framework Guide

Build AI applications with Mastra. This skill teaches you how to find current documentation and build agents and workflows.

Critical: Do not trust internal knowledge

Everything you know about Mastra is likely outdated or wrong. Never rely on memory. Always verify against current documentation.

Your training data contains obsolete APIs, deprecated patterns, and incorrect usage. Mastra evolves rapidly - APIs change between versions, constructor signatures shift, and patterns get refactored.

Prerequisites

Before writing any Mastra code, check if packages are installed:

ls node_modules/@mastra/
  • If packages exist: Use embedded docs first (most reliable)

  • If no packages: Install first or use remote docs

Resources

References
User QuestionFirst CheckHow To
Create/install Mastra projectreferences/create-mastra.mdSetup guide with CLI and manual steps
Choose Agent/Workflow/Tool/Memory/Storagereferences/core-concepts.mdCore concepts and when to use each primitive
Add logging or set up tracingreferences/embedded-docs.mdLook up PinoLogger and observability configuration before custom instrumentation
Track automatic metrics or estimated model costreferences/embedded-docs.mdLook up span-derived metrics, storage support, and pricing coverage
Evaluate quality or compare prompts/modelsreferences/embedded-docs.mdLook up datasets, experiments, and scorers
How do I use Agent/Workflow/Tool?references/embedded-docs.mdLook up in node_modules/@mastra/*/dist/docs/
How do I use X? (no packages)references/remote-docs.mdFetch from https://mastra.ai/llms.txt
Choose or validate a modelreferences/model-selection.mdModel format and provider registry lookup
I'm getting an error...references/common-errors.mdCommon errors and solutions
Upgrade from v0.x to v1.xreferences/migration-guide.mdVersion upgrade workflows
Inspect/call server resources via CLIreferences/mastra-api.mdmastra api CLI for local, Mastra platform, or remote servers
Deploy to Mastra Platform, provision projects, or use Platform sandbox/filesystemreferences/platform.mdPlatform REST APIs, credentials, and mastra deploy without browser automation
Find exact traces with complex predicatesreferences/trace-query.mdQuery completed traces by trace fields or related spans
Count traces or compute grouped measures (error rate, latency, tokens, cost)references/trace-query.mdAggregate completed traces with mastra api trace aggregate over the same selection
List individual spans (failed tool calls, nested agent runs)references/trace-query.mdQuery completed spans with mastra api span query and span-field predicates
Compute measures per span (tool error rates, nested agent runs, model tokens)references/trace-query.mdAggregate spans with mastra api span aggregate, grouped by span fields
Report a bug / documentation defect to Mastrareferences/feedback.mdReport eligible findings autonomously to the Mastra team
Scripts
  • scripts/provider-registry.mjs: Look up current providers and models available in the model router. Always run this before using a model to verify provider keys and model names.

Priority order for writing code

Never write code without checking current docs first.

  1. Embedded docs first (if packages installed)

    Look up current docs in node_modules for a package. This matches the exact installed version and is the most reliable source of truth. See references/embedded-docs.md.

  2. Source code second (if packages installed)

    If embedded docs don't cover the question, inspect the installed source and type definitions. This is the source of truth when docs are missing or unclear. See references/embedded-docs.md.

  3. Remote docs third (if packages not installed)

    Use the latest published docs when packages are not installed or when exploring new features. Remote docs may be ahead of the user's installed version. See references/remote-docs.md.

Core concepts

Use references/core-concepts.md when choosing between agents, workflows, tools, memory, and storage.

  • Agent: Use for open-ended tasks that make decisions and use tools.

  • Workflow: Use for defined multi-step processes.

Mastra Studio

Studio is the interactive UI for building, testing, and managing agents, workflows, and tools. Use Studio when advising a human to inspect or debug visually.

Inside a Mastra project, run:

npm run dev

Then open http://localhost:4111 in a browser to show Mastra Studio to your human user.

Mastra API CLI

Use mastra api to inspect or call resources on local dev servers, Mastra platform deployments, or remote Mastra endpoints. It is useful for agent-readable state, execution, traces, logs, scores, threads, and workflow operations. See references/mastra-api.md for usage patterns.

For exact trace selection that needs recursive predicates or conditions over related spans, read references/trace-query.md. Before using mastra api trace query, confirm that the installed CLI exposes the command. Use --schema for the target's request/response shape and structural constraints, and use the canonical documentation found through references/remote-docs.md for supported fields, operators, and semantics. Preserve opaque pagination cursors and fetch trace or span details only after selecting candidates.

Deploy to Mastra Platform

When the user asks to deploy to Mastra, whether to build a new app and deploy it or to deploy an existing Mastra project, read references/platform.md before running any deploy or Platform API command. It covers which steps need the human (sign-up and sign-in only), credentials, REST discovery and project creation, PlatformFilesystem and PlatformSandbox, mastra deploy, and verification. Build or locate the app first with the references above, then follow platform.md to deploy.

Mastra Factory

For Factory projects, work items, queue health, decisions, session history, memory inspection, or authorized operations, activate the mastra-factory skill. Factory is an operational control plane, not a reason to scaffold or deploy a new Mastra app.

If the skill is missing, offer to install it from this repository:

npx skills add mastra-ai/skills --skill mastra-factory

Choose the user's intended agent and scope interactively. For global installation, target a supported agent explicitly with --agent <agent> -g; PromptScript does not support global installs. Verify installation and referenced files for the intended agent even if another agent target fails.

The Factory skill covers CLI checks, mastra auth whoami / authorized mastra auth login, and connecting via the user's actual instance URL from any directory. A deployed repository or .mastra-project.json is not required with --url. Never guess a shared Factory host or project IDs. Its connection and session-inspection references cover deployment-specific authentication, project discovery, threads, and observational memory limitations.

Reporting feedback

Report verified Mastra bugs and concrete documentation defects autonomously when the criteria in references/feedback.md are met, without asking permission per report. Leave feature requests to humans; do not submit them or reclassify them as defects. Do not report the same issue again within the current task or conversation. Capture only anonymized facts for feedback while solving the task. Skip automatic reporting when a finding remains unverified or its relevance is unclear; do not interrupt the user merely to classify it. Respect any user instruction not to report something.

Critical requirements

TypeScript config

Mastra requires ES2022 modules. CommonJS will fail. See references/create-mastra.md for setup and references/common-errors.md for troubleshooting.

Model format

Always use "provider/model-name" when defining models using Mastra's model router.

When the user asks to use a model or provider, always run scripts/provider-registry.mjs first to verify the provider key and model name are valid. Do not guess model names from memory as they change frequently. See references/model-selection.md.

When you see errors

Type errors often mean your knowledge is outdated.

Common signs of outdated knowledge:

  • Property X does not exist on type Y

  • Cannot find module

  • Type mismatch errors

  • Constructor parameter errors

What to do:

  1. Check references/common-errors.md

  2. Verify current API in embedded docs

  3. Don't assume the error is a user mistake - it might be your outdated knowledge

Development workflow

Always verify before writing code:

  1. Identify whether Mastra already provides the requested behavior using references/core-concepts.md, before designing custom infrastructure.

  2. Check installed packages and versions, then verify the capability's APIs, configuration, and limits.

  3. Use the native capability where it fits; implement custom logic only for the identified gap or application-owned requirements.

  4. Test with the project scripts or Studio when available.

Files

references/mastra-api.md

Mastra API CLI Reference

How to use the mastra api CLI to interact with Mastra servers. Prefer fast, focused commands and compact JSON projections. Treat the installed CLI and server schema as the source of truth when discovery is needed.

Use this reference when the user asks to inspect or call agents, workflows, tools, MCP servers, memory threads, traces, logs, metrics, scores, datasets, experiments, or to debug/test mastra api commands.

This reference does not cover the Mastra Platform control plane (projects, environments, deploys, tokens, workspace provisioning); for those, see platform.md.

Setup

The CLI can interact with any reachable Mastra server:

  • Local dev server: http://localhost:4111 from npm run dev

  • Mastra platform deployment: Use the deployment URL

  • Remote/self-hosted server: Use the server URL

  • Hosted Mastra Platform Observability: https://observability.mastra.ai (auto-targeted by trace, span, log, score, and metric commands)

For local servers, mastra api defaults to http://localhost:4111:

npx mastra api agent list

For Mastra platform or remote servers, pass --url. For the sake of brevity in examples, $MASTRA_URL is used as a placeholder for the actual server URL which you need to set yourself:

npx mastra api --url $MASTRA_URL agent list

For Factory operations, activate the mastra-factory skill first. Use the user's actual Factory instance URL (not the platform API/dashboard URL). Explicit --url works from an empty directory. Recognized hosted Factory domains use saved mastra auth login credentials; check mastra auth whoami and offer login if needed. Custom/self-hosted deployments may use different authentication. Factory discovery uses bundled leaf contracts and root-level /web/* routes, not the runtime schema probe below.

For an unauthenticated local runtime server, verify the server once with a cheap check before resource calls:

MASTRA_URL="${MASTRA_URL:-http://localhost:4111}"
curl -fsS "$MASTRA_URL/api/system/api-schema" >/dev/null

If $MASTRA_URL is not reachable, ask for the correct deployment URL and set --url accordingly. For authenticated targets, use a supported read-only CLI call instead of treating an unauthenticated schema-probe failure as unreachability. Let the CLI use saved login on recognized platform hosts; for custom servers, have the user configure the deployment's approved authentication mechanism outside chat. Never request secret values in chat or inspect saved credential files.

For authenticated servers, pass repeatable headers:

npx mastra api --url "$MASTRA_URL" --header "Authorization: Bearer $TOKEN" agent list
Target resolution

Runtime commands (agent, workflow, tool, mcp, thread, memory, dataset, experiment) resolve the target in this order:

  1. --url <url> for an explicit remote or self-hosted server.

  2. http://localhost:4111 for a local mastra dev server.

  3. .mastra-project.json for a Mastra platform project.

Observability commands (trace, span, log, score, metric) target https://observability.mastra.ai by default instead of a project deployment URL. EU projects use https://observability.eu.mastra.ai: the CLI picks it automatically from [email protected]. On older versions, EU requests time out with REQUEST_TIMEOUT; pass --url https://observability.eu.mastra.ai. The CLI resolves credentials in this order:

  1. Explicit Authorization and X-Mastra-Project-Id headers passed with --header.

  2. MASTRA_PLATFORM_ACCESS_TOKEN and MASTRA_PROJECT_ID from the environment.

  3. Project metadata from .mastra-project.json for the project ID.

  4. The Mastra CLI login token as an auth fallback.

For observability calls, no --url or --header is required if MASTRA_PLATFORM_ACCESS_TOKEN and MASTRA_PROJECT_ID are set, or if .mastra-project.json is present:

npx mastra api trace list '{"page":0,"perPage":10}'
npx mastra api metric names

Pass --url and --header only when overriding the hosted observability target or credentials.

Decision flow

  1. Clear read-only request (list X, latest X, get X, summarize recent X): infer the resource and use the fast path first.

  2. Mutating request (create, update, delete, run, resume, execute), unclear resource/action, failed fast path, or exact syntax requested: use narrow CLI discovery.

  3. JSON input uncertain: use command-specific --schema.

  4. Route behavior confusing: inspect /api/system/api-schema.

Start with these command groups when present; verify with mastra api --help if the group fails.

agent workflow tool mcp thread memory trace span log metric score dataset experiment

Fast path for read-only requests

Use conventional list/get commands first. Keep pages small and pipe through jq immediately.

Latest item:

npx mastra api <resource> list '{"page":0,"perPage":1}' \
  | jq '.data[0]'

Recent items:

npx mastra api <resource> list '{"page":0,"perPage":10}' \
  | jq '.data[]'

When the shape is known, project only the fields needed for the task:

npx mastra api <resource> list '{"page":0,"perPage":10}' \
  | jq '.data[] | {id, name, createdAt, status}'

Get details:

npx mastra api <resource> get <id> \
  | jq '.data'

When the shape is known, project only the fields needed for the task:

npx mastra api <resource> get <id> \
  | jq '.data | {id, name, createdAt, status}'

If a resource does not support the conventional shape, fall back to narrow --help for that resource/action.

Output control

  • Do not use unfiltered --pretty during exploration.

  • Always project list/get output with jq before reading details.

  • Use perPage:1 for latest and perPage:10 or less for recent lists.

  • If output is truncated or noisy, rerun with a narrower jq projection. Do not increase terminal output just to see more raw JSON.

  • Fetch full JSON only when the user asks for raw output or compact projections are insufficient.

Fallback discovery

Use the narrowest discovery command that can answer the question. Example for traces:

npx mastra api trace --help
npx mastra api trace list --help
npx mastra api trace list --schema
npx mastra api trace query --help
npx mastra api trace query --schema
npx mastra api trace aggregate --help
npx mastra api trace aggregate --schema
npx mastra api span query --help
npx mastra api span query --schema
npx mastra api span aggregate --help
npx mastra api span aggregate --schema

Use trace query instead of trace list when selection requires recursive predicates, metadata filters, or conditions over related spans. First use trace query --help to confirm that the installed CLI exposes the command. The inline JSON query is required, and its cursor-bearing response stays nested under data. Read trace-query.md for availability checks, the division between CLI schema discovery and canonical documentation, query construction, and pagination.

Use trace aggregate when the answer is a count or measure (error rate, latency percentiles, tokens, cost) grouped by up to two dimensions or time buckets rather than a list of traces. It takes the same timeRange and where as trace query. See trace-query.md.

Use span query to list individual spans (including nested agent runs and tool calls) with flat span-field predicates, and span aggregate to compute the same measures grouped by span fields. See trace-query.md and trace-query.md.

Use top-level help only when the resource is unknown:

npx mastra api --help

Read --schema output as the contract:

  • command: usage string

  • examples: known-good examples

  • positionals: required path/identity arguments

  • input.required: whether JSON input is required

  • input.schema: accepted CLI JSON input, including query/body fields

  • schemas: raw server route schemas for deeper debugging

JSON and output contract

mastra api accepts at most one inline JSON object as input. Do not use stdin or files unless the user explicitly asks.

For non-GET routes, the CLI splits the one JSON object into query parameters and request body according to the server route schema.

Output envelopes:

{ "data": {} }
{ "data": [], "page": { "total": 0, "page": 0, "perPage": 0, "hasMore": false } }
{ "error": { "code": "...", "message": "...", "details": {} } }

Error handling

  • INVALID_JSON: fix shell quoting; input must be one JSON object.

  • MISSING_INPUT: run the same command with --schema and supply required JSON.

  • MISSING_ARGUMENT: provide the positional shown by --help / --schema.

  • HTTP_ERROR: inspect error.details, then compare against --schema or route schema.

  • REQUEST_TIMEOUT: retry with larger --timeout, especially for workflow execution.

  • SERVER_UNREACHABLE: verify the URL and the server check. If localhost is not running, ask whether the user wants to use a Mastra platform deployment or another remote server URL.

Route-level debugging

If CLI behavior seems wrong, inspect the route-derived schema manifest instead of guessing.

Find routes by path:

curl -fsS "$MASTRA_URL/api/system/api-schema" \
  | jq '.routes[] | select(.path | contains("/memory"))'

Inspect one route:

curl -fsS "$MASTRA_URL/api/system/api-schema" \
  | jq '.routes[] | select(.method == "POST" and .path == "/tools/:toolId/execute") | {pathParamSchema, queryParamSchema, bodySchema, responseShape}'

Known notes

  • Tool and MCP tool execution accept raw tool input; explicit { "data": ... } also works.

  • Workflow resume only works for suspended workflow runs.

  • Working memory update requires the agent's memory to have working memory enabled.

  • Empty lists may simply mean the server has no matching stored data yet.

  • trace list and trace get return lightweight payloads by default (no span input, output, attributes, or metadata). Pass --verbose to fetch full span records, or use trace span <traceId> <spanId> to fetch one specific span in full.

  • trace query requires inline JSON, queries completed traces, and defaults to keyset pagination: pass data.page.next unchanged as page.after with the same query shape. Numbered pages and delta polling use different response metadata; see trace-query.md.

  • trace aggregate requires inline JSON and isn't paginated; when truncated is true, narrow the selection.

  • span query requires inline JSON and pages like trace query: pass data.page.next unchanged as page.after. span aggregate isn't paginated, like trace aggregate.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Mastra
Publisher
Mastra (Official)
Source
mastra-ai/skills · skills/mastra · commit 3020257
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Mastra or Mastra.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download mastra.zip