@mastra/mcp-docs-server 1.1.8 → 1.1.9-alpha.1

package/.docs/docs/observability/tracing/overview.md

@@ -4,7 +4,7 @@ Tracing provides specialized monitoring and debugging for the AI-related operati
 
 Unlike traditional application tracing, Tracing focuses specifically on understanding your AI pipeline — capturing token usage, model parameters, tool execution details, and conversation flows. This makes it easier to debug issues, optimize performance, and understand how your AI systems behave in production.
 
-## How It Works
+## How it works
 
 Traces are created by:
 
@@ -103,7 +103,7 @@ Bridges provide bidirectional integration with external tracing systems. Unlike
 
 You can use both together — a bridge for context propagation and exporters to send traces to additional destinations.
 
-## Sampling Strategies
+## Sampling strategies
 
 Sampling allows you to control which traces are collected, helping you balance between observability needs and resource costs. In production environments with high traffic, collecting every trace can be expensive and unnecessary. Sampling strategies let you capture a representative subset of traces while ensuring you don't miss critical information about errors or important operations.
 
@@ -179,7 +179,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Multi-Config Setup
+## Multi-config setup
 
 Complex applications often require different tracing configurations for different scenarios. You might want detailed traces with full sampling during development, sampled traces sent to external providers in production, and specialized configurations for specific features or customer segments. The `configSelector` function enables dynamic configuration selection at runtime, allowing you to route traces based on request context, environment variables, feature flags, or any custom logic.
 
@@ -313,7 +313,7 @@ This configuration sends traces to all three destinations simultaneously:
 
 > **Info:** Remember: A single trace can be sent to multiple exporters. You don't need separate configs for each exporter unless you want different sampling rates or processors.
 
-## Adding Custom Metadata
+## Adding custom metadata
 
 Custom metadata allows you to attach additional context to your traces, making it easier to debug issues and understand system behavior in production. Metadata can include business logic details, performance metrics, user context, or any information that helps you understand what happened during execution.
 
