"namespace:net.digitalpipe.verify-test" matching MCP tools:

• benchmark

  XFMS — Xpansion Framework Model Source

  Run a live A/B test against the engine's TOP 3 PICKS for a stated purpose — the engine chooses the candidates from the full catalog. Generates 5 representative test queries (auto-expands to 10 or 15 if results are too close to call), runs them through the picked models in parallel, and returns real cost, latency, and plain-English commentary on who won what. Use AFTER `pick` or `rank` when the user wants the engine's own picks stress-tested with live data. DO NOT use this when the user has already named specific candidate models — the engine will ignore the names and test its own picks. Use `compare` instead in that case. Costs more than `rank` (15+ live LLM calls).

  Connector

• get_integration_guide

  TestMyVibes

  Returns the canonical guide for using TMV from a coding-agent context. Covers the fix-test-retest loop, how to write a good test prompt, how to read the actionTrail / consoleErrors / failedRequests outputs, and common gotchas. Call this first if you're a new agent on a project — it'll save you a debug session. The same content is served at https://testmyvibes.com/docs/coding-agents.

  Connector

• create_tests

  3TG Test Generation

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

  Connector

• validate_spec

  3TG Test Generation

  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.

  Connector

• varrd_ai

  VARRD — Statistically Validated Trading Edges + AI Research Engine

  Talk to VARRD AI (~$0.25/turn). Describe any trading idea in plain language and the system handles everything — loading decades of market data, charting your pattern, running statistical tests, backtesting with stops, and generating exact trade setups. MULTI-TURN: First call creates a session. Keep calling with the same session_id, following context.next_actions each time. 1. Your idea -> VARRD charts pattern 2. 'test it' -> statistical test (event study or backtest) 3. 'show me the trade setup' -> exact entry/stop/target prices HYPOTHESIS INTEGRITY (critical): VARRD tests ONE hypothesis at a time — one formula, one setup. Never combine multiple setups into one formula or ask to 'test all' — each idea must be tested as a separate hypothesis for the statistics to be valid. Say 'start a new hypothesis' between ideas to reset cleanly. - ALLOWED: Test the SAME setup across multiple markets ('test this on ES, NQ, and CL') — same formula, different data. - NOT ALLOWED: Test multiple DIFFERENT formulas/setups at once — each is a separate hypothesis requiring its own chart-test-result cycle. If ELROND council returns 4 setups, test each one separately: chart setup 1 -> test -> results -> 'start new hypothesis' -> chart setup 2 -> etc. KEY CAPABILITIES you can ask for: - 'Use the ELROND council on [market]' -> 8 expert investigators - 'Optimize the stop loss and take profit' -> SL/TP grid search - 'Test this on ES, NQ, and CL' -> multi-market testing - 'Simulate trading this with 1.5 ATR stop' -> backtest with stops EDGE VERDICTS in context.edge_verdict after testing: - STRONG EDGE: Significant vs zero AND vs market baseline - MARGINAL: Significant vs zero only (beats nothing, but real signal) - PINNED: Significant vs market only (flat returns but different from market) - NO EDGE: Neither significant test passed TERMINAL STATES: Stop when context.has_edge is true (edge found) or false (no edge — valid result). Always read context.next_actions.

  Connector

• benchmark

  XFMS — Model Source

  Run a live A/B test against the engine's TOP 3 PICKS for a stated purpose — the engine chooses the candidates from the full catalog. Generates 5 representative test queries (auto-expands to 10 or 15 if results are too close to call), runs them through the picked models in parallel, and returns real cost, latency, and plain-English commentary on who won what. Use AFTER `pick` or `rank` when the user wants the engine's own picks stress-tested with live data. DO NOT use this when the user has already named specific candidate models — the engine will ignore the names and test its own picks. Use `compare` instead in that case. Costs more than `rank` (15+ live LLM calls).

  Connector

• webhooks_manage

  gapup-mcp

  Manage HTTP webhook callbacks for async tools (T5/T6 batch flagships). Instead of polling every 5s, register a callback URL — Gapup posts the job result to your endpoint the moment it completes. Supported events: job.completed | job.failed | monitoring.alert | quota.threshold. Modes: register (add endpoint), list (view active webhooks), revoke (soft-delete), test (fire a test payload to verify your receiver), history (last 20 fires). Security: every delivery is signed with HMAC-SHA256 on the body — verify the X-Gapup-Signature header against sha256(secret, body).

  Connector

• create_spec

  3TG Test Generation

  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 fine — handle those normally.) See the cliConfig parameter description for the full shape. 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.

  Connector

• create_spec_for_function

  3TG Test Generation

  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.

  Connector

• compare_treaty_position

  mcp-server

  Double-tax-treaty position for a relocation corridor (from→to): is a DTA in force, the residence tie-breaker test, treaty withholding rates (dividends/interest/royalties), and any limitation-on-benefits/principal-purpose test. Use ISO alpha-2 codes. Indicative, not advice.

  Connector

• ping

  Alai

  Verify your API key and return your user ID. Use this to test authentication.

  Connector

• baselight_ping

  Baselight

  Simple ping test to verify MCP server is responding

  Connector

• robots_txt

  Httpbin

  Fetch a sample robots.txt from httpbin.org (/robots.txt). Use to test robots.txt parsing or as a content-type placeholder.

  Connector

• provision_test_card

  TestMyVibes

  Issues a single-use Stripe-Issuing virtual card hard-capped at fundedUsd, billed at funded + 25% markup + $2 service fee. PAN + CVC are returned ONCE in the response and TMV never persists them. Card auto-freezes 24h after creation. In sandbox mode (test key) cards auth only against Stripe test-mode merchants, perfect for verifying customer checkout flows without real money. Charged in credits at 1 credit = $0.10 (so a $10 funded card costs ~125 credits all-in). Provisioning fee absorbed into the markup.

  Connector

• pentest_map_techniques

  pentest-mcp-server

  Given a profile of the authorized test target (technology stack, exposed services, authentication type, OS), return a ranked list of ATT&CK techniques and OWASP test cases most relevant to that profile — not a generic dump of all techniques. Ranking factors: platform match, service match, auth type exposure, technique prevalence. Each result includes why it is relevant to this specific profile, the detection opportunity, and the recommended mitigation. Use when starting an authorized engagement to prioritize the testing scope; pair with pentest_guide to get the full methodology for each top-ranked vector.

  Connector

• webhooks_manage

  gapup-mcp

  Manage HTTP webhook callbacks for async tools (T5/T6 batch flagships). Instead of polling every 5s, register a callback URL — Gapup posts the job result to your endpoint the moment it completes. Supported events: job.completed | job.failed | monitoring.alert | quota.threshold. Modes: register (add endpoint), list (view active webhooks), revoke (soft-delete), test (fire a test payload to verify your receiver), history (last 20 fires). Security: every delivery is signed with HMAC-SHA256 on the body — verify the X-Gapup-Signature header against sha256(secret, body).

  Connector

• create_tests_from_spec

  3TG Test Generation

  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]` warning when stripping happens, so check stderr if you expected per-source values to apply. 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.

  Connector

• create_mock_for_function

  3TG Test Generation

  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.

  Connector

• search_tools

  Keploy

  DISCOVER tool names you do NOT already know, by keyword. Most Keploy tools are hidden from the default tool list to save context. If you ALREADY know the exact name (e.g. a skill named it), call get_tool_schema instead — it is exact and far cheaper than this fuzzy search. Returns {"matches": [{name, description, inputSchema}, ...], "total_catalog": N}. Search by intent words, e.g. "test report", "mock patch", "update test case", "cloud replay branch", "record".

  Connector

• calls_agent_duel

  dialogbrain

  Start an agent-vs-agent VOICE test call: two AI voice agents share one LiveKit room — a 'caller' persona agent pursues a task brief against the 'callee' business agent under test. Use to evaluate booking flows, latency, and conversation quality without a human caller. The CALLER agent should have an EMPTY voice_greeting (it must stay silent until the callee greets) and voice_filler_enabled=false. Afterwards inspect both call_ids with agents.traces_list / calls.get_transcript. A subscribe-only `listen` token is returned for listening in live.

  Connector