"TypeScript" matching MCP tools:

• json-to-typescriptB

  JobDoneBotC

  Infer TypeScript interface definitions from JSON samples.

  ConnectorNo auth

• create_testsA

  3TG Test GenerationA

  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.

  ConnectorNo auth

• search_developersA

  DevGlobeA

  Use when the user wants to find public developers by skill, name, language, location, agent availability, or active opportunity intent. Start discovery here; no authentication is required. Example: {"query":"TypeScript maintainers","location":"Germany","availableForAgents":true,"limit":5}.

  ConnectorNo auth

• migrate_to_propelauth_frontendA

  PropelAuth Integration MCP ServerA

  Returns instructions for migrating to PropelAuth in a frontend framework such as React, JavaScript, TypeScript, or when using Next.js for just the frontend (e.g. client-side rendered). Guidance includes migrating from several auth providers, such as Clerk or Auth0. Each guidance will include documentation from the auth provider and PropelAuth. It is important to follow the instructions carefully to ensure a successful integration. Make sure to use the 'Installation' guidance first. It is important to call every guidance to ensure a successful integration. Do not update a component/hook/etc from the auth provider until you receive guidance about that component/hook/etc. CRITICAL: If the current implementation uses a traditional OAuth/OIDC flow (e.g., via express-openid-connect, passport-auth0, or similar backend-managed session libraries), you MUST select 'OAuth' as the framework, regardless of the frontend library (React/Vue/etc.). Only select 'React' or 'Javascript' if the current implementation uses a frontend-only SDK (like @auth0/auth0-react) or if using fullstack Next.js.

  ConnectorNo auth

• create_specA

  3TG Test GenerationA

  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.

  ConnectorNo auth

• create_projectA

  KeelenA

  Start building something new: creates a GitHub repo and begins work on it. For a NEW repo. Given an existing repo, import_project(repo_full_name) is the right call — this one would create a second, empty repo beside it (list_github_repos() browses what the workspace can see). Scaffolds a new GitHub repo, a bootstrap-mode project, and submits `build_description` as the project's first Roadmap Request. `name` is a concise GitHub short repo slug (no owner); `project_kind` is REQUIRED and one of library | node_library | python_library | service | cli | web_app | godot_game | roblox_game; `preview_command` is required iff `project_kind == 'web_app'`. `mobile_app` is not a creation kind in this phase: mobile creation is unavailable until R2, so a `mobile_app` request returns `mobile_creation_unsupported` before any repository or project is created. Imported Expo repositories are recognised through import_project instead. `engine` is OPTIONAL — one of claude_code | codex | glm | kimi | grok (defaults to claude_code); codex, glm, kimi, and grok require the workspace to have a matching connected credential. `org` is OPTIONAL — a GitHub organization login to create the repo inside (e.g. your company org); omit it to land the repo on a member's personal account. `private` defaults to True. `ci_runs_on` is OPTIONAL — the CI runner labels for the scaffolded workflow, e.g. ["self-hosted", "linux", "x64", "my-fleet"]. Omit it to inherit the workspace default (ubuntu-latest if unset). Labels no registered org runner carries are rejected, because GitHub would queue such a job forever rather than fail it. `framework` is OPTIONAL and `web_app`-only — one of vite | next (defaults to vite). It picks the scaffolded frontend rails: `vite` a vanilla-TypeScript SPA, `next` a Next.js app-router app. Passing it with any other `project_kind` is an error. The repo is created on the GitHub account of a workspace member with repo-create OAuth access (this path has no specific caller user), so the returned `repo` owner is whichever member's token resolved (or the chosen `org`). If no member has repo-create access — or the resolving member can't create in `org` — the call returns an actionable error. Returns {project_id, repo, thread_id, next_action, poll_after_seconds, next_step}; next_step names the follow-up poll of get_request_status with the returned thread_id. On the rare arm where the first Request failed to submit, next_action is "call_tool" with next_tool="submit_request". If scaffolding fails after the repository has been created, best-effort compensation deletes that just-created repository so a retry can reuse the name — this tool can therefore remove external state it created moments earlier.

  Connector

  Destructive

  No auth