@@ -341,7 +341,7 @@ execute: async (inputData, context) => {
 
 Metadata set here will be shown in all configured exporters.
 
-### Automatic Metadata from RequestContext
+### Automatic Metadata from `RequestContext`
 
 Instead of manually adding metadata to each span, you can configure Mastra to automatically extract values from RequestContext and attach them as metadata to all spans in a trace. This is useful for consistently tracking user identifiers, environment information, feature flags, or any request-scoped data across your entire trace.
 
@@ -420,7 +420,7 @@ requestContext.set('session', { data: { experimentId: 'exp-999' } })
 // Metadata will include: { user: { id: 'user-456' }, session: { data: { experimentId: 'exp-999' } } }
 ```
 
-#### How It Works
+#### How it works
 
 1. **TraceState Computation**: At the start of a trace (root span creation), Mastra computes which keys to extract by merging configuration-level and per-request keys
 2. **Automatic Extraction**: Root spans (agent runs, workflow executions) automatically extract metadata from RequestContext
@@ -429,7 +429,7 @@ requestContext.set('session', { data: { experimentId: 'exp-999' } })
 
 ### Adding Tags to Traces
 
-Tags are string labels that help you categorize and filter traces. Unlike metadata (which contains structured key-value data), tags are simple strings designed for quick filtering and organization.
+Tags are string labels that help you categorize and filter traces. Unlike metadata (which contains structured key-value data), tags are plain strings designed for quick filtering and organization.
 
 Use `tracingOptions.tags` to add tags when executing agents or workflows:
 
@@ -510,7 +510,7 @@ const result = await agent.generate([{ role: 'user', content: 'Handle confidenti
 })
 ```
 
-#### How It Works
+#### How it works
 
 - **Trace-wide effect**: When set on the root span, these options apply to all child spans in the trace (tool calls, model generations, etc.)
 - **Export-time filtering**: The data is still available internally during execution but is excluded when spans are exported to observability platforms
@@ -558,7 +558,7 @@ execute: async (inputData, context) => {
 
 This gives you fine-grained control over which child spans include RequestContext metadata. Root spans (agent/workflow executions) always extract metadata automatically, while child spans only extract when you explicitly pass `requestContext`.
 
-## Creating Child Spans
+## Creating child spans
 
 Child spans allow you to track fine-grained operations within your workflow steps or tools. They provide visibility into sub-operations like database queries, API calls, file operations, or complex calculations. This hierarchical structure helps you identify performance bottlenecks and understand the exact sequence of operations.
 
@@ -597,7 +597,7 @@ execute: async (inputData, context) => {
 
 Child spans automatically inherit the trace context from their parent, maintaining the relationship hierarchy in your observability platform.
 
-## Span Formatting
+## Span formatting
 
 Mastra provides two ways to transform span data before it reaches your observability platform: **span processors** and **custom span formatters**. Both allow you to modify, filter, or enrich trace data, but they operate at different levels and serve different purposes.
 
@@ -617,11 +617,11 @@ Span processors transform, filter, or enrich trace data before it's exported. Th
 
 #### Built-in Processors
 
-- [Sensitive Data Filter](https://mastra.ai/docs/observability/tracing/processors/sensitive-data-filter) redacts sensitive information. It is enabled in the default observability config.
+- [Sensitive Data Filter](https://mastra.ai/docs/observability/tracing/processors/sensitive-data-filter) redacts sensitive information. It's enabled in the default observability config.
 
 #### Creating Custom Processors
 
-You can create custom span processors by implementing the `SpanOutputProcessor` interface. Here's a simple example that converts all input text in spans to lowercase:
+You can create custom span processors by implementing the `SpanOutputProcessor` interface. Here's a basic example that converts all input text in spans to lowercase:
 
 ```ts
 import type { SpanOutputProcessor, AnySpan } from '@mastra/observability'
@@ -664,10 +664,10 @@ Processors are executed in the order they're defined, allowing you to chain mult
 
 Custom span formatters transform how spans appear in specific observability platforms. Unlike span processors, formatters are configured per-exporter, allowing different formatting for different destinations. Formatters support both synchronous and asynchronous operations.
 
-#### Use Cases
+#### Use cases
 
 - **Extract plain text from AI SDK messages** - Convert structured message arrays to readable text
-- **Transform input/output formats** - Customize how data appears in specific platforms
+- **Transform input/output formats** - Customize how data displays in specific platforms
 - **Platform-specific field mapping** - Add or remove fields based on platform requirements
 - **Async data enrichment** - Fetch additional context from external APIs or databases
 
@@ -794,7 +794,7 @@ const exporter = new LangfuseExporter({
 
 > **Note:** Async formatters add latency to span export. Keep async operations fast (under 100ms) to avoid slowing down your application. Consider using caching for frequently accessed data.
 
-## Serialization Options
+## Serialization options
 
 Serialization options control how span data (input, output, and attributes) is truncated before export. This is useful when working with large payloads, deeply nested objects, or when you need to optimize trace storage.
 
@@ -830,7 +830,7 @@ export const mastra = new Mastra({
 | `maxArrayLength`  | 50      | Maximum number of items in arrays. Additional items are omitted. |
 | `maxObjectKeys`   | 50      | Maximum number of keys in objects. Additional keys are omitted.  |
 
-### Use Cases
+### Use cases
 
 **Increasing limits for debugging**: If your agents or tools work with large documents, API responses, or data structures, increase these limits to capture more context in your traces:
 
@@ -855,7 +855,7 @@ serializationOptions: {
 
 All options are optional — if not specified, they fall back to the defaults shown above.
 
-## Retrieving Trace IDs
+## Retrieving trace IDs
 
 When you execute agents or workflows with tracing enabled, the response includes a `traceId` that you can use to look up the full trace in your observability platform. This is useful for debugging, customer support, or correlating traces with other events in your system.
 
@@ -911,7 +911,7 @@ Once you have a trace ID, you can:
 
 The trace ID is only available when tracing is enabled. If tracing is disabled or sampling excludes the request, `traceId` will be `undefined`.
 
-## Integrating with External Tracing Systems
+## Integrating with external tracing systems
 
 When running Mastra agents or workflows within applications that have existing distributed tracing (OpenTelemetry, Datadog, etc.), you can connect Mastra traces to your parent trace context. This creates a unified view of your entire request flow, making it easier to understand how Mastra operations fit into the broader system.
 
@@ -1017,13 +1017,13 @@ app.post('/api/analyze', async (req, res) => {
 
 This creates a single distributed trace that includes both the HTTP request handling and the Mastra agent execution, viewable in your observability platform of choice.
 
-## Flushing Traces in Serverless Environments
+## Flushing traces in serverless environments
 
 In serverless environments like Vercel's fluid compute, AWS Lambda, or Cloudflare Workers, runtime instances can be reused across multiple requests. The `flush()` method allows you to ensure all buffered spans are exported before the runtime terminates, without shutting down the exporter (which would prevent future exports).
 
 > **Storage requirements:** Serverless environments have ephemeral filesystems. Use external storage instead of local file storage (`file:./mastra.db`). See the [Vercel deployment guide](https://mastra.ai/guides/deployment/vercel) for a complete setup example.
 
-### Using flush()
+### Using `flush()`
 
 Call `flush()` on the observability instance to flush all exporters:
 
@@ -1035,7 +1035,7 @@ const observability = mastra.getObservability()
 await observability.flush()
 ```
 
-### When to Use flush()
+### When to Use `flush()`
 
 Use `flush()` in these scenarios:
 
@@ -1056,7 +1056,7 @@ export async function POST(req: Request) {
 }
 ```
 
-### flush() vs shutdown()
+### `flush()` vs `shutdown()`
 
 | Method       | Behavior                                      | Use Case                                   |
 | ------------ | --------------------------------------------- | ------------------------------------------ |
@@ -1065,7 +1065,7 @@ export async function POST(req: Request) {
 
 Use `flush()` when you need to ensure data is exported but want to keep the exporter ready for future requests. Use `shutdown()` only when the application is terminating.
 
-## What Gets Traced
+## What gets traced
 
 Mastra automatically creates spans for:
 
@@ -1083,7 +1083,7 @@ Mastra automatically creates spans for:
 - **Control flow** - Conditionals, loops, parallel execution
 - **Wait operations** - Delays and event waiting
 
-## See Also
+## See also
 
 ### Reference Documentation
 

package/.docs/docs/observability/tracing/processors/sensitive-data-filter.md

@@ -1,8 +1,8 @@
-# Sensitive Data Filter
+# Sensitive data filter
 
 The Sensitive Data Filter is a span processor that redacts sensitive information from your traces during the processing pipeline before export. This ensures that passwords, API keys, tokens, and other confidential data never leave your application or get stored in observability platforms.
 
-## Default Configuration
+## Default configuration
 
 The Sensitive Data Filter is included in the recommended observability configuration:
 
@@ -53,7 +53,7 @@ With the default configuration, the filter redacts these common sensitive field
 
 > **Note:** Field matching is case-insensitive and normalizes separators. For example, `api-key`, `api_key`, and `Api Key` are all treated as `apikey`.
 
-## How It Works
+## How it works
 
 The Sensitive Data Filter processes spans before they're sent to exporters, scanning through:
 
@@ -65,9 +65,9 @@ The Sensitive Data Filter processes spans before they're sent to exporters, scan
 
 When a sensitive field is detected, its value is replaced with `[REDACTED]` by default. The filter handles nested objects, arrays, and circular references safely.
 
-## Custom Configuration
+## Custom configuration
 
-You can customize which fields are redacted and how redaction appears:
+You can customize which fields are redacted and how redaction displays:
 
 ```ts
 import { SensitiveDataFilter, DefaultExporter, Observability } from '@mastra/observability'
@@ -108,7 +108,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Redaction Styles
+## Redaction styles
 
 The filter supports two redaction styles:
 
@@ -156,7 +156,7 @@ new SensitiveDataFilter({
 
 Values shorter than 7 characters are fully redacted to prevent information leakage.
 
-## Field Matching Rules
+## Field matching rules
 
 The filter uses intelligent field matching:
 
@@ -167,9 +167,9 @@ The filter uses intelligent field matching:
 3. **Exact Matching**: After normalization, fields must match exactly
 
    - `token` matches `token`, `Token`, `TOKEN`
-   - `token` does NOT match `promptTokens` or `tokenCount`
+   - `token` doesn't match `promptTokens` or `tokenCount`
 
-## Nested Object Handling
+## Nested object handling
 
 The filter recursively processes nested structures:
 
@@ -207,7 +207,7 @@ The filter recursively processes nested structures:
 }
 ```
 
-## Performance Considerations
+## Performance considerations
 
 The Sensitive Data Filter is designed to be lightweight and efficient:
 
@@ -215,7 +215,7 @@ The Sensitive Data Filter is designed to be lightweight and efficient:
 - **Circular Reference Handling**: Safely handles complex object graphs
 - **Error Recovery**: If filtering fails, the field is replaced with an error marker rather than crashing
 
-## Disabling the Filter
+## Disabling the filter
 
 If you need to disable sensitive data filtering (not recommended for production):
 
@@ -235,7 +235,7 @@ export const mastra = new Mastra({
 
 > **Warning:** Only disable sensitive data filtering in controlled environments. Never disable it when sending traces to external services or shared storage.
 
-## Common Use Cases
+## Common use cases
 
 ### Healthcare Applications
 
@@ -279,7 +279,7 @@ new SensitiveDataFilter({
 })
 ```
 
-## Error Handling
+## Error handling
 
 If the filter encounters an error while processing a field, it replaces the field with a safe error marker:
 

package/.docs/docs/rag/chunking-and-embedding.md

@@ -1,4 +1,4 @@
-# Chunking and Embedding Documents
+# Chunking and embedding documents
 
 Before processing, create a MDocument instance from your content. You can initialize it from various formats:
 
@@ -9,7 +9,7 @@ const docFromMarkdown = MDocument.fromMarkdown('# Your Markdown content...')
 const docFromJSON = MDocument.fromJSON(`{ "key": "value" }`)
 ```
 
-## Step 1: Document Processing
+## Step 1: Document processing
 
 Use `chunk` to split documents into manageable pieces. Mastra supports multiple chunking strategies optimized for different document types:
 
@@ -65,7 +65,7 @@ const chunks = await doc.chunk({
 
 We go deeper into chunking strategies in our [`chunk()` reference documentation](https://mastra.ai/reference/rag/chunk).
 
-## Step 2: Embedding Generation
+## Step 2: Embedding generation
 
 Transform chunks into embeddings using your preferred provider. Mastra supports embedding models through the model router.
 
@@ -123,9 +123,9 @@ const { embeddings } = await embedMany({
 })
 ```
 
-> **Vector Database Compatibility:** When storing embeddings, the vector database index must be configured to match the output size of your embedding model. If the dimensions do not match, you may get errors or data corruption.
+> **Vector Database Compatibility:** When storing embeddings, the vector database index must be configured to match the output size of your embedding model. If the dimensions don't match, you may get errors or data corruption.
 
-## Example: Complete Pipeline
+## Example: Complete pipeline
 
 Here's an example showing document processing and embedding generation with both providers:
 

package/.docs/docs/rag/overview.md

@@ -59,11 +59,11 @@ console.log('Similar chunks:', results)
 
 This example shows the essentials: initialize a document, create chunks, generate embeddings, store them, and query for similar content.
 
-## Document Processing
+## Document processing
 
 The basic building block of RAG is document processing. Documents can be chunked using various strategies (recursive, sliding window, etc.) and enriched with metadata. See the [chunking and embedding doc](https://mastra.ai/docs/rag/chunking-and-embedding).
 
-## Vector Storage
+## Vector storage
 
 Mastra supports multiple vector stores for embedding persistence and similarity search, including pgvector, Pinecone, Qdrant, and MongoDB. See the [vector database doc](https://mastra.ai/docs/rag/vector-databases).
 

package/.docs/docs/rag/retrieval.md

@@ -1,10 +1,10 @@
-# Retrieval in RAG Systems
+# Retrieval in RAG systems
 
 After storing embeddings, you need to retrieve relevant chunks to answer user queries.
 
 Mastra provides flexible retrieval options with support for semantic search, filtering, and re-ranking.
 
-## How Retrieval Works
+## How retrieval works
 
 1. The user's query is converted to an embedding using the same model used for document embeddings
 2. This embedding is compared to stored embeddings using vector similarity
@@ -14,7 +14,7 @@ Mastra provides flexible retrieval options with support for semantic search, fil
 - Re-ranked for better relevance
 - Processed through a knowledge graph
 
-## Basic Retrieval
+## Basic retrieval
 
 The simplest approach is direct semantic search. This method uses vector similarity to find chunks that are semantically similar to the query:
 
@@ -63,7 +63,7 @@ Results include both the text content and a similarity score:
 ]
 ```
 
-## Advanced Retrieval options
+## Advanced retrieval options
 
 ### Metadata Filtering
 

package/.docs/docs/rag/vector-databases.md

@@ -1,8 +1,8 @@
-# Storing Embeddings in A Vector Database
+# Storing embeddings in a vector database
 
 After generating embeddings, you need to store them in a database that supports vector similarity search. Mastra provides a consistent interface for storing and querying embeddings across various vector databases.
 
-## Supported Databases
+## Supported databases
 
 **MongoDB**:
 
@@ -234,7 +234,7 @@ await store.upsert({
 })
 ```
 
-**ElasticSearch**:
+**Elasticsearch**:
 
 ```ts
 import { ElasticSearchVector } from '@mastra/elasticsearch'
@@ -337,7 +337,7 @@ await store.upsert({
 })
 ```
 
-## Using Vector Storage
+## Using vector storage
 
 Once initialized, all vector stores share the same interface for creating indexes, upserting embeddings, and querying.
 
@@ -355,11 +355,11 @@ await store.createIndex({
 
 The dimension size must match the output dimension of your chosen embedding model. Common dimension sizes are:
 
-- OpenAI text-embedding-3-small: 1536 dimensions (or custom, e.g., 256)
-- Cohere embed-multilingual-v3: 1024 dimensions
-- Google gemini-embedding-001: 768 dimensions (or custom)
+- `OpenAI text-embedding-3-small`: 1536 dimensions (or custom, e.g., 256)
+- `Cohere embed-multilingual-v3`: 1024 dimensions
+- `Google gemini-embedding-001`: 768 dimensions (or custom)
 
-> **Warning:** Index dimensions cannot be changed after creation. To use a different model, delete and recreate the index with the new dimension size.
+> **Warning:** Index dimensions can't be changed after creation. To use a different model, delete and recreate the index with the new dimension size.
 
 ### Naming Rules for Databases
 
@@ -490,7 +490,7 @@ Index names must:
 - Example: `My_Index` is not valid (contains uppercase letters)
 - Example: `_myindex` is not valid (begins with underscore)
 
-**ElasticSearch**:
+**Elasticsearch**:
 
 Index names must:
 
@@ -543,7 +543,7 @@ The upsert operation:
 - Creates new vectors if they don't exist
 - Automatically handles batching for large datasets
 
-## Adding Metadata
+## Adding metadata
 
 Vector stores support rich metadata (any JSON-serializable fields) for filtering and organization. Since metadata is stored with no fixed schema, use consistent field naming to avoid unexpected query results.
 
@@ -581,9 +581,9 @@ Key metadata considerations:
 - Only include fields you plan to filter or sort by - extra fields add overhead
 - Add timestamps (e.g., 'createdAt', 'lastUpdated') to track content freshness
 
-## Deleting Vectors
+## Deleting vectors
 
-When building RAG applications, you often need to clean up stale vectors when documents are deleted or updated. Mastra provides the `deleteVectors` method that supports deleting vectors by metadata filters, making it easy to remove all embeddings associated with a specific document.
+When building RAG applications, you often need to clean up stale vectors when documents are deleted or updated. Mastra provides the `deleteVectors` method that supports deleting vectors by metadata filters, making it straightforward to remove all embeddings associated with a specific document.
 
 ### Delete by Metadata Filter
 
@@ -637,7 +637,7 @@ await store.deleteVectors({
 })
 ```
 
-## Best Practices
+## Best practices
 
 - Create indexes before bulk insertions
 - Use batch operations for large insertions (the upsert method handles batching automatically)

package/.docs/docs/server/auth/auth0.md

@@ -1,4 +1,4 @@
-# MastraAuthAuth0 Class
+# MastraAuthAuth0 class
 
 The `MastraAuthAuth0` class provides authentication for Mastra using Auth0. It verifies incoming requests using Auth0-issued JWT tokens and integrates with the Mastra server using the `auth` option.
 
@@ -66,7 +66,7 @@ export const mastra = new Mastra({
 By default, `MastraAuthAuth0` allows all authenticated users who have valid Auth0 tokens for the specified audience. The token verification ensures that:
 
 1. The token is properly signed by Auth0
-2. The token is not expired
+2. The token isn't expired
 3. The token audience matches your configured audience
 4. The token issuer matches your Auth0 domain
 

package/.docs/docs/server/auth/clerk.md

@@ -1,4 +1,4 @@
-# MastraAuthClerk Class
+# MastraAuthClerk class
 
 The `MastraAuthClerk` class provides authentication for Mastra using Clerk. It verifies incoming requests using Clerk's authentication system and integrates with the Mastra server using the `auth` option.
 

package/.docs/docs/server/auth/composite-auth.md

@@ -1,8 +1,8 @@
-# CompositeAuth Class
+# CompositeAuth class
 
 The `CompositeAuth` class allows you to combine multiple authentication providers into a single auth handler. It tries each provider in order until one succeeds.
 
-## Use Cases
+## Use cases
 
 - Support both API keys and OAuth tokens
 - Migrate between auth providers without breaking existing clients
@@ -17,7 +17,7 @@ CompositeAuth is included in `@mastra/core`, no additional packages required.
 import { CompositeAuth } from '@mastra/core/server'
 ```
 
-## Usage Example
+## Usage example
 
 Combine SimpleAuth (for API keys) with Clerk (for user sessions):
 
@@ -57,7 +57,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## How It Works
+## How it works
 
 When a request comes in, CompositeAuth:
 
@@ -79,7 +79,7 @@ async authenticateToken(token, request) {
 }
 ```
 
-## Provider Order
+## Provider order
 
 The order of providers matters. Place the most common authentication method first for better performance:
 
@@ -97,7 +97,7 @@ new CompositeAuth([
 ])
 ```
 
-## Multiple OAuth Providers
+## Multiple OAuth providers
 
 Support users from different identity providers:
 
@@ -124,7 +124,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Migration Example
+## Migration example
 
 Migrate from JWT to Clerk while maintaining backwards compatibility:
 
@@ -156,7 +156,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## With Custom Providers
+## With custom providers
 
 Combine built-in providers with custom implementations:
 
@@ -181,7 +181,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Error Handling
+## Error handling
 
 CompositeAuth silently catches errors from individual providers and moves to the next one. This prevents one failing provider from blocking authentication:
 

package/.docs/docs/server/auth/custom-auth-provider.md

@@ -1,4 +1,4 @@
-# Custom Auth Providers
+# Custom auth providers
 
 Custom auth providers allow you to implement authentication for identity systems that aren't covered by the built-in providers. Extend the `MastraAuthProvider` base class to integrate with any authentication system.
 
@@ -17,7 +17,7 @@ Create custom auth providers to support:
 - Specialized authorization rules
 - Enterprise SSO integrations
 
-## Creating a Custom Auth Provider
+## Creating a custom auth provider
 
 Extend the `MastraAuthProvider` class and implement the required methods:
 
@@ -101,9 +101,9 @@ export class MyAuthProvider extends MastraAuthProvider<MyUser> {
 }
 ```
 
-## Required Methods
+## Required methods
 
-### authenticateToken()
+### `authenticateToken()`
 
 Verify the incoming token and return the user object if valid, or `null` if authentication fails.
 
@@ -120,7 +120,7 @@ async authenticateToken(token: string, request: HonoRequest): Promise<TUser | nu
 
 The token is automatically extracted from the `Authorization: Bearer <token>` header. If you need to access other headers or cookies, use the `request` parameter.
 
-### authorizeUser()
+### `authorizeUser()`
 
 Determine if the authenticated user is allowed to access the resource.
 
@@ -135,7 +135,7 @@ async authorizeUser(user: TUser, request: HonoRequest): Promise<boolean> | boole
 
 **Returns**: `true` to allow access, `false` to deny (returns 403 Forbidden).
 
-## Configuration Options
+## Configuration options
 
 The `MastraAuthProviderOptions` interface supports these options:
 
@@ -168,7 +168,7 @@ const auth = new MyAuthProvider({
 })
 ```
 
-## Using Your Auth Provider
+## Using your auth provider
 
 Register your custom auth provider with the Mastra instance:
 
@@ -186,7 +186,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Helper Utilities
+## Helper utilities
 
 The `@mastra/auth` package provides utilities for common token verification patterns:
 
@@ -268,7 +268,7 @@ export class MyJwksAuth extends MastraAuthProvider<MyUser> {
 }
 ```
 
-## Custom Authorization Logic
+## Custom authorization logic
 
 Override the default authorization by providing a custom `authorizeUser` function:
 
@@ -308,7 +308,7 @@ const auth = new MyAuthProvider({
 })
 ```
 
-## Testing Custom Auth Providers
+## Testing custom auth providers
 
 Example test structure using Vitest:
 
@@ -432,7 +432,7 @@ describe('MyAuthProvider', () => {
 })
 ```
 
-## Error Handling
+## Error handling
 
 Provide descriptive errors for common failure scenarios:
 
@@ -490,7 +490,7 @@ export class MyAuthProvider extends MastraAuthProvider<MyUser> {
 }
 ```
 
-## Built-in Providers
+## Built-in providers
 
 Mastra includes these auth providers as reference implementations:
 

package/.docs/docs/server/auth/firebase.md

@@ -1,4 +1,4 @@
-# MastraAuthFirebase Class
+# MastraAuthFirebase class
 
 The `MastraAuthFirebase` class provides authentication for Mastra using Firebase Authentication. It verifies incoming requests using Firebase ID tokens and integrates with the Mastra server using the `auth` option.
 
@@ -66,12 +66,12 @@ export const mastra = new Mastra({
 
 The `MastraAuthFirebase` class can be configured through constructor options or environment variables.
 
-### Environment Variables
+### Environment variables
 
 - `FIREBASE_SERVICE_ACCOUNT`: Path to Firebase service account JSON file
 - `FIRESTORE_DATABASE_ID` or `FIREBASE_DATABASE_ID`: Firestore database ID
 
-> **Note:** When constructor options are not provided, the class automatically reads these environment variables. This means you can simply call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
+> **Note:** When constructor options aren't provided, the class automatically reads these environment variables. This means you can call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
 
 ### User Authorization