@jini-ai/agent-plugins 0.6.17 → 0.6.19

package/jev/skills/jev/references/javascript-sdk.md

@@ -0,0 +1,146 @@
+# JavaScript SDK reference
+
+Sources: `docs.typesafe.ai/sdk/javascript.md` (quickstart), `docs.typesafe.ai/sdk/javascript/api.md`
+(API index) and these reference sub-pages under `docs.typesafe.ai/sdk/javascript/api/`:
+`classes/TypeSafeClient`, `interfaces/TypeSafeClientConfig`, `interfaces/RequestOptions`,
+`interfaces/RetryPolicy`, `interfaces/SystemOneRequest`, `variables/ENV`, `functions/choice`,
+`functions/score`, `functions/noul`, `type-aliases/ScoreCriteria`, the error classes, and
+`sdk/javascript/changelog`. All checked on 2026-09-21 against SDK `v0.6.0`. Append `.md` to any of
+those paths to read the raw page. If the installed package's version differs, trust its `.d.ts`
+files over this page.
+
+## Install
+
+Requires Node.js 20+. The package ships ESM, CommonJS, and TypeScript declarations.
+
+```sh
+npm install @typesafe-ai/sdk
+```
+
+## Client
+
+```ts
+import { choice, score, noul, TypeSafeClient } from "@typesafe-ai/sdk";
+
+const client = new TypeSafeClient();            // key from TYPESAFE_API_KEY
+const pinned = new TypeSafeClient({ apiKey });  // explicit key wins over the env var
+```
+
+`new TypeSafeClient(config?)` throws if the API key is missing, the config is invalid, or the runtime
+is unsupported. Explicit options win over environment variables, which win over SDK defaults. Empty
+or whitespace-only env values are ignored.
+
+`TypeSafeClientConfig` (all optional):
+
+| Option | Env fallback | Default |
+|---|---|---|
+| `apiKey` | `TYPESAFE_API_KEY` | none. Required from one source or the other. |
+| `baseURL` | `TYPESAFE_BASE_URL` | `https://api.typesafe.ai` |
+| `defaultModel` | `TYPESAFE_DEFAULT_MODEL` | `jev-latest` |
+| `logLevel` | `TYPESAFE_LOG_LEVEL` | `warn`. `info` logs request summaries. `debug` adds headers and bodies. Credential headers are redacted, bodies are not. |
+| `timeout` | none | `10000` ms per attempt. There is no total retry budget. |
+| `retry` | none | `Partial<RetryPolicy>`, see below |
+| `defaultHeaders` | none | extra headers on every request |
+| `fetch` | none | global `fetch` |
+| `logger` | none | a prefixed `console` |
+| `dangerouslyAllowBrowser` | none | `false` |
+
+**Don't set `dangerouslyAllowBrowser` in code that ships to a browser.** The docs say it exposes the API key to page
+users. Call Jev from server-side code, never from an admin or site bundle that ships to a browser.
+
+## Calling `systemOne`
+
+```ts
+const response = await client.systemOne(
+  {
+    state: { document: "I was charged twice. Please fix this ASAP." },
+    questions: {
+      category: choice("What is this ticket about?", { billing: null, technical: null, other: null }),
+      frustration: score("How frustrated the customer appears", [
+        "Calm, just stating facts",
+        "Frustrated but civil",
+        "Very angry, strong language",
+      ]),
+      billing: noul("Is this about billing?"),
+    },
+    // model: "jev-1.13.0",  // optional; omitted uses the client's defaultModel
+  },
+  { timeout: 5000 }, // optional RequestOptions
+);
+
+response.answers.category.choice;     // "billing" | "technical" | "other"
+response.answers.frustration.score;   // number, 0..2
+response.answers.billing.noul;        // number, 0..1
+response.model;                       // resolved versioned id, e.g. "jev-1.13.0"
+response.usage;                       // input and output token counts
+```
+
+- `systemOne(request, options?)` returns an `APIPromise<SystemOneResult<Q>>`. `request` is
+  `{ state, questions, model? }`, and `questions` must be non-empty.
+- Answer types are inferred from the helper that built each question. For example, `.choice` is
+  narrowed to the criteria's keys.
+- Question helpers:
+  - `choice(instructions, criteria)`: `criteria` maps each label to a description, or to `null` for
+    an undescribed label.
+  - `score(instructions, criteria)`: `criteria` is an ordered array of at least two level
+    descriptions, indexed from 0. Since `v0.6.0` it is an array. Earlier versions took an object
+    keyed by integers, so check the installed version if you see that shape.
+  - `noul(instructions?, criteria?)`: `criteria` is optional `{ true?, false? }`.
+- `instructions` and every description accept `EntryType`: text, a JSON object or array, or `null`.
+  This is the same structured shape the HTTP API documents (see `primitives-reference.md`).
+- `systemOne()` also throws if the questions are empty or a Score has fewer than two levels.
+
+`RequestOptions` (per call): `timeout`, `retry` (a `Partial<RetryPolicy>`), `headers` (merged over
+`defaultHeaders`), and `signal` (an `AbortSignal` that cancels the request and any pending retries).
+
+## Retries
+
+Retries are on by default, so don't wrap `systemOne` in your own retry loop. `RetryPolicy` defaults:
+
+| Field | Default |
+|---|---|
+| `maxRetries` | `2` (after the first attempt; `0` disables) |
+| `httpStatuses` | `408`, `429`, and `500`–`599` (this covers `529 Overloaded`) |
+| `apiConnectionError` / `apiTimeoutError` | `true` / `true` |
+| `backoffInitialMs` / `backoffMaxMs` | `500` / `5000` (doubles each retry) |
+| `backoffJitter` | `0.25` |
+| `respectRetryAfter` / `maxRetryAfterMs` | `true` / `60000` |
+
+## Errors
+
+Every SDK error extends `TypeSafeError`:
+
+- `APIError`: a non-2xx response after retries. It has `status`, `body`, `headers`, and `requestId`
+  (from `x-typesafe-request-id`). Subclasses by status:
+  - `BadRequestError` (400), `AuthenticationError` (401), `PermissionDeniedError` (403),
+    `NotFoundError` (404), `UnprocessableEntityError` (422), `RateLimitError` (429, also has
+    `retryAfterMs`), `InternalServerError` (5xx, which includes `529`).
+- `APIConnectionError`: DNS, TLS, or connection failure. Its subclass `APITimeoutError` fires when
+  the full response didn't arrive within `timeout`.
+- `APIUserAbortError`: the caller aborted through `signal`.
+
+```ts
+import { APIError, RateLimitError, UnprocessableEntityError } from "@typesafe-ai/sdk";
+
+try {
+  await client.systemOne({ state, questions });
+} catch (err) {
+  if (err instanceof UnprocessableEntityError) {
+    // Malformed question. err.body names the offending field. Fix it; don't retry.
+  } else if (err instanceof RateLimitError) {
+    // Retries are already exhausted here.
+  } else if (err instanceof APIError) {
+    // Log err.status and err.requestId.
+  }
+  throw err;
+}
+```
+
+## Not covered here
+
+`client.models.list()` returns the models available to the account as `ModelCard[]`. The API index
+also lists `APIPromise`/`WithResponse` (probably access to the raw HTTP response), `Logger`,
+`ModelCard`'s fields, and `VERSION`. Their pages weren't checked for this skill. Read the page or the
+installed `.d.ts` before relying on them.
+TypeSafe's own agent-skill FAQ names "the agent invents request or response fields" as a known
+failure mode.