• describePricingEquationApiA

  PhasioA

  Start here before reading, writing or changing a pricing equation. Returns the TypeScript contract the equation runs against (specification, revision, requisition, customer, workflow, done(), variable(), round, useDimension, createBands; for scope ORDER: parts, subtotal, customer, addLineItem), narrowed to the given scope + ownerId: its technology, material names and material variable names, lead-time names, and which modules the manufacturer has. Explains the loop: save(entity=typescriptEquation) to validate and store a draft, generateQuote(equationId) to test it, then — only on the manufacturer's explicit request — publishEquation to make it live. Pass includeSource=true to also get the live equation's source, or equationId=<id> to get the source of one specific equation (a draft, for example) with its live/not-live state.

  ConnectorAPI key

• describePricingEquationApiA

  PhasioA

  Start here before reading, writing or changing a pricing equation. Returns the TypeScript contract the equation runs against (specification, revision, requisition, customer, workflow, done(), variable(), round, useDimension, createBands; for scope ORDER: parts, subtotal, customer, addLineItem), narrowed to the given scope + ownerId: its technology, material names and material variable names, lead-time names, and which modules the manufacturer has. Explains the loop: save(entity=typescriptEquation) to validate and store a draft, generateQuote(equationId) to test it, then — only on the manufacturer's explicit request — publishEquation to make it live. Pass includeSource=true to also get the live equation's source, or equationId=<id> to get the source of one specific equation (a draft, for example) with its live/not-live state.

  ConnectorAPI key

