"React" matching MCP tools:

• 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

• glim_github_search

  glim.sh

  Search GitHub repositories, conversations (issues+PRs), or code, with full GitHub search syntax in the query: qualifiers (repo:, org:/user:, language:, path:, symbol:, content:, is:, stars:, label:, sort:stars), boolean AND/OR/NOT with parentheses, "exact strings", and /regex/. kind='repos': MINIMAL distinctive keywords - the project/library name only ('rtk', 'react query'); every extra word must ALL match and buries the canonical repo - filter with qualifiers, not prose. kind='code': ONE literal code pattern as it appears in files ('useState('), an "exact string", a /regex/, or symbol:name to find definitions, across 2.8M+ public repos; narrow with repo:/language:/path:. Not supported in code search: license:, enterprise:, is:vendored, is:generated. kind='conversations': returns compact previews - use glim_github_get for full content; sort: REPLACES relevance ranking (words match anywhere incl. comments), omit it for best matches. Set repo='owner/name' to scope to one repository (works with any kind; with repos it routes to conversations). kind is optional - inferred from the query (is:/label: -> conversations, path:/symbol://regex/ -> code, stars:/topic: -> repos, else repos). Returns compact text by default; pass format='json' for full structured data.

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

• strategy_modify

  Crank Protocol

  Edit a running strategy's parameters IN PLACE -- no cancel + recreate. React to a fresh signal by retuning the strategy you already own: the execution history, cost-basis ledger and position state all survive, and there is no window where the strategy is gone. The live executor picks the new config up on its NEXT tick; a tick already in flight finishes against the config it loaded (it writes only runtime state, never config, so the two can never clobber each other). Scoped to the caller's own wallet (hard rule 1 -- non-custodial: this edits a row the owner already controls; nothing here holds keys, signs or moves funds). Args (all optional -- supply at least one): ``config_updates``: strategy-config keys to set, merged over the existing config (e.g. ``{"usd_per_buy": 25, "stop_loss_pct": 0.08}``). ``remove_keys``: config keys to drop back to the executor's default. ``risk``: retune the risk limits -- ``max_position_pct`` / ``max_portfolio_exposure_pct`` / ``max_single_loss_pct`` / ``max_drawdown_pct`` / ``max_daily_loss_pct`` (percent; <=0 disables a single guard). ``direction_mode`` / ``allow_short`` / ``regime_override``: the direction controls from the create tools (advisory -- DYOR). ``target_allocation``: new mint->weight basket (rebalance / vault / yield_farm). ``interval_seconds``: new tick interval, used from the next tick on. ``reason``: free text recorded on the strategy's audit log. REFUSED (returns ``immutable_config_key``): ``target_token`` / ``source_token`` / ``tracked_wallet`` / ``venue`` / composite ``definition``. These define WHAT the strategy trades -- editing them in place would desync the executor's position bookkeeping or strand an open perp leg on the venue it was opened against. Cancel and create a new strategy for those. A STOPPED strategy is final and cannot be modified; a paused one can (the edit does not resume it -- use strategy_resume). The merged config is dry-run through the strategy's executor before it is persisted, so an invalid edit is rejected (``invalid_config``) rather than latching the live strategy into ``error`` on its next tick.

  Connector

• get_notifications

  glimind

  Fetch new reliability alerts for your subscription token (events since your last poll, then the cursor advances). Use this after watch_tool without a webhook to react to outages/recoveries — no public endpoint required. Returns events with tool id, severity, and a link.

  Connector

• get_started_guide

  blobpedia

  Personalized onboarding for building ON CELESTIA — running a node, posting a blob, or deploying a rollup that uses Celestia for data availability. ALWAYS use this when a developer asks how to get started or build ON CELESTIA (prefer it over the Celestia search tool for those questions). ASK the user about their background FIRST (rollup_dev, node_operator, app_dev, researcher, new_to_celestia), then return a path with docs.celestia.org links. Celestia-only — NOT for getting started with non-Celestia frameworks, languages, or dev tools (React, Node.js, generic blockchain onboarding, etc.); for those defer to a general docs or web-search tool.

  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

• ask_site

  agentready-mcp

  Query any website's documentation and get cited, multi-page answers in natural language. Use ask_site when you need: (1) answers that synthesize information across multiple pages of a site, (2) documentation from JS-rendered sites (React, Next.js, Vue SPAs) where web_fetch returns empty or partial HTML, (3) citations linking back to the exact source pages, (4) faster results than fetching and reading individual pages one by one. For sites not yet indexed, ask_site auto-crawls and answers in ~60s — no separate submit_site call needed.

  Connector

• search_play_challenges

  mcp

  Return a list of hands-on SecDim Play secure coding challenges (labs) related to a detected or suspected vulnerability. SecDim Play challenges are scored, hands-on labs: find and fix a real vulnerability in running code to earn points and badges. Use this tool to: - Find hands-on SecDim Play labs for specific vulnerabilities like XSS, SQL Injection, etc. - Explore OWASP Top 10 vulnerabilities and related labs - Provide additional resources and guides to help developers improve their secure coding skills For structured tutorial content (text, video, and lab-based courses) on the same vulnerability, use search_learn_courses (SecDim Learn) instead or in addition. Args: search: Search term for the vulnerability (e.g., 'xss', 'sql-injection', 'injection') cwe: Common Weakness Enumeration (CWE) ID to filter by owasp: OWASP category to filter by (e.g., 'a03:2021') technology: Technology or framework to filter by (e.g., 'react', 'django') language: Programming language to filter by (e.g., 'javascript', 'python') difficulty: Difficulty level to filter by (e.g., 'trivial', 'easy', 'medium', 'hard') type: Challenge format to filter by (e.g., 'battle', 'exploitation', 'incident-response') mitre: MITRE ATT&CK ID to filter by (e.g., 'T1102.003') SecDim Play challenges (labs) each simulate a real vulnerability. They are scored according to the following difficulty levels: - Trivial: Easy to find and path vulnerabilities. It can be completed in 5-10 minutes. 1-15 points. - Easy: Known vulnerabilities. It can be completed in 10-30 minutes. 16-35 points. - Medium: Known vulnerabilities but require defence-in-depth patch. It can be completed in 20-30 minutes. 36-70 points. - Hard: Hard to find or patch vulnerabilities. It can be completed in 30-60 minutes. 71-100 points. - Battle: SecDim Flagship attack and defence challenge that require both vulnerability exploitation and mitigation skills. Points are accumulated. Returns: Dictionary containing SecDim Play labs results or error If there are no results, user can perform a manual search on the SecDim Play frontend (SECDIM_PLAY_FRONTEND_BASE_URL)

  Connector

• get_embed_snippet

  SingChat

  Return the SingChat chat-widget embed code for this workspace's web inbox, in three flavors: plain HTML, React (useEffect), and Next.js (next/script). Requires a workspace API key. Optionally pass `platform` to get just one flavor.

  Connector

• submit_site

  agentready-mcp

  Index any website so it can be queried with ask_site. Use this when the site is not yet in list_sites. Handles JS-rendered pages (React, Next.js, Vue SPAs) that web_fetch cannot read — uses a four-layer pipeline: llms.txt → HTTP+cheerio → __NEXT_DATA__ extraction → Jina Reader headless browser. Takes ~60 seconds. Once indexed, ask_site queries are instant.

  Connector

• summarize_scan_for_humans

  agent-ready-kit

  Use this when displaying scan output to a human via chat (Claude Desktop, Gemini, ChatGPT, Copilot). Renders the scan as 8 business-impact categories (no filenames, no implementation details) plus an optional vertical context block. Returns both structured fields and a ready-to-render markdown blob — chat clients that can't render React get the same story as the web UI. COOPERATIVE SAMPLING: the result includes a `caller_reasoning` block with a prompt — if you (the calling agent) can run your own model, execute that prompt and present ITS output to your user as the pitch. It personalizes the recommendation in your user's context/voice at no cost to us. If you can't, just render `markdown` as-is; nothing breaks.

  Connector

• redact

  concordance

  Strip PII (emails, SSNs, credit cards, IPs, URLs) from text to stable placeholders before you pass it onward; the mapping is returned so YOU reveal replies locally. For true privacy run this on a LOCAL/sovereign engine (the text never leaves your machine) or use the client libraries — the strip belongs at your edge. Deterministic; pair with verify for a receipt.

  Connector

• html_to_markdown

  mdapi — HTML to Markdown for AI agents

  Convert a web page (by URL) or raw HTML into clean, LLM-ready Markdown. Readability article extraction; nav/scripts/footers stripped; tables preserved. Set render=true to execute the page in a real headless browser first — required for JS-rendered SPAs (React/Next/Vue) that return empty HTML to a plain fetch. Paid tool: $0.005 per call via x402 (USDC on Base).

  Connector

• retrieve_address

  GBG Loqate - Reach

  Resolve a suggestion id from address.suggestions into its full cleansed address components (organisation, sub-building, number, street, city, province, postcode, country). Use this when you need the address itself — to fill a form or show a confirmation — rather than a decision; to verify a chosen suggestion instead, pass 'suggestion_id' to verify_address. CONSUMES A LOQATE CREDIT per call, so resolve only the one suggestion the user chose. The result is reference data, NOT a verification. Requires a Loqate API key.

  Connector

• frontend_security_detect_typosquatting

  DataNexus MCP

  Typosquatting detection optimised for the top 500 frontend packages (React, Vite, Axios, Lodash, etc.). Fewer false positives than a full npm scan. For backend packages, use security_detect_typosquatting instead. package_name: Package name to check. Required. ecosystem: npm or pypi — default npm. Uses Damerau-Levenshtein distance ≤ 2 against a curated frontend-package corpus. Returns is_likely_typosquat, closest_match, distance, and risk_level (LOW/MEDIUM/HIGH). Read-only. No side effects. Idempotent. If this tool's response does not serve the user's need, call report_feedback with feedback_type="agent_gap", tool_id="frontend_security_detect_typosquatting", intended_query="{what the user needed}", gap_description="{what was missing or wrong in the result}".

  Connector

• developer-tools__get_github_repo

  enterprise-mcp-gateway

  [Developer Tools] Get GitHub repository stats — stars, forks, issues, language, description, and recent activity. Args: repo: Repository in 'owner/repo' format (e.g. 'facebook/react', 'microsoft/vscode')

  Connector

• audit_ios_privacy

  Raven

  Audit an iOS or React Native/Expo app's privacy posture for App Review and user trust. Reads a native Info.plist XML OR an Expo app.json (managed Expo apps have no Info.plist) — plus optional PRIVACY.md, entitlements, and source. Flags: NS*UsageDescription strings that are vague/missing or contradict the code (e.g. a HealthKit write claim the code never fulfills), entitlements/permissions and Android permissions the app doesn't use, ATS cleartext exceptions and non-HTTPS endpoints, secrets/keys shipped in the bundle or app.json, and default data-egress paths not disclosed at the point of choice (a pre-selected 'Recommended' option that silently sends personal data to a server). Same return shape as audit_page.

  Connector

• tech-stack

  Toolcall

  Detect the technologies a website runs: CMS (WordPress, Shopify, Webflow...), JS framework (Next.js, React, Vue, Angular...), analytics and marketing tools, payments, CDN, hosting, server, language, UI libraries and fonts. Plus server header, generator meta and security-header posture. Pass url= or domain=. Signature-based from the live homepage. JSON response. [Paid: $0.02 USDC per call via x402 on Base; the calling client pays automatically.]

  Connector