{"serverId":"mcp-registry/dev.3tg/mcp","tools":[{"name":"create_agent_instructions","fixed":{"name":"create_agent_instructions","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, par","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","properties":{},"description":"No inputs.","additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":199,"tokensAfter":199},{"name":"create_mock_for_function","fixed":{"name":"create_mock_for_function","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 exac","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","fileName","functionName","clientId"],"properties":{"clientId":{"type":"string","minLength":1,"description":"The 3tg.dev client ID."},"fileName":{"type":"string","minLength":1,"description":"Path of the source file relative to the user's project root."},"settings":{"type":"object","properties":{"creationMode":{"type":"string","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."},"mockAsFunction":{"type":"boolean","description":"Declare mocks as function instead of const (3TG flag -N)."},"useAiEnrichment":{"type":"boolean","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."},"aiEnrichmentMode":{"enum":["auto","client","local","off"],"type":"string","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."},"noRuleDefaultTrue":{"type":"boolean","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."}},"description":"Subset of .3tg/settings.json relevant to this tool.","additionalProperties":false},"cliConfig":{"type":"object","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"},"additionalProperties":{}},"moduleType":{"enum":["module","commonjs"],"type":"string","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."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"description":"Full UTF-8 contents of the source file."},"functionName":{"type":"string","minLength":1,"description":"Name of the exported function to mock. Forwarded as `-f <functionName>`."}},"additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":2155,"tokensAfter":2155},{"name":"create_spec","fixed":{"name":"create_spec","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","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","fileName","clientId"],"properties":{"clientId":{"type":"string","minLength":1,"description":"The 3tg.dev client ID."},"fileName":{"type":"string","minLength":1,"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`."},"settings":{"type":"object","properties":{"creationMode":{"type":"string","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."},"mockAsFunction":{"type":"boolean","description":"Declare mocks as function instead of const (3TG flag -N)."},"useAiEnrichment":{"type":"boolean","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."},"aiEnrichmentMode":{"enum":["auto","client","local","off"],"type":"string","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."},"noRuleDefaultTrue":{"type":"boolean","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."}},"description":"Subset of .3tg/settings.json relevant to this tool.","additionalProperties":false},"cliConfig":{"type":"object","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"},"additionalProperties":{}},"moduleType":{"enum":["module","commonjs"],"type":"string","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."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"description":"Full UTF-8 contents of the source file."}},"additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":2140,"tokensAfter":2140},{"name":"create_spec_for_function","fixed":{"name":"create_spec_for_function","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","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","fileName","functionName","clientId"],"properties":{"clientId":{"type":"string","minLength":1,"description":"The 3tg.dev client ID."},"fileName":{"type":"string","minLength":1,"description":"Path of the source file relative to the user's project root."},"settings":{"type":"object","properties":{"creationMode":{"type":"string","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."},"mockAsFunction":{"type":"boolean","description":"Declare mocks as function instead of const (3TG flag -N)."},"useAiEnrichment":{"type":"boolean","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."},"aiEnrichmentMode":{"enum":["auto","client","local","off"],"type":"string","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."},"noRuleDefaultTrue":{"type":"boolean","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."}},"description":"Subset of .3tg/settings.json relevant to this tool.","additionalProperties":false},"cliConfig":{"type":"object","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"},"additionalProperties":{}},"moduleType":{"enum":["module","commonjs"],"type":"string","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."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"description":"Full UTF-8 contents of the source file."},"functionName":{"type":"string","minLength":1,"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."}},"additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":2176,"tokensAfter":2176},{"name":"create_tests","fixed":{"name":"create_tests","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 accou","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","fileName","clientId"],"properties":{"clientId":{"type":"string","minLength":1,"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."},"fileName":{"type":"string","minLength":1,"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."},"settings":{"type":"object","properties":{"creationMode":{"type":"string","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."},"mockAsFunction":{"type":"boolean","description":"Declare mocks as function instead of const (3TG flag -N)."},"useAiEnrichment":{"type":"boolean","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."},"aiEnrichmentMode":{"enum":["auto","client","local","off"],"type":"string","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."},"noRuleDefaultTrue":{"type":"boolean","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."}},"description":"Subset of .3tg/settings.json relevant to this tool.","additionalProperties":false},"cliConfig":{"type":"object","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"},"additionalProperties":{}},"moduleType":{"enum":["module","commonjs"],"type":"string","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."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"description":"Full UTF-8 contents of the source file."}},"additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":2176,"tokensAfter":2176},{"name":"create_tests_from_spec","fixed":{"name":"create_tests_from_spec","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 ","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","specContent","fileName","clientId"],"properties":{"clientId":{"type":"string","minLength":1,"description":"The 3tg.dev client ID."},"fileName":{"type":"string","minLength":1,"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`."},"settings":{"type":"object","properties":{"creationMode":{"type":"string","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."},"mockAsFunction":{"type":"boolean","description":"Declare mocks as function instead of const (3TG flag -N)."},"useAiEnrichment":{"type":"boolean","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."},"aiEnrichmentMode":{"enum":["auto","client","local","off"],"type":"string","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."},"noRuleDefaultTrue":{"type":"boolean","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."}},"description":"Subset of .3tg/settings.json relevant to this tool.","additionalProperties":false},"cliConfig":{"type":"object","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"},"additionalProperties":{}},"moduleType":{"enum":["module","commonjs"],"type":"string","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."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"description":"Full UTF-8 contents of the source file."},"specContent":{"type":"string","maxLength":50000,"minLength":1,"description":"Full UTF-8 contents of the `.3tg.md` spec — as the user has edited it locally under `.3tg/<sourceDir>/<basename>.3tg.md`."}},"additionalProperties":false},"annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: false, destructiveHint: false, idempotentHint: false (inferred from the name).","verify":true}],"tokensBefore":2205,"tokensAfter":2205},{"name":"get_client_info","fixed":{"name":"get_client_info","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. S","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["clientId"],"properties":{"clientId":{"type":"string","maxLength":256,"minLength":1,"description":"The 3tg.dev clientId to inspect."}},"additionalProperties":false},"annotations":{"readOnlyHint":true}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: true (inferred from the name).","verify":true}],"tokensBefore":225,"tokensAfter":225},{"name":"validate_config","fixed":{"name":"validate_config","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 / miss","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["config"],"properties":{"config":{"type":"object","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"},"additionalProperties":{}}},"additionalProperties":false},"annotations":{"readOnlyHint":true}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: true (inferred from the name).","verify":true}],"tokensBefore":292,"tokensAfter":292},{"name":"validate_spec","fixed":{"name":"validate_spec","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 3T","inputSchema":{"type":"object","$schema":"http://json-schema.org/draft-07/schema#","required":["sourceCode","specContent","fileName"],"properties":{"fileName":{"type":"string","minLength":1,"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`."},"sourceCode":{"type":"string","maxLength":500000,"minLength":1,"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."},"specContent":{"type":"string","maxLength":50000,"minLength":1,"description":"Full UTF-8 contents of the `.3tg.md` spec to validate — exactly as it lives under `.3tg/<sourceDir>/<basename>.3tg.md`."}},"additionalProperties":false},"annotations":{"readOnlyHint":true}},"changes":[{"kind":"annotations","detail":"Added readOnlyHint: true (inferred from the name).","verify":true}],"tokensBefore":421,"tokensAfter":421}],"toolsChanged":9,"tokensSaved":0,"todo":[],"note":"Deterministic fixes. Changes marked verify need a human look before shipping (renames, inferred annotations, inferred types, removed text). Parameter descriptions in `todo` need to be written by someone who knows the API."}