dtc-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log level: debug, info, warn, error | |
| SHOPIFY_STORE | No | Shopify store domain (*.myshopify.com) | |
| DTC_MCP_SANDBOX | No | Sandbox mode: auto, sidecar, or vm | |
| KLAVIYO_API_KEY | Yes | Klaviyo private API key (pk_...) | |
| DTC_MCP_DOCS_URL | No | Override docs source URL | |
| DTC_MCP_NODE_PATH | No | Absolute path to Node binary for sidecar | |
| SHOPIFY_CLIENT_ID | No | Dev Dashboard app Client ID | |
| SHOPIFY_API_VERSION | No | Shopify API version (default 2026-01) | |
| DTC_MCP_DOCS_REFRESH | No | Set to 0 to disable docs refresh | |
| SHOPIFY_ACCESS_TOKEN | No | Legacy custom app Admin API token (shpat_...) | |
| SHOPIFY_CLIENT_SECRET | No | Dev Dashboard app Client Secret (shpss_...) | |
| DTC_MCP_MAX_RESPONSE_KB | No | Max response size in KB (default 100) | |
| KLAVIYO_CONVERSION_METRIC_ID | No | Override auto-discovered Placed Order metric ID |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_codeA | execute_code(code: string) -> { ok, result, stdout, state, durationMs } state: current globalThis stash (auto-populated, summary-form — read this to see what data from prior calls is available without re-fetching) Sandbox globals: klaviyo, shopify, console, pick, topN, summarize, globalThis (persists across calls) Discovery: search_docs / read_doc surface SDK paths, parameter shapes, and recipes. The SDK uses JSON:API conventions (sort keys, sparse fieldsets) that differ from typical JS SDKs — search_docs FIRST for unfamiliar methods. Reference example (real API surface — note JSON:API request shape): const metricId = await klaviyo.getConversionMetricId(); const report = await klaviyo.reporting.campaignValues({ data: { type: 'campaign-values-report', attributes: { timeframe: { key: 'last_30_days' }, conversion_metric_id: metricId, statistics: ['recipients', 'open_rate', 'conversion_value'], }} }); globalThis.report = report; return topN(report.data.attributes.results, 5, r => r.statistics.conversion_value); |
| search_docsA | Search the bundled SDK reference docs for Klaviyo and Shopify methods exposed inside the execute_code sandbox. Returns ranked markdown chunks: method signatures, parameter descriptions, and runnable code examples. Use this BEFORE writing code in execute_code — the SDK surface is constrained to registered methods (escape hatches are 'klaviyo.get/post/paginate' and 'shopify.gql/ql'). The docs index is refreshed daily from a CDN-backed source repo, so new Klaviyo/Shopify API revisions land without requiring a new MCP release. |
| read_docA | Fetch a specific SDK docs chunk by exact path, or list all available paths when called with no args. Use this instead of search_docs when you already know the chunk ID — it's cheaper and more deterministic. Common patterns: • read_doc({}) → list every chunk ID with one-line summaries (use this once at the start of a session to map the SDK surface) • read_doc({ path: "klaviyo.reporting.campaignValues" }) → fetch one method's full doc (signature + JSDoc + example) verbatim • read_doc({ platform: "shopify" }) → list only Shopify chunk IDs This adopts the "filesystem-as-API" pattern from Anthropic's Code Execution with MCP research: LLMs are faster and more accurate when they can read a typed-source-of-truth doc page directly, rather than re-searching for it on every code generation. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools occupy clearly distinct roles: execute_code runs sandboxed code, while search_docs finds relevant documentation and read_doc fetches a specific doc chunk. Even though search_docs and read_doc both access documentation, their boundaries are explicit: search for exploration, read for deterministic retrieval by path.
All three tools follow a consistent verb_noun snake_case pattern: execute_code, search_docs, read_doc. This makes the tool's action and target immediately predictable.
Three tools are well-scoped for this server's purpose: one for code execution and two complementary docs-access tools. Each tool earnts its place and there is no bloat or redundancy.
The server covers its apparent lifecycle completely: discover what is available via read_doc/search_docs, then execute code against the constrained SDK with persistent globalThis state. There are no obvious dead ends or missing operations that would block an agent.