package/jev/skills/jev/references/patterns.md

@@ -0,0 +1,123 @@
+# Patterns
+
+TypeSafe documents four named architectural patterns for using Jev in a larger system
+(`docs.typesafe.ai/patterns.md` and its four sub-pages, crawled 2026-09-21). Each assumes you
+already understand the primitives and confidence — read the main `SKILL.md` first if you haven't.
+
+## Speculative fan-out
+
+**What:** Put every question a system might need — including ones that only matter for some inputs
+— into a single request, and let code decide afterward what's relevant. Every question evaluates in
+parallel against the same `state`, so adding more of them usually has little effect on response time.
+
+**Worked example (support-ticket triage, one request, 5 questions):**
+
+- `category` (Choice: `bug_report` / `billing` / `feature_request` / `account`)
+- `bug_severity` (Score, 3 levels) — only meaningful if `category == bug_report`
+- `has_reproducible_steps` (Noul) — only meaningful if `category == bug_report`
+- `refund_requested` (Noul) — only meaningful if `category == billing`
+- `frustration` (Score, 3 levels) — relevant regardless of category
+
+All five are asked upfront; the ones that don't apply to a given ticket are simply ignored in code.
+Routing logic then reads whichever answers matter:
+
+```python
+if category.choice == "bug_report":
+    if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
+        escalate_to_engineering(ticket)  # high severity + reproducible
+elif category.choice == "billing":
+    if refund.noul > 0.7:
+        flag_likely_refund(ticket)
+# ...other categories...
+if frustration.score > 1.5:
+    flag_for_priority_response(ticket)  # regardless of category
+```
+
+The category answer decides which speculative answers get read. A bug-report ticket's `refund`
+answer is never consulted.
+
+**Why:** cost and speed. A separate request per question would resend the state each time and add
+round trips. In one request, the extra questions cost only their own tokens and barely change
+latency.
+
+## Confidence-gated routing
+
+**What:** Use `confidence` as a second decision axis alongside the answer itself — the answer says
+*what*, confidence says *whether to act on it*. Give different actions different confidence floors
+based on the cost of being wrong.
+
+**Worked example (voice banking commands, one Choice question, `intent`: `check_balance` /
+`approve_transfer` / `other`):**
+
+```python
+if intent.confidence < 0.6:
+    route_to_human_agent(request)          # floor: catches anything genuinely uncertain
+elif intent.choice == "check_balance":
+    # Low stakes — 0.6 is already sufficient.
+    show_balance(request)
+elif intent.choice == "approve_transfer":
+    if intent.confidence > 0.85:
+        approve_automatically(request)      # high stakes, but high confidence
+    else:
+        ask_user_to_confirm(request)        # high stakes, moderate confidence
+```
+
+**Why:** the same 0.6 floor filters out genuine model uncertainty regardless of intent; above that,
+each action gets its own threshold scaled to how expensive a wrong automatic action would be.
+Thresholds like these are domain-specific and not portable between question types — don't carry a
+threshold tuned on one Choice over to a different Choice or a Score without re-validating it.
+
+## Composite scoring
+
+**What:** Break one complex judgment into several independent Score dimensions, normalize each to
+0–1, and combine them with weights owned in code — rather than asking the model to produce one
+holistic number directly.
+
+**Worked example (resume screening, 4 independent 5-level Score questions in one request:
+`python_depth`, `team_leadership`, `system_design`, `generalist`), combined with different weights
+for two different roles from the same raw scores:**
+
+```python
+py, lead, arch, general = (response.answers[k].score / 4 for k in
+    ["python_depth", "team_leadership", "system_design", "generalist"])
+
+# Senior IC
+ic_score = (0.40 * py) + (0.10 * lead) + (0.40 * arch) + (0.10 * general)
+
+# Engineering Manager
+em_score = (0.15 * py) + (0.40 * lead) + (0.20 * arch) + (0.25 * general)
+```
+
+**Why:** ranking candidates this way gives visibility into exactly how the final number was built
+(each component is inspectable), and the same raw per-dimension scores can be re-weighted for a
+different downstream decision without another model call.
+
+## Intent routing
+
+**What:** Use Jev as a cheap, fast classifier in front of the real handlers, so only the requests
+that actually need an expensive model or a human get one.
+
+**Worked example (customer-service routing, 2 questions in one request — `intent`: Choice of
+`order_status` / `product_question` / `return_exchange` / `complaint`; `complexity`: Score, 3
+levels):**
+
+```python
+if intent.confidence < 0.5:
+    route_to_human(request)                            # floor, applies to every intent
+elif intent.choice == "order_status":
+    handle_deterministically(request)                    # no LLM at all
+elif intent.choice == "product_question":
+    route_to_llm("product_specialist", request)
+elif intent.choice == "return_exchange":
+    route_to_llm("returns_specialist", request)
+elif intent.choice == "complaint":
+    if complexity.score > 1 or complexity.confidence < 0.5:
+        route_to_human(request)
+    else:
+        route_to_llm("complaint_resolution", request)
+```
+
+**Why:** one intent needs no LLM at all, two route to different specialist LLMs, and one uses a
+*second* answer's confidence (`complexity`, a Score) to decide between an LLM and a human —
+reinforcing that a confidence threshold's meaning depends on which question and which stakes it's
+gating, not a single number reused everywhere.

