Parse tracking specifications from Google Sheets spreadsheets, allowing users to import CSV-formatted specs directly.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tealium-mcp-server Validate this data layer: { page: { pageName: 'Home' }, user: { isLoggedIn: true } }"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for Tealium data layer validation, documentation generation, debugging, and code generation. Built for tag management specialists and analytics engineers.
Tool | Description |
| Validate data layers against schemas and Tealium best practices |
| Generate Markdown or JSON Schema documentation from specs |
| Diagnose issues, find missing variables, detect type mismatches |
| Generate TypeScript/JavaScript code from specifications |
| Parse CSV/JSON tracking specs from spreadsheets |
Resource | Description |
| Standard data layer schema (page, user, event) |
| E-commerce schema (products, transactions) |
| Hotel industry schema (bookings, rooms, guests) |
| Basic data layer template |
| Hotel booking funnel template |
| Tealium implementation best practices |
Related MCP server: Google Tag Manager MCP Server
# Clone or download this repository
cd tealium-mcp-server
# Install dependencies
npm install
# Build
npm run build# Add the server to Claude Code
claude mcp add --transport stdio tealium -- node /path/to/tealium-mcp-server/dist/index.js
# Verify it's configured
claude mcp listEdit your Claude Desktop config file:
Linux/WSL: ~/.config/Claude/claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"tealium": {
"command": "node",
"args": ["/path/to/tealium-mcp-server/dist/index.js"]
}
}
}Ask Claude:
"Validate this data layer: { page: { pageName: 'Home' }, user: { isLoggedIn: true } }"
Ask Claude:
"Debug this data layer from my booking page and tell me what's wrong"
Then paste your data layer JSON from the browser console.
Ask Claude:
"Generate documentation for my tracking specification"
Then provide your spec in JSON or paste CSV content.
Ask Claude:
"Generate TypeScript interfaces for my hotel booking data layer"
Ask Claude:
"Parse this tracking spec from my Google Sheet"
Then paste CSV content with columns like: variable, type, required, description
When a developer sends a data layer for review or when checking a live page:
"Validate this data layer against the hotel schema:
{
page: { pageName: 'Booking Confirmation', pageType: 'confirmation' },
hotel: { hotelCode: 'BCN001', hotelName: 'Barceló Sants' },
booking: { bookingId: 'RES123', bookingTotal: 450, bookingCurrency: 'EUR' }
}"When something isn't tracking correctly (e.g., QA finds missing data in reports):
"Debug this data layer from the booking page - events aren't firing correctly:
[paste JSON from browser console: copy(utag_data)]"The tool will identify:
Missing required variables
Wrong data types (string vs number)
Invalid dates
Empty values
PII exposure risks
When onboarding new developers or updating tracking specs:
"Generate documentation for our hotel booking data layer"Or from an existing spec:
"Parse this tracking spec and generate documentation:
[paste CSV from Google Sheets]"When developers need implementation code:
"Generate TypeScript code for our booking funnel data layer with these events:
- search.initiated
- hotel.viewed
- room.selected
- booking.completed"When the analytics team sends a new tracking requirement (usually a spreadsheet):
"Parse this tracking spec from our Google Sheet:
variable,type,required,description
page.pageName,string,true,Page identifier
booking.bookingTotal,number,true,Total booking amount
booking.bookingCurrency,string,true,ISO currency code
..."Task | Ask Claude |
Validate data layer | "Validate this data layer: {...}" |
Debug issues | "Debug this data layer: {...}" |
Generate docs | "Generate documentation for this spec" |
Generate code | "Generate TypeScript for this data layer" |
Parse spreadsheet | "Parse this tracking spec: [CSV]" |
Get best practices | "Show me Tealium best practices" |
Get hotel template | "Show me the hotel booking template" |
To quickly grab the data layer from any page:
// In browser DevTools console:
copy(JSON.stringify(utag_data, null, 2))Then paste it into Claude with "Debug this data layer" or "Validate this".
# Use the MCP Inspector to test
npx @modelcontextprotocol/inspector node dist/index.jsThis server includes specialized support for hotel/travel tracking:
Search data: destination, check-in/out dates, guests, rooms
Hotel data: code, name, brand, star rating, category
Room data: type, code, capacity, amenities
Booking data: ID, status, dates, nights, rates, totals
Guest data: type, loyalty ID, tier, points
Perfect for hotel chains like Barcelo, Marriott, Hilton, etc.
# Build
npm run build
# Run development (build + start)
npm run devMIT
Analyzes a data layer for common issues, missing variables, type mismatches, and provides recommendations. Perfect for troubleshooting tracking issues.
| Name | Required | Description | Default |
|---|---|---|---|
| dataLayer | Yes | The data layer JSON to debug | |
| checkPoints | No | Specific areas to focus on (e.g., "ecommerce", "loyalty", "search") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a non-mutating 'Analyzes' operation and that recommendations are produced, but it does not describe return structure, side effects, or how the optional 'checkPoints' parameter changes behavior. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's main purpose. The marketing-style phrase 'Perfect for troubleshooting tracking issues' is somewhat extra, but the overall length is appropriate and the message is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what the tool returns and how 'checkPoints' affects the analysis. It does neither, leaving an agent without enough information to correctly interpret the tool's response or fully understand the optional parameter's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions, providing 100% coverage. The description adds some context about the kind of analysis performed ('missing variables, type mismatches'), which loosely contextualizes the 'dataLayer' input, but it does not add meaningful detail about 'checkPoints' beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyzes') and names the resource ('data layer'), and goes on to specify the scope: common issues, missing variables, type mismatches, and recommendations. This clearly states what the tool does, though it does not explicitly distinguish it from the sibling 'validate_data_layer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Perfect for troubleshooting tracking issues' gives a clear use case and implied context, but there is no explicit guidance on when to prefer this tool over sibling 'validate_data_layer' or when it should not be used. The selection guidance is largely implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates TypeScript or JavaScript code from a tracking specification or data layer. Includes type definitions, helper functions, and event tracking code.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Tracking specification with variables and events | |
| language | No | Target language | typescript |
| dataLayer | No | Data layer object to generate types from | |
| includeHelpers | No | Include helper functions like trackEvent() |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It usefully reveals the artifacts it generates, but it does not describe side effects, output format, return behavior, or whether the code is returned inline or persisted somewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no filler. The core action and input are front-loaded, and the second sentence enumerates deliverables without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters well and the description specifies the kinds of output, but there is no output schema, no annotations, and no usage-selection guidance. An agent is left without clarity on how the generated code is returned or why this tool should be chosen over generate_documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context by mentioning the input source and generated outputs, but it does not clarify parameter meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Generates TypeScript or JavaScript code from a tracking specification or data layer.' It also lists concrete outputs (type definitions, helper functions, event tracking code), which clearly distinguishes it from siblings like validate_data_layer, debug_data_layer, and generate_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to select this tool over the sibling tools. The description implies it should be used when generated code is needed, but it does not state conditions, prerequisites, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates documentation from a data layer structure or tracking specification. Outputs Markdown or JSON Schema format.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | A tracking specification object with variables and events | |
| format | No | Output format | markdown |
| dataLayer | No | A data layer object to document |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state the core behavior: generating documentation from an input structure and outputting Markdown or JSON Schema. However, it does not disclose behavior around missing inputs, whether both spec and dataLayer can be provided simultaneously, or any side effects, which leaves meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler, and the primary action is front-loaded. The second sentence is largely redundant with the format parameter's enum, but it is still efficient and aids quick comprehension. It could have been condensed into one sentence without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 3-parameter tool with no required fields, no output schema, and no annotations, yet the description does not clarify whether at least one of spec or dataLayer must be provided, what happens if neither is given, or how the two inputs interact. An agent lacks crucial calling constraints and return details beyond the format names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters and their descriptions. The tool description only restates the concepts of 'data layer structure' and 'tracking specification' that the schema already covers. It adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Generates documentation'), its input source ('data layer structure or tracking specification'), and its output formats ('Markdown or JSON Schema'). This distinguishes it from sibling tools like validate_data_layer, debug_data_layer, parse_tracking_spec, and generate_code, all of which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool should be used by naming its purpose and inputs, but it does not explicitly state when to prefer it over alternatives or when not to use it. There is no mention of how it differs from generate_code or that validate/debug tools serve different needs. Usage context is only implied, not specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses tracking specifications from CSV or JSON format (e.g., exported from Google Sheets or Excel). Normalizes the data into a structured format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Input format (auto-detected if not specified) | auto |
| content | Yes | CSV or JSON content to parse | |
| hasHeader | No | For CSV: whether the first row is a header |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'Parses' and 'Normalizes' suggest a read-only transformation, but the description does not mention side effects, error behavior on malformed input, or what the normalized 'structured format' looks like. This lack of detail leaves key behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary verb and resource, and contains no redundant filler. Every clause contributes to the tool's purpose. It is concise while conveying the essential input and processing intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input side is complete due to full schema coverage, and the description says the output is a normalized structured format. However, with no output schema, the description should specify the returned format or structure more concretely, and it does not cover error behavior on invalid input. Still, for a straightforward parser with fully documented inputs, this is adequate if not richly detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's reference to 'CSV or JSON' and Google Sheets/Excel adds slight context to the content parameter but does not explain hasHeader or format choices beyond the schema. No parameter information is needed beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Parses'), a resource ('tracking specifications'), and the input formats ('CSV or JSON'), which clearly differentiates it from siblings like validate_data_layer or generate_code. The normalization clause adds the tool's core purpose. An agent can identify what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a context clue with '(e.g., exported from Google Sheets or Excel)', implying when raw tracking spec files would be parsed. However, it does not explicitly state when to use this tool versus alternatives such as validate_data_layer or debug_data_layer, nor any exclusions. Usage is inferred from the verb rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Tealium data layer object against schemas and best practices. Returns errors, warnings, and suggestions for improvement.
| Name | Required | Description | Default |
|---|---|---|---|
| dataLayer | Yes | The data layer JSON object to validate | |
| schemaUri | No | Schema to validate against (tealium://schema/standard, tealium://schema/ecommerce, or tealium://schema/hotels) | tealium://schema/standard |
| strictMode | No | When true, treats warnings as errors |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the return categories ('errors, warnings, and suggestions for improvement'), which is useful, but it does not mention side effects, whether the input is mutated, what happens with an invalid schemaUri, or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. It leads with the core action and immediately conveys the value of the return value, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented in the schema, and the description communicates the tool's purpose and output categories. It is slightly incomplete because it does not help an agent distinguish this tool from similar siblings or describe the response shape, but for a validation tool with full schema coverage it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds no parameter-specific details beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Validates a Tealium data layer object') and states the outcome (errors, warnings, suggestions). It is clear about what the tool does, but it does not explicitly differentiate it from sibling tools like debug_data_layer, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as debug_data_layer or parse_tracking_spec. The description implies a validation use case but gives no explicit context, exclusions, or conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0debug_data_layergenerate_codegenerate_documentationparse_tracking_specvalidate_data_layerScored across 5 tools
Most tools are distinct, but validate_data_layer and debug_data_layer have significant overlap: both analyze a data layer for errors and issues. The descriptions differ in focus (schemas/best practices vs. common issues/missing variables), but an agent could easily confuse which to use for troubleshooting.
All five tool names follow a consistent verb_noun snake_case pattern: validate_, generate_, debug_, parse_, generate_. The pattern is predictable and clearly conveys the action and target.
Five tools is well-scoped for a data layer/tracking specification utility server. Each tool covers a distinct phase (parse, validate, debug, generate docs, generate code) without unnecessary bloat.
The toolset covers a complete workflow: parse raw specs, validate/debug data layers, and generate documentation or code. Minor gaps exist, such as no tool to edit or transform an existing data layer definition directly, but the core lifecycle is well represented.
Let AI manage your Google Tag Manager containers — tags, triggers, variables, and more.
GTM data layer for AI agents: find scored B2B leads free, reveal verified email+mobile, audit ads.
Google Ads, GA4 and Tag Manager in your AI client, with a preview before every change.
Define, ship & query your analytics tracking from one source of truth, trusted by humans and agents.
