Mastra im Test: TypeScript-Agenten mit echter Evaluationsschleife

Mastra ist ein TypeScript-Framework für LLM-Agenten und eines der vollständigsten: Agenten, Workflow-Engine, Memory, MCP-Server-Autorisierung, Guardrails, Tracing, Evals und eine gehostete Plattform in einem Repository. Die Position hier ist eindeutig. Mastra ist der am besten unterstützte Weg, einen Agenten in eine bestehende Node- oder Next.js-Codebasis zu bringen, und die falsche Wahl für ein Python-Team oder für eine Gruppe, die nur den Tool-Calling-Loop braucht.

Es liegt über der Modellschicht und unterhalb der Anwendung: Modelle gehen als provider/model-Strings hinein, und das Framework übernimmt den Agenten-Loop, den Workflow-Graphen, den Thread-Zustand und die Traces. Die direkten Wettbewerber sind LangGraph.js, das Vercel AI SDK, das OpenAI Agents SDK und neuere Einträge wie VoltAgent. Der Unterschied liegt nicht im Loop, der ist Commodity, sondern darin, wie viel der umgebenden Laufzeitumgebung jedes Framework bereit ist zu übernehmen.

Was Mastra tatsächlich ist

Mastra ist ein Monorepo aus gescopeten npm-Paketen, nicht eine einzelne Bibliothek. Der Kern ist @mastra/core, alles andere hängt daran: @mastra/memory, @mastra/libsql, @mastra/pg, @mastra/observability, @mastra/evals, @mastra/mcp und der Rest. Die Mastra-Klasse in src/mastra/index.ts ist das Registry-Objekt, das Agenten, Workflows, Storage, Logging und Observability verdrahtet, und aus ihr bezieht jeder andere Teil des Frameworks seine Dienste.

• Lizenz: Apache-2.0 für alles außerhalb der ee/-Verzeichnisse, darin quelloffen unter der Mastra Enterprise Edition License.
• Reife: @mastra/core stand am 7. Oktober 2026 bei 1.75.0; das Repository zeigt 28,6k Sterne und 2,9k Forks, die erste Version erschien im Oktober 2024.
• Verbreitung: 2,23 Millionen npm-Downloads für @mastra/core in der Woche bis 4. Oktober 2026, gegenüber 4,55 Millionen für @langchain/langgraph und 34,5 Millionen für das ai-Paket von Vercel.
• Release-Tempo: 99 Releases von @mastra/core in den 30 Tagen bis 7. Oktober 2026 und 301 in 90 Tagen, von insgesamt 1.656 seit Oktober 2024.
• Laufzeit: Node 22.18 oder neuer, mit einem Hono-basierten Server, Deployern für Vercel, Netlify und Cloudflare oder jedem eigenen HTTP-Host.
• Modellzugriff: ein Model Router, der einen provider/model-String auflöst, 213 Anbieter und 7.790 Modelle listet, Fallback-Ketten pro Modell unterstützt und den Anbieterschlüssel aus der Umgebung liest.
• Typen: Zod, Valibot oder ArkType über Standard JSON Schema für Tools, Workflow-Schritte und strukturierte Ausgabe.

Wie es funktioniert

Zwei Primitive tragen die meiste Last. Ein Agent bindet Modell, Instruktionen und Tools und iteriert, bis das Modell eine endgültige Antwort oder eine Stop-Bedingung liefert. Ein Workflow aus createStep und createWorkflow mit .then(), .branch(), .parallel() und .commit() ist der deterministische Pfad für Prozesse mit bekannter Reihenfolge. Die Dokumentation ist eindeutig: Für eine definierte Pipeline ist der zweite Weg richtig, für offene Aufgaben der erste, was der Aufteilung in den erklären Agent Loop entspricht.

Um diese beiden Primitive herum liegen die Teile, die einen Agenten produktionsfähig halten. Memory zerfällt in Nachrichtenhistorie, Working Memory, semantische Erinnerung und Observational Memory, bei der Hintergrund-Agenten ältere Turns zu Beobachtungen komprimieren, bevor das Kontextfenster voll ist. Storage ist austauschbar über LibSQL, Postgres, ClickHouse, MongoDB, MSSQL und DuckDB, und dieselbe Engine trägt Suspend und Resume bei Workflows. Ein Workflow kann damit auf eine menschliche Freigabe warten und Stunden später weiterlaufen, wie in Human-in-the-the-loop-Mustern beschrieben.

MCP-Unterstützung ist das Unterscheidungsmerkmal

Mastra ist eines der wenigen Frameworks, die MCP sowohl konsumieren als auch bereitstellen. MCPClient verbindet sich mit Servern über stdio oder Streamable HTTP, MCPServer stellt Mastra-Agenten, Tools, Workflows, Prompts und Ressourcen anderen Systemen zur Verfügung. Registrierte Server laufen unter /api/mcp/:serverId/mcp und sprechen die Revision 2026-07-28 des Protokolls, sodass ein Team mit internen Tools hinter einem MCP-Server den Agenten anschließen kann, ohne eine Integrationsschicht zu bauen.

import { Agent } from '@mastra/core/agent'
import { Mastra } from '@mastra/core/mastra'
import { MCPServer, MCPClient } from '@mastra/mcp'

// Expose Mastra primitives to other agents and systems
const mcpServer = new MCPServer({
  id: 'support-mcp',
  name: 'Support tools',
  version: '1.0.0',
  agents: { supportAgent },
  tools: { refundTool },
  workflows: { triage },
})

// Consume remote MCP tools, gating the destructive ones
const client = new MCPClient({
  servers: {
    jira: {
      url: new URL('https://jira.example.com/mcp'),
      requireToolApproval: ({ toolName }) => toolName.startsWith('delete_'),
    },
  },
})

const assistant = new Agent({
  id: 'assistant',
  name: 'Assistant',
  instructions: 'Answer from the available tools and cite the source.',
  model: 'anthropic/claude-sonnet-4-6',
  tools: await client.listTools(),
})

export const mastra = new Mastra({
  agents: { assistant },
  mcpServers: { mcpServer },
})

Die Sicherheitsdefaults sind besser als der Durchschnitt. requireToolApproval sperrt Tools nach Name oder Argumenten, stdio-Subprozesse erben nur eine kuratierte Umgebungsliste, sofern nicht inheritDefaultEnv gesetzt ist, allowedHosts begrenzt ausgehende HTTP-Hosts, und die Doku rät, Annotations von Servern, die man nicht kontrolliert, als nicht vertrauenswürdige Hinweise zu behandeln. Tool-Ergebnisse bleiben unvertrauenswürdige Modelleingaben, weshalb die Guardrail-Prozessoren und nicht die MCP-Schicht diesen Inhalt bereinigen müssen, wie in den Injektionsmustern.

Erste Schritte

npm create mastra@latest erzeugt ein Projekt mit dem src/mastra-Layout, einem Dev-Server, Studio und einem Deployer. Die kleinste nützliche Oberfläche ist klein: ein Tool, ein Agent, eine Registry.

// src/mastra/tools/stock-price.ts
import { createTool } from '@mastra/core/tools'
import { z } from 'zod'

export const stockPrice = createTool({
  id: 'stock-price',
  description: 'Latest price for a ticker symbol',
  inputSchema: z.object({ symbol: z.string().describe('Ticker, for example INGY') }),
  outputSchema: z.object({ symbol: z.string(), price: z.number() }),
  execute: async ({ symbol }) => ({ symbol, price: await quote(symbol) }),
})

// src/mastra/index.ts
import { Mastra } from '@mastra/core'
import { Agent } from '@mastra/core/agent'
import { LibSQLStore } from '@mastra/libsql'
import { stockPrice } from './tools/stock-price'

export const agent = new Agent({
  id: 'research',
  name: 'Research agent',
  instructions: 'Look prices up with the tool. Never guess a number.',
  model: 'anthropic/claude-sonnet-4-6',
  tools: { stockPrice },
})

export const mastra = new Mastra({
  agents: { agent },
  storage: new LibSQLStore({ id: 'mastra', url: 'file:./mastra.db' }),
})

// run.ts - Node 22.18 and later run TypeScript directly
const answer = await mastra.getAgentById('research').generate('INGY price')
console.log(answer.text, answer.usage)

Zwei Details überraschen Neulinge. Agenten besser über mastra.getAgentById() auflösen statt direkt zu importieren, denn ein direkter Import läuft zwar, verfehlt aber Storage, Logger und Telemetrie der Instanz, und solche Läufe fehlen in den Traces. Und der Modell-String ist das Router-Format provider/model, gelesen aus einer Umgebungsvariablen wie ANTHROPIC_API_KEY, und kein Provider-Objekt.

Observability und Evals sind das eigentliche Produkt

Hier liegt der Teil, der das Framework begründet und nicht der Agenten-Loop. Jeder Agentenlauf, jeder Workflow-Schritt, jeder Tool- und Modellaufruf erzeugt einen Span, und Exporter schreiben diese Spans in den Mastra-Storage oder in jedes OpenTelemetry-kompatible Backend, mit benannten Integrationen für Langfuse, Arize Phoenix und Datadog. Metriken werden ohne zusätzliche Instrumentierung aus den Spans abgeleitet, und Studio ergänzt Graphansicht, Time Travel zum erneuten Abspielen eines einzelnen Schritts und einen Experiment-Tab. Teams, die das mit OpenTelemetry-Tracing von Hand gebaut haben, erkennen die Form wieder.

• Tracing und Logging: Spans plus strukturierte Logs, korreliert über Trace- und Span-ID, sodass ein Logeintrag direkt zum Lauf führt, der ihn erzeugt hat.
• Metriken: Tokenzahlen, Latenz und Kostenschätzungen beim Schließen eines Spans; die Aggregation braucht einen analytisch fähigen Store wie DuckDB, ClickHouse oder Postgres.
• Scorer: vorgefertigte und eigene Scorer an einem Agenten oder an einem einzelnen Workflow-Schritt, mit deterministischer Stichprobe pro Trace, damit Scores über Läufe hinweg vergleichbar bleiben.
• Guardrails als Prozessoren: Prompt-Injection-Erkennung, Moderation, PII-Maskierung, System-Prompt-Scrubbing und ein Kostenlimit, jeweils mit block-, redact- oder warn-Strategie.

