# 3TG Test Generation (remote · mcp.3tg.dev)

3rd Generation Testing (3TG) — generate deterministic test suites from Markdown spec tables via MCP.

- Trust score: 64/100 (medium)
- Change this week: +18
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.3tg.dev`: 64/100 (this document), [markdown](https://verifymcp.io/servers/dev-3tg-mcp/mcp.md), [page](https://verifymcp.io/servers/dev-3tg-mcp/mcp)

## Channel facts

- Endpoint: `https://mcp.3tg.dev/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 10 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 48/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (poor).
  - Context-footprint check failed: tool/resource definitions use about 12040 tokens (~860/item across 14 items; 10 tools + 4 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http dev-3tg-mcp https://mcp.3tg.dev/mcp
```

### Codex

```toml
[mcp_servers.dev-3tg-mcp]
url = "https://mcp.3tg.dev/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "dev-3tg-mcp": {
      "type": "remote",
      "url": "https://mcp.3tg.dev/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add dev-3tg-mcp --url https://mcp.3tg.dev/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  dev-3tg-mcp:
    url: "https://mcp.3tg.dev/mcp"
```

### Other

```json
{
  "mcpServers": {
    "dev-3tg-mcp": {
      "type": "http",
      "url": "https://mcp.3tg.dev/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 62, +2)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 60, +12)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 48, +1)

- [functional] New prompt “generate-tests”
- [functional] New prompt “configure”

### 2026-07-28 (score 47, +1)

- [functional regression] Prompt “generate-tests” was removed
- [functional regression] Prompt “configure” was removed

### 2026-07-27 (score 46, +6)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 40)

First indexed and scored.

## MCP tools (10)

### `create_tests` (~1867 tokens)

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 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.

When 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.

CRITICAL POST-CALL ACTION — write returned files to disk:
  The MCP server does NOT touch the user's filesystem. It returns the generated file CONTENTS in the response's `files` arr…

Input parameters:

- `cliConfig` (object): 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) **Globa…
- `clientId` (string, required): 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` (string, required): 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.
- `moduleType` (string): 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…
- `settings` (object): Subset of .3tg/settings.json relevant to this tool.
- `sourceCode` (string, required): Full UTF-8 contents of the source file.

Output parameters:

- `code` (number): 3TG CLI exit code (0 on success).
- `enrichment`: 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` / `s…
- `files` (array): **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…
- `stderr` (string)
- `stdout` (string)

### `create_spec` (~1927 tokens)

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.

IMPORTANT — 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.

The 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.

Quota / 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.

If 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 f…

Input parameters:

- `cliConfig` (object): 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) **Globa…
- `clientId` (string, required): The 3tg.dev client ID.
- `fileName` (string, required): 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`.
- `moduleType` (string): 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…
- `settings` (object): Subset of .3tg/settings.json relevant to this tool.
- `sourceCode` (string, required): Full UTF-8 contents of the source file.

Output parameters:

- `code` (number): 3TG CLI exit code (0 on success).
- `enrichment`: 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` / `s…
- `files` (array): **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…
- `stderr` (string)
- `stdout` (string)

### `create_tests_from_spec` (~1994 tokens)

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 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.

Quota / 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.

\**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]…

Input parameters:

- `cliConfig` (object): 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) **Globa…
- `clientId` (string, required): The 3tg.dev client ID.
- `fileName` (string, required): 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`.
- `moduleType` (string): 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…
- `settings` (object): Subset of .3tg/settings.json relevant to this tool.
- `sourceCode` (string, required): Full UTF-8 contents of the source file.
- `specContent` (string, required): Full UTF-8 contents of the `.3tg.md` spec — as the user has edited it locally under `.3tg/<sourceDir>/<basename>.3tg.md`.

Output parameters:

- `code` (number): 3TG CLI exit code (0 on success).
- `enrichment`: 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` / `s…
- `files` (array): **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…
- `stderr` (string)
- `stdout` (string)

### `create_spec_for_function` (~1650 tokens)

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 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.

Quota / 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.

CRITICAL POST-CALL ACTION — write returned files to disk:
  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.

  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.

  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.

Input parameters:

- `cliConfig` (object): 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) **Globa…
- `clientId` (string, required): The 3tg.dev client ID.
- `fileName` (string, required): Path of the source file relative to the user's project root.
- `functionName` (string, required): Name of the exported function or React component to scope the spec to. Forwarded to 3TG as `-f <functionName>`. Use `default` for default exports.
- `moduleType` (string): 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…
- `settings` (object): Subset of .3tg/settings.json relevant to this tool.
- `sourceCode` (string, required): Full UTF-8 contents of the source file.

Output parameters:

- `code` (number): 3TG CLI exit code (0 on success).
- `enrichment`: 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` / `s…
- `files` (array): **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…
- `stderr` (string)
- `stdout` (string)

### `create_mock_for_function` (~1600 tokens)

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 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.

CRITICAL POST-CALL ACTION — write returned files to disk:
  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.

  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.

  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.

Input parameters:

- `cliConfig` (object): 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) **Globa…
- `clientId` (string, required): The 3tg.dev client ID.
- `fileName` (string, required): Path of the source file relative to the user's project root.
- `functionName` (string, required): Name of the exported function to mock. Forwarded as `-f <functionName>`.
- `moduleType` (string): 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…
- `settings` (object): Subset of .3tg/settings.json relevant to this tool.
- `sourceCode` (string, required): Full UTF-8 contents of the source file.

Output parameters:

- `code` (number): 3TG CLI exit code (0 on success).
- `enrichment`: 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` / `s…
- `files` (array): **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…
- `stderr` (string)
- `stdout` (string)

### `validate_spec` (~516 tokens)

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 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.

WHAT IT CATCHES:
  \- 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).
  \- ERROR: a table targets a function the source does not export (the generated test would import a non-existent symbol).
  \- WARNING: a parameter column matches no parameter of any exported function (likely a typo such as `input_a` for `a`).
  \- INFO: exported functions the spec doesn't cover yet.

WHAT 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".

This 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.

Input parameters:

- `fileName` (string, required): 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…
- `sourceCode` (string, required): 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, required): Full UTF-8 contents of the `.3tg.md` spec to validate — exactly as it lives under `.3tg/<sourceDir>/<basename>.3tg.md`.

Output parameters:

- `diagnostics` (array): Ordered findings. `error` = will break generation; `warning` = probably a mistake but generation still runs; `info` = advisory (coverage gaps, unverifiable columns).
- `parsed` (object): What 3TG actually parsed — useful for eyeballing coverage.
- `summary` (string): One-line human summary — lead with this when reporting back.
- `valid` (boolean): 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 correc…

### `validate_config` (~362 tokens)

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 the wrong type (e.g. `mock-parameters` set to a string instead of an object);
  \- an unknown / misspelled key, including invalid rule names (e.g. `rules.string.no-emppty` or a `no-such-rule`);
  \- any other Draft-7 schema violation.

This 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.

This 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).

Input parameters:

- `config` (object, required): 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. Mu…

Output parameters:

- `problems` (array): 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.
- `rawOutput` (string): Raw 3TG `-C` output, included only when invalid or inconclusive so the failure can be debugged. Omitted on a clean pass.
- `summary` (string): One-line human summary — lead with this when reporting back.
- `valid` (boolean): True iff 3TG reported the configuration valid. False on a confirmed schema violation OR an inconclusive run (see `problems` / `rawOutput`).

### `get_client_info` (~346 tokens)

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 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.
  \- The `available` field below is the number of test cases the client can still produce in the current period.

Use this for:
  \- Verifying a freshly-entered clientId during `/mcp__3tg__configure` before saving it to `.3tg/credentials.json`.
  \- Reporting current quota / plan to the user.
  \- Pre-flight checks so the agent can warn early if quota is low.

Errors:
  \- INVALID_CLIENT_ID — license-api rejected the clientId (typo, suspended, wrong product).
  \- LICENSE_API_UNAVAILABLE — transient network / DNS / TLS failure.

Note: quota exhaustion is NOT an error here — the response carries `exhausted: true` and the QuotaInfo for the agent to surface.

Input parameters:

- `clientId` (string, required): The 3tg.dev clientId to inspect.

Output parameters:

- `available` (number): 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 too…
- `clientId` (string): Echo of the input for round-trip clarity.
- `endOfPeriod` (string): ISO date of the current billing period end.
- `exhausted` (boolean): `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.
- `planName` (string): 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.
- `recurring` (number): 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 >= `recurri…
- `recurringRemaining` (number): 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 fra…
- `startOfPeriod` (string): ISO date of the current billing period start.
- `total` (number): Lifetime allocation (recurring + boosters since signup). Same unit as `available` — number of test cases.

### `create_agent_instructions` (~759 tokens)

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.

Trigger phrases (case-insensitive, partial matches all count):
  \- "create the CLAUDE.md needed by 3tg"
  \- "create the CLAUDE.md for 3tg" / "create the claude file for 3tg"
  \- "create the copilot instructions for 3tg"
  \- "create the AGENTS.md for 3tg"
  \- "set up 3tg in this project" / "init 3tg here"
  \- "install 3tg config" / "install 3tg in this project"
  \- "configure 3tg" (when in a tool-only client like GitHub Copilot)
  \- "write the 3tg agent instructions"
  \- any request containing both "3tg" and a setup / install / create / configure / scaffold verb

The 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.

For EACH entry in `files`, the agent MUST:
  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/`).
  2\. Project-wide entries (audience `claude` / `copilot` / `cross_vendor`) use the `anchorHeading` for idempotency: if the f…

Output parameters:

- `anchorHeading` (string): 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…
- `files` (array): 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.
- `version` (string): 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 versio…

### `help` (~368 tokens)

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):
  \- "how do I use 3tg?" / "how do I use the 3tg mcp?"
  \- "what does 3tg do?" / "what is 3tg?"
  \- "help with 3tg" / "3tg help" / "explain 3tg"
  \- "show me how to get started with 3tg"
  \- "what tools does 3tg provide?" / "list 3tg tools"
  \- any question containing "3tg" and a usage / overview verb

The 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.

After 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".

This tool does NOT consume quota and does NOT require a clientId. There is no reason NOT to call it for 3TG questions.

Output parameters:

- `content` (string): The full quick-start guide. Paraphrase the relevant section back to the user rather than dumping the whole thing.
- `format` (string): Always `markdown` — the content is GitHub-Flavored Markdown.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/dev-3tg-mcp/mcp#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 63
- 2026-08-01: 63
- 2026-07-31: 62
- 2026-07-30: 60
- 2026-07-29: 48
- 2026-07-28: 47
- 2026-07-27: 46
- 2026-07-26: 40

## Links

- Remote endpoint: https://mcp.3tg.dev/mcp
- Website: https://3tg.dev/
- Changelog RSS feed: https://verifymcp.io/servers/dev-3tg-mcp/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/dev-3tg-mcp/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/dev-3tg-mcp/mcp