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., "@Tracking Plan MCP Server Create an ecommerce GA4 tracking plan."
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.
Beginner-friendly Model Context Protocol (MCP) server built with TypeScript + Node.js to create, list, inspect, and validate tracking plans for Ecommerce and Lead-Generation / Service Businesses.
The Tracking Plan MCP Server allows AI assistants (such as Cursor, Claude Desktop, and Antigravity) to manage analytics tracking specifications locally.
It supports two distinct business models out-of-the-box:
Ecommerce Businesses: Product views, cart activity, checkout steps, payment info, revenue, and purchase transactions.
Lead Generation & Service Businesses: Service views, form starts, form submissions, lead generation, phone clicks, email clicks, WhatsApp clicks, appointment bookings, and quote requests.
Related MCP server: Orchestration MCP
AI Assistant (Cursor / Claude Desktop / Antigravity)
ā
MCP Client
ā
MCP Server (stdio transport)
ā
MCP Tools (create_tracking_plan, get_tracking_plan, list_tracking_plans, validate_tracking_event)
ā
Tracking Plan Service (Business logic & Validation)
ā
JSON Storage (fs/promises)
ā
data/tracking-plans.jsonTracks:
Product page views (view_item)
Cart interactions (add_to_cart, remove_from_cart, view_cart)
Checkout flow (begin_checkout, add_payment_info)
Purchases & revenue (purchase)
Purchase Event Required Parameters: transaction_id, value, currency, items.
Tracks:
Service page views (view_service)
Form interactions (form_start, form_submit)
Lead submissions (generate_lead)
Direct contacts (contact, phone_click, email_click, whatsapp_click)
Appointment bookings (appointment_start, appointment_booked)
Quote requests (quote_request)
Lead Submission Required Parameters: form_id, form_name.
Tool Name | Parameters | Description |
|
| Creates a new tracking plan after validating business_type and checking duplicate IDs. |
|
| Retrieves complete tracking plan definition. |
|
| Lists all tracking plans, optionally filtered by |
|
| Validates a tracking payload against plan schemas, returning errors and warnings. |
tracking-plan-mcp/
āāā data/
ā āāā tracking-plans.json # JSON persistence storage
āāā dist/ # Compiled JavaScript output
āāā src/
ā āāā index.ts # MCP Server entry point & tool registration
ā āāā models/
ā ā āāā tracking.ts # TypeScript types, Zod schemas, & ErrorCodes
ā āāā services/
ā ā āāā trackingPlanService.ts # Business logic & event validator
ā āāā storage/
ā ā āāā jsonStorage.ts # Safe JSON storage reader/writer
ā āāā tools/
ā āāā createTrackingPlan.ts # create_tracking_plan tool handler
ā āāā getTrackingPlan.ts # get_tracking_plan tool handler
ā āāā listTrackingPlans.ts # list_tracking_plans tool handler
ā āāā validateTrackingEvent.ts # validate_tracking_event tool handler
āāā tests/
ā āāā createTrackingPlan.test.ts
ā āāā getTrackingPlan.test.ts
ā āāā listTrackingPlans.test.ts
ā āāā validateTrackingEvent.test.ts
āāā .gitignore
āāā package.json
āāā tsconfig.json
āāā vitest.config.ts
āāā README.mdnpm installnpm testnpm run buildnpm startAdd to .cursor/mcp.json or Cursor MCP settings:
{
"mcpServers": {
"tracking-plan-mcp": {
"command": "node",
"args": ["C:/Users/FLS/.gemini/antigravity/scratch/tracking-plan-mcp/dist/index.js"]
}
}
}Add to .gemini/antigravity/mcp_config.json:
{
"mcpServers": {
"tracking-plan-mcp": {
"command": "node",
"args": ["C:/Users/FLS/.gemini/antigravity/scratch/tracking-plan-mcp/dist/index.js"]
}
}
}"Create an ecommerce GA4 tracking plan."
"Create a lead generation tracking plan for an HVAC business."
"Show me all ecommerce tracking plans."
"Show me all lead generation tracking plans."
"Validate this purchase event against the ecommerce tracking plan: { name: 'purchase', value: 99.99, currency: 'USD' }"
"Validate this lead form submission against the lead generation tracking plan: { name: 'generate_lead', form_id: 'f1', form_name: 'Contact Form' }"
Licensed under the MIT License.
Creates a new tracking plan specification for an ecommerce or lead-generation business.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique tracking plan ID (e.g. 'ecommerce-ga4', 'leadgen-hvac') | |
| name | Yes | Human readable tracking plan name | |
| events | Yes | List of tracking events with parameters | |
| platform | Yes | Target platform (e.g. 'GA4', 'Mixpanel', 'GTM') | |
| description | No | Description of the tracking plan purpose | |
| business_type | Yes | Target business type: 'ecommerce' or 'lead_generation' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It only says a plan is "created" and never states whether a duplicate id overwrites an existing plan, whether events are validated on creation, whether required permissions exist, or what the result looks like ā significant gaps for a mutation tool with a nested event/parameter structure.
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?
One front-loaded sentence with no filler, so it is efficiently sized. However, that brevity leaves behavioral questions unanswered for a 6-parameter, 5-required mutation tool, meaning the sentence is short but arguably under-committed.
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?
With no annotations, no output schema, and a nested events structure carrying required parameters, the description should address overwrite semantics, validation behavior, or at least confirm what happens on success. None of that is present, so the definition is materially incomplete for the tool's complexity.
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 id, name, platform, business_type, events, and description are already documented in the schema, and the description adds nothing beyond echoing the business_type enum values. Baseline 3 applies when the schema does the heavy lifting.
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 ("Creates") and resource ("tracking plan specification") and scopes it to two business types, so an agent can distinguish it from get/list/validate siblings by the write verb. It stops short of naming those siblings or stating that it is the only creation entry point, so sibling differentiation is implied rather than explicit.
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 gives no when-to-use guidance, no prerequisites, and no mention of the alternative siblings (get_tracking_plan, list_tracking_plans, validate_tracking_event). An agent must infer that this is the creation tool purely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a complete tracking plan definition by plan_id.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | ID of the tracking plan to retrieve (e.g. 'ecommerce-ga4') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Retrieves' implies a read operation, but there is no disclosure of permissions, behavior when the plan_id is missing, or whether the response includes all plan versions/details.
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?
A single front-loaded sentence with no wasted words. It states the operation and the key parameter immediately and appropriately for a simple lookup tool.
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?
For a single-parameter read with no output schema and no annotations, the description omits what a 'complete tracking plan definition' contains and how missing IDs are handled. It is minimally adequate given the low complexity.
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%, and plan_id already includes an example ('ecommerce-ga4') in the schema. The description only repeats 'by plan_id' without adding format or edge-case semantics, 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?
States a specific verb ('Retrieves'), resource ('tracking plan definition'), and scope ('by plan_id'), making the operation clear. It is distinguishable from list_tracking_plans and create_tracking_plan, though it does not explicitly name alternatives.
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 gives no explicit when-to-use guidance or alternatives. The phrase 'by plan_id' hints that a plan ID must be known, but it never mentions list_tracking_plans for discovery or any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available tracking plans with optional filtering by business_type ('ecommerce' or 'lead_generation').
| Name | Required | Description | Default |
|---|---|---|---|
| business_type | No | Optional filter by business type: 'ecommerce' or 'lead_generation' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, and it adds almost nothing beyond the name: no confirmation that this is read-only, no pagination or ordering behavior, no return shape, and no auth requirements. 'Lists all' hints at a safe read but that is inference, not disclosure.
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?
One front-loaded sentence with no filler; the filter and its allowed values come after the core action. Nothing is wasted, though it is terse enough that it could carry a little more context without bloating.
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?
For a one-optional-param list tool this is minimally adequate, but with no output schema and no annotations the description should say something about what a tracking plan record contains or how results are returned/paged. That gap leaves the agent without return-shape or safety context.
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% and the single parameter is a fully documented enum, so the schema already does the work. The description merely repeats the same enum values, adding no new semantics; baseline 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?
States a specific verb (lists) and resource (tracking plans) with scope ('all available'), which implicitly separates it from the singular get_tracking_plan sibling. It does not explicitly name or contrast with any sibling, so it stops 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?
The phrase 'all available ... with optional filtering' implies this is the enumeration/browse entry point versus get_tracking_plan or create_tracking_plan, but no when-to-use condition, prerequisite, or alternative is stated. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an analytics tracking event payload against a target tracking plan schema.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | Event payload object to validate, including name/event and parameter key-values | |
| plan_id | Yes | Target tracking plan ID (e.g. 'ecommerce-ga4' or 'leadgen-ga4') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It never states that validation is read-only/non-mutating, what a failed validation produces (error list, message shape), or any constraints, and with no output schema the agent has no idea what it gets back beyond an implied pass/fail.
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?
A single front-loaded sentence with no redundant or wasted phrasing. It is efficient, though its terseness leaves behavioral gaps that a slightly longer form could have closed.
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?
For a validation tool with a nested event object, no annotations, and no output schema, the agent needs to know the result format and whether the call mutates anything. Neither is covered, so the definition is incomplete for correct invocation and interpretation.
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% and both parameters (plan_id with examples, event payload object) are documented in the schema. The description adds no format or example detail beyond what the schema already provides, so the baseline 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?
Clear specific verb ('validates') plus resource ('analytics tracking event payload') and the standard it is checked against ('target tracking plan schema'). An agent can distinguish it from the sibling plan-read/create tools. It stops short of explicitly naming which sibling it pairs with or is not.
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 a QA/validation workflow via 'against a target tracking plan schema', but gives no explicit when-to-use, when-not, or prerequisite guidance. Nothing tells the agent to first resolve a plan with get_tracking_plan/list_tracking_plans before calling this.
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.0create_tracking_planget_tracking_planlist_tracking_plansvalidate_tracking_eventScored across 4 tools
Each tool has a distinct purpose: retrieve a single plan, list plans, create a plan, and validate an event. No overlapping functionality, and the boundaries are clear from names and descriptions.
All tools follow a consistent snake_case verb_noun pattern (get_, list_, create_, validate_). No deviations or mixed conventions.
Four tools is a lean and well-scoped set for tracking plan operations. Each tool serves a clear role without redundancy.
Core operations (create, read/list, validate event) are present, but missing update and delete operations leaves a notable gap in lifecycle management. Agents cannot modify or remove tracking plans.
MCP server for Modern Treasury ā payment orders, transactions, counterparties and ledgers.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Cross-product MCP server for CRM, LeadKit, ProjectKit, Bookio. 10 action types, MIT open spec.
MCP server for Product Management
