Local MCP capabilities provider for Expo
3TG Test Generation is installed from its publisher's own source and answers where it runs, so this marketplace is not in the path of a single call. There is no address here to send one to, and a panel that pretended otherwise would be showing you an answer we made up. Install it and call it from your own client — the Installation tab has the entry for each one.
What it does
3rd Generation Testing (3TG) — generate deterministic test suites from Markdown spec tables via MCP.
Quickstart
# 1 — add it to Claude Code
claude mcp add --scope user --transport http 3tg-test-generation-mcp https://mcp.3tg.dev/mcp
# 2 — ask your agent for something these tools do
# create_tests, create_spec, create_tests_from_spec and 7 more
3TG Test Generation costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.
Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine and nothing runs on ours: this server answers at its publisher’s own address, and what you install is the connection straight to it.
This is a public server: it answers at its publisher’s own address and this marketplace is not in the path. Claude Code registers it in one command; --scope user makes it available in every project. The transport below is http, as the publisher's own manifest declares it.
claude mcp add --scope user --transport http 3tg-test-generation-mcp https://mcp.3tg.dev/mcpReconnect, or start a new session, and the tools appear in the model’s tool list.
One config entry pointing straight at the publisher’s own address — this marketplace is not in the path, and nothing from this listing executes on your machine.
10 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
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. Quota / credits: this tool consumes credi
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | Full UTF-8 contents of the source file. |
| fileName | string | yes | 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. |
| clientId | string | yes | 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. |
| settings | object | no | Subset of .3tg/settings.json relevant to this tool. |
| cliConfig | object | no | 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: (1) **Global |
| moduleType | string | no | 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 i |
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. IMPORT
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | Full UTF-8 contents of the source file. |
| fileName | string | yes | 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. |
| clientId | string | yes | The 3tg.dev client ID. |
| settings | object | no | Subset of .3tg/settings.json relevant to this tool. |
| cliConfig | object | no | 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: (1) **Global |
| moduleType | string | no | 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 i |
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. Inputs: the source code plus the spec content (the spec li
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | Full UTF-8 contents of the source file. |
| specContent | string | yes | Full UTF-8 contents of the .3tg.md spec — as the user has edited it locally under .3tg/<sourceDir>/<basename>.3tg.md. |
| fileName | string | yes | 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. |
| clientId | string | yes | The 3tg.dev client ID. |
| settings | object | no | Subset of .3tg/settings.json relevant to this tool. |
| cliConfig | object | no | 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: (1) **Global |
| moduleType | string | no | 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 i |
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. IMPORTANT — never hand-author a .3tg.md yourself. The format is parser-strict: parameter columns named exactly as the pa
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | Full UTF-8 contents of the source file. |
| fileName | string | yes | Path of the source file relative to the user's project root. |
| functionName | string | yes | Name of the exported function or React component to scope the spec to. Forwarded to 3TG as -f <functionName>. Use default for default exports. |
| clientId | string | yes | The 3tg.dev client ID. |
| settings | object | no | Subset of .3tg/settings.json relevant to this tool. |
| cliConfig | object | no | 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: (1) **Global |
| moduleType | string | no | 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 i |
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. AI enrichment is on by default (it helps the mock pick representative return values), but **this tool does NOT consume credi
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | Full UTF-8 contents of the source file. |
| fileName | string | yes | Path of the source file relative to the user's project root. |
| functionName | string | yes | Name of the exported function to mock. Forwarded as -f <functionName>. |
| clientId | string | yes | The 3tg.dev client ID. |
| settings | object | no | Subset of .3tg/settings.json relevant to this tool. |
| cliConfig | object | no | 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: (1) **Global |
| moduleType | string | no | 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 i |
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. WHY 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 na
| Parameter | Type | Required | Notes |
|---|---|---|---|
| sourceCode | string | yes | 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 | string | yes | Full UTF-8 contents of the .3tg.md spec to validate — exactly as it lives under .3tg/<sourceDir>/<basename>.3tg.md. |
| fileName | string | yes | 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 f |
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. WHAT IT CATCHES (via 3TG's -C check-config pass): - a value of
| Parameter | Type | Required | Notes |
|---|---|---|---|
| config | object | yes | 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. Mus |
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. Credit-consumption model (so you can explain the numbers to the user accurately): - 1 credit = 1 generated test case (a single test(...) / it(...) block in the emitted .test.ts / .test.tsx). - Credits are
| Parameter | Type | Required | Notes |
|---|---|---|---|
| clientId | string | yes | The 3tg.dev clientId to inspect. |
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 t
No parameter schema on file.
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. Trigger phrases (case-insensitive, partial matches all count):
No parameter schema on file.
- Every tool — any call limit is its publisher’s, not ours
- No card, and mcprush charges nothing for it
- Runs at its publisher’s own address — this marketplace is not in the path
- Nothing to cap, because mcprush bills nothing
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable: mcprush charges nothing to install 3TG Test Generation or to call it, at any volume.
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
This listing is an address its publisher runs, and you connect to it directly — this marketplace is not in the path. The scanner reads packages and public source, and an address is neither. So there is no grade — not a withheld one, an unmeasured one.
Release history
This is an address its publisher runs: which release it serves is theirs to choose, so there is nothing here to pin. The history below is for reading; the current release on file is 1.1.0.
No release note was published with this version.
One review per account, from a signed-in account that does not publish this listing. Nothing else is asked — you can say what you think before you install it. Publishers can reply once per review, and a review can be edited or deleted by whoever wrote it.
Any signed-in account that does not publish 3TG Test Generation can review it, once — before installing it or after. A review from an account that has installed it is marked as one.
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes a signed-in account that does not publish it, and nothing else.