@mastra/mcp-docs-server 1.1.9-alpha.0 → 1.1.9-alpha.2

package/.docs/docs/memory/semantic-recall.md

@@ -1,10 +1,10 @@
-# Semantic Recall
+# Semantic recall
 
 If you ask your friend what they did last weekend, they will search in their memory for events associated with "last weekend" and then tell you what they did. That's sort of like how semantic recall works in Mastra.
 
 > **Watch 📹:** What semantic recall is, how it works, and how to configure it in Mastra → [YouTube (5 minutes)](https://youtu.be/UVZtK8cK8xQ)
 
-## How Semantic Recall Works
+## How semantic recall works
 
 Semantic recall is RAG-based search that helps agents maintain context across longer interactions when messages are no longer within [recent message history](https://mastra.ai/docs/memory/message-history).
 
@@ -16,7 +16,7 @@ When it's enabled, new messages are used to query a vector DB for semantically s
 
 After getting a response from the LLM, all new messages (user, assistant, and tool calls/results) are inserted into the vector DB to be recalled in later interactions.
 
-## Quick Start
+## Quick start
 
 Semantic recall is enabled by default, so if you give your agent memory it will be included:
 
@@ -33,7 +33,7 @@ const agent = new Agent({
 })
 ```
 
-## Using the recall() Method
+## Using the `recall()` method
 
 While `listMessages` retrieves messages by thread ID with basic pagination, [`recall()`](https://mastra.ai/reference/memory/recall) adds support for **semantic search**. When you need to find messages by meaning rather than recency, use `recall()` with a `vectorSearchString`:
 
@@ -182,7 +182,7 @@ const agent = new Agent({
 })
 ```
 
-### Using FastEmbed (Local)
+### Using FastEmbed (local)
 
 To use FastEmbed (a local embedding model), install `@mastra/fastembed`:
 
@@ -224,7 +224,7 @@ const agent = new Agent({
 })
 ```
 
-## PostgreSQL Index Optimization
+## PostgreSQL index optimization
 
 When using PostgreSQL as your vector store, you can optimize semantic recall performance by configuring the vector index. This is particularly important for large-scale deployments with thousands of messages.
 
@@ -283,6 +283,6 @@ You might want to disable semantic recall in scenarios like:
 - When message history provides sufficient context for the current conversation.
 - In performance-sensitive applications, like realtime two-way audio, where the added latency of creating embeddings and running vector queries is noticeable.
 
-## Viewing Recalled Messages
+## Viewing recalled messages
 
 When tracing is enabled, any messages retrieved via semantic recall will appear in the agent's trace output, alongside recent message history (if configured).

package/.docs/docs/memory/working-memory.md

@@ -13,7 +13,7 @@ Working memory can persist at two different scopes:
 
 **Important:** Switching between scopes means the agent won't see memory from the other scope - thread-scoped memory is completely separate from resource-scoped memory.
 
-## Quick Start
+## Quick start
 
 Here's a minimal example of setting up an agent with working memory:
 
@@ -37,13 +37,13 @@ const agent = new Agent({
 })
 ```
 
-## How it Works
+## How it works
 
 Working memory is a block of Markdown text that the agent is able to update over time to store continuously relevant information:
 
 [YouTube video player](https://www.youtube-nocookie.com/embed/UMy_JHLf1n8)
 
-## Memory Persistence Scopes
+## Memory persistence scopes
 
 Working memory can operate in two different scopes, allowing you to choose how memory persists across conversations:
 
@@ -117,7 +117,7 @@ const memory = new Memory({
 - Temporary or session-specific information
 - Workflows where each thread needs working memory but threads are ephemeral and not related to each other
 
-## Storage Adapter Support
+## Storage adapter support
 
 Resource-scoped working memory requires specific storage adapters that support the `mastra_resources` table:
 
@@ -128,7 +128,7 @@ Resource-scoped working memory requires specific storage adapters that support t
 - **Upstash** (`@mastra/upstash`)
 - **MongoDB** (`@mastra/mongodb`)
 
-## Custom Templates
+## Custom templates
 
 Templates guide the agent on what information to track and update in working memory. While a default template is used if none is provided, you'll typically want to define a custom template tailored to your agent's specific use case to ensure it remembers the most relevant information.
 
@@ -142,7 +142,7 @@ const memory = new Memory({
       template: `
 # User Profile
 
-## Personal Info
+## Personal info
 
 - Name:
 - Location:
@@ -156,7 +156,7 @@ const memory = new Memory({
   - [Deadline 1]: [Date]
   - [Deadline 2]: [Date]
 
-## Session State
+## Session state
 
 - Last Task Discussed:
 - Open Questions:
@@ -168,7 +168,7 @@ const memory = new Memory({
 })
 ```
 
-## Designing Effective Templates
+## Designing effective templates
 
 A well-structured template keeps the information straightforward for the agent to parse and update. Treat the template as a short form that you want the assistant to keep up to date.
 
@@ -206,7 +206,7 @@ const paragraphMemory = new Memory({
 })
 ```
 
-## Structured Working Memory
+## Structured working memory
 
 Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Zod](https://zod.dev/) schema. When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
@@ -265,20 +265,20 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
 - **Set a field to `null` to delete it:** This explicitly removes the field from memory
 - **Arrays are replaced entirely:** When an array field is provided, it replaces the existing array (arrays aren't merged element-by-element)
 
-## Choosing Between Template and Schema
+## Choosing between template and schema
 
 - Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics** — the agent must provide the complete memory content on each update.
 - Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. Schemas use **merge semantics** — the agent only provides fields to update, and existing fields are preserved.
 - Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
 
-## Example: Multi-step Retention
+## Example: Multi-step retention
 
 Below is a simplified view of how the `User Profile` template updates across a short user conversation:
 
 ```nohighlight
 # User Profile
 
-## Personal Info
+## Personal info
 
 - Name:
 - Location:
@@ -303,7 +303,7 @@ The agent can now refer to `Sam` or `Berlin` in later responses without requesti
 
 If your agent isn't properly updating working memory when you expect it to, you can add system instructions on _how_ and _when_ to use this template in your agent's `instructions` setting.
 
-## Setting Initial Working Memory
+## Setting initial working memory
 
 While agents typically update working memory through the `updateWorkingMemory` tool, you can also set initial working memory programmatically when creating or updating threads. This is useful for injecting user data (like their name, preferences, or other info) that you want available to the agent without passing it in every request.
 
@@ -372,7 +372,7 @@ await memory.updateWorkingMemory({
 })
 ```
 
-## Read-Only Working Memory
+## Read-only working memory
 
 In some scenarios, you may want an agent to have access to working memory data without the ability to modify it. This is useful for:
 

package/.docs/docs/observability/datasets/overview.md

@@ -1,4 +1,4 @@
-# Datasets Overview
+# Datasets overview
 
 **Added in:** `@mastra/core@1.4.0`
 

package/.docs/docs/observability/datasets/running-experiments.md

@@ -1,4 +1,4 @@
-# Running Experiments
+# Running experiments
 
 **Added in:** `@mastra/core@1.4.0`
 

package/.docs/docs/observability/logging.md

@@ -4,7 +4,7 @@ Mastra's logging system captures function execution, input data, and output resp
 
 When deploying to Mastra Cloud, logs are shown on the [Logs](https://mastra.ai/docs/mastra-cloud/observability) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
 
-## Configuring logs with PinoLogger
+## Configuring logs with `PinoLogger`
 
 When [initializing a new Mastra project](https://mastra.ai/guides/getting-started/quickstart) using the CLI, `PinoLogger` is included by default.
 

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

@@ -1,8 +1,8 @@
-# Observability Overview
+# Observability overview
 
 Mastra provides observability features for AI applications. Monitor LLM operations, trace agent decisions, and debug complex workflows with tools that understand AI-specific patterns.
 
-## Key Features
+## Key features
 
 ### Tracing
 
@@ -13,13 +13,13 @@ Specialized tracing for AI operations that captures:
 - **Workflow steps**: Branching logic, parallel execution, and step outputs
 - **Automatic instrumentation**: Tracing with decorators
 
-## Storage Requirements
+## Storage requirements
 
 The `DefaultExporter` persists traces to your configured storage backend. Not all storage providers support observability—for the full list, see [Storage Provider Support](https://mastra.ai/docs/observability/tracing/exporters/default).
 
 For production environments with high traffic, we recommend using **ClickHouse** for the observability domain via [composite storage](https://mastra.ai/reference/storage/composite). See [Production Recommendations](https://mastra.ai/docs/observability/tracing/exporters/default) for details.
 
-## Quick Start
+## Quick start
 
 Configure Observability in your Mastra instance:
 
@@ -63,7 +63,7 @@ With this basic setup, you will see Traces and Logs in both Studio and in Mastra
 
 We also support various external tracing providers like MLflow, Langfuse, Braintrust, and any OpenTelemetry-compatible platform (Datadog, New Relic, SigNoz, etc.). See more about this in the [Tracing](https://mastra.ai/docs/observability/tracing/overview) documentation.
 
-## What's Next?
+## What's next?
 
 - **[Set up Tracing](https://mastra.ai/docs/observability/tracing/overview)**: Configure tracing for your application
 - **[Configure Logging](https://mastra.ai/docs/observability/logging)**: Add structured logging

package/.docs/docs/observability/tracing/bridges/otel.md

@@ -1,4 +1,4 @@
-# OpenTelemetry Bridge
+# OpenTelemetry bridge
 
 > **Warning:** The OpenTelemetry Bridge is currently **experimental**. APIs and configuration options may change in future releases.
 
@@ -6,7 +6,7 @@ The OpenTelemetry (OTEL) Bridge enables bidirectional integration between Mastra
 
 > **Looking to send traces without existing OTEL infrastructure?:** If you don't have existing OpenTelemetry instrumentation, the [OpenTelemetry Exporter](https://mastra.ai/docs/observability/tracing/exporters/otel) may be simpler — it sends traces directly without requiring an OTEL SDK setup.
 
-## When to Use the Bridge
+## When to use the bridge
 
 Use the OtelBridge when you:
 
@@ -15,7 +15,7 @@ Use the OtelBridge when you:
 - Need OTEL-instrumented code inside Mastra tools to maintain proper parent-child relationships
 - Are building a distributed system where trace context must propagate across services
 
-## How It Works
+## How it works
 
 The OtelBridge provides two-way integration:
 
@@ -138,13 +138,13 @@ Use the `--import` flag to ensure instrumentation loads before your application:
 tsx --import ./instrumentation.ts ./src/index.ts
 ```
 
-## Semantic Conventions
+## Semantic conventions
 
 The OtelBridge exports Mastra spans using [OpenTelemetry Semantic Conventions for GenAI v1.38.0](https://github.com/open-telemetry/semantic-conventions/tree/v1.38.0/docs/gen-ai). This includes standardized span names (`chat {model}`, `execute_tool {tool_name}`, etc.) and attributes (`gen_ai.usage.input_tokens`, `gen_ai.request.model`, etc.).
 
 For details on span naming and attributes, see the [OpenTelemetry Exporter semantic conventions](https://mastra.ai/docs/observability/tracing/exporters/otel).
 
-## Trace Hierarchy
+## Trace hierarchy
 
 With the OtelBridge, your traces maintain proper hierarchy across OTEL and Mastra boundaries:
 
@@ -157,7 +157,7 @@ HTTP POST /api/chat (from Hono middleware)
     └── chat gpt-4o (follow-up LLM call)
 ```
 
-## Multi-Service Distributed Tracing
+## Multi-service distributed tracing
 
 The OtelBridge enables trace propagation across service boundaries. When Service A calls Service B via HTTP, trace context propagates automatically:
 
@@ -176,7 +176,7 @@ Both services must have:
 2. W3C Trace Context propagator enabled
 3. Mastra with OtelBridge configured
 
-## Using Tags
+## Using tags
 
 Tags help you categorize and filter traces in your OTEL backend. Add tags when executing agents or workflows:
 

package/.docs/docs/observability/tracing/exporters/arize.md

@@ -1,4 +1,4 @@
-# Arize Exporter
+# Arize exporter
 
 [Arize](https://arize.com/) provides observability platforms for AI applications through [Phoenix](https://phoenix.arize.com/) (open-source) and [Arize AX](https://arize.com/generative-ai/) (enterprise). The Arize exporter sends traces using OpenTelemetry and [OpenInference](https://github.com/Arize-ai/openinference/tree/main/spec) semantic conventions, compatible with any OpenTelemetry platform that supports OpenInference.
 
@@ -176,7 +176,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 The Arize exporter supports advanced configuration for fine-tuning OpenTelemetry behavior:
 
@@ -260,7 +260,7 @@ await agent.generate(input, {
 
 Reserved fields such as `input`, `output`, `sessionId`, thread/user IDs, and OpenInference IDs are excluded automatically.
 
-## OpenInference Semantic Conventions
+## OpenInference semantic conventions
 
 This exporter implements the [OpenInference Semantic Conventions](https://github.com/Arize-ai/openinference/tree/main/spec) for generative AI applications, providing standardized trace structure across different observability platforms.
 

package/.docs/docs/observability/tracing/exporters/braintrust.md

@@ -1,4 +1,4 @@
-# Braintrust Exporter
+# Braintrust exporter
 
 [Braintrust](https://www.braintrust.dev/) is an evaluation and monitoring platform that helps you measure and improve LLM application quality. The Braintrust exporter sends your traces to Braintrust, enabling systematic evaluation, scoring, and experimentation.
 

package/.docs/docs/observability/tracing/exporters/cloud.md

@@ -1,4 +1,4 @@
-# Cloud Exporter
+# Cloud exporter
 
 The `CloudExporter` sends traces to Mastra Cloud for centralized monitoring and team collaboration. It's automatically enabled when using the default observability configuration with a valid access token.
 
@@ -83,7 +83,7 @@ new CloudExporter({
 })
 ```
 
-## Viewing Traces
+## Viewing traces
 
 ### Mastra Cloud Dashboard
 

package/.docs/docs/observability/tracing/exporters/datadog.md

@@ -1,4 +1,4 @@
-# Datadog Exporter
+# Datadog exporter
 
 [Datadog](https://datadoghq.com/) is a comprehensive monitoring platform with dedicated LLM Observability features. The Datadog exporter sends your traces to Datadog's LLM Observability product, providing insights into model performance, token usage, and conversation flows.
 
@@ -90,7 +90,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Complete Configuration
 
@@ -128,7 +128,7 @@ new DatadogExporter({
 
 Note: When using agent mode, the API key is read from the local agent's configuration.
 
-## Span Type Mapping
+## Span type mapping
 
 Mastra span types are automatically mapped to Datadog LLMObs span kinds:
 

package/.docs/docs/observability/tracing/exporters/default.md

@@ -1,4 +1,4 @@
-# Default Exporter
+# Default exporter
 
 The `DefaultExporter` persists traces to your configured storage backend, making them accessible through Studio. It's automatically enabled when using the default observability configuration and requires no external services.
 
@@ -68,7 +68,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Viewing Traces
+## Viewing traces
 
 ### Studio
 
@@ -79,7 +79,7 @@ Access your traces through Studio:
 3. Filter and search your local traces
 4. Inspect detailed span information
 
-## Tracing Strategies
+## Tracing strategies
 
 DefaultExporter automatically selects the optimal tracing strategy based on your storage provider. You can also override this selection if needed.
 
@@ -106,7 +106,7 @@ new DefaultExporter({
 })
 ```
 
-## Storage Provider Support
+## Storage provider support
 
 Different storage providers support different tracing strategies. Some providers support observability for production workloads, while others are intended primarily for local development.
 
@@ -139,7 +139,7 @@ The following storage providers **don't support** the observability domain. If y
 - **batch-with-updates**: 10-100x throughput improvement, full span lifecycle
 - **insert-only**: Additional 70% reduction in database operations, perfect for analytics
 
-## Production Recommendations
+## Production recommendations
 
 Observability data grows quickly in production environments. A single agent interaction can generate hundreds of spans, and high-traffic applications can produce thousands of traces per day. Most general-purpose databases aren't optimized for this write-heavy, append-only workload.
 
@@ -156,7 +156,7 @@ Observability data grows quickly in production environments. A single agent inte
 
 If you're using a provider without observability support (like Convex or DynamoDB) or want to optimize performance, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to ClickHouse while keeping other data in your primary database.
 
-## Batching Behavior
+## Batching behavior
 
 ### Flush Triggers
 
@@ -167,7 +167,7 @@ For both batch strategies (`batch-with-updates` and `insert-only`), traces are f
 3. **Emergency flush**: Buffer approaches `maxBufferSize` limit
 4. **Shutdown**: Force flush all pending events
 
-### Error Handling
+### Error handling
 
 The DefaultExporter includes robust error handling for production use:
 

package/.docs/docs/observability/tracing/exporters/laminar.md

@@ -1,4 +1,4 @@
-# Laminar Exporter
+# Laminar exporter
 
 [Laminar](https://laminar.sh/) is an open-source platform for engineering LLM products. The Laminar exporter sends your Mastra traces to Laminar via OTLP/HTTP (protobuf), with Laminar-native span attributes for correct rendering (paths, inputs/outputs, tags, metadata).
 

package/.docs/docs/observability/tracing/exporters/langfuse.md

@@ -1,4 +1,4 @@
-# Langfuse Exporter
+# Langfuse exporter
 
 [Langfuse](https://langfuse.com/) is an open-source observability platform specifically designed for LLM applications. The Langfuse exporter sends your traces to Langfuse, providing detailed insights into model performance, token usage, and conversation flows.
 
@@ -93,7 +93,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Realtime vs Batch Mode
 
@@ -145,7 +145,7 @@ new LangfuseExporter({
 })
 ```
 
-## Prompt Linking
+## Prompt linking
 
 You can link LLM generations to prompts stored in [Langfuse Prompt Management](https://langfuse.com/docs/prompt-management). This enables version tracking and metrics for your prompts.
 

package/.docs/docs/observability/tracing/exporters/langsmith.md

@@ -1,4 +1,4 @@
-# LangSmith Exporter
+# LangSmith exporter
 
 [LangSmith](https://smith.langchain.com/) is LangChain's platform for monitoring and evaluating LLM applications. The LangSmith exporter sends your traces to LangSmith, providing insights into model performance, debugging capabilities, and evaluation workflows.
 
@@ -91,7 +91,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Complete Configuration
 
@@ -116,7 +116,7 @@ new LangSmithExporter({
 })
 ```
 
-### Environment Variables
+### Environment variables
 
 | Variable             | Description                                                       |
 | -------------------- | ----------------------------------------------------------------- |
@@ -126,7 +126,7 @@ new LangSmithExporter({
 
 The `projectName` config option takes precedence over the `LANGCHAIN_PROJECT` environment variable, allowing you to programmatically route traces to different projects.
 
-## Dynamic Configuration
+## Dynamic configuration
 
 You can dynamically override LangSmith settings per-span using `withLangsmithMetadata`. This is useful for routing traces to different projects based on runtime conditions (e.g., customer, environment, or feature).
 

package/.docs/docs/observability/tracing/exporters/otel.md

@@ -1,4 +1,4 @@
-# OpenTelemetry Exporter
+# OpenTelemetry exporter
 
 The OpenTelemetry (OTEL) exporter sends your traces to any OTEL-compatible observability platform using standardized [OpenTelemetry Semantic Conventions for GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/). This ensures broad compatibility with platforms like Datadog, New Relic, SigNoz, MLflow, Dash0, Traceloop, Laminar, and more.
 
@@ -34,7 +34,7 @@ yarn add @mastra/otel-exporter@latest @opentelemetry/exporter-trace-otlp-proto
 bun add @mastra/otel-exporter@latest @opentelemetry/exporter-trace-otlp-proto
 ```
 
-### For gRPC Providers (Dash0, Datadog)
+### For `gRPC` Providers (Dash0, Datadog)
 
 **npm**:
 
@@ -86,7 +86,7 @@ yarn add @mastra/otel-exporter@latest @opentelemetry/exporter-trace-otlp-http
 bun add @mastra/otel-exporter@latest @opentelemetry/exporter-trace-otlp-http
 ```
 
-## Environment Variables
+## Environment variables
 
 All providers support zero-config setup via environment variables. Set the appropriate variables and the exporter will automatically use them:
 
@@ -98,7 +98,7 @@ All providers support zero-config setup via environment variables. Set the appro
 | Traceloop | `TRACELOOP_API_KEY` (required), `TRACELOOP_DESTINATION_ID`, `TRACELOOP_ENDPOINT` (optional) |
 | Laminar   | `LMNR_PROJECT_API_KEY` (required), `LAMINAR_ENDPOINT` (optional)                            |
 
-## Provider Configurations
+## Provider configurations
 
 ### MLflow
 
@@ -187,7 +187,7 @@ export const mastra = new Mastra({
 
 > **Info:** Get your Dash0 endpoint from your dashboard. It should be in the format `ingress.{region}.aws.dash0.com:4317`.
 
-### SigNoz
+### `SigNoz`
 
 [SigNoz](https://signoz.io/) is an open-source APM alternative with built-in Tracing support.
 
@@ -389,7 +389,7 @@ new OtelExporter({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Complete Configuration
 
@@ -409,7 +409,7 @@ new OtelExporter({
 })
 ```
 
-## OpenTelemetry Semantic Conventions
+## `OpenTelemetry` semantic conventions
 
 The exporter follows [OpenTelemetry Semantic Conventions for GenAI v1.38.0](https://github.com/open-telemetry/semantic-conventions/tree/v1.38.0/docs/gen-ai), ensuring compatibility with observability platforms:
 
@@ -432,7 +432,7 @@ The exporter follows [OpenTelemetry Semantic Conventions for GenAI v1.38.0](http
 - `gen_ai.request.temperature` - Sampling temperature
 - `gen_ai.response.finish_reasons` - Completion reasons
 
-## Protocol Selection Guide
+## Protocol selection guide
 
 Choose the right protocol package based on your provider:
 

package/.docs/docs/observability/tracing/exporters/posthog.md

@@ -1,4 +1,4 @@
-# PostHog Exporter
+# PostHog exporter
 
 [PostHog](https://posthog.com/) is an analytics platform with AI observability features for monitoring LLM applications. The PostHog exporter sends your traces to PostHog as structured events, providing insights into token usage, costs, latency, and conversation flows.
 
@@ -90,7 +90,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Complete Configuration
 

package/.docs/docs/observability/tracing/exporters/sentry.md

@@ -1,4 +1,4 @@
-# Sentry Exporter
+# Sentry exporter
 
 [Sentry](https://sentry.io/) is an application monitoring platform with AI-specific tracing capabilities. The Sentry exporter sends your traces to Sentry using OpenTelemetry semantic conventions, providing insights into model performance, token usage, and tool executions.
 
@@ -92,7 +92,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 ### Complete Configuration
 
@@ -132,7 +132,7 @@ new SentryExporter({
 
 > **Tip:** Set to `1.0` (100%) for development and `0.1` to `0.2` (10-20%) for production high-load applications. To disable tracing entirely, don't set `tracesSampleRate` at all rather than setting it to `0`.
 
-## Span Type Mapping
+## Span type mapping
 
 Mastra span types are automatically mapped to Sentry operations:
 
@@ -155,7 +155,7 @@ Mastra span types are automatically mapped to Sentry operations:
 | `PROCESSOR_RUN`             | `ai.processor`         |                                                   |
 | `GENERIC`                   | `ai.span`              |                                                   |
 
-## OpenTelemetry Semantic Conventions
+## OpenTelemetry semantic conventions
 
 The exporter uses standard GenAI semantic conventions with Sentry-specific attributes: