# RevCent MCP Guide: `EditTrackingDomain`

AI/MCP-focused guide for editing an existing RevCent Tracking Domain.

This document explains the `EditTrackingDomain` operation, when to use it, its schema, the important limitations around editing a Tracking Domain, URL Parameter Set handling, legacy `url_parameters`, and safe editing workflow.

---

## Required References

AI/MCP clients should read and reference these documents when working with Tracking Domains:

```text
https://revcent.com/documentation/markdown/mcp/operation/OverviewTrackingDomain.md
```

```text
https://revcent.com/documentation/markdown/mcp/operation/CreateTrackingDomain.md
```

Related operation references:

| Operation / Overview | Link | Why It Matters |
|---|---|---|
| Tracking Domain Overview | `https://revcent.com/documentation/markdown/mcp/operation/OverviewTrackingDomain.md` | Broad overview of Tracking Domains, DNS tracking, visitor tracking, URL parameter capture, metadata, conversion attribution, reporting, and setup lifecycle. |
| CreateTrackingDomain | `https://revcent.com/documentation/markdown/mcp/operation/CreateTrackingDomain.md` | Explains initial Tracking Domain creation, root-domain requirements, A records, SSL initialization, DNS initialization, and setup lifecycle. |
| GetTrackingDomain | `https://revcent.com/documentation/markdown/mcp/operation/GetTrackingDomain.md` | Retrieve the current Tracking Domain before editing and verify the result after editing. |
| GetTrackingDomains | | Locate an existing Tracking Domain when the ID is unknown. |
| GetUrlParameterSets | `https://revcent.com/documentation/markdown/mcp/operation/OverviewUrlParameterSet.md` | Retrieve reusable URL Parameter Sets before associating them with a Tracking Domain. |
| InitializeTrackingDomainSSL | `https://revcent.com/documentation/markdown/mcp/operation/InitializeTrackingDomainSSL.md` | Initializes SSL after A records are added. |
| InitializeTrackingDomainDNS | `https://revcent.com/documentation/markdown/mcp/operation/InitializeTrackingDomainDNS.md` | Completes DNS tracking setup after SSL is issued. |

---

## Operation Summary

Operation:

```text
EditTrackingDomain
```

Title:

```text
Edit A Tracking Domain
```

Purpose:

```text
Edit a previously created Tracking Domain using the Tracking Domain ID.
```

Use `EditTrackingDomain` to update editable Tracking Domain properties such as:

- name,
- description,
- associated URL Parameter Sets,
- legacy domain-specific URL parameters.

Important:

```text
EditTrackingDomain is a partial-edit operation.
Only include the properties you wish to modify.
```

If only changing the name, send only `tracking_domain_id` and `name`.

If only updating URL Parameter Sets, send only `tracking_domain_id` and `url_parameter_sets`.

Do not include unchanged fields.

---

## What Tracking Domains Do

A RevCent Tracking Domain enables first-party DNS tracking for a merchant-controlled root domain.

Tracking Domains help RevCent:

- track visitors,
- capture URL parameters,
- store URL parameter values as metadata,
- connect visitor activity to Sales/conversions,
- support campaign attribution,
- support affiliate attribution,
- improve ecommerce conversion reporting,
- support BigQuery attribution reports,
- make sale lifecycle analysis more granular.

Simple model:

```text
Visitor lands on tracked domain with URL parameters
    ↓
RevCent DNS tracking / Track.js captures visitor and parameters
    ↓
Selected URL parameter values are stored as metadata
    ↓
Customer later purchases
    ↓
Sale/conversion can be attributed to visitor and metadata
```

---

## Critical Limitation: The Domain Cannot Be Edited

The root domain associated with a Tracking Domain cannot be modified after creation.

`GetTrackingDomain` describes `domain` as:

```text
The root domain associated with the tracking domain. Cannot be modified once a tracking domain is created.
```

Therefore:

```text
EditTrackingDomain cannot change the root domain.
```

If the wrong domain was created, the usual fix is:

```text
Create a new Tracking Domain for the correct root domain.
```

Do not attempt to edit:

```text
domain
```

because it is not part of the `EditTrackingDomain` input schema.

---

## What EditTrackingDomain Does Not Do

`EditTrackingDomain` does not:

- change the root domain,
- create DNS A records,
- initialize SSL,
- issue SSL,
- create SSL CNAME records,
- initialize DNS tracking,
- verify DNS records,
- install Track.js,
- configure WooCommerce plugin DNS tracking,
- create URL Parameter Sets,
- run reporting queries,
- retroactively rewrite historical metadata or conversions.

For DNS/SSL setup, use the Tracking Domain setup operations described in `CreateTrackingDomain` and the Tracking Domain overview.

For reporting, use BigQuery.

For creating reusable URL Parameter Sets, use the URL Parameter Set operations.

---

## Input Schema

`EditTrackingDomain` input schema:

```text
type: object
additionalProperties: false
required:
  - tracking_domain_id
```

Only send supported fields.

---

## Required Field

| Field | Type | Required | Description |
|---|---:|---:|---|
| `tracking_domain_id` | string | Yes | 20-character Tracking Domain ID. |

Example minimal shape:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT"
}
```

In practice, include at least one editable field in addition to `tracking_domain_id`.

---

## Editable Fields

| Field | Type | Purpose |
|---|---:|---|
| `name` | string | Update the Tracking Domain name. Must be unique from other Tracking Domain names. |
| `description` | string | Update the Tracking Domain description. |
| `url_parameter_sets` | array[string] | Replace/modify associated reusable URL Parameter Set IDs. |
| `url_parameters` | array[object] | Legacy/manual domain-specific URL parameters. Prefer URL Parameter Sets instead. |

---

## Output Schema

Successful output can include:

| Field | Type | Description |
|---|---:|---|
| `api_call_id` | string | 20-character API call ID. |
| `api_call_unix` | integer | Unix timestamp when the API call was initiated. |
| `code` | integer | API response code. `1` indicates success. |
| `tracking_domain_id` | string | 20-character Tracking Domain ID. |
| `result` | string | Result message. |

After editing, use `GetTrackingDomain` to verify the saved configuration.

---

## Always Retrieve Before Editing

Before calling `EditTrackingDomain`, use:

```text
GetTrackingDomain
```

This lets AI/MCP inspect:

- current name,
- description,
- enabled state,
- immutable root domain,
- URL Parameter Sets,
- legacy URL parameters,
- A records,
- SSL status,
- SSL CNAME records,
- DNS status.

Recommended workflow:

```text
GetTrackingDomain
    ↓
Review current configuration
    ↓
Identify exactly what should change
    ↓
Confirm user intent
    ↓
Call EditTrackingDomain with only intended fields
    ↓
Call GetTrackingDomain again to verify
```

Do not edit blindly.

---

## Editing `name`

Use `name` when the user wants a clearer internal label.

Example:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "name": "Main Store Tracking"
}
```

Good names:

```text
Main Store Tracking
Example.com Tracking
Brand A Tracking Domain
Primary WooCommerce Tracking
Production Conversion Tracking
```

Avoid vague names:

```text
Test
Tracking
Domain
New Domain
```

---

## Editing `description`

Use `description` to document the Tracking Domain's purpose.

Example:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "description": "Production tracking domain for example.com. Used for RevCent DNS tracking, visitor attribution, URL parameter metadata, WooCommerce conversion tracking, and BigQuery reporting."
}
```

A good description should mention:

- root domain,
- store/brand,
- production/test purpose,
- checkout/storefront context,
- expected traffic sources,
- URL parameter strategy,
- whether WooCommerce plugin or Track.js is used,
- reporting/attribution purpose.

---

## URL Parameter Sets

`url_parameter_sets` is the recommended approach for managing URL parameters.

Schema:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameter_sets": [
    "PPPPPPPPPPPPPPPPPPPP"
  ]
}
```

`url_parameter_sets` is an array of URL Parameter Set IDs.

Rules:

- IDs must be valid URL Parameter Sets created in RevCent.
- Use `GetUrlParameterSets` to retrieve existing URL Parameter Sets.
- If `url_parameter_sets` is not provided, existing URL Parameter Sets remain unchanged.
- To remove all URL Parameter Sets, provide an empty array.

Important:

```text
URL Parameter Sets are preferred over domain-specific url_parameters.
```

Why URL Parameter Sets are better:

- reusable across multiple Tracking Domains,
- easier to maintain,
- more organized,
- avoids duplicate parameter definitions,
- easier for AI/MCP to reason about,
- reduces inconsistent metadata naming between domains.

---

## Editing `url_parameter_sets`

Use this when the user wants to associate a Tracking Domain with reusable URL Parameter Sets.

Example: replace current associated sets with two sets:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameter_sets": [
    "PPPPPPPPPPPPPPPPPPPP",
    "QQQQQQQQQQQQQQQQQQQQ"
  ]
}
```

Example: remove all URL Parameter Sets:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameter_sets": []
}
```

Important:

```text
Providing url_parameter_sets changes the Tracking Domain's associated URL Parameter Sets.
Omitting url_parameter_sets leaves the existing association unchanged.
```

Before removing all URL Parameter Sets, confirm the user understands this may stop future capture of those reusable URL parameters for this Tracking Domain.

---

## Legacy `url_parameters`

`url_parameters` is a legacy/manual approach to saving URL parameters specific to one Tracking Domain.

The schema explicitly recommends using URL Parameter Sets instead of saving URL parameters directly on a domain.

Use `url_parameters` only when:

- the parameter truly applies only to this one Tracking Domain,
- the user explicitly wants domain-specific parameter behavior,
- URL Parameter Sets are not appropriate for the use case,
- maintaining the configuration directly on this domain is intentional.

Prefer:

```text
url_parameter_sets
```

over:

```text
url_parameters
```

---

## `url_parameters` Schema

Each item in `url_parameters` can include:

| Field | Type | Purpose |
|---|---:|---|
| `url_parameter` | string | Query parameter to capture, such as `utm_source`. |
| `metadata_name` | string | Metadata name to save the value as. If empty, the URL parameter name is used. |
| `default_value` | string | Optional default value to save instead of the URL value when the parameter is present. |
| `days` | integer | Number of days to persist the parameter for the visitor. Defaults to 30 if not provided. |

Example:

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameters": [
    {
      "url_parameter": "utm_source",
      "metadata_name": "utm_source",
      "days": 30
    },
    {
      "url_parameter": "utm_campaign",
      "metadata_name": "utm_campaign",
      "days": 30
    }
  ]
}
```

---

## URL Parameter Field Details

### `url_parameter`

The URL query parameter to capture.

Examples:

```text
utm_source
utm_medium
utm_campaign
utm_content
utm_term
gclid
fbclid
ttclid
msclkid
affiliate_id
sub_id
click_id
ad_id
adset_id
creative_id
```

Example visitor URL:

```text
https://example.com/?utm_source=google&utm_campaign=spring_sale&gclid=abc123
```

If `utm_source` is configured, RevCent can save:

```text
utm_source = google
```

as visitor metadata and later attach that metadata to resulting Sales/conversions.

---

### `metadata_name`

The metadata name to save the URL parameter value as in RevCent.

Recommended:

```text
Leave empty or use the same value as url_parameter.
```

Example:

```json
{
  "url_parameter": "utm_source",
  "metadata_name": "utm_source"
}
```

If `metadata_name` is empty:

```text
RevCent saves the URL parameter value using the URL parameter name.
```

Example:

```text
url_parameter = utm_source
metadata_name empty
saved metadata name = utm_source
```

Use a different `metadata_name` only when the business intentionally wants normalized or renamed metadata.

Example:

```json
{
  "url_parameter": "utm_source",
  "metadata_name": "source"
}
```

This saves:

```text
source = google
```

instead of:

```text
utm_source = google
```

---

### `default_value`

Optional.

`default_value` is used when the URL parameter is present but the user wants RevCent to save a fixed/default value instead of the actual URL value.

Example:

```json
{
  "url_parameter": "utm_source",
  "metadata_name": "utm_source",
  "default_value": "organic",
  "days": 30
}
```

If URL contains:

```text
?utm_source=anything
```

RevCent saves:

```text
utm_source = organic
```

Recommended:

```text
Leave default_value empty unless there is a specific business reason to override actual URL values.
```

---

### `days`

Optional.

`days` controls how long RevCent persists the URL parameter value for the visitor.

If not provided:

```text
RevCent uses the default value of 30 days.
```

Recommended value:

```text
30
```

Example:

```json
{
  "url_parameter": "utm_source",
  "metadata_name": "utm_source",
  "days": 30
}
```

Use a different value only when the business has a clear attribution-window reason.

---

## Recommended URL Parameters for Ecommerce

Common URL parameters to capture for ecommerce attribution:

| Parameter | Purpose |
|---|---|
| `utm_source` | Traffic source, such as Google, Meta, email, affiliate, TikTok. |
| `utm_medium` | Channel, such as cpc, social, email, organic. |
| `utm_campaign` | Campaign name. |
| `utm_content` | Creative, variation, email block, or link variation. |
| `utm_term` | Keyword/search term. |
| `gclid` | Google Ads click ID. |
| `fbclid` | Facebook/Meta click ID. |
| `ttclid` | TikTok click ID. |
| `msclkid` | Microsoft Ads click ID. |
| `affiliate_id` | Affiliate/partner ID. |
| `sub_id` | Affiliate sub ID. |
| `sub_id_2` | Secondary affiliate sub ID. |
| `click_id` | Generic click ID. |
| `campaign_id` | External campaign identifier. |
| `ad_id` | Ad identifier. |
| `adset_id` | Ad set identifier. |
| `creative_id` | Creative identifier. |
| `landing_page` | Landing page identifier. |

Best practice:

```text
Use descriptive parameter and metadata names.
```

Poor:

```text
s
c
x
```

Better:

```text
utm_source
utm_campaign
affiliate_id
ad_id
```

Descriptive metadata improves reporting, BigQuery analysis, AI Assistant workflows, attribution, refund/chargeback analysis, and customer lifecycle reporting.

---

## Metadata Impact

URL parameter edits affect future metadata capture.

When URL parameters are captured, their values can be attached to visitor and sale/conversion context.

This enables:

- granular campaign reporting,
- ad click attribution,
- affiliate attribution,
- customer journey analysis,
- refund analysis by traffic source,
- chargeback analysis by campaign/source,
- subscription lifecycle attribution,
- AI Assistant workflow decisions,
- BigQuery reporting.

Important:

```text
Editing URL parameter configuration affects future tracking behavior.
It does not retroactively rewrite already-captured historical metadata.
```

---

## Editing URL Parameters Safely

Before editing URL parameters or URL Parameter Sets, confirm:

- which parameters should be captured,
- metadata names,
- attribution window in days,
- whether URL Parameter Sets should be used instead,
- whether existing URL Parameter Sets should remain,
- whether removing sets is intentional,
- whether any downstream reports depend on current metadata names,
- whether AI workflows use current metadata names,
- whether affiliate/campaign reporting depends on current parameters.

Changing metadata names can break reporting consistency if reports expect the old names.

---

## Example: Rename Only

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "name": "Example.com Production Tracking"
}
```

---

## Example: Description Only

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "description": "Production DNS tracking domain for example.com. Captures attribution parameters for WooCommerce Sales, RevCent Sales, subscriptions, and BigQuery conversion reporting."
}
```

---

## Example: Associate URL Parameter Sets

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameter_sets": [
    "PPPPPPPPPPPPPPPPPPPP",
    "QQQQQQQQQQQQQQQQQQQQ"
  ]
}
```

---

## Example: Remove All URL Parameter Sets

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameter_sets": []
}
```

Use only when the user explicitly wants to remove all reusable URL Parameter Set associations.

---

## Example: Legacy Domain-Specific URL Parameters

Use only when the parameters should exist directly on this Tracking Domain instead of through reusable URL Parameter Sets.

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "url_parameters": [
    {
      "url_parameter": "utm_source",
      "metadata_name": "utm_source",
      "days": 30
    },
    {
      "url_parameter": "utm_medium",
      "metadata_name": "utm_medium",
      "days": 30
    },
    {
      "url_parameter": "gclid",
      "metadata_name": "gclid",
      "days": 30
    }
  ]
}
```

---

## Example: Combined Intentional Edit

Only combine fields when the user explicitly wants all changes.

```json
{
  "tracking_domain_id": "TTTTTTTTTTTTTTTTTTTT",
  "name": "Main Store Tracking",
  "description": "Tracks visitor attribution and URL parameters for example.com.",
  "url_parameter_sets": [
    "PPPPPPPPPPPPPPPPPPPP"
  ]
}
```

For safer review, separate risky edits:

```text
Edit 1: name / description
Edit 2: URL Parameter Sets
Edit 3: domain-specific legacy URL parameters, if absolutely required
```

---

## Tracking Domain Readiness Is Separate

Editing name, description, or URL parameters does not make a Tracking Domain DNS-ready.

DNS readiness depends on the setup lifecycle from `CreateTrackingDomain`:

```text
CreateTrackingDomain
    ↓
Add A records
    ↓
InitializeTrackingDomainSSL
    ↓
Add CNAME records
    ↓
SSL status becomes ISSUED
    ↓
InitializeTrackingDomainDNS
    ↓
DNS status becomes COMPLETE
```

A Tracking Domain is ready when:

```text
ssl.status = ISSUED
dns.status = COMPLETE
```

Use `GetTrackingDomain` to check those statuses.

---

## WooCommerce / Third-Party Shop Guidance

For WooCommerce and other supported third-party shops, Tracking Domains are important because they allow the store's domain to participate in RevCent's tracking and attribution.

A WooCommerce store should have the store's domain DNS-complete in RevCent for tracking so visitor/source metadata can attach to Sales and their lifecycle.

When editing a Tracking Domain for a WooCommerce store:

- do not change the immutable root domain,
- preserve attribution parameters used by the store,
- use URL Parameter Sets for reusable attribution definitions,
- ensure the store/plugin is configured to pass visitor/conversion context correctly,
- confirm metadata names align with reporting expectations.

---

## BigQuery and Reporting

Do not use `EditTrackingDomain` for reporting.

Use BigQuery for reporting and analysis.

Tracking Domain URL parameters and metadata can support reports such as:

- revenue by `utm_source`,
- revenue by `utm_campaign`,
- subscriptions by `gclid`,
- refunds by affiliate ID,
- chargebacks by source/campaign,
- customer lifetime value by traffic source,
- WooCommerce sales by ad click ID,
- campaign conversion rates,
- subscription renewal revenue by original acquisition source.

Correct operation choice:

| Need | Correct Operation |
|---|---|
| Change Tracking Domain configuration | `EditTrackingDomain` |
| Retrieve Tracking Domain configuration/status | `GetTrackingDomain` |
| Find Tracking Domains | `GetTrackingDomains` |
| Create a new Tracking Domain | `CreateTrackingDomain` |
| Manage reusable URL parameter definitions | URL Parameter Set operations |
| Report on attribution/metadata | `BigQueryRunQuery` |

---

## Recommended Edit Workflow

```text
1. User asks to edit a Tracking Domain.
2. If tracking_domain_id is unknown, use GetTrackingDomains.
3. Use GetTrackingDomain to retrieve current configuration.
4. Confirm the user is not trying to change the immutable root domain.
5. Identify exactly what should change:
       name
       description
       url_parameter_sets
       url_parameters
6. Prefer URL Parameter Sets over direct url_parameters.
7. If using url_parameter_sets, retrieve valid IDs with GetUrlParameterSets.
8. Confirm whether existing URL Parameter Sets should remain or be replaced.
9. Build EditTrackingDomain request with only intended fields.
10. Call EditTrackingDomain.
11. Use GetTrackingDomain to verify.
12. If DNS/SSL readiness is the real issue, use setup/status operations instead.
```

---

## Pre-Edit Checklist

Before calling `EditTrackingDomain`, verify:

- Tracking Domain ID is correct.
- Current Tracking Domain was retrieved with `GetTrackingDomain`.
- User explicitly confirmed the edit.
- Only intended fields are included.
- The user is not trying to change the root domain.
- If wrong root domain was used, a new Tracking Domain should be created.
- If editing URL Parameter Sets, valid URL Parameter Set IDs are known.
- If providing an empty `url_parameter_sets` array, removal of all sets is intentional.
- If editing legacy `url_parameters`, URL Parameter Sets were considered first.
- Metadata names are intentional.
- Attribution window (`days`) is intentional.
- Downstream reports/AI workflows will not unexpectedly break due to metadata name changes.
- User understands edits affect future tracking behavior, not historical metadata.

---

## Best Practices

1. Retrieve with `GetTrackingDomain` before editing.
2. Only include fields that should change.
3. Do not attempt to edit `domain`; it is immutable.
4. Create a new Tracking Domain if the wrong root domain was used.
5. Prefer `url_parameter_sets` over legacy `url_parameters`.
6. Use `GetUrlParameterSets` to retrieve valid URL Parameter Set IDs.
7. Use descriptive URL parameter and metadata names.
8. Leave `metadata_name` empty or equal to `url_parameter` unless normalization is intentional.
9. Leave `default_value` empty unless overriding real URL values is intentional.
10. Use `days = 30` unless the attribution window should differ.
11. Confirm before clearing all URL Parameter Sets.
12. Verify after editing with `GetTrackingDomain`.
13. Use BigQuery for tracking/attribution reporting.
14. Use the Tracking Domain overview for broader DNS/visitor/conversion context.
15. Use the CreateTrackingDomain guide for DNS/SSL setup lifecycle.

---

## Common Mistakes to Avoid

Do not:

- try to change the root domain with `EditTrackingDomain`,
- include unsupported fields,
- send all fields when only one field should change,
- remove all URL Parameter Sets accidentally,
- use legacy `url_parameters` when URL Parameter Sets are better,
- change metadata names without considering reporting impact,
- set arbitrary `default_value` values that hide real URL data,
- guess URL Parameter Set IDs,
- assume editing a Tracking Domain completes DNS/SSL setup,
- call tracking domain ready before `ssl.status = ISSUED` and `dns.status = COMPLETE`,
- use `EditTrackingDomain` for reporting,
- expect historical metadata to be rewritten after editing future capture settings.

---

## AI/MCP Decision Guide

| User Intent | Correct Action |
|---|---|
| Rename Tracking Domain | Use `EditTrackingDomain` with `name` only. |
| Update description | Use `EditTrackingDomain` with `description` only. |
| Change root domain | Cannot edit; create a new Tracking Domain. |
| Add reusable parameter definitions | Use `url_parameter_sets` with valid URL Parameter Set IDs. |
| Remove all URL Parameter Sets | Send `url_parameter_sets: []` only after explicit confirmation. |
| Add one-off domain-specific parameters | Use legacy `url_parameters` only when URL Parameter Sets are not appropriate. |
| Check DNS/SSL status | Use `GetTrackingDomain`. |
| Complete SSL/DNS setup | Use `InitializeTrackingDomainSSL` / `InitializeTrackingDomainDNS`. |
| Report on attribution or metadata | Use `BigQueryRunQuery`. |
| Understand tracking concepts | Read `OverviewTrackingDomain.md`. |
| Understand setup lifecycle | Read `CreateTrackingDomain.md`. |

---

## Final AI/MCP Instruction

Use `EditTrackingDomain` to modify editable properties of an existing RevCent Tracking Domain.

It is a partial-edit operation, so only include fields that should change. The root `domain` cannot be modified after creation; if the wrong root domain was created, create a new Tracking Domain instead.

Prefer reusable `url_parameter_sets` over legacy domain-specific `url_parameters`. URL parameter configuration affects future visitor metadata capture and attribution, so edit carefully and verify with `GetTrackingDomain` after saving.

For broader Tracking Domain context, read:

```text
https://revcent.com/documentation/markdown/mcp/operation/OverviewTrackingDomain.md
```

For initial creation and DNS/SSL setup lifecycle, read:

```text
https://revcent.com/documentation/markdown/mcp/operation/CreateTrackingDomain.md
```


---
Document Parent Directory
* [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.