Code-execution MCP server for Klaviyo + Shopify analytics. The LLM writes TypeScript against typed SDKs in a stateful V8 sandbox — three composable tools instead of dozens.
dtc-mcp registers three tools with descriptions and partial schemas. However, critical gaps prevent a higher score: (1) execute_code lacks parameter descriptions for 'timeoutMs' beyond a bare label; (2) search_docs and read_doc have minimal input documentation; (3) no output schemas are documented anywhere in the source; (4) error handling and recovery guidance are absent; (5) no input validation guidance or constraints on code execution timeout ranges. The server is STDIO-only, which is a hard transport cap at 50, but definition quality issues independently limit it further. Naming is reasonable (execute_, search_, read_) but descriptions are terse and lack 'what to do if it fails' guidance.
Execute TypeScript code in a stateful V8 sandbox with access to Klaviyo and Shopify SDKs
Read a specific documentation page
Search documentation for Klaviyo and Shopify APIs
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields when schema is invisible.
Parameter descriptions are minimal. 'timeoutMs' in execute_code has only 'Timeout in milliseconds for code execution', no range (min/max), no default, no guidance on when to use.
No error handling or recovery guidance. If execute_code times out or fails, the LLM receives no hint on what to do next (retry? reduce timeout? split code?).
search_docs and read_doc descriptions are extremely brief (34 - 40 chars). They lack context on when to use search vs. direct read, what documentation they cover (Klaviyo? Shopify? both?), and what structure they return.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No input validation constraints visible. execute_code accepts arbitrary TypeScript, no guidance on unsafe patterns, injection risks, or allowed SDK methods.