Eine Kante lohnt sich vor dem ersten CI-Lauf zu kennen. Scorer, die an einem Agenten oder Schritt hängen, registrieren sich selbst; Scorer, die direkt an runEvals() oder die Quick Checks übergeben werden, müssen zusätzlich auf der Mastra-Instanz registriert sein, sonst schlägt jeder Speichervorgang mit Scorer with id <id> not found fehl und die Scores erreichen den Store nie. Die Doku räumt ein, dass die Ergebnisse identisch sind, und genau das macht den Fehler irritierend.

Preise und die Lizenzteilung

Das Framework ist kostenlos, und an der gehosteten Plattform verdient der Anbieter sein Geld. Die Preisseite nennt drei Stufen, und der Zähler ist der interessante Teil: Observability-Events, CPU-Stunden, Datenausgang und ein Model Gateway, das 5,5 Prozent auf die Marktpreise der Token legt.

Zwei Posten verdienen Aufmerksamkeit. Eine dauerhaft laufende Instanz kostet 100 USD pro Projekt zusätzlich zur Stufe, und das Gateway berechnet Markpreis plus 5,5 Prozent auf Input- und Output-Token mit eigenem Schlüssel. Memory wird noch einmal abgerechnet, mit 10 USD pro Million Token über den ersten 100.000 beziehungsweise 1 Mio. hinaus, sodass ein gesprächiger Agent mit langem Kontext in drei Zählern auftaucht.

Wo es hakt

Die Schwächen zuerst. Das Release-Tempo ist das operative: 301 Releases in 90 Tagen bedeuten, dass sich die API des Frameworks unter einem verschiebt und das Lesen der Release Notes zur Arbeit gehört. Zweitens ist die Breite zweischneidig. Das Repository liefert Harness, Workspaces, Channels, Voice, Browser-Steuerung, Code Mode und Agent Factories mit, ein kleines Team zahlt also an Review-Fläche für Funktionen, die es nicht nutzt. Drittens ist Observational Memory nicht kostenlos, weil Hintergrund-Agenten die Historie auf jedem Turn komprimieren. Viertens sind gerade die Studio-Extras, Time Travel, Experimente und der Evaluate-Tab, der Grund, auf der bezahlten Stufe zu bleiben, und die fehlen, wenn die Traces an Langfuse gehen und alles andere selbst betrieben wird.

Gegenüber dem OpenAI Agents SDK, das schlanker ist, unter MIT steht und nah an der Responses API bleibt, ist Mastra die portablere und zugleich schwerere Option. Die ehrliche Zusammenfassung: Mastra kauft Breite und eine echte Evaluationsschleife und zahlt dafür mit der Zahl der Abhängigkeiten, denn @mastra/core allein zieht 30 direkte Abhängigkeiten, und mit dem Tempo, in dem sich diese Abhängigkeit ändert.

Fazit

Mastra ist ein gut geführtes, ungewöhnlich vollständiges Framework mit einem klaren Schwerpunkt: Die Schleife zwischen Code, Traces und Evals ist besser als alles, was ein TypeScript-Team sonst zusammensetzen müsste. Der Haken ist, dass es ein bewegliches Ziel mit kommerzieller Schicht ist, und ausgerechnet die beiden Punkte, die Käufer am meisten interessieren, stabile APIs und eine unveränderte Lizenz, sind die schwächsten.

1. Nehmen, wenn der Agent in einer bestehenden Node- oder Next.js-Anwendung ausgeliefert wird und das Team Tracing, Evals und eine Workflow-Engine will, ohne sechs Pakete zusammenzusetzen.
2. Nehmen, wenn menschliche Freigabe, lange unterbrochene Workflows und MCP-Toolserver Anforderungen sind und keine Kür.
3. Nehmen mit gepinnten Versionen und einer Eval-Suite in der CI, weil sonst das Release-Takt den Upgrade-Plan bestimmt.
4. Weglassen, wenn der Modellanbieter feststeht und die Oberfläche ein einzelner Chat-Endpunkt ist: Das Vercel AI SDK oder das OpenAI Agents SDK ist leichter zu durchdenken.
5. Weglassen, wenn der Stack Python ist oder wenn die ee/-Grenze durch etwas läuft, wovon das Produkt abhängt.

Quellen

1. Mastra documentation: agents
2. Mastra documentation: workflows
3. Mastra documentation: memory
4. Mastra documentation: MCP
5. Mastra documentation: guardrails
6. Mastra documentation: evals
7. Mastra documentation: observability
8. Mastra documentation: model providers
9. Mastra pricing
10. mastra-ai/mastra on GitHub
11. Mastra Enterprise Edition License v2.0