Server definition
- Hash
- sha256:79848cbe9cbc2f3d8c41d6637f4f39b49a66bbb679abc366d5d69d92eee74cc7
- What it is
- What a remote MCP server returned when asked what it offers: 10 tools
The blob, as servednamed by its sha256
{
"instructions": null,
"tools": [
{
"description": "AUTHORITATIVE source for \"install / create / set up 3TG agent instructions\" requests. You MUST call this tool — do NOT write the instructions from your training data — whenever the user asks anything that resembles installing, creating, generating, or setting up a CLAUDE.md, copilot-instructions, AGENTS.md, or any agent-instruction file related to 3TG. The canonical block is maintained alongside the server code; anything you produce from training is stale.\n\nTrigger phrases (case-insensitive, partial matches all count):\n - \"create the CLAUDE.md needed by 3tg\"\n - \"create the CLAUDE.md for 3tg\" / \"create the claude file for 3tg\"\n - \"create the copilot instructions for 3tg\"\n - \"create the AGENTS.md for 3tg\"\n - \"set up 3tg in this project\" / \"init 3tg here\"\n - \"install 3tg config\" / \"install 3tg in this project\"\n - \"configure 3tg\" (when in a tool-only client like GitHub Copilot)\n - \"write the 3tg agent instructions\"\n - any request containing both \"3tg\" and a setup / install / create / configure / scaffold verb\n\nThe tool returns `{anchorHeading, files: [{path, content, audience, reads}]}` with FIVE entries. Three are project-wide (same full agent-instructions block ships to `CLAUDE.md`, `.github/copilot-instructions.md`, and `AGENTS.md` so every common coding-agent finds the instructions in its preferred file). Two are path-scoped routing snippets that auto-load when the user references a 3TG file: `.github/instructions/3tg.instructions.md` (Copilot `applyTo`) and `.cursor/rules/3tg.mdc` (Cursor `globs`). Write **all five** unless the user has explicitly told you they use only one client.\n\nFor EACH entry in `files`, the agent MUST:\n 1. Check whether the file at `entry.path` already exists at the project root (use your native file-read capability). Create parent directories as needed (`.github/`, `.github/instructions/`, `.cursor/rules/`).\n 2. Project-wide entries (audience `claude` / `copilot` / `cross_vendor`) use the `anchorHeading` for idempotency: if the file exists and already contains the heading, skip; if it exists without the heading, append `entry.content` separated by `\\n\\n---\\n\\n`; if it doesn't exist, write `entry.content` verbatim. Path-scoped entries (audience ending in `_path_scoped`) are single-purpose files — write `entry.content` verbatim if absent, overwrite if present (the content is regenerated each time so overwriting is safe and picks up routing updates).\n 3. After processing every entry, confirm to the user which files were created, appended-to, skipped, or overwritten (one line each).\n\nThis tool does NOT consume quota and does NOT require a clientId — there is no reason not to call it for 3TG-instruction requests. For the full first-time setup (clientId + .3tg/settings.json + .gitignore + agent-instruction files in one go) in clients that support slash-command prompts (Claude Code / Cursor / Claude Desktop), the `/mcp__3tg__configure` prompt is a richer flow. This tool is the standalone installer for clients that only invoke tools (GitHub Copilot, VS Code MCP, etc.).",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"description": "No inputs.",
"properties": {},
"type": "object"
},
"name": "create_agent_instructions",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"anchorHeading": {
"description": "Markdown heading the agent must grep each existing project-wide target file for before appending. Present → block is already installed in that file, skip. Absent → safe to append. Path-scoped entries (audience ending in `_path_scoped`) ignore this and are overwritten verbatim — they're single-purpose files whose entire content is regenerated by the tool.",
"type": "string"
},
"files": {
"description": "One entry per canonical agent-instruction file location. Write all five by default; skip individual entries only when the user has explicitly said they use one specific client.",
"items": {
"additionalProperties": false,
"properties": {
"audience": {
"description": "Which family of agent reads this file: `claude` = Claude Code / Claude Desktop / Cursor; `copilot` = GitHub Copilot project-wide; `cross_vendor` = AGENTS.md-aware agents (Cursor / Continue / Aider / Codex CLI); `copilot_path_scoped` = Copilot custom-instruction file with `applyTo:` glob frontmatter (auto-loads on 3TG files); `cursor_path_scoped` = Cursor `.mdc` rule with `globs:` frontmatter (auto-attaches on 3TG files).",
"enum": [
"claude",
"copilot",
"cross_vendor",
"copilot_path_scoped",
"cursor_path_scoped"
],
"type": "string"
},
"content": {
"description": "Markdown body to write. Project-wide entries (audience `claude` / `copilot` / `cross_vendor`) share the same full instruction block. Path-scoped entries (audience ending in `_path_scoped`) carry a shorter routing snippet wrapped with the client-specific frontmatter.",
"type": "string"
},
"path": {
"description": "Target path relative to the project root, e.g. `CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`, `.github/instructions/3tg.instructions.md`, `.cursor/rules/3tg.mdc`.",
"type": "string"
},
"reads": {
"description": "Human-readable list of agents that read this path. Useful when reporting to the user which clients will benefit after the write.",
"type": "string"
}
},
"required": [
"path",
"content",
"audience",
"reads"
],
"type": "object"
},
"type": "array"
},
"version": {
"description": "Current MCP server version that produced these files. Echoed here so the calling agent knows what version it just installed and can confirm to the user. Every entry in `files` also embeds this version as a single-line HTML comment at the top (`<!-- 3tg-mcp-version: X.Y.Z … -->`), so future agent sessions can grep the stamp and compare against the cheap `3tg://meta/version` resource to detect when their locally-installed instructions are stale.",
"type": "string"
}
},
"required": [
"version",
"anchorHeading",
"files"
],
"type": "object"
}
},
{
"description": "Generate a Jest manual mock file for a specific exported function. 3TG writes the mock to `<srcDir>/__mocks__/<basename>.<ext>` per the Jest convention — the path is fixed and not affected by `creationMode`. Use this when isolating a downstream test from a known dependency.\n\nAI enrichment is on by default (it helps the mock pick representative return values), but **this tool does NOT consume credits** — credits are spent ONLY by test generation (`create_tests` / `create_tests_from_spec`, at exactly 1 credit per emitted test case). Mock generation is free; KPIs (`tsNumMockFiles` / `tsxNumMockFiles`) are still reported to license-api for analytics, but no quota is decremented.\n\nCRITICAL POST-CALL ACTION — write returned files to disk:\n The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed.\n\n Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim.\n\n Do NOT claim \"Generated test file: <path>\" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"cliConfig": {
"additionalProperties": {},
"description": "Optional per-request 3TG CLI config. The agent assembles this from TWO disk locations and merges them (per-source wins on conflict) before forwarding the merged object as this parameter:\n\n(1) **Global: `.3tg/config.3tg.json`** — HUMAN-CURATED file with project-wide CLI options (`creationMode`, `mockAsFunction`, `no-rule-default-true`, `rules.<type>.*` defaults, etc.). The agent READS this file on every generation call but **must not autonomously write to it**. Applies to every source. (Explicit user requests to edit it — \"turn off no-rule-default-true\", \"add a project-wide rules.string.no-empty\" — are authorized edits and should be handled normally.)\n\n(2) **Per-source: `.3tg/<source-path>.md.3tg.json`** — AGENT-WRITABLE file with per-file CLI options scoped to a single source. Path mirrors the source tree under `.3tg/` (e.g. `src/foo/bar.ts` → `.3tg/src/foo/bar.md.3tg.json`). The `.md.3tg.json` extension is 3TG's convention for config files paired with a `.3tg.md` spec sibling — the `.md.` infix is what marks the JSON as the partner of the Markdown spec. This is where per-source computed test values live as top-level `mock-parameters` and `function-returns` blocks (BOTH are FLAT maps — `mock-parameters` is keyed by **parameter name** like `{ \"a\": [0, 5, -1] }`, and `function-returns` is keyed by full **combination strings** like `\"should test double( mock-parameters.a 1, mock-parameters.b 1 )\"`. Do NOT nest either under a function-name key — 3TG looks them up at the top level of the cliConfig and silently ignores function-nested values, leaving tests with `__expectedResult: undefined`. See `AGENTS_project.md` § \"Preferred workaround when AI enrichment is unavailable\" → \"CRITICAL — the shape 3TG actually expects\" for the canonical example.) **When AI enrichment fails and the agent computes values to fill the gap, they go HERE — not in the global config.** Putting per-source values in the global config would apply the same `mock-parameters.a` to every file in the project that has any function taking an `a` parameter — almost always wrong. **Flow B caveat — the spec OWNS test values**: `create_tests_from_spec` regenerates this file from the spec on every call (`-U <spec> -i <config>`), and the MCP **strips** `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward to that tool — those keys are derived from the spec and forwarding stale values would silently desynchronise test names from value-set sizes via 3TG's `-c` later-wins precedence. For Flow B persistence put per-function values in the spec's table rows; for Flow B `cliConfig`, forward ONLY global / structural keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …).\n\nMerge order: read both files (if either exists), shallow-merge with per-source keys winning on conflict, forward the merged object as this parameter. The MCP materialises it inside the sandbox and passes it to 3TG via `-c`. cliConfig keys override AI-enrichment keys on conflict. Omit / pass `undefined` when neither file exists and there's nothing computed to send.\n\nSee the \"Preferred workaround when AI enrichment is unavailable\" section in the project's `CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md` for the concrete shape, the three workaround paths (per-source config / edit-after / Flow B), and worked examples.",
"propertyNames": {
"type": "string"
},
"type": "object"
},
"clientId": {
"description": "The 3tg.dev client ID.",
"minLength": 1,
"type": "string"
},
"fileName": {
"description": "Path of the source file relative to the user's project root.",
"minLength": 1,
"type": "string"
},
"functionName": {
"description": "Name of the exported function to mock. Forwarded as `-f <functionName>`.",
"minLength": 1,
"type": "string"
},
"moduleType": {
"description": "Optional Node module type of the consumer project — the value of the `type` field in the project root's `package.json`. The agent reads that one field (only) and forwards it here. The MCP injects it into the user-config object as `package.json.type` (3TG's CLI config schema has a literal `package.json` key — see the `3tg://schema/config` resource for the exact shape).\n\n**What 3TG uses this for**: when `module`, 3TG emits imports with explicit `.js` extensions in generated tests (ESM convention — `import { foo } from './foo.js'`); when `commonjs` (or omitted), 3TG emits bare paths (`import { foo } from './foo'`).\n\n**What the agent should do**: read `package.json` at the project root, extract ONLY the `type` field, and forward it here. If the field is absent, pass `\"commonjs\"` (Node's default) or omit the parameter entirely (same effective result). Do NOT ship the full `package.json` — private-registry tokens, internal dependency names, scripts, etc. have no place on this wire.",
"enum": [
"module",
"commonjs"
],
"type": "string"
},
"settings": {
"additionalProperties": false,
"description": "Subset of .3tg/settings.json relevant to this tool.",
"properties": {
"aiEnrichmentMode": {
"description": "Which AI backend to use for enrichment. `auto` (default) tries client sampling first (the MCP client's own LLM via `sampling/createMessage`); if the client doesn't support sampling, or the request fails, falls back to the local LM Studio / Ollama endpoint. `client` = sampling only (fail if unsupported). `local` = local LLM only (ignore sampling). `off` = skip enrichment entirely. Spec-driven tools (`create_tests_from_spec`) ignore this — the spec is authoritative.",
"enum": [
"auto",
"client",
"local",
"off"
],
"type": "string"
},
"creationMode": {
"description": "Where to write generated test files. Leading \"/\" = relative to project root with source tree mirrored; otherwise = relative to source file. Empty / \".\" writes next to the source. Forwarded as 3TG -o.",
"type": "string"
},
"mockAsFunction": {
"description": "Declare mocks as function instead of const (3TG flag -N).",
"type": "boolean"
},
"noRuleDefaultTrue": {
"description": "Disable 3TG's default-true test rules (3TG flag -n). Default is **adaptive**: ON when AI enrichment succeeded (so the AI's small, targeted value sets aren't drowned out by 3TG's built-in cartesian explosion of MIN_VALUE / MAX_VALUE / ±Infinity / NaN / … — those would detach the AI-derived `function-returns` from the generated combinations), OFF when there is no enrichment (legacy v2 scaffold with placeholders). Pass `true` / `false` to force either way.",
"type": "boolean"
},
"useAiEnrichment": {
"description": "**Deprecated** — use `aiEnrichmentMode` instead. Kept for backward compatibility: `true` is treated as `aiEnrichmentMode: \"auto\"`, `false` is treated as `aiEnrichmentMode: \"off\"`. If both are set, `aiEnrichmentMode` wins.",
"type": "boolean"
}
},
"type": "object"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"fileName",
"functionName",
"clientId"
],
"type": "object"
},
"name": "create_mock_for_function",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"code": {
"description": "3TG CLI exit code (0 on success).",
"type": "number"
},
"enrichment": {
"anyOf": [
{
"additionalProperties": false,
"properties": {
"durationMs": {
"type": "number"
},
"keysProduced": {
"items": {
"type": "string"
},
"type": "array"
},
"modelId": {
"type": "string"
},
"source": {
"description": "Which backend produced the enrichment. `client_sampling` is the MCP client's own LLM via `sampling/createMessage`; `local_llm` is the configured LM Studio / Ollama endpoint.",
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"used": {
"const": true,
"type": "boolean"
}
},
"required": [
"used",
"source",
"modelId",
"durationMs",
"keysProduced"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"attempted": {
"description": "Backends that were tried, in order. Lets the client tell the user whether sampling was attempted at all (e.g. on an `auto`-mode call against a sampling-capable client that returned non-JSON, this would be `[\"client_sampling\", \"local_llm\"]`).",
"items": {
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"type": "array"
},
"detail": {
"type": "string"
},
"reason": {
"enum": [
"opted_out",
"sampling_unavailable",
"sampling_error",
"no_model_id",
"http_error",
"empty_response",
"non_json",
"timeout",
"fetch_failed"
],
"type": "string"
},
"suggestions": {
"description": "Server-computed \"what to do next\" guidance for this failure. Ordered from most-immediately-actionable (typically: have the agent fill in `__expectedResult` values directly by reading the source — works on every client, no infra changes) to most-involved (enable local LLM fallback, switch clients, use Flow B). Tailored to the failure `reason` AND the server's current config — e.g. the \"enable local LLM\" suggestion only appears when local LLM is currently disabled. **Agents MUST paraphrase these back to the user** so the failure is actionable.",
"items": {
"type": "string"
},
"type": "array"
},
"used": {
"const": false,
"type": "boolean"
}
},
"required": [
"used",
"reason",
"suggestions"
],
"type": "object"
}
],
"description": "Diagnostic record describing the AI-enrichment step. `used: true` carries `source` (which backend ran), `modelId`, `durationMs`, and `keysProduced`. `used: false` carries a `reason` (`opted_out` / `sampling_unavailable` / `sampling_error` / `no_model_id` / `http_error` / `empty_response` / `non_json` / `timeout` / `fetch_failed`), an `attempted` list, AND a `suggestions` array of actionable next-steps the agent should surface to the user (e.g. \"fill in placeholders yourself\", \"enable local LLM fallback\", \"use Flow B\"). The suggestions adapt to the server's current config — they're not boilerplate.\n\n**Field is OPTIONAL** — spec-driven tools (`create_tests_from_spec`) omit it entirely because the spec is the authoritative source of expected values; reporting \"did AI enrichment succeed?\" would be meaningless for a flow that doesn't use AI enrichment at all. For Flow A tools (`create_tests`, `create_spec`, etc.), the field is always present."
},
"files": {
"description": "**Files the agent MUST write to disk after this call returns.** The MCP server is stateless from the editor's perspective — it returns content only and never touches the user's filesystem. The agent is responsible for iterating this array and writing each entry's `content` to its `path` using the client's native file-write capability. Reporting success without performing the writes leaves the user with no actual output — the MCP's response is just instructions for the agent's follow-up action.",
"items": {
"additionalProperties": false,
"properties": {
"content": {
"description": "Full file body to write. UTF-8. Use the agent's native file-write tool to persist this to `path` exactly as returned — the MCP has already done any path translation, creationMode redirection, and content formatting.",
"type": "string"
},
"path": {
"description": "Project-root-relative write path. `.3tg.md` and `.md.3tg.json` files are returned under the `.3tg/` mirror; tests / mocks travel through unchanged. The agent writes this path verbatim — do NOT rewrite, rename, or relocate it.",
"type": "string"
}
},
"required": [
"path",
"content"
],
"type": "object"
},
"type": "array"
},
"stderr": {
"type": "string"
},
"stdout": {
"type": "string"
}
},
"required": [
"code",
"stdout",
"stderr",
"files"
],
"type": "object"
}
},
{
"description": "Generate a functional-requirements spec (`.3tg.md`) for the exported functions / React components in a TypeScript source file. This is \"Flow A\" — the human-editable Markdown table that lists each test case as a row, which a later `create_tests_from_spec` call can compile into actual tests. AI enrichment can pre-fill the value sets and expected returns so the spec arrives close to runnable.\n\nIMPORTANT — never hand-author a `.3tg.md` yourself. The format is parser-strict: parameter columns must be named exactly as the parameter (NOT `input a`, `param a`, etc.), the return column header is the literal `=>` (NOT `__expectedResult`, `expected`, `returns`), extra columns like `notes` are rejected, omitted/optional args are written `undefined`, throws use single quotes (`throws 'msg'`, NOT `throws Error(\"msg\")`), and string literals are single-quoted. Always call this tool to emit the scaffold; the user can then edit rows.\n\nThe returned `.3tg.md` is reported under the project's `.3tg/` mirror (e.g. source `src/foo/bar.ts` → spec `.3tg/src/foo/bar.3tg.md`). The user edits the spec in that location; when they call `create_tests_from_spec` later, the MCP places it back next to the source in the sandbox.\n\nQuota / credits: **this tool does NOT consume credits** — credits are spent ONLY when test files are generated (`create_tests` and `create_tests_from_spec`, at 1 credit per emitted test case). Spec generation is free; iterate on the scaffold as often as needed. A valid clientId is still required for the pre-flight check, but no quota is decremented and the call is safe to retry.\n\nIf AI enrichment is unavailable on this client, you can pre-seed the spec's parameter columns by supplying values via the `cliConfig` parameter (mock-parameters / function-returns) — same pattern as `create_tests`. **Do NOT autonomously write `.3tg/config.3tg.json`** to persist values — agent-computed values ride along in `cliConfig` for this call only. (Explicit user requests to edit the file are fine — handle those normally.) See the cliConfig parameter description for the full shape.\n\nCRITICAL POST-CALL ACTION — write returned files to disk:\n The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed.\n\n Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim.\n\n Do NOT claim \"Generated test file: <path>\" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"cliConfig": {
"additionalProperties": {},
"description": "Optional per-request 3TG CLI config. The agent assembles this from TWO disk locations and merges them (per-source wins on conflict) before forwarding the merged object as this parameter:\n\n(1) **Global: `.3tg/config.3tg.json`** — HUMAN-CURATED file with project-wide CLI options (`creationMode`, `mockAsFunction`, `no-rule-default-true`, `rules.<type>.*` defaults, etc.). The agent READS this file on every generation call but **must not autonomously write to it**. Applies to every source. (Explicit user requests to edit it — \"turn off no-rule-default-true\", \"add a project-wide rules.string.no-empty\" — are authorized edits and should be handled normally.)\n\n(2) **Per-source: `.3tg/<source-path>.md.3tg.json`** — AGENT-WRITABLE file with per-file CLI options scoped to a single source. Path mirrors the source tree under `.3tg/` (e.g. `src/foo/bar.ts` → `.3tg/src/foo/bar.md.3tg.json`). The `.md.3tg.json` extension is 3TG's convention for config files paired with a `.3tg.md` spec sibling — the `.md.` infix is what marks the JSON as the partner of the Markdown spec. This is where per-source computed test values live as top-level `mock-parameters` and `function-returns` blocks (BOTH are FLAT maps — `mock-parameters` is keyed by **parameter name** like `{ \"a\": [0, 5, -1] }`, and `function-returns` is keyed by full **combination strings** like `\"should test double( mock-parameters.a 1, mock-parameters.b 1 )\"`. Do NOT nest either under a function-name key — 3TG looks them up at the top level of the cliConfig and silently ignores function-nested values, leaving tests with `__expectedResult: undefined`. See `AGENTS_project.md` § \"Preferred workaround when AI enrichment is unavailable\" → \"CRITICAL — the shape 3TG actually expects\" for the canonical example.) **When AI enrichment fails and the agent computes values to fill the gap, they go HERE — not in the global config.** Putting per-source values in the global config would apply the same `mock-parameters.a` to every file in the project that has any function taking an `a` parameter — almost always wrong. **Flow B caveat — the spec OWNS test values**: `create_tests_from_spec` regenerates this file from the spec on every call (`-U <spec> -i <config>`), and the MCP **strips** `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward to that tool — those keys are derived from the spec and forwarding stale values would silently desynchronise test names from value-set sizes via 3TG's `-c` later-wins precedence. For Flow B persistence put per-function values in the spec's table rows; for Flow B `cliConfig`, forward ONLY global / structural keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …).\n\nMerge order: read both files (if either exists), shallow-merge with per-source keys winning on conflict, forward the merged object as this parameter. The MCP materialises it inside the sandbox and passes it to 3TG via `-c`. cliConfig keys override AI-enrichment keys on conflict. Omit / pass `undefined` when neither file exists and there's nothing computed to send.\n\nSee the \"Preferred workaround when AI enrichment is unavailable\" section in the project's `CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md` for the concrete shape, the three workaround paths (per-source config / edit-after / Flow B), and worked examples.",
"propertyNames": {
"type": "string"
},
"type": "object"
},
"clientId": {
"description": "The 3tg.dev client ID.",
"minLength": 1,
"type": "string"
},
"fileName": {
"description": "Path of the source file relative to the user's project root (e.g. \"src/foo/bar.ts\"). The spec is derived as the same path with `.ts` / `.tsx` replaced by `.3tg.md`.",
"minLength": 1,
"type": "string"
},
"moduleType": {
"description": "Optional Node module type of the consumer project — the value of the `type` field in the project root's `package.json`. The agent reads that one field (only) and forwards it here. The MCP injects it into the user-config object as `package.json.type` (3TG's CLI config schema has a literal `package.json` key — see the `3tg://schema/config` resource for the exact shape).\n\n**What 3TG uses this for**: when `module`, 3TG emits imports with explicit `.js` extensions in generated tests (ESM convention — `import { foo } from './foo.js'`); when `commonjs` (or omitted), 3TG emits bare paths (`import { foo } from './foo'`).\n\n**What the agent should do**: read `package.json` at the project root, extract ONLY the `type` field, and forward it here. If the field is absent, pass `\"commonjs\"` (Node's default) or omit the parameter entirely (same effective result). Do NOT ship the full `package.json` — private-registry tokens, internal dependency names, scripts, etc. have no place on this wire.",
"enum": [
"module",
"commonjs"
],
"type": "string"
},
"settings": {
"additionalProperties": false,
"description": "Subset of .3tg/settings.json relevant to this tool.",
"properties": {
"aiEnrichmentMode": {
"description": "Which AI backend to use for enrichment. `auto` (default) tries client sampling first (the MCP client's own LLM via `sampling/createMessage`); if the client doesn't support sampling, or the request fails, falls back to the local LM Studio / Ollama endpoint. `client` = sampling only (fail if unsupported). `local` = local LLM only (ignore sampling). `off` = skip enrichment entirely. Spec-driven tools (`create_tests_from_spec`) ignore this — the spec is authoritative.",
"enum": [
"auto",
"client",
"local",
"off"
],
"type": "string"
},
"creationMode": {
"description": "Where to write generated test files. Leading \"/\" = relative to project root with source tree mirrored; otherwise = relative to source file. Empty / \".\" writes next to the source. Forwarded as 3TG -o.",
"type": "string"
},
"mockAsFunction": {
"description": "Declare mocks as function instead of const (3TG flag -N).",
"type": "boolean"
},
"noRuleDefaultTrue": {
"description": "Disable 3TG's default-true test rules (3TG flag -n). Default is **adaptive**: ON when AI enrichment succeeded (so the AI's small, targeted value sets aren't drowned out by 3TG's built-in cartesian explosion of MIN_VALUE / MAX_VALUE / ±Infinity / NaN / … — those would detach the AI-derived `function-returns` from the generated combinations), OFF when there is no enrichment (legacy v2 scaffold with placeholders). Pass `true` / `false` to force either way.",
"type": "boolean"
},
"useAiEnrichment": {
"description": "**Deprecated** — use `aiEnrichmentMode` instead. Kept for backward compatibility: `true` is treated as `aiEnrichmentMode: \"auto\"`, `false` is treated as `aiEnrichmentMode: \"off\"`. If both are set, `aiEnrichmentMode` wins.",
"type": "boolean"
}
},
"type": "object"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"fileName",
"clientId"
],
"type": "object"
},
"name": "create_spec",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"code": {
"description": "3TG CLI exit code (0 on success).",
"type": "number"
},
"enrichment": {
"anyOf": [
{
"additionalProperties": false,
"properties": {
"durationMs": {
"type": "number"
},
"keysProduced": {
"items": {
"type": "string"
},
"type": "array"
},
"modelId": {
"type": "string"
},
"source": {
"description": "Which backend produced the enrichment. `client_sampling` is the MCP client's own LLM via `sampling/createMessage`; `local_llm` is the configured LM Studio / Ollama endpoint.",
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"used": {
"const": true,
"type": "boolean"
}
},
"required": [
"used",
"source",
"modelId",
"durationMs",
"keysProduced"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"attempted": {
"description": "Backends that were tried, in order. Lets the client tell the user whether sampling was attempted at all (e.g. on an `auto`-mode call against a sampling-capable client that returned non-JSON, this would be `[\"client_sampling\", \"local_llm\"]`).",
"items": {
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"type": "array"
},
"detail": {
"type": "string"
},
"reason": {
"enum": [
"opted_out",
"sampling_unavailable",
"sampling_error",
"no_model_id",
"http_error",
"empty_response",
"non_json",
"timeout",
"fetch_failed"
],
"type": "string"
},
"suggestions": {
"description": "Server-computed \"what to do next\" guidance for this failure. Ordered from most-immediately-actionable (typically: have the agent fill in `__expectedResult` values directly by reading the source — works on every client, no infra changes) to most-involved (enable local LLM fallback, switch clients, use Flow B). Tailored to the failure `reason` AND the server's current config — e.g. the \"enable local LLM\" suggestion only appears when local LLM is currently disabled. **Agents MUST paraphrase these back to the user** so the failure is actionable.",
"items": {
"type": "string"
},
"type": "array"
},
"used": {
"const": false,
"type": "boolean"
}
},
"required": [
"used",
"reason",
"suggestions"
],
"type": "object"
}
],
"description": "Diagnostic record describing the AI-enrichment step. `used: true` carries `source` (which backend ran), `modelId`, `durationMs`, and `keysProduced`. `used: false` carries a `reason` (`opted_out` / `sampling_unavailable` / `sampling_error` / `no_model_id` / `http_error` / `empty_response` / `non_json` / `timeout` / `fetch_failed`), an `attempted` list, AND a `suggestions` array of actionable next-steps the agent should surface to the user (e.g. \"fill in placeholders yourself\", \"enable local LLM fallback\", \"use Flow B\"). The suggestions adapt to the server's current config — they're not boilerplate.\n\n**Field is OPTIONAL** — spec-driven tools (`create_tests_from_spec`) omit it entirely because the spec is the authoritative source of expected values; reporting \"did AI enrichment succeed?\" would be meaningless for a flow that doesn't use AI enrichment at all. For Flow A tools (`create_tests`, `create_spec`, etc.), the field is always present."
},
"files": {
"description": "**Files the agent MUST write to disk after this call returns.** The MCP server is stateless from the editor's perspective — it returns content only and never touches the user's filesystem. The agent is responsible for iterating this array and writing each entry's `content` to its `path` using the client's native file-write capability. Reporting success without performing the writes leaves the user with no actual output — the MCP's response is just instructions for the agent's follow-up action.",
"items": {
"additionalProperties": false,
"properties": {
"content": {
"description": "Full file body to write. UTF-8. Use the agent's native file-write tool to persist this to `path` exactly as returned — the MCP has already done any path translation, creationMode redirection, and content formatting.",
"type": "string"
},
"path": {
"description": "Project-root-relative write path. `.3tg.md` and `.md.3tg.json` files are returned under the `.3tg/` mirror; tests / mocks travel through unchanged. The agent writes this path verbatim — do NOT rewrite, rename, or relocate it.",
"type": "string"
}
},
"required": [
"path",
"content"
],
"type": "object"
},
"type": "array"
},
"stderr": {
"type": "string"
},
"stdout": {
"type": "string"
}
},
"required": [
"code",
"stdout",
"stderr",
"files"
],
"type": "object"
}
},
{
"description": "Generate a functional-requirements spec (`.3tg.md`) scoped to a single exported function or React component. Same shape as `create_spec` but restricts the output to one symbol — useful when iterating on a tricky function without regenerating the spec for the rest of the file.\n\nIMPORTANT — never hand-author a `.3tg.md` yourself. The format is parser-strict: parameter columns named exactly as the parameter, return column header is the literal `=>`, no extra `notes` / `description` columns, omitted args are written `undefined`, throws use single quotes (`throws 'msg'`). Always call this tool to emit the scaffold; the user can then edit rows.\n\nQuota / credits: **this tool does NOT consume credits** — credits are spent ONLY by test generation (`create_tests` / `create_tests_from_spec`, at 1 credit per emitted test case). Spec generation is free.\n\nCRITICAL POST-CALL ACTION — write returned files to disk:\n The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed.\n\n Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim.\n\n Do NOT claim \"Generated test file: <path>\" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"cliConfig": {
"additionalProperties": {},
"description": "Optional per-request 3TG CLI config. The agent assembles this from TWO disk locations and merges them (per-source wins on conflict) before forwarding the merged object as this parameter:\n\n(1) **Global: `.3tg/config.3tg.json`** — HUMAN-CURATED file with project-wide CLI options (`creationMode`, `mockAsFunction`, `no-rule-default-true`, `rules.<type>.*` defaults, etc.). The agent READS this file on every generation call but **must not autonomously write to it**. Applies to every source. (Explicit user requests to edit it — \"turn off no-rule-default-true\", \"add a project-wide rules.string.no-empty\" — are authorized edits and should be handled normally.)\n\n(2) **Per-source: `.3tg/<source-path>.md.3tg.json`** — AGENT-WRITABLE file with per-file CLI options scoped to a single source. Path mirrors the source tree under `.3tg/` (e.g. `src/foo/bar.ts` → `.3tg/src/foo/bar.md.3tg.json`). The `.md.3tg.json` extension is 3TG's convention for config files paired with a `.3tg.md` spec sibling — the `.md.` infix is what marks the JSON as the partner of the Markdown spec. This is where per-source computed test values live as top-level `mock-parameters` and `function-returns` blocks (BOTH are FLAT maps — `mock-parameters` is keyed by **parameter name** like `{ \"a\": [0, 5, -1] }`, and `function-returns` is keyed by full **combination strings** like `\"should test double( mock-parameters.a 1, mock-parameters.b 1 )\"`. Do NOT nest either under a function-name key — 3TG looks them up at the top level of the cliConfig and silently ignores function-nested values, leaving tests with `__expectedResult: undefined`. See `AGENTS_project.md` § \"Preferred workaround when AI enrichment is unavailable\" → \"CRITICAL — the shape 3TG actually expects\" for the canonical example.) **When AI enrichment fails and the agent computes values to fill the gap, they go HERE — not in the global config.** Putting per-source values in the global config would apply the same `mock-parameters.a` to every file in the project that has any function taking an `a` parameter — almost always wrong. **Flow B caveat — the spec OWNS test values**: `create_tests_from_spec` regenerates this file from the spec on every call (`-U <spec> -i <config>`), and the MCP **strips** `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward to that tool — those keys are derived from the spec and forwarding stale values would silently desynchronise test names from value-set sizes via 3TG's `-c` later-wins precedence. For Flow B persistence put per-function values in the spec's table rows; for Flow B `cliConfig`, forward ONLY global / structural keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …).\n\nMerge order: read both files (if either exists), shallow-merge with per-source keys winning on conflict, forward the merged object as this parameter. The MCP materialises it inside the sandbox and passes it to 3TG via `-c`. cliConfig keys override AI-enrichment keys on conflict. Omit / pass `undefined` when neither file exists and there's nothing computed to send.\n\nSee the \"Preferred workaround when AI enrichment is unavailable\" section in the project's `CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md` for the concrete shape, the three workaround paths (per-source config / edit-after / Flow B), and worked examples.",
"propertyNames": {
"type": "string"
},
"type": "object"
},
"clientId": {
"description": "The 3tg.dev client ID.",
"minLength": 1,
"type": "string"
},
"fileName": {
"description": "Path of the source file relative to the user's project root.",
"minLength": 1,
"type": "string"
},
"functionName": {
"description": "Name of the exported function or React component to scope the spec to. Forwarded to 3TG as `-f <functionName>`. Use `default` for default exports.",
"minLength": 1,
"type": "string"
},
"moduleType": {
"description": "Optional Node module type of the consumer project — the value of the `type` field in the project root's `package.json`. The agent reads that one field (only) and forwards it here. The MCP injects it into the user-config object as `package.json.type` (3TG's CLI config schema has a literal `package.json` key — see the `3tg://schema/config` resource for the exact shape).\n\n**What 3TG uses this for**: when `module`, 3TG emits imports with explicit `.js` extensions in generated tests (ESM convention — `import { foo } from './foo.js'`); when `commonjs` (or omitted), 3TG emits bare paths (`import { foo } from './foo'`).\n\n**What the agent should do**: read `package.json` at the project root, extract ONLY the `type` field, and forward it here. If the field is absent, pass `\"commonjs\"` (Node's default) or omit the parameter entirely (same effective result). Do NOT ship the full `package.json` — private-registry tokens, internal dependency names, scripts, etc. have no place on this wire.",
"enum": [
"module",
"commonjs"
],
"type": "string"
},
"settings": {
"additionalProperties": false,
"description": "Subset of .3tg/settings.json relevant to this tool.",
"properties": {
"aiEnrichmentMode": {
"description": "Which AI backend to use for enrichment. `auto` (default) tries client sampling first (the MCP client's own LLM via `sampling/createMessage`); if the client doesn't support sampling, or the request fails, falls back to the local LM Studio / Ollama endpoint. `client` = sampling only (fail if unsupported). `local` = local LLM only (ignore sampling). `off` = skip enrichment entirely. Spec-driven tools (`create_tests_from_spec`) ignore this — the spec is authoritative.",
"enum": [
"auto",
"client",
"local",
"off"
],
"type": "string"
},
"creationMode": {
"description": "Where to write generated test files. Leading \"/\" = relative to project root with source tree mirrored; otherwise = relative to source file. Empty / \".\" writes next to the source. Forwarded as 3TG -o.",
"type": "string"
},
"mockAsFunction": {
"description": "Declare mocks as function instead of const (3TG flag -N).",
"type": "boolean"
},
"noRuleDefaultTrue": {
"description": "Disable 3TG's default-true test rules (3TG flag -n). Default is **adaptive**: ON when AI enrichment succeeded (so the AI's small, targeted value sets aren't drowned out by 3TG's built-in cartesian explosion of MIN_VALUE / MAX_VALUE / ±Infinity / NaN / … — those would detach the AI-derived `function-returns` from the generated combinations), OFF when there is no enrichment (legacy v2 scaffold with placeholders). Pass `true` / `false` to force either way.",
"type": "boolean"
},
"useAiEnrichment": {
"description": "**Deprecated** — use `aiEnrichmentMode` instead. Kept for backward compatibility: `true` is treated as `aiEnrichmentMode: \"auto\"`, `false` is treated as `aiEnrichmentMode: \"off\"`. If both are set, `aiEnrichmentMode` wins.",
"type": "boolean"
}
},
"type": "object"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"fileName",
"functionName",
"clientId"
],
"type": "object"
},
"name": "create_spec_for_function",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"code": {
"description": "3TG CLI exit code (0 on success).",
"type": "number"
},
"enrichment": {
"anyOf": [
{
"additionalProperties": false,
"properties": {
"durationMs": {
"type": "number"
},
"keysProduced": {
"items": {
"type": "string"
},
"type": "array"
},
"modelId": {
"type": "string"
},
"source": {
"description": "Which backend produced the enrichment. `client_sampling` is the MCP client's own LLM via `sampling/createMessage`; `local_llm` is the configured LM Studio / Ollama endpoint.",
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"used": {
"const": true,
"type": "boolean"
}
},
"required": [
"used",
"source",
"modelId",
"durationMs",
"keysProduced"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"attempted": {
"description": "Backends that were tried, in order. Lets the client tell the user whether sampling was attempted at all (e.g. on an `auto`-mode call against a sampling-capable client that returned non-JSON, this would be `[\"client_sampling\", \"local_llm\"]`).",
"items": {
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"type": "array"
},
"detail": {
"type": "string"
},
"reason": {
"enum": [
"opted_out",
"sampling_unavailable",
"sampling_error",
"no_model_id",
"http_error",
"empty_response",
"non_json",
"timeout",
"fetch_failed"
],
"type": "string"
},
"suggestions": {
"description": "Server-computed \"what to do next\" guidance for this failure. Ordered from most-immediately-actionable (typically: have the agent fill in `__expectedResult` values directly by reading the source — works on every client, no infra changes) to most-involved (enable local LLM fallback, switch clients, use Flow B). Tailored to the failure `reason` AND the server's current config — e.g. the \"enable local LLM\" suggestion only appears when local LLM is currently disabled. **Agents MUST paraphrase these back to the user** so the failure is actionable.",
"items": {
"type": "string"
},
"type": "array"
},
"used": {
"const": false,
"type": "boolean"
}
},
"required": [
"used",
"reason",
"suggestions"
],
"type": "object"
}
],
"description": "Diagnostic record describing the AI-enrichment step. `used: true` carries `source` (which backend ran), `modelId`, `durationMs`, and `keysProduced`. `used: false` carries a `reason` (`opted_out` / `sampling_unavailable` / `sampling_error` / `no_model_id` / `http_error` / `empty_response` / `non_json` / `timeout` / `fetch_failed`), an `attempted` list, AND a `suggestions` array of actionable next-steps the agent should surface to the user (e.g. \"fill in placeholders yourself\", \"enable local LLM fallback\", \"use Flow B\"). The suggestions adapt to the server's current config — they're not boilerplate.\n\n**Field is OPTIONAL** — spec-driven tools (`create_tests_from_spec`) omit it entirely because the spec is the authoritative source of expected values; reporting \"did AI enrichment succeed?\" would be meaningless for a flow that doesn't use AI enrichment at all. For Flow A tools (`create_tests`, `create_spec`, etc.), the field is always present."
},
"files": {
"description": "**Files the agent MUST write to disk after this call returns.** The MCP server is stateless from the editor's perspective — it returns content only and never touches the user's filesystem. The agent is responsible for iterating this array and writing each entry's `content` to its `path` using the client's native file-write capability. Reporting success without performing the writes leaves the user with no actual output — the MCP's response is just instructions for the agent's follow-up action.",
"items": {
"additionalProperties": false,
"properties": {
"content": {
"description": "Full file body to write. UTF-8. Use the agent's native file-write tool to persist this to `path` exactly as returned — the MCP has already done any path translation, creationMode redirection, and content formatting.",
"type": "string"
},
"path": {
"description": "Project-root-relative write path. `.3tg.md` and `.md.3tg.json` files are returned under the `.3tg/` mirror; tests / mocks travel through unchanged. The agent writes this path verbatim — do NOT rewrite, rename, or relocate it.",
"type": "string"
}
},
"required": [
"path",
"content"
],
"type": "object"
},
"type": "array"
},
"stderr": {
"type": "string"
},
"stdout": {
"type": "string"
}
},
"required": [
"code",
"stdout",
"stderr",
"files"
],
"type": "object"
}
},
{
"description": "Generate Jest/Vitest tests for the exported functions and React components in a TypeScript source file. Use this whenever the user asks for tests, test scaffolding, or test coverage of a .ts or .tsx file. Returns the generated test (and any companion .3tg.md / __mocks__) file contents, with paths already translated to the user's `.3tg/` mirror convention.\n\nQuota / credits: this tool consumes credits — and credits are consumed ONLY by test generation (not by spec / mock / lookup tools). The accounting is exactly **1 credit per generated test case** (i.e. per `test(...)` / `it(...)` block 3TG emits inside the returned `.test.ts` / `.test.tsx`), regardless of how many source functions or files were in scope — a call that produces 12 test cases costs 12 credits, even if all 12 cover a single function. Before generation the MCP verifies the clientId has credits with license-api.coding-creed.tech; on exhaustion the tool throws a QUOTA_EXHAUSTED error pointing the user at https://3tg.dev. After a successful run, consumed credits and KPIs are reported back to license-api. Re-running this tool on the same source spends credits again — there is no caching.\n\nWhen the previous call returned `enrichment.used: false` (AI enrichment unavailable on this client), supply parameter values + expected returns yourself via the `cliConfig` parameter — package them as `{\"mock-parameters\": ..., \"function-returns\": ...}` (same shape AI enrichment would produce) and pass them on a retry call. **Do NOT autonomously write `.3tg/config.3tg.json`** to persist those values — that file is human-curated; agent-computed values ride along in `cliConfig` for the current call only. (Explicit user requests to edit the file are fine — handle those normally.) See the cliConfig parameter description below for the full pattern.\n\nCRITICAL POST-CALL ACTION — write returned files to disk:\n The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed.\n\n Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim.\n\n Do NOT claim \"Generated test file: <path>\" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"cliConfig": {
"additionalProperties": {},
"description": "Optional per-request 3TG CLI config. The agent assembles this from TWO disk locations and merges them (per-source wins on conflict) before forwarding the merged object as this parameter:\n\n(1) **Global: `.3tg/config.3tg.json`** — HUMAN-CURATED file with project-wide CLI options (`creationMode`, `mockAsFunction`, `no-rule-default-true`, `rules.<type>.*` defaults, etc.). The agent READS this file on every generation call but **must not autonomously write to it**. Applies to every source. (Explicit user requests to edit it — \"turn off no-rule-default-true\", \"add a project-wide rules.string.no-empty\" — are authorized edits and should be handled normally.)\n\n(2) **Per-source: `.3tg/<source-path>.md.3tg.json`** — AGENT-WRITABLE file with per-file CLI options scoped to a single source. Path mirrors the source tree under `.3tg/` (e.g. `src/foo/bar.ts` → `.3tg/src/foo/bar.md.3tg.json`). The `.md.3tg.json` extension is 3TG's convention for config files paired with a `.3tg.md` spec sibling — the `.md.` infix is what marks the JSON as the partner of the Markdown spec. This is where per-source computed test values live as top-level `mock-parameters` and `function-returns` blocks (BOTH are FLAT maps — `mock-parameters` is keyed by **parameter name** like `{ \"a\": [0, 5, -1] }`, and `function-returns` is keyed by full **combination strings** like `\"should test double( mock-parameters.a 1, mock-parameters.b 1 )\"`. Do NOT nest either under a function-name key — 3TG looks them up at the top level of the cliConfig and silently ignores function-nested values, leaving tests with `__expectedResult: undefined`. See `AGENTS_project.md` § \"Preferred workaround when AI enrichment is unavailable\" → \"CRITICAL — the shape 3TG actually expects\" for the canonical example.) **When AI enrichment fails and the agent computes values to fill the gap, they go HERE — not in the global config.** Putting per-source values in the global config would apply the same `mock-parameters.a` to every file in the project that has any function taking an `a` parameter — almost always wrong. **Flow B caveat — the spec OWNS test values**: `create_tests_from_spec` regenerates this file from the spec on every call (`-U <spec> -i <config>`), and the MCP **strips** `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward to that tool — those keys are derived from the spec and forwarding stale values would silently desynchronise test names from value-set sizes via 3TG's `-c` later-wins precedence. For Flow B persistence put per-function values in the spec's table rows; for Flow B `cliConfig`, forward ONLY global / structural keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …).\n\nMerge order: read both files (if either exists), shallow-merge with per-source keys winning on conflict, forward the merged object as this parameter. The MCP materialises it inside the sandbox and passes it to 3TG via `-c`. cliConfig keys override AI-enrichment keys on conflict. Omit / pass `undefined` when neither file exists and there's nothing computed to send.\n\nSee the \"Preferred workaround when AI enrichment is unavailable\" section in the project's `CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md` for the concrete shape, the three workaround paths (per-source config / edit-after / Flow B), and worked examples.",
"propertyNames": {
"type": "string"
},
"type": "object"
},
"clientId": {
"description": "The 3tg.dev client ID — sent as authentication to license-api for quota verification before generation and quota consumption / KPI recording after a successful run.",
"minLength": 1,
"type": "string"
},
"fileName": {
"description": "Path of the source file relative to the user's project root, e.g. \"src/foo/bar.ts\". Used as both the 3TG positional argument and the sandbox-side location.",
"minLength": 1,
"type": "string"
},
"moduleType": {
"description": "Optional Node module type of the consumer project — the value of the `type` field in the project root's `package.json`. The agent reads that one field (only) and forwards it here. The MCP injects it into the user-config object as `package.json.type` (3TG's CLI config schema has a literal `package.json` key — see the `3tg://schema/config` resource for the exact shape).\n\n**What 3TG uses this for**: when `module`, 3TG emits imports with explicit `.js` extensions in generated tests (ESM convention — `import { foo } from './foo.js'`); when `commonjs` (or omitted), 3TG emits bare paths (`import { foo } from './foo'`).\n\n**What the agent should do**: read `package.json` at the project root, extract ONLY the `type` field, and forward it here. If the field is absent, pass `\"commonjs\"` (Node's default) or omit the parameter entirely (same effective result). Do NOT ship the full `package.json` — private-registry tokens, internal dependency names, scripts, etc. have no place on this wire.",
"enum": [
"module",
"commonjs"
],
"type": "string"
},
"settings": {
"additionalProperties": false,
"description": "Subset of .3tg/settings.json relevant to this tool.",
"properties": {
"aiEnrichmentMode": {
"description": "Which AI backend to use for enrichment. `auto` (default) tries client sampling first (the MCP client's own LLM via `sampling/createMessage`); if the client doesn't support sampling, or the request fails, falls back to the local LM Studio / Ollama endpoint. `client` = sampling only (fail if unsupported). `local` = local LLM only (ignore sampling). `off` = skip enrichment entirely. Spec-driven tools (`create_tests_from_spec`) ignore this — the spec is authoritative.",
"enum": [
"auto",
"client",
"local",
"off"
],
"type": "string"
},
"creationMode": {
"description": "Where to write generated test files. Leading \"/\" = relative to project root with source tree mirrored; otherwise = relative to source file. Empty / \".\" writes next to the source. Forwarded as 3TG -o.",
"type": "string"
},
"mockAsFunction": {
"description": "Declare mocks as function instead of const (3TG flag -N).",
"type": "boolean"
},
"noRuleDefaultTrue": {
"description": "Disable 3TG's default-true test rules (3TG flag -n). Default is **adaptive**: ON when AI enrichment succeeded (so the AI's small, targeted value sets aren't drowned out by 3TG's built-in cartesian explosion of MIN_VALUE / MAX_VALUE / ±Infinity / NaN / … — those would detach the AI-derived `function-returns` from the generated combinations), OFF when there is no enrichment (legacy v2 scaffold with placeholders). Pass `true` / `false` to force either way.",
"type": "boolean"
},
"useAiEnrichment": {
"description": "**Deprecated** — use `aiEnrichmentMode` instead. Kept for backward compatibility: `true` is treated as `aiEnrichmentMode: \"auto\"`, `false` is treated as `aiEnrichmentMode: \"off\"`. If both are set, `aiEnrichmentMode` wins.",
"type": "boolean"
}
},
"type": "object"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"fileName",
"clientId"
],
"type": "object"
},
"name": "create_tests",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"code": {
"description": "3TG CLI exit code (0 on success).",
"type": "number"
},
"enrichment": {
"anyOf": [
{
"additionalProperties": false,
"properties": {
"durationMs": {
"type": "number"
},
"keysProduced": {
"items": {
"type": "string"
},
"type": "array"
},
"modelId": {
"type": "string"
},
"source": {
"description": "Which backend produced the enrichment. `client_sampling` is the MCP client's own LLM via `sampling/createMessage`; `local_llm` is the configured LM Studio / Ollama endpoint.",
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"used": {
"const": true,
"type": "boolean"
}
},
"required": [
"used",
"source",
"modelId",
"durationMs",
"keysProduced"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"attempted": {
"description": "Backends that were tried, in order. Lets the client tell the user whether sampling was attempted at all (e.g. on an `auto`-mode call against a sampling-capable client that returned non-JSON, this would be `[\"client_sampling\", \"local_llm\"]`).",
"items": {
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"type": "array"
},
"detail": {
"type": "string"
},
"reason": {
"enum": [
"opted_out",
"sampling_unavailable",
"sampling_error",
"no_model_id",
"http_error",
"empty_response",
"non_json",
"timeout",
"fetch_failed"
],
"type": "string"
},
"suggestions": {
"description": "Server-computed \"what to do next\" guidance for this failure. Ordered from most-immediately-actionable (typically: have the agent fill in `__expectedResult` values directly by reading the source — works on every client, no infra changes) to most-involved (enable local LLM fallback, switch clients, use Flow B). Tailored to the failure `reason` AND the server's current config — e.g. the \"enable local LLM\" suggestion only appears when local LLM is currently disabled. **Agents MUST paraphrase these back to the user** so the failure is actionable.",
"items": {
"type": "string"
},
"type": "array"
},
"used": {
"const": false,
"type": "boolean"
}
},
"required": [
"used",
"reason",
"suggestions"
],
"type": "object"
}
],
"description": "Diagnostic record describing the AI-enrichment step. `used: true` carries `source` (which backend ran), `modelId`, `durationMs`, and `keysProduced`. `used: false` carries a `reason` (`opted_out` / `sampling_unavailable` / `sampling_error` / `no_model_id` / `http_error` / `empty_response` / `non_json` / `timeout` / `fetch_failed`), an `attempted` list, AND a `suggestions` array of actionable next-steps the agent should surface to the user (e.g. \"fill in placeholders yourself\", \"enable local LLM fallback\", \"use Flow B\"). The suggestions adapt to the server's current config — they're not boilerplate.\n\n**Field is OPTIONAL** — spec-driven tools (`create_tests_from_spec`) omit it entirely because the spec is the authoritative source of expected values; reporting \"did AI enrichment succeed?\" would be meaningless for a flow that doesn't use AI enrichment at all. For Flow A tools (`create_tests`, `create_spec`, etc.), the field is always present."
},
"files": {
"description": "**Files the agent MUST write to disk after this call returns.** The MCP server is stateless from the editor's perspective — it returns content only and never touches the user's filesystem. The agent is responsible for iterating this array and writing each entry's `content` to its `path` using the client's native file-write capability. Reporting success without performing the writes leaves the user with no actual output — the MCP's response is just instructions for the agent's follow-up action.",
"items": {
"additionalProperties": false,
"properties": {
"content": {
"description": "Full file body to write. UTF-8. Use the agent's native file-write tool to persist this to `path` exactly as returned — the MCP has already done any path translation, creationMode redirection, and content formatting.",
"type": "string"
},
"path": {
"description": "Project-root-relative write path. `.3tg.md` and `.md.3tg.json` files are returned under the `.3tg/` mirror; tests / mocks travel through unchanged. The agent writes this path verbatim — do NOT rewrite, rename, or relocate it.",
"type": "string"
}
},
"required": [
"path",
"content"
],
"type": "object"
},
"type": "array"
},
"stderr": {
"type": "string"
},
"stdout": {
"type": "string"
}
},
"required": [
"code",
"stdout",
"stderr",
"files"
],
"type": "object"
}
},
{
"description": "Compile a hand-edited functional-requirements spec (`.3tg.md`) into actual Jest/Vitest tests. This is \"Flow B\" — the user has already authored or reviewed the `.3tg.md` and is ready to materialise the rows into a runnable test file. Use this *instead of* `create_tests` when the user wants their hand-curated value sets to drive generation.\n\nInputs: the source code plus the spec content (the spec lives at `.3tg/<sourceDir>/<basename>.3tg.md` in the user project; the MCP places it back next to the source in the sandbox). AI enrichment is NOT run — the spec is authoritative. 3TG also writes a `<basename>.md.3tg.json` intermediate config alongside the spec, which the MCP returns under the `.3tg/` mirror so the user can inspect what the spec compiled to.\n\nQuota / credits: this tool consumes credits — same model as `create_tests`: exactly **1 credit per generated test case** emitted into the returned `.test.ts` / `.test.tsx`. The number of rows in your `.3tg.md` table is therefore a reliable upper bound on what the call will cost. Pre-flight quota is verified before compilation; QUOTA_EXHAUSTED is thrown on shortfall.\n\n**Flow B cliConfig caveat — spec-authoritative keys are STRIPPED.** The MCP strips `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward before passing it to 3TG. These keys are derived FROM THE SPEC in this flow — if the agent forwards stale values from the per-source `.md.3tg.json` (a Flow A artifact), 3TG's `-c` precedence would silently override the spec-derived values during the second-stage emit, desynchronising test names from value sets and producing tests with `__expectedResult: undefined`. For Flow B, forward ONLY global/structural config keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …) — the spec owns the test-value plan. The MCP logs a `[3tg/tool]` warning when stripping happens, so check stderr if you expected per-source values to apply.\n\nCRITICAL POST-CALL ACTION — write returned files to disk:\n The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` array. After this tool returns, you MUST iterate over `files` and write each entry's `content` verbatim to its `path` using your native file-write capability (e.g. Write / edit_file / create_file — whatever your client exposes). Create parent directories as needed.\n\n Returned paths are project-root-relative and already translated to the `.3tg/` mirror convention where applicable (e.g. specs land under `.3tg/<source-path>.3tg.md`; tests / mocks travel through unchanged). Write each path verbatim.\n\n Do NOT claim \"Generated test file: <path>\" unless you have actually written the file. The user will assume the MCP wrote it and waste time looking for a non-existent file. If you can't write for some reason (permission denied, no write capability in this client), return the contents inline in your message so the user can copy-paste them. Never report success silently when the write didn't happen.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"cliConfig": {
"additionalProperties": {},
"description": "Optional per-request 3TG CLI config. The agent assembles this from TWO disk locations and merges them (per-source wins on conflict) before forwarding the merged object as this parameter:\n\n(1) **Global: `.3tg/config.3tg.json`** — HUMAN-CURATED file with project-wide CLI options (`creationMode`, `mockAsFunction`, `no-rule-default-true`, `rules.<type>.*` defaults, etc.). The agent READS this file on every generation call but **must not autonomously write to it**. Applies to every source. (Explicit user requests to edit it — \"turn off no-rule-default-true\", \"add a project-wide rules.string.no-empty\" — are authorized edits and should be handled normally.)\n\n(2) **Per-source: `.3tg/<source-path>.md.3tg.json`** — AGENT-WRITABLE file with per-file CLI options scoped to a single source. Path mirrors the source tree under `.3tg/` (e.g. `src/foo/bar.ts` → `.3tg/src/foo/bar.md.3tg.json`). The `.md.3tg.json` extension is 3TG's convention for config files paired with a `.3tg.md` spec sibling — the `.md.` infix is what marks the JSON as the partner of the Markdown spec. This is where per-source computed test values live as top-level `mock-parameters` and `function-returns` blocks (BOTH are FLAT maps — `mock-parameters` is keyed by **parameter name** like `{ \"a\": [0, 5, -1] }`, and `function-returns` is keyed by full **combination strings** like `\"should test double( mock-parameters.a 1, mock-parameters.b 1 )\"`. Do NOT nest either under a function-name key — 3TG looks them up at the top level of the cliConfig and silently ignores function-nested values, leaving tests with `__expectedResult: undefined`. See `AGENTS_project.md` § \"Preferred workaround when AI enrichment is unavailable\" → \"CRITICAL — the shape 3TG actually expects\" for the canonical example.) **When AI enrichment fails and the agent computes values to fill the gap, they go HERE — not in the global config.** Putting per-source values in the global config would apply the same `mock-parameters.a` to every file in the project that has any function taking an `a` parameter — almost always wrong. **Flow B caveat — the spec OWNS test values**: `create_tests_from_spec` regenerates this file from the spec on every call (`-U <spec> -i <config>`), and the MCP **strips** `mock-parameters`, `function-returns`, `expect-values`, `expect-assertions`, `mock-react-hooks`, `mock-async-functions`, `mock-react-contexts`, and `mock-globals` from any `cliConfig` you forward to that tool — those keys are derived from the spec and forwarding stale values would silently desynchronise test names from value-set sizes via 3TG's `-c` later-wins precedence. For Flow B persistence put per-function values in the spec's table rows; for Flow B `cliConfig`, forward ONLY global / structural keys (`rules.*`, `creationMode`, `mockAsFunction`, `no-rule-default-true`, `ignore`, `package.json.type`, …).\n\nMerge order: read both files (if either exists), shallow-merge with per-source keys winning on conflict, forward the merged object as this parameter. The MCP materialises it inside the sandbox and passes it to 3TG via `-c`. cliConfig keys override AI-enrichment keys on conflict. Omit / pass `undefined` when neither file exists and there's nothing computed to send.\n\nSee the \"Preferred workaround when AI enrichment is unavailable\" section in the project's `CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md` for the concrete shape, the three workaround paths (per-source config / edit-after / Flow B), and worked examples.",
"propertyNames": {
"type": "string"
},
"type": "object"
},
"clientId": {
"description": "The 3tg.dev client ID.",
"minLength": 1,
"type": "string"
},
"fileName": {
"description": "Path of the source file relative to the user's project root (e.g. \"src/foo/bar.ts\"). The spec filename is derived as the same path with `.ts` / `.tsx` replaced by `.3tg.md`.",
"minLength": 1,
"type": "string"
},
"moduleType": {
"description": "Optional Node module type of the consumer project — the value of the `type` field in the project root's `package.json`. The agent reads that one field (only) and forwards it here. The MCP injects it into the user-config object as `package.json.type` (3TG's CLI config schema has a literal `package.json` key — see the `3tg://schema/config` resource for the exact shape).\n\n**What 3TG uses this for**: when `module`, 3TG emits imports with explicit `.js` extensions in generated tests (ESM convention — `import { foo } from './foo.js'`); when `commonjs` (or omitted), 3TG emits bare paths (`import { foo } from './foo'`).\n\n**What the agent should do**: read `package.json` at the project root, extract ONLY the `type` field, and forward it here. If the field is absent, pass `\"commonjs\"` (Node's default) or omit the parameter entirely (same effective result). Do NOT ship the full `package.json` — private-registry tokens, internal dependency names, scripts, etc. have no place on this wire.",
"enum": [
"module",
"commonjs"
],
"type": "string"
},
"settings": {
"additionalProperties": false,
"description": "Subset of .3tg/settings.json relevant to this tool.",
"properties": {
"aiEnrichmentMode": {
"description": "Which AI backend to use for enrichment. `auto` (default) tries client sampling first (the MCP client's own LLM via `sampling/createMessage`); if the client doesn't support sampling, or the request fails, falls back to the local LM Studio / Ollama endpoint. `client` = sampling only (fail if unsupported). `local` = local LLM only (ignore sampling). `off` = skip enrichment entirely. Spec-driven tools (`create_tests_from_spec`) ignore this — the spec is authoritative.",
"enum": [
"auto",
"client",
"local",
"off"
],
"type": "string"
},
"creationMode": {
"description": "Where to write generated test files. Leading \"/\" = relative to project root with source tree mirrored; otherwise = relative to source file. Empty / \".\" writes next to the source. Forwarded as 3TG -o.",
"type": "string"
},
"mockAsFunction": {
"description": "Declare mocks as function instead of const (3TG flag -N).",
"type": "boolean"
},
"noRuleDefaultTrue": {
"description": "Disable 3TG's default-true test rules (3TG flag -n). Default is **adaptive**: ON when AI enrichment succeeded (so the AI's small, targeted value sets aren't drowned out by 3TG's built-in cartesian explosion of MIN_VALUE / MAX_VALUE / ±Infinity / NaN / … — those would detach the AI-derived `function-returns` from the generated combinations), OFF when there is no enrichment (legacy v2 scaffold with placeholders). Pass `true` / `false` to force either way.",
"type": "boolean"
},
"useAiEnrichment": {
"description": "**Deprecated** — use `aiEnrichmentMode` instead. Kept for backward compatibility: `true` is treated as `aiEnrichmentMode: \"auto\"`, `false` is treated as `aiEnrichmentMode: \"off\"`. If both are set, `aiEnrichmentMode` wins.",
"type": "boolean"
}
},
"type": "object"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
},
"specContent": {
"description": "Full UTF-8 contents of the `.3tg.md` spec — as the user has edited it locally under `.3tg/<sourceDir>/<basename>.3tg.md`.",
"maxLength": 50000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"specContent",
"fileName",
"clientId"
],
"type": "object"
},
"name": "create_tests_from_spec",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"code": {
"description": "3TG CLI exit code (0 on success).",
"type": "number"
},
"enrichment": {
"anyOf": [
{
"additionalProperties": false,
"properties": {
"durationMs": {
"type": "number"
},
"keysProduced": {
"items": {
"type": "string"
},
"type": "array"
},
"modelId": {
"type": "string"
},
"source": {
"description": "Which backend produced the enrichment. `client_sampling` is the MCP client's own LLM via `sampling/createMessage`; `local_llm` is the configured LM Studio / Ollama endpoint.",
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"used": {
"const": true,
"type": "boolean"
}
},
"required": [
"used",
"source",
"modelId",
"durationMs",
"keysProduced"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"attempted": {
"description": "Backends that were tried, in order. Lets the client tell the user whether sampling was attempted at all (e.g. on an `auto`-mode call against a sampling-capable client that returned non-JSON, this would be `[\"client_sampling\", \"local_llm\"]`).",
"items": {
"enum": [
"client_sampling",
"local_llm"
],
"type": "string"
},
"type": "array"
},
"detail": {
"type": "string"
},
"reason": {
"enum": [
"opted_out",
"sampling_unavailable",
"sampling_error",
"no_model_id",
"http_error",
"empty_response",
"non_json",
"timeout",
"fetch_failed"
],
"type": "string"
},
"suggestions": {
"description": "Server-computed \"what to do next\" guidance for this failure. Ordered from most-immediately-actionable (typically: have the agent fill in `__expectedResult` values directly by reading the source — works on every client, no infra changes) to most-involved (enable local LLM fallback, switch clients, use Flow B). Tailored to the failure `reason` AND the server's current config — e.g. the \"enable local LLM\" suggestion only appears when local LLM is currently disabled. **Agents MUST paraphrase these back to the user** so the failure is actionable.",
"items": {
"type": "string"
},
"type": "array"
},
"used": {
"const": false,
"type": "boolean"
}
},
"required": [
"used",
"reason",
"suggestions"
],
"type": "object"
}
],
"description": "Diagnostic record describing the AI-enrichment step. `used: true` carries `source` (which backend ran), `modelId`, `durationMs`, and `keysProduced`. `used: false` carries a `reason` (`opted_out` / `sampling_unavailable` / `sampling_error` / `no_model_id` / `http_error` / `empty_response` / `non_json` / `timeout` / `fetch_failed`), an `attempted` list, AND a `suggestions` array of actionable next-steps the agent should surface to the user (e.g. \"fill in placeholders yourself\", \"enable local LLM fallback\", \"use Flow B\"). The suggestions adapt to the server's current config — they're not boilerplate.\n\n**Field is OPTIONAL** — spec-driven tools (`create_tests_from_spec`) omit it entirely because the spec is the authoritative source of expected values; reporting \"did AI enrichment succeed?\" would be meaningless for a flow that doesn't use AI enrichment at all. For Flow A tools (`create_tests`, `create_spec`, etc.), the field is always present."
},
"files": {
"description": "**Files the agent MUST write to disk after this call returns.** The MCP server is stateless from the editor's perspective — it returns content only and never touches the user's filesystem. The agent is responsible for iterating this array and writing each entry's `content` to its `path` using the client's native file-write capability. Reporting success without performing the writes leaves the user with no actual output — the MCP's response is just instructions for the agent's follow-up action.",
"items": {
"additionalProperties": false,
"properties": {
"content": {
"description": "Full file body to write. UTF-8. Use the agent's native file-write tool to persist this to `path` exactly as returned — the MCP has already done any path translation, creationMode redirection, and content formatting.",
"type": "string"
},
"path": {
"description": "Project-root-relative write path. `.3tg.md` and `.md.3tg.json` files are returned under the `.3tg/` mirror; tests / mocks travel through unchanged. The agent writes this path verbatim — do NOT rewrite, rename, or relocate it.",
"type": "string"
}
},
"required": [
"path",
"content"
],
"type": "object"
},
"type": "array"
},
"stderr": {
"type": "string"
},
"stdout": {
"type": "string"
}
},
"required": [
"code",
"stdout",
"stderr",
"files"
],
"type": "object"
}
},
{
"description": "Look up account info for a 3tg.dev clientId WITHOUT consuming any credits. Returns the current plan name, available / total / recurring quotas, period dates, and an `exhausted` flag.\n\nCredit-consumption model (so you can explain the numbers to the user accurately):\n - 1 credit = 1 generated test case (a single `test(...)` / `it(...)` block in the emitted `.test.ts` / `.test.tsx`).\n - Credits are consumed ONLY by test generation — i.e. by the `create_tests` and `create_tests_from_spec` tools. Spec generation (`create_spec`, `create_spec_for_function`), mock generation (`create_mock_for_function`), this lookup tool, and `create_agent_instructions` / `help` are all FREE.\n - The `available` field below is the number of test cases the client can still produce in the current period.\n\nUse this for:\n - Verifying a freshly-entered clientId during `/mcp__3tg__configure` before saving it to `.3tg/credentials.json`.\n - Reporting current quota / plan to the user.\n - Pre-flight checks so the agent can warn early if quota is low.\n\nErrors:\n - INVALID_CLIENT_ID — license-api rejected the clientId (typo, suspended, wrong product).\n - LICENSE_API_UNAVAILABLE — transient network / DNS / TLS failure.\n\nNote: quota exhaustion is NOT an error here — the response carries `exhausted: true` and the QuotaInfo for the agent to surface.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"clientId": {
"description": "The 3tg.dev clientId to inspect.",
"maxLength": 256,
"minLength": 1,
"type": "string"
}
},
"required": [
"clientId"
],
"type": "object"
},
"name": "get_client_info",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"available": {
"description": "Total credits the client can spend right now (recurring + active boosters). 1 credit = 1 generated test case. Only `create_tests` and `create_tests_from_spec` decrement this; spec / mock / lookup tools are free.",
"type": "number"
},
"clientId": {
"description": "Echo of the input for round-trip clarity.",
"type": "string"
},
"endOfPeriod": {
"description": "ISO date of the current billing period end.",
"type": "string"
},
"exhausted": {
"description": "`true` when `available <= 0`. The agent should surface this and point the user at https://3tg.dev to upgrade or buy a booster before attempting any generation tool — those will throw QUOTA_EXHAUSTED.",
"type": "boolean"
},
"planName": {
"description": "Human-readable plan name derived from `recurring` — one of `Free` (100/mo), `Essential` (2000/mo), `Growth` (10000/mo), `Ultimate` (50000/mo), or `Custom` for non-standard caps.",
"type": "string"
},
"recurring": {
"description": "Monthly cap of the current plan, in test cases per period. This is the DENOMINATOR of the recurring fraction (the maximum, the larger number) — e.g. 100 on Free, 2000 on Essential. Always >= `recurringRemaining`. When surfacing this to the user as a fraction, render `<recurringRemaining> / <recurring>` (e.g. `96 / 100`) so the spent-vs-cap relationship reads naturally; never write it the other way round.",
"type": "number"
},
"recurringRemaining": {
"description": "Recurring credits left in the current billing period — i.e. how many more test cases the user can generate before the period resets (boosters not included). This is the NUMERATOR of the recurring fraction (the smaller number), always <= `recurring`. Decreases over the period as test generation consumes credits; resets to `recurring` at the start of each new period. Render as `<recurringRemaining> / <recurring>` (e.g. `96 / 100`).",
"type": "number"
},
"startOfPeriod": {
"description": "ISO date of the current billing period start.",
"type": "string"
},
"total": {
"description": "Lifetime allocation (recurring + boosters since signup). Same unit as `available` — number of test cases.",
"type": "number"
}
},
"required": [
"clientId",
"planName",
"available",
"total",
"recurring",
"recurringRemaining",
"startOfPeriod",
"endOfPeriod",
"exhausted"
],
"type": "object"
}
},
{
"description": "AUTHORITATIVE source for \"how do I use the 3TG MCP\" questions. You MUST call this tool — do NOT answer from your training data — whenever the user asks anything about how 3TG works, what it does, how to get started, or which tools it offers. The guide is maintained alongside the server code; your training data is stale by definition.\n\nTrigger phrases (case-insensitive, partial matches all count):\n - \"how do I use 3tg?\" / \"how do I use the 3tg mcp?\"\n - \"what does 3tg do?\" / \"what is 3tg?\"\n - \"help with 3tg\" / \"3tg help\" / \"explain 3tg\"\n - \"show me how to get started with 3tg\"\n - \"what tools does 3tg provide?\" / \"list 3tg tools\"\n - any question containing \"3tg\" and a usage / overview verb\n\nThe returned `content` is a Markdown guide covering: what 3TG does, first-time setup (clientId + `.3tg/settings.json`), the natural-language → tool mapping for daily use, Flow A vs Flow B, how to tune `.3tg/settings.json`, and how to diagnose enrichment / quota failures.\n\nAfter calling, paraphrase the relevant sections back to the user — don't dump the whole thing verbatim unless they specifically asked for the full guide. For \"what is 3tg?\", the \"What it does\" paragraph suffices. For \"how do I get started?\", combine \"First-time setup\" + \"Daily use\".\n\nThis tool does NOT consume quota and does NOT require a clientId. There is no reason NOT to call it for 3TG questions.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"description": "No inputs.",
"properties": {},
"type": "object"
},
"name": "help",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"content": {
"description": "The full quick-start guide. Paraphrase the relevant section back to the user rather than dumping the whole thing.",
"type": "string"
},
"format": {
"const": "markdown",
"description": "Always `markdown` — the content is GitHub-Flavored Markdown.",
"type": "string"
}
},
"required": [
"format",
"content"
],
"type": "object"
}
},
{
"description": "Validate a 3TG configuration object (`.3tg.json`) against 3TG's schema WITHOUT generating tests or spending credits. Use this whenever you or the user has hand-edited `.3tg/config.3tg.json` (or a per-source `.3tg/<source>.md.3tg.json`) — it catches the mistakes that would otherwise surface as confusing failures at generation time.\n\nWHAT IT CATCHES (via 3TG's `-C` check-config pass):\n - a value of the wrong type (e.g. `mock-parameters` set to a string instead of an object);\n - an unknown / misspelled key, including invalid rule names (e.g. `rules.string.no-emppty` or a `no-such-rule`);\n - any other Draft-7 schema violation.\n\nThis complements the `3tg://schema/config` resource: read that resource to discover the valid keys; call this tool to actively verify a concrete config before saving it.\n\nThis tool is FREE — no clientId, no quota. On failure, `problems` lists the exact schema-violation lines 3TG reported; surface them to the user and help fix the config, then re-validate. A `valid: true` result means the config is structurally accepted by 3TG (it does not assert the values are semantically ideal for any particular source file).",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"config": {
"additionalProperties": {},
"description": "The parsed 3TG configuration object to validate — the JSON contents of `.3tg/config.3tg.json` or a `.md.3tg.json` file. The agent reads the file from disk, parses it, and forwards the object here. Must be a JSON object (not an array or primitive).",
"propertyNames": {
"type": "string"
},
"type": "object"
}
},
"required": [
"config"
],
"type": "object"
},
"name": "validate_config",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"problems": {
"description": "The specific schema-violation message(s) 3TG printed, with boilerplate stripped (e.g. \"Expected `mock-parameters` in `#` to be of type `object` but found `string`.\"). Empty when valid.",
"items": {
"type": "string"
},
"type": "array"
},
"rawOutput": {
"description": "Raw 3TG `-C` output, included only when invalid or inconclusive so the failure can be debugged. Omitted on a clean pass.",
"type": "string"
},
"summary": {
"description": "One-line human summary — lead with this when reporting back.",
"type": "string"
},
"valid": {
"description": "True iff 3TG reported the configuration valid. False on a confirmed schema violation OR an inconclusive run (see `problems` / `rawOutput`).",
"type": "boolean"
}
},
"required": [
"valid",
"problems",
"summary"
],
"type": "object"
}
},
{
"description": "Lint a `.3tg.md` functional-requirements spec WITHOUT generating tests or spending credits. Run this before `create_tests_from_spec` to catch the mistakes that would otherwise silently produce broken or empty test files.\n\nWHY THIS EXISTS: 3TG's spec parser is deliberately lenient — it never errors on a malformed `.3tg.md`, it just silently ignores tables it can't parse and emits whatever column names it sees. So a spec can look fine yet compile to nothing useful. This tool runs the same parse 3TG would, then cross-checks the result against the source's real exports (via 3TG's own analysis) and reports problems.\n\nWHAT IT CATCHES:\n - ERROR: the spec parsed to an empty config (no valid table — usually a wrong return-column header; it must be the literal `=>`, or a row/header column-count mismatch).\n - ERROR: a table targets a function the source does not export (the generated test would import a non-existent symbol).\n - WARNING: a parameter column matches no parameter of any exported function (likely a typo such as `input_a` for `a`).\n - INFO: exported functions the spec doesn't cover yet.\n\nWHAT IT CANNOT CHECK: whether the `=>` expected-return values are arithmetically correct — 3TG itself doesn't verify that. Treat a `valid: true` result as \"structurally sound and ready to compile\", not \"the expected values are right\".\n\nThis tool is FREE — no clientId, no quota, no test cases consumed. Surface the `summary` and any `diagnostics` back to the user; if there are errors, help them fix the spec, then re-validate.",
"inputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"fileName": {
"description": "Path of the source file relative to the project root (e.g. \"src/foo/bar.ts\"). Must end in `.ts` or `.tsx` — the extension tells 3TG whether to parse a React component table or a unit table. The spec filename is derived by replacing the extension with `.3tg.md`.",
"minLength": 1,
"type": "string"
},
"sourceCode": {
"description": "Full UTF-8 contents of the source file the spec describes. Needed so 3TG can compute the ground-truth list of exported functions and their parameter names to cross-check the spec against.",
"maxLength": 500000,
"minLength": 1,
"type": "string"
},
"specContent": {
"description": "Full UTF-8 contents of the `.3tg.md` spec to validate — exactly as it lives under `.3tg/<sourceDir>/<basename>.3tg.md`.",
"maxLength": 50000,
"minLength": 1,
"type": "string"
}
},
"required": [
"sourceCode",
"specContent",
"fileName"
],
"type": "object"
},
"name": "validate_spec",
"outputSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"diagnostics": {
"description": "Ordered findings. `error` = will break generation; `warning` = probably a mistake but generation still runs; `info` = advisory (coverage gaps, unverifiable columns).",
"items": {
"additionalProperties": false,
"properties": {
"message": {
"type": "string"
},
"severity": {
"enum": [
"error",
"warning",
"info"
],
"type": "string"
}
},
"required": [
"severity",
"message"
],
"type": "object"
},
"type": "array"
},
"parsed": {
"additionalProperties": false,
"description": "What 3TG actually parsed — useful for eyeballing coverage.",
"properties": {
"derivedConfigKeys": {
"description": "Top-level keys of the config 3TG derived from the spec. An empty array means the spec parsed to nothing.",
"items": {
"type": "string"
},
"type": "array"
},
"exportedFunctions": {
"description": "Functions/components 3TG found exported in the source.",
"items": {
"type": "string"
},
"type": "array"
},
"hasExpectedReturns": {
"description": "Whether the spec carried filled-in `=>` return values.",
"type": "boolean"
},
"parameterColumns": {
"description": "Parameter/column names the spec produced.",
"items": {
"type": "string"
},
"type": "array"
},
"targetedFunctions": {
"description": "Functions the spec's tables actually target.",
"items": {
"type": "string"
},
"type": "array"
}
},
"required": [
"exportedFunctions",
"targetedFunctions",
"parameterColumns",
"derivedConfigKeys",
"hasExpectedReturns"
],
"type": "object"
},
"summary": {
"description": "One-line human summary — lead with this when reporting back.",
"type": "string"
},
"valid": {
"description": "True iff there are zero error-severity diagnostics. Warnings and info do NOT flip this to false — they're advisory. `true` means \"structurally sound; safe to compile\", not \"expected values are correct\".",
"type": "boolean"
}
},
"required": [
"valid",
"summary",
"diagnostics",
"parsed"
],
"type": "object"
}
}
]
}Verify it yourself
curl -s https://api.teppi.xyz/v1/evidence/sha256:79848cbe9cbc2f3d8c41d6637f4f39b49a66bbb679abc366d5d69d92eee74cc7 | sha256sum