• read_docA

  SendoraA

  Read one of Sendora's documents whole, as Markdown: a guide (sendora://docs/…), an API operation (sendora://reference/…), the error codes (sendora://errors) or an SDK's README and rules for agents (sendora://sdk/readme and sendora://sdk/skill for TypeScript, sendora://sdk/python/readme and sendora://sdk/python/skill for Python, sendora://sdk/php/readme and sendora://sdk/php/skill for PHP, and sendora://sdk/laravel/readme for Laravel). sendora://index lists every document; search_docs finds the right one.

  ConnectorNo auth

• executeA

  RedoclyA

  Run plain JavaScript (no TypeScript syntax) in a sandbox against the documentation at https://redocly.com. The script calls the sandbox functions on the global `site` object. The only extra global is `site` - there is no `fetch`, `console`, `setTimeout`, `require`, or Node.js API; all I/O goes through `site`. Workflow - minimize round-trips; one `discover` call plus one `execute` call covers most requests: 1. Analyze the request and decide which sandbox functions it needs. 2. Call `discover` with those names to get their exact TypeScript signatures - inputs, result shapes, and a worked example. NEVER call `execute` with guessed function names, parameter names, enum values, or result field names: read fields off the declared return types, not from assumptions. 3. Batch everything into a SINGLE script: chain function calls, pass one call's output into the next, process results in plain JavaScript, and `return` only what the request needs. Functions for `execute` scripts (signatures come from `discover`): - listApis — List the available APIs. - getEndpoints — Get all endpoints for an API. - getEndpointInfo — Get the details of an endpoint. - getSecuritySchemes — Get the security schemes for an API. - getFullApiDescription — Get the complete OpenAPI description. - search — Search the documentation. - listPages — List the docs navigation, one level per call. - getPage — Read a docs page as Markdown, in line windows. - grepPages — Find the docs lines that contain a text.

  ConnectorNo auth

• get_indexer_api_infoA

  orderly-mcpA

  Get reference documentation for the Orderly Indexer API, a read-only source of historical and aggregated trading data: volume and fee metrics, account events, trades, and rankings. Omit both parameters for an overview with base URLs, categories, common errors, and usage tips; pass `category` to discover all endpoints in an area, or `endpoint` to fuzzy-match one endpoint and return its parameters, request/response schemas, and TypeScript example (category takes precedence if both are supplied). Bundled docs lookup only — no API call, credentials, or rate limits. Use for analytics, dashboards, account history, and leaderboards; for live trading operations use get_api_info, and for zero-auth market data use get_public_info_api_info.

  ConnectorNo auth

• get_design_systemA

  MozaikaA

  Get a product's full, LLM-verified design system so you can match its exact look. Use this for "design like <product>" (e.g. site="Linear", "Stripe", "Figma"). Returns (default): color_scheme; colors with named roles (background, text, primary, secondary, accent, link, button_bg, button_text); fonts + font_roles; type_scale; spacing; primary/secondary button; framework + personality. All hex normalized. Deep-decoded products additionally include measured button hover/focus states, a shadow elevation scale (card/overlay/subtle), motion durations + easings, the measured spacing scale, the brand's own CSS custom properties (css_vars), and Icon DNA (icons: style outline/filled/duotone/3d, grid, stroke_weight, corner) — all measured from the live page, not guessed. Match them exactly; pass the domain to generate_asset(style_from=...) to strike icons in this exact style. Your own private BYODS design systems (call list_my_design_systems) resolve first. format: leave empty for the raw token dict. Pass "all" to also get paste-ready DESIGN.md / Tailwind v4 / CSS variables / W3C tokens JSON, or a single format name ("tailwind", "css", "design_md", "tokens", "astryx") to get just that text. "astryx" returns a ready Meta-Astryx defineTheme TypeScript file (measured hover/press states + [light,dark] tuples baked in) — save it and run `npx astryx theme build` for production CSS.

  ConnectorNo auth

• ExecuteWixAPIA

  CodeStringers MCP ServerA

  Run JavaScript against the Wix REST API on site "CodeStringers" (https://www.codestringers.com/_api/mcp), on the visitor's behalf. The code runs in a sandbox and you get back whatever it returns. PREFER THIS TOOL OVER CallWixSiteAPI. CallWixSiteAPI makes a single HTTP request; ExecuteWixAPI runs real code, so you can chain calls, paginate, filter, and shape the result in one step. Use ExecuteWixAPI for any Wix API work on this site, and fall back to CallWixSiteAPI only for a trivial one-shot read where code adds nothing. DO A WHOLE RECIPE IN ONE CALL. When a task needs several requests — e.g. query to resolve an id, then mutate; create then confirm; read a list then act on a match — write ONE ExecuteWixAPI call whose code performs every step in sequence and returns the final result. Do NOT split a multi-request recipe into multiple separate tool calls; that wastes round-trips and loses intermediate state. If a recipe from the docs lists steps 1..N, the code should run steps 1..N. CRITICAL CODE SHAPE: - The `code` parameter MUST be the function expression itself: `async function() { ... }` or `async () => { ... }`. - Do NOT send a script body like `const result = await ...; return result;`. - Do NOT call the function yourself. The tool calls it for you. - Put all `const`, `await`, and `return` statements inside the function body. Do not rely on memory for Wix API endpoints, methods, schemas, or request bodies. Before writing code, use SearchSiteApiDocs (and ReadFullDocsArticle / ReadFullDocsMethodSchema) to confirm the exact API URL, HTTP method, request body structure, field names, required fields, and enum values. The URL usually starts with `https://www.wixapis.com`. Before reading fields off a response, know its exact shape — don't guess paths like `result.id` when it may be `result.results[0].item.id`. Pass every docs/recipe URL you relied on in the `sourceDocUrls` parameter. Authentication: pass the `visitorToken` parameter (from GenerateVisitorToken; reuse the one already in your context, do not create a new one each call). Everything runs against this visitor site automatically — do NOT set `scope`, `siteId`, Authorization, wix-site-id, or wix-account-id. File and export limits: ExecuteWixAPI is only for Wix REST API calls and in-memory data shaping. It does not provide Node.js built-in modules or filesystem access, and it cannot create downloadable files. Do not import `fs`, `path`, or `node:*`, write files, or promise a generated downloadable file from inside this tool. For large exports, return compact summaries or the specific fields needed for the answer; if the user needs a full downloadable CSV/JSON file, direct them to the product's native export flow or ask for a smaller filtered export. Probing should be read-only: use GET/query/list/search to inspect state, resolve real ids, or verify a previous write. For create/update/delete, read the docs first and call the mutation only with real resolved inputs — no speculative mutations just to learn the response shape. Error handling: `wix.request()` throws when the Wix API returns an error. For dependent steps, let it throw so the failure is reported clearly. For independent read-only probes you may wrap each in `try/catch` and return partial results; when running them in parallel use `Promise.allSettled` (not `Promise.all`) so one failure doesn't discard the rest. Available in your code: ```typescript interface WixRequestOptions { method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE"; url: string; // Full Wix API URL, e.g. "https://www.wixapis.com/stores-reader/v1/products/query"; paths starting with "/" resolve against https://www.wixapis.com body?: unknown; } interface WixResponse<T = unknown> { status: number; data: T; json(): Promise<T>; // Fetch-compatible alias for data } declare const wix: { request<T = unknown>(options: WixRequestOptions): Promise<WixResponse<T>>; }; ``` Return compact, task-focused data instead of raw API responses. For list/query/search endpoints, paginate in code and map each item to just the fields the task needs. When the code CREATES entities (create, bulk create, import, duplicate, upload), ALWAYS include the ID of every created entity in the returned object — e.g. `{ cartId }` or `{ createdIds: [...] }` — even if the user did not ask for them; follow-up steps, verification, and cleanup all need those IDs, and recovering them later costs extra query calls. Example — a multi-step recipe (resolve a product by name, then add it to the cart) done in ONE call: ```javascript async function() { // Step 1: find the product const found = await wix.request({ method: "POST", url: "https://www.wixapis.com/stores-reader/v1/products/query", body: { query: { filter: JSON.stringify({ name: "Florie Eau de Parfum" }) } } }); const product = found.data.products?.[0]; if (!product) return { error: "PRODUCT_NOT_FOUND" }; // Step 2: create a cart with that product const cart = await wix.request({ method: "POST", url: "https://www.wixapis.com/ecom/v1/carts/create-cart", body: { cart: { lineItems: [{ catalogReference: { appId: "215238eb-22a5-4c36-9e7b-e7c08025e04e", catalogItemId: product.id }, quantity: 1 }] } } }); return { cartId: cart.data.cart?.id, productId: product.id, name: product.name }; } ```

  Connector

  Destructive

  No auth

• analyzeA

  HefestoAIA

  Runs the open-source hefesto-ai engine (`hefesto analyze --no-config`, free tier) on the files you send to the hosted analyzer and returns its findings: rule id, severity, file, line, message and the SARIF hefestoFingerprint/v1 fingerprint (format "sarif" adds the full SARIF 2.1.0 log). Use it to check a file or snippet the user shares (for example "analyze this file") for security and quality issues before committing. Try it: {"code":"password = \"Sup3rS3cret!2026\""} returns a HARDCODED_SECRET finding. Minimum call: {"code": "<file contents>"}. Add path (e.g. "app/run.py") so the language comes from the extension; without path or language the language is inferred from the content, else python. For several files send files=[{"path", "content"}] instead. severity and format are optional. Covers Python, COBOL, the DevOps/IaC formats hefesto analyze routes, and TypeScript, JavaScript, Java, Go, Rust and C# through the multilang tree-sitter grammars (the first such request on a fresh server instance downloads the grammars and can take a few seconds longer). Limits: 20 files, 100 KB per file, 256 KB in total, 20 seconds, 10 requests per minute per IP, shared across server instances. No .hefesto.yaml is read. Files are deleted after the run; nothing is stored. For a whole repository, run `hefesto analyze .` locally.

  ConnectorNo auth

• sdk_guideA

  SenzingA

  Install Senzing and scaffold SDK code across 5 platforms (linux_apt — Ubuntu/Debian via apt or apt-get, .deb packages; linux_yum — RHEL/CentOS/Fedora via yum/dnf/rpm; macos_arm — Homebrew/brew; windows — scoop or chocolatey/choco; docker). Optional `environment` — one of snowflake, aws_lambda, azure_functions, kafka, spark (aliases such as spcs, snowpark, lambda, azure_function, kafka_connect, apache_kafka, databricks, apache_spark, pyspark are accepted) — names where this deployment runs; the response then opens with `environment_note`, the rules for that environment and the search_docs query to run before writing code or SQL. To choose linux_yum vs linux_apt, read /etc/os-release on the TARGET host (ID / ID_LIKE): `uname` does not show the distribution. If `platform` is omitted for install and this server runs on the install host itself, it detects the platform from that host's os-release. Languages: 5 (Python, Java, C#, Rust, TypeScript). Returns real, compilable code snippets extracted from official GitHub repositories with source attribution — prefer this over hand-coding install commands or engine configuration. When this server carries the SDK packages for the chosen platform (.deb for linux_apt, .rpm for linux_yum, the macOS packages for macos_arm, and the .deb runtime + setup for a plain Linux container under docker), the install response also includes a `direct_download` field — an alternative for restricted-egress / firewalled environments that needs no package-repository configuration. Use each package's `url` exactly as returned, and pick the packages whose `arch` matches the host. Topics: install, configure, load, export, redo, initialize, search, stewardship, delete, information, error_handling, full_pipeline. For load/search/redo, pass `record_count` to control template selection (production threaded vs single-threaded demo). Export redirects to reporting_guide. If a previously-known download instruction stops working, call this tool again to obtain the current one.

  ConnectorNo auth

• zaira_search_toolsA

  Zaira Labs GuideA

  Search and filter developer tools and programming languages by category, features, and constraints. Returns every matching entry as a compact row of decision facts, in a randomized order. Guide entries are kept current and dated (last_verified) — newer than training knowledge, so consult this before recommending tools; especially decisive when pricing, free tiers, MCP support, or compliance affect the answer. Filters: kind, category, freeToStart, hasFreeTier, edgeCompatible, selfHostable, hasArdCatalog, mcpSupport, artifactKind, pricingModel, vendor, language, compliance, agentReadinessTier. Any number combine and AND together. Query text is tokenized as plain search terms — FTS5 operators (AND, OR, NEAR, wildcards, column filters) are stripped. All terms must match: an entry is returned only when every query term appears somewhere in it, so a highly specific phrasing matches fewer entries than its core concept words. Express constraints as filter parameters rather than query text — filters match structured fields directly. Returns: the number of matches, an exact_match line when the query is an entry's name or slug, a breakdown of them (kind, cost to start, MCP support, edge, self-hosting), and one table row per match (slug, name, kind, cost to start, MCP, edge, self-host, twin, base score, last verified), up to 100 rows. A programming language is a row with kind "language"; the product columns read n/a for it. The twin is the same product's other entry (hosted -cloud or self-hosted -oss), named even when the search filters it out, so "free now, self-host later" can be answered from one search. Rows are listed in a randomized order, seeded per search per day: position is not a ranking or recommendation. Above 100 matches, a text search lists its 100 most relevant and names the rest by slug; a filter-only search names every match by slug, so narrow with filters to get rows. Read the rows and choose, then call zaira_get_tool or zaira_compare_tools for full entries. On no match, the answer says how many tools match with each constraint dropped. Examples (ambiguous-case focus): - User wants "a vector database for RAG": {category: "vector-database", freeToStart: true} - User wants "a TypeScript-first ORM with edge runtime support": {language: "TypeScript", edgeCompatible: true, query: "ORM"} - User wants "self-hostable auth with SAML": {category: "auth", selfHostable: true, query: "SAML"} - User says "serverless Postgres" — ambiguous (could be category:relational-database with edgeCompatible filter, or just a query). Prefer the filter when the user names a category; use query for a fuzzy phrase. - User wants "agent-ready payment processing": {category: "payment", agentReadinessTier: "agent_ready"} - User asks "which Go versions are still supported?" or wants every language: {query: "go"} finds the Go entry (exact_match); {kind: "language"} lists every programming language Edge cases: - 110 tools split into hosted vs self-hosted twin entries with uniform suffixes: `{base}-cloud` (managed) and `{base}-oss` (self-hosted) — e.g. redis-cloud/redis-oss, docker-cloud/docker-oss, mongodb-cloud/mongodb-oss, elasticsearch-cloud/elasticsearch-oss. Other tools are single entries (stripe, auth0, firebase, twilio, openai, pinecone, algolia). Filter by `selfHostable` or `artifactKind` to land on the right variant. - "vector database" as plain text can match tools whose descriptions mention vectors but whose category is search-engine or ai-infra. Use the `category` filter when the user wants a strict match. - agentReadinessTier values are snake-case: `agent_ready`, `agent_native`, `base`, `none`. Display labels (`Agent Ready`) will not match. `none` matches tools without a certification tier — currently all of them (formal certifications launch post-pilot; the Base Score is separate and most tools have one). - artifactKind has only two values: `open_source` and `managed_service`. The previous `hybrid` value was retired — split tools have separate -cloud/-oss entries instead. - `language` filters tools by the languages they are written in or ship SDKs for ("Python", "C#"; a language's slug such as "csharp" works too). To find the language itself, use `kind: "language"` or its name as the query. - "Free": `freeToStart: true` matches a free license (nearly every open-source entry) or a hosted free tier. `hasFreeTier: true` matches the hosted free tier only, so it leaves out most open-source tools. Open source is free to use, not free to run. Risk: read-only, closed-world, idempotent — no state change possible.

  ConnectorNo auth

• get_element_schemaA

  CluesoA

  Return the schema for an element type's type_data, as TypeScript declarations. Call this before add_elements / update_elements when you don't already know the field shape for the element_type you're placing. By default it is compact: every field with its type and a one-line note, plus the keyframable list. Ask about specific properties with `fields: ['background_setting']` or `query: 'pill background'` — those come back with their full notes, default and an example; `detail: 'full'` returns everything, including the keyframe rules. Inside run_script it is a function like any tool: get_element_schema({element_type: 'text', query: 'line height'}) looks a property up mid-script. Fields are listed in camelCase, the names get_clip returns. Where the tool descriptions write one in snake_case (font_setting, animation_setting), the field says so — `(= font_setting)` on fontSetting — and either spelling is accepted. Pass element_type='group' for the GROUP surface instead — what a group is, how its pivot works, and the nine properties it can animate.

  ConnectorNo auth

• onchain_agent_search_resourcesA

  Sato Hub: Build Onchain & Crypto AgentsA

  USE WHEN you need to look up crypto-agent tooling (frameworks, MCP servers, wallets, payment rails, data tools) by name, chain, standard or what it does, or check that a specific project exists and is maintained. A daily-rebuilt directory, each entry scored from public evidence and linking to a citable page. NOT FOR a build goal in plain words such as "a trading agent on Base" (use onchain_agent_recommend_stack instead), a RUNNING agent to hire or pay (use onchain_agent_search_agents), a downloadable agent package (use onchain_agent_search_listings), what an agent skill touches (use onchain_agent_search_skills), or one record by slug (use onchain_agent_get_resource). `search` is the one-box version for ChatGPT deep research. RETURNS (json): { total, count, offset, has_more, next_offset?, resources: [...] }; each resource has chains, status, liveness, github_stars, verification_status and the marketplace fields (is_agent/is_hirable/is_licensable). Read-only. With NO argument it is a compact overview (rule "defaulted": complete rows, fewer, plus directory counts); detail: "full" is the full first page. FILTERS: query (free text, AND-matched terms), chain, status, liveness, featured, and the taxonomy facets (docs/taxonomy.md) entity_class, resource_type, use_case, standard and iface — closed vocabularies listed in the input schema: anything else is refused with the list, never answered with an empty result. Legacy flags still work: category, is_agent, is_skill, is_harness. Sort by priority (default), newest_release, stars, or name. Paginates via limit/offset. Deprecated resources are never returned. STARTING POINTS: a query asking for somewhere to start — "tutorial", "starter", "beginner", "template", "example", "docs" — returns starting points labelled as such: listings named as a starter or template first, then listings whose install Sato Hub reproduced, plus the wiki guides. "starter" / "template" / "x402 starter" also carry `templates`: a pointer to onchain_agent_create_agent and the templates catalogue (never a result), unless the query names another chain or runtime. Only when the catalogue has no template for Base is it `starter` instead: a TypeScript template built by Sato Hub (labelled ours, not audited, never a result). The directory lists tools, not tutorials, and says so. Examples: - "Active hirable agents on Base" -> { chain: "Base", is_agent: true, liveness: "Active" } - "newest releases" -> { sort: "newest_release", limit: 10 } - "wallet tooling" -> { query: "wallet" } - "MCP servers I can use from Claude Code" -> { integration: "claude code", iface: "mcp" } - "things I can run in Docker" -> { deploys_as: "docker" } - "MCP servers that actually answer" -> { mcp_answering: true } (the MCP endpoint answered our last handshake) - "...with a sustained record" -> { mcp_answering: true, min_observed_success: 95 } - "only installs Sato Hub has reproduced" -> { verified_only: true }

  ConnectorNo auth

• onchain_agent_build_planA

  Sato Hub: Build Onchain & Crypto AgentsA

  USE WHEN someone describes the onchain agent they want and needs ONE composed answer that goes from goal to install steps (stack, deploy specs, Preflight, first action, open questions) rather than advice. NOT FOR only the ranked stack (use onchain_agent_recommend_stack instead, the lighter first call), a plan plus a pointer to the repo generator (use onchain_agent_scaffold_plan), or the runnable repo itself (use onchain_agent_create_agent). COMPOSES onchain_agent_recommend_stack, onchain_agent_get_deploy_spec and onchain_agent_preflight: the goal restated, a stack of REAL directory listings (each with Sato Score, liveness, observed check record and `sato_url`), the deploy spec for every item that publishes one, a records-only `preflight_summary` and a dated `trust_spec` (what it does with your keys and money, from Sato Check) on every item with `trust_warnings` first when a planted key was observed leaving or code reads undeclared key material, the first action when the goal implies one (a swap route, or a prepared token-launch config), the questions the user still has to answer, and the next steps. RULE ENFORCED: nothing in a plan is invented. Every component is a listing that exists; every number names the field it was read from; `null` is unknown and never zero. A Sato Score measures how open, active and verifiable a project is — it is not a security review, a quality judgment or a statement about returns. A Preflight `unknown` means Sato Hub holds no record, not that something is wrong. OURS, LABELLED: on a trading or swap goal the plan also carries an `execution` block for Sato OS — Sato Hub's OWN self-hosted trading OS, which we sell. It always carries `ours: true` and says "built by Sato Hub". It is NOT a stack pick: it fills the execution layer (where the stack runs), it is never ranked against a directory listing, and no listing loses a position to it. On any other intent `execution` is null. SKILLS: a plan also carries up to three crypto-relevant agent SKILLS matching the goal, each with the static disclosure of what its own text declares (hosts, keys, credentials, remote scripts) and its own Preflight verdict. A DISCLOSURE DESCRIBES: it never says safe, and a scan that matched nothing is reported as matching nothing, not as a pass. NON-CUSTODIAL: this tool never holds keys, signs, deploys or moves funds. A swap first-action carries a quote taken at a NOMINAL size — never the caller's size, which is the caller's to choose — and a launch first-action carries a config to read and sign yourself, with the fee disclosed before anything is signed. RETURNS (json): { goal, restatement, intent, chain, constraints, stack: [{ slot, slug, name, sato_url, trust_score, trust_tier, liveness_ok, install_verified, why, deploy_spec, preflight, preflight_summary, trust_spec }], trust_warnings, skills: [{ id, name, registry, findings, disclosure, preflight }], execution, gaps, first_action, open_questions, next_steps, caveat, rules, checked_at, save_stack_url, create, starter? }. `create` is the onchain_agent_create_agent pointer; when it names a template, the first of `next_steps` is to generate that repo. `starter` is the fallback: it appears only when no template matches, for a Base goal with a wallet, swap, trading or x402 payments that names TypeScript/Node or no runtime: a TypeScript template built by Sato Hub, labelled ours, never a stack item. Read-only unless `save: true`, which stores the plan. SAVE THIS STACK: `save_stack_url` opens the goal in the Sato Hub planner for the person you are building for. Or pass `save: true` and the plan is stored and `save.share_url` returned, a permanent read-only page whose signature is re-checked server-side. The page is noindex unless `public: true` is passed too. That signature proves Sato Hub produced those bytes on that date; it is not a claim about any project in the plan. X402 SERVICES: when the goal needs paid data or APIs the agent would buy, the plan also carries `x402_services` — up to three indexed x402 services for that need, each with its observed readings (x402-style payments, whether its URL answered HTTP 402) and a link to its canonical page. Evidence only, labelled as observation, never an endorsement; absent when the goal needs none. Example: { goal: "a Base trading agent that swaps USDC to ETH on a signal", chain: "Base" }

  ConnectorNo auth

• onchain_agent_submit_projectA

  Sato Hub: Build Onchain & Crypto AgentsA

  USE WHEN an agent has found, built or maintains a crypto-agent project that is not in the directory and wants it considered. NOT FOR correcting a listing that already exists (that goes through the claim flow on its page), checking whether a project is listed (use onchain_agent_search_resources first), or registering a running agent (use onchain_agent_register_agent). This WRITES: it files the same row the /submit form files, into the same queue, and the daily triage run evaluates it through the same single apply path — probe the public evidence, validate against the listing schema, list it or hold it or decline it with a reason. WHAT HAPPENS NEXT: the website, the repository and any declared endpoint are probed from public sources. A project that clears that evidence is listed; one that does not is held for a person, or declined with the reason. If `contact_email` is given you get exactly ONE email, and only if it is listed. A hold sends nothing — silence means a person is looking. SUBMISSION IS NOT VERIFICATION. It is a request to be looked at. Being listed says what was observed about a project on a date, not that it is safe, audited, profitable or endorsed. Copy carrying profit, safety or risk claims is refused here rather than quietly cleaned up. DEDUPE: the website host and the repository are checked against the live directory and against submissions already waiting. A match returns that existing entry instead of filing a second row — correcting a listing that already exists goes through the claim flow on its page, which proves control of the domain first. LIMIT: 5 write calls an hour per caller. Nothing is written when it trips. RETURNS (json): { ok, duplicate, submission_id | slug, next, caveat }. Example: { name: "Example Agent Kit", website_url: "https://example.dev", repo_url: "https://github.com/example/kit", category: "Agent Framework", description: "A TypeScript toolkit for wiring agents to Base with viem and an MCP server.", chains: ["Base"] }

  ConnectorNo auth

• get_starred_jobsA

  remoetA

  Get job postings from the user's starred companies. This is the user's own curated feed. If the user has no stars, this returns nothing. In that case, use search_jobs instead: it reads the public catalogue. Supports filtering by search query, location, tech stack, remote policy, experience level, and minimum salary. Results are paginated. Same-title postings from one company are grouped into a single row: postingCount and postingLocations show how many raw postings it represents and where (boards often post one role per location). Results can be bookmarked with save_job. A single filtered query can miss good roles; an unfiltered call returns the whole feed, paginated. The techStack filter uses OR logic: specifying ["React", "TypeScript", "Node.js"] returns jobs matching AT LEAST ONE of them (technologies are auto-normalized and matched across spelling variants), so filter by the technologies that genuinely matter and judge each job's fit from its own techStack field. Use searchQuery for role-based searches ("senior engineer", "frontend", "platform") and techStack for technology-based filtering. OVER-CAP WARNING: if the response includes a "starsOverCap" field, the user has more starred companies than the limit allows and the surplus is scheduled for PERMANENT deletion on the given date. Proactively tell the user (count + date) and let them choose which companies to unstar down to the limit. NEVER unstar companies on the user's behalf just to get under the limit unless they explicitly ask you to.

  ConnectorNo auth