package/jev/skills/jev/references/primitives-reference.md

@@ -0,0 +1,187 @@
+# Primitives, HTTP API, and Models reference
+
+Everything below is quoted or directly restated from `docs.typesafe.ai`'s `introduction.md`,
+`primitives.md`, `primitives/choice.md`, `primitives/score.md`, `primitives/noul.md`,
+`primitives/advanced.md`, `api.md`, and `models.md` (crawled 2026-09-21). Read the live docs if
+anything here looks out of date. TypeSafe ships new model versions on its own schedule.
+
+## Endpoint
+
+```http
+POST https://api.typesafe.ai/v1/systemone
+Authorization: Bearer <API_KEY>
+Content-Type: application/json
+```
+
+### Request body (top level, all required)
+
+| Field | Type | Notes |
+|---|---|---|
+| `state` | `string \| object \| array` | The content every question in this request is evaluated against. See "State format" below. |
+| `model` | `string` | e.g. `"jev-latest"`. See "Models, aliases, and versions." |
+| `questions` | `map<string, Question>` | Key is your own id — chosen by your code, **never sent to the model, never used in inference**. Write the complete question in `instructions` even if the id looks self-explanatory. |
+
+### Response body (top level, all required)
+
+| Field | Type | Notes |
+|---|---|---|
+| `model` | `string` | The concrete, versioned model that actually answered (e.g. `"jev-1.13.0"`), even if the request's `model` field was an alias. |
+| `answers` | `map<string, Answer>` | Keyed by the same ids you sent in `questions`. |
+| `usage` | `{ input_tokens: integer, output_tokens: integer }` | Token accounting for the whole request (all questions combined), used for billing. |
+
+### Errors
+
+| Status | Meaning | What to do |
+|---|---|---|
+| `401 Unauthorized` | Missing or invalid API key. | Check the `Authorization` header. |
+| `422 Unprocessable Entity` | Request body failed validation (missing required field, malformed question). The body details the offending field. | Fix the request; don't retry unchanged. |
+| `429 Too Many Requests` | Rate limit exceeded. | Retry with exponential backoff; honor `retry-after` if present. SDKs do this by default. |
+| `529 Overloaded` | TypeSafe is temporarily overloaded. | Retry after a short delay, with backoff. |
+
+## State format
+
+| Format | Useful for | Example |
+|---|---|---|
+| String | A message, article, or passage | `"My card was charged twice."` |
+| Object | Named fields, related records, or application state | `{"message": "...", "order_id": "A-104"}` |
+| Array | A sequence of messages or records | `["Hi", "My customer number is TS1337.", "My card was charged twice."]` |
+
+- Text only — string, JSON object, or array of text values. No image, audio, or video input.
+- English is the primary training language and currently the most accurate. Other languages,
+  including CJK scripts, are accepted but less accurate — test on real content before relying on
+  Jev for a non-English workload.
+- Prefer an object over a bare string for most requests, so parts of the state have descriptive
+  names a question can reference (see "Referencing nested state" below).
+- Use an object, not a giant string, when you can — it composes with per-question structure and lets
+  you filter irrelevant fields out in code (see jaggedness #5, large/irrelevant state hurts accuracy).
+
+## Question types — full field reference
+
+Every question shares this shape: an id (your key, not sent to the model), `type`, `instructions`
+(required on all three), and `criteria` (required for Choice and Score, optional for Noul).
+
+### Choice
+
+```json
+{ "type": "choice", "instructions": <EntryType>, "criteria": { "<option>": <EntryType|null>, ... } }
+```
+
+- `criteria` is a **required** map: option name → description. A description of `null` is valid when
+  the option name is self-explanatory (e.g. `{"calm": null, "frustrated": null, "angry": null}`).
+- **Maximum 255 options.** Each option adds only a few tokens, so give the full list of teams,
+  categories, or products rather than a shortlist. Add an `other` / `none of the above` option when
+  the list might not cover every input.
+- Answer: `{ "type": "choice", "choice": "<winning option>", "confidence": <0-1>, "probabilities": { "<option>": <0-1>, ... } }` — `probabilities` sums to 1 across every option; `choice` is the
+  highest-probability option; `confidence` is derived from how peaked/flat that distribution is.
+
+### Score
+
+```json
+{ "type": "score", "instructions": <EntryType>, "criteria": [<EntryType>, <EntryType>, ...] }
+```
+
+- `criteria` is a **required, ordered array** of level descriptions, low end of the scale first.
+  **At least 2 levels, at most 10.** Levels are 0-indexed by array position. The model is given only
+  the description text for each level and judges each independently — it does not see the level
+  number or its neighbors.
+- Use as many levels as you can describe distinctly; three is fine. Don't add levels you can't
+  describe distinctly — plain numeric levels (`["0", "1", "2"]`) measurably perform worse than
+  described ones for the same input (docs show a same-input comparison: descriptive levels →
+  score 0.0 at confidence 1.0; numeric-only levels → score 0.55 at confidence 0.33).
+- Answer: `{ "type": "score", "score": <number>, "confidence": <0-1>, "legend": { "<index>": "<description>", ... }, "probabilities": { "<index>": <0-1>, ... } }`.
+  **`score` formula:** the probability-weighted mean of level indices — `Σ(level_index ×
+  probability[level_index])`. It can therefore land between two levels (e.g. `1.43` between levels 1
+  and 2); do not treat `score` as an exact measurement interpolated within a level (jaggedness #2).
+- To split a complex judgment into several Score questions and recombine: normalize each score to
+  0–1 by dividing by `len(criteria) - 1` (the top level index), then combine with weights you own in
+  code (composite scoring — see `patterns.md`).
+- Structured level descriptions (an object per level, e.g. `{what: ..., examples: [...]}`) can
+  materially change `score`/`confidence` when the example matches the real input — the docs show the
+  same input scoring `1.43`/`0.35` with a plain-string level vs. `1.03`/`0.96` once a matching
+  example was added to that level's description.
+
+### Noul
+
+```json
+{ "type": "noul", "instructions": <EntryType>, "criteria": { "true": <EntryType>, "false": <EntryType> } }
+```
+
+- `criteria` is **optional** — an object clarifying what "yes" and "no" mean for ambiguous
+  boundaries. Omit it when the question is unambiguous.
+- Answer: `{ "type": "noul", "noul": <0-1> }` — the probability the answer is yes. **No `confidence`
+  field** (a two-outcome distribution is already fully described by one number).
+- `noul` is a probability of "yes," not a scale of the thing you asked about — it is not directly
+  comparable to a Score's `score` value for the same underlying question (docs show a 4-row example
+  where Noul values 0.03/0.14/0.81/0.92 line up with Score values 0.0/1.0/2.05/2.89 for parallel
+  questions on the same 4 inputs — not linearly related).
+- Threshold guidance: use 0.5 when acting on a false yes and missing a true yes cost about the same;
+  raise the threshold when a false yes is expensive, lower it when missing a true yes is expensive.
+  A "don't know" band (e.g. `0.2 < noul < 0.8`) can route ambiguous cases to human review while still
+  surfacing the raw probability.
+- Phrase the question so a "yes" answer is unambiguous — `criteria.true`/`criteria.false` exist
+  specifically for the cases where that's not obvious from the instructions alone.
+
+### Structured `instructions`/`criteria` (`EntryType`)
+
+`instructions`, Choice's per-option `criteria` values, Score's per-level `criteria` entries, and
+Noul's `criteria.true`/`criteria.false` all accept the same shape — `EntryType` = `string | object |
+array | null` — not just plain text.
+
+- Use structure when it adds clarity (a multi-part question) or when the question needs supporting
+  data that's already JSON (a schema, a taxonomy node, a database row) — pass that JSON directly, or
+  the relevant subfields, rather than string-templating it into prose.
+- Field names inside a structured value are **not part of the API and none are reserved** — you
+  choose them (docs use examples like `question`, `focus`, `what`, `not_for`, `examples`), and the
+  model sees the field names along with the values.
+- Reference a specific part of `state` from inside `instructions` with a backtick dot/index path,
+  e.g. `` `ticket.messages[0].text` ``.
+- **Walking a taxonomy:** for a deep classification tree, ask one Choice per level, with the current
+  node's children as `criteria` keys and their **subtrees** as the option values (not just a
+  description) — this lets the model see what's under each branch before committing. If a branch is
+  too large, trim its value to direct children plus a sample of leaves.
+
+## Batching questions in one request
+
+- All three types can be mixed freely in one `questions` map.
+- Every question in a request is evaluated **in parallel and in isolation** against the same
+  `state`. Adding questions barely changes response time and costs only the extra tokens for the
+  added question text.
+- Only split into two sequential requests when code genuinely cannot construct the second request
+  until it has read the first response (e.g. rank-then-verify over a large candidate set — see
+  `cookbooks.md`'s "Skill suggestion" and "Structure recovery" entries, and "Hierarchical
+  classification" for beam search over sequential per-level requests).
+
+## Models, aliases, and versions
+
+| Field | Value |
+|---|---|
+| Current model | `jev-1.13.0` (the only model family as of this writing) |
+| Price | $42 per billion input tokens ($0.042 / million). **Output tokens are free.** |
+| Rate limits | 250,000 tokens/second, 1,200 requests/minute — **stated as adjusting dynamically and subject to change without notice** as TypeSafe scales capacity. Higher limits available on custom/enterprise plans (`sales@typesafe.ai`). |
+| Context length | 64k tokens per request (`state` + every question combined); 32k tokens for `state` plus the single longest question. |
+| Input | Text only (string / JSON object / array of text). No image, audio, or video. |
+
+**Aliases:**
+
+| Alias | Points to (currently) | Meaning |
+|---|---|---|
+| `jev-latest` | `jev-1.13.0` | Most recent **stable, official** release. SDK default; what these docs' examples use. |
+| `jev-preview` | `jev-1.13.0` | Most recent release, official or not — moves ahead of `jev-latest` when a preview build exists. Currently identical to `jev-latest`; no preview build is live right now. |
+
+An alias moves when TypeSafe ships a new release, so answers behind it can change without any change
+on your side. The response's `model` field always reports the concrete versioned id that answered.
+**If you've tuned confidence thresholds against a specific version, pin that version's id instead of
+an alias.**
+
+`GET /v1/models` lists available `model` names (the aliases) with a description and release date —
+`{"models": [{"name": string, "description": string, "release_date": string}, ...]}`. Versioned ids
+like `jev-1.13.0` are always accepted by the `model` field whether or not they're listed there.
+
+**Customization:** Jev is not fine-tuned or LoRA-adapted per customer — the same weights serve every
+account. It's trained with RLCD (reinforcement learning for calibrated decisions — see TypeSafe's
+"AI primer" for how this differs from optimizing for generated text). Customization happens entirely
+through how you shape the request: `state` content, `instructions`/`criteria` wording, and how you
+decompose and recombine questions in code — not through any per-account training.
+
+**Data handling:** Jev is not trained on customer requests or responses. Zero data retention (ZDR)
+is available for enterprise customers — see TypeSafe's `/legal` for the DPA and privacy policy.

package/langfuse/plugin.json

@@ -0,0 +1,22 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "langfuse",
+  "version": "0.1.0",
+  "description": "Connects the site to Langfuse through the ai-trace-langfuse provider in @jini-ai/provider-plugins. Installation alone does not enable or configure the provider.",
+  "author": "Jini",
+  "license": "Apache-2.0",
+  "extensions": {
+    "tovu": {
+      "id": "jini/langfuse",
+      "displayName": "Langfuse",
+      "providerPlugin": "ai-trace-langfuse",
+      "provides": [
+        "ai-tracing"
+      ]
+    }
+  },
+  "keywords": [
+    "langfuse",
+    "ai-trace-langfuse"
+  ]
+}

package/meilisearch/mcp.json

@@ -0,0 +1,4 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
+  "mcpServers": {}
+}

package/meilisearch/plugin.json

@@ -0,0 +1,54 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "meilisearch",
+  "version": "0.1.0",
+  "description": "Runs the site's visitor search on a Meilisearch server (self-hosted or Meilisearch Cloud) instead of the host's built-in search. Ships the search provider itself (a host loads it only when the host shipped it) and the know-how to connect it. Meilisearch receives PUBLIC content only: published, publicly visible titles, text and URLs. Members-only or otherwise restricted content is never sent to it and stays in the host's built-in search.",
+  "author": "Tovu",
+  "license": "Apache-2.0",
+  "extensions": {
+    "tovu": {
+      "maturity": "soon",
+      "summary": "Powers your site's search with Meilisearch. Only public content is sent to it.",
+      "id": "tovu/meilisearch",
+      "provides": [
+        "site-search"
+      ],
+      "credentialCards": [
+        {
+          "target": "meilisearch",
+          "title": "Connect Meilisearch",
+          "label": "Tovu Search — Meilisearch",
+          "ownedApiLabel": "Tovu Search — Meilisearch",
+          "category": "general",
+          "intro": "Connect your Meilisearch server to index and search this site’s public content only.",
+          "usedFor": [
+            "Keeps a search index of your site's public content",
+            "Finds matching public content for your site's visitors"
+          ],
+          "keyHint": "Scope the key to the site index: indexes.create, indexes.delete, documents.add, documents.get, search, settings.update and tasks.get. Use a scoped key rather than the master key.",
+          "saveKind": "api",
+          "fields": [
+            {
+              "name": "baseUrl",
+              "label": "Meilisearch server URL",
+              "hint": "The HTTPS URL of your own Cloud or self-hosted Meilisearch server.",
+              "required": true
+            }
+          ]
+        }
+      ],
+      "toolKeywords": {
+        "search_status": "meilisearch",
+        "search_set_provider": "meilisearch"
+      }
+    }
+  },
+  "keywords": [
+    "meilisearch",
+    "search",
+    "site-search",
+    "full-text-search",
+    "typo-tolerance",
+    "search-engine"
+  ]
+}