@zackbart/connecta 0.31.0 → 0.32.0

package/dist/operator-ui/model.d.ts

@@ -1,6 +1,6 @@
 import type { OperatorConnectorOverlay, OperatorTool, OperatorUiContract, OperatorViewer } from "./contract.js";
 import type { CatalogAccessObservation, CatalogDriftReport, ResourceTemplateRefusalCode } from "../types.js";
-/** Tool verdicts, independent of the selected pool's trust. */
+/** Tool verdicts, independent of whether the selected pool is read-only. */
 export type UiToolSafety = "runs_in_programs" | "needs_approval";
 export interface UiTool extends Pick<OperatorTool, "name" | "address" | "description"> {
     /** Absent only in payloads older than the field; the page then shows no badge. */

package/dist/operator-ui/view.js

@@ -551,6 +551,7 @@ const REASON_LABELS = {
     invalid_args: "arguments didn't match the schema",
     destructive_reroute: "needed host approval",
     destructive_tool_requires_approval: "needed host approval",
+    read_only_endpoint: "endpoint is read-only",
     approval_required: "needed approval",
     auth_required: "needed authorization",
     result_too_large: "result too large to return inline",

package/dist/program-writes.js

@@ -1,4 +1,4 @@
-// Budget and outcome accounting for writes dispatched by trusted programs.
+// Budget and outcome accounting for writes dispatched by programs on writable endpoints.
 // Await each dispatched write once; never conceal an unknown outcome.
 import { CONFIG_DEFAULTS } from "./config-defaults.js";
 import { Effect } from "effect";
@@ -41,7 +41,7 @@ export function writeStateOf(outcome) {
         : state;
 }
 /**
- * The trusted-pool writes one program sends. The play closes this when the
+ * The writes one program sends. The play closes this when the
  * program settles — a write that reaches the gate after is not sent — and
  * drains what is on the wire before the run's scope aborts it, so the write
  * finishes and its activity says how it did. The result never hides a write

package/dist/provider.d.ts

@@ -3,9 +3,8 @@ import type { Connector, ConnectorCallAdmissionPolicy, ConnectorUsageGuide, Tool
 /**
  * How a provider reaches its vendor: the vendor's hosted MCP server, an
  * `api()` connector over the vendor's HTTP API, one connector composing both
- * with an explicit operation ownership map, or `"dual"`: the configured
- * `auth.type` selects the implementation, OAuth reaching the hosted MCP server
- * and a key reaching Connecta's REST connector.
+ * with an explicit operation ownership map, or `"dual"`: configuration selects the implementation, usually by `auth.type`. Mixpanel
+ * uses explicit `via` because service accounts reach both implementations.
  */
 export type ProviderKind = "mcp" | "api" | "composed" | "dual";
 /** Options every provider accepts, validated before `create` runs. */

package/dist/providers/_shared/google/workspace.js

@@ -311,7 +311,7 @@ export function googleWorkspaceClient(options) {
      * write Google accepted, or one that left with no answer, may have landed:
      * telling the agent to retry it invites a duplicate, so it is reported as
      * an uncertain outcome that is not retried — the same verdict core reaches
-     * for a trusted-pool program write (`write_outcome_unknown`). A read is safe to
+     * for a program write (`write_outcome_unknown`). A read is safe to
      * repeat and keeps its retryable classification.
      */
     /**

package/dist/providers/breeze/skill.generated.js

@@ -1,9 +1,9 @@
 // Generated by scripts/generate-providers.mjs; do not edit.
 export const skill = {
-    "content": ".breezechms.com (Breeze ChMS, now Tithely Church Management): people, tags, events, attendance, forms, volunteers, and giving.\n\nChurch purpose: \n\n## Sensitive data: reduce in code\n\nPeople records carry home addresses, phones, birthdates, and family ties, and\ngiving records reveal who gives and how much — religious affiliation by proxy.\nRead them inside `execute_code` and return only the counts, totals, or the\nfew fields the task needs. Never echo whole profiles or donor lists.\n\n## Ids and profile fields\n\n- Ids are numeric strings. Read them from a list tool; never guess one.\n- Events have two ids: an instance id (`list_events` `id`) for one\n  occurrence, and a series `eventId`. Attendance, volunteers, and\n  check-in take the instance id.\n- Person `details` are keyed by profile `fieldId`, not by name. Call\n  `list_profile_fields` once and map ids to names in code. Multiple-choice\n  values and `list_people` filters use option ids from the same call;\n  join several with `-`.\n- `list_people` has no name search. List without details and match names\n  in code, then `get_person` the hits.\n- Projections rename Breeze's snake_case fields to camelCase and drop photo\n  paths and internal columns; `raw: true` returns Breeze's rows.\n\n## Pagination\n\n`list_people` pages by `cursor`: continue while `page.hasMore`. Breeze\nreports no total, so a full page sets `hasMore` and the next may be empty.\n`list_events` and `list_account_log` do not page: `truncated: true`\nmeans narrow the date range. Other lists return everything.\n\n## Giving\n\n`list_contributions` and `list_funds` call endpoints Breeze removed from\nits public reference in 2023 but still serves. They may change or vanish\nwithout notice; a failure there is not your argument's fault. Amounts are\ndecimal strings; `totalAmount` is an exact sum. Online gifts processed by\nTithe.ly arrive through its sync, batched per deposit, so the latest days\nmay be missing. Read the currency from `get_account_summary`.\n\n## Writes and the hatches\n\n- Every write, `add_person`, `assign_tag`, and `record_check_in`\n  included, follows the routing in the `usage` skill. Fetch it with\n  `skills({ name: \"usage\" })` for guest API and trust rules.\n  Those three only add, and `add_person` never deduplicates.\n- `update_person` field values: text, date (M/D/YYYY), or option id in\n  `response`; email, phone, address, and family_role values in `details`.\n- Every Breeze call is a GET, writes included, so the hatches split by\n  endpoint. `breeze_api_get` admits only reviewed read endpoints and their\n  documented parameters, such as `/tags/list_folders`,\n  `/events/list_event`, `/events/attendance/eligible`, `/giving/view`,\n  and `/pledges/list_campaigns`; it refuses anything else. Everything else\n  — event, family, volunteer, and form writes, giving writes, check-out,\n  undocumented parameters — is `breeze_api_mutate`. Paths are below\n  `/api`; `*_json` values may be passed as objects.\n- `list_account_log` actions include person_created, person_updated,\n  person_deleted, tag_assign, tag_unassign, event_created,\n  attendance_deleted, form_entry_updated, contribution_added,\n  contribution_updated, contribution_deleted, and batch_updated.\n\n## Rate limits\n\nBreeze publishes no limit and sends no rate headers; a third party reports\nabout 20 requests per minute. Keep loops sequential and prefer one list call\nover many single reads.\n",
+    "content": ".breezechms.com (Breeze ChMS, now Tithely Church Management): people, tags, events, attendance, forms, volunteers, and giving.\n\nChurch purpose: \n\n## Sensitive data: reduce in code\n\nPeople records carry home addresses, phones, birthdates, and family ties, and\ngiving records reveal who gives and how much — religious affiliation by proxy.\nRead them inside `execute_code` and return only the counts, totals, or the\nfew fields the task needs. Never echo whole profiles or donor lists.\n\n## Ids and profile fields\n\n- Ids are numeric strings. Read them from a list tool; never guess one.\n- Events have two ids: an instance id (`list_events` `id`) for one\n  occurrence, and a series `eventId`. Attendance, volunteers, and\n  check-in take the instance id.\n- Person `details` are keyed by profile `fieldId`, not by name. Call\n  `list_profile_fields` once and map ids to names in code. Multiple-choice\n  values and `list_people` filters use option ids from the same call;\n  join several with `-`.\n- `list_people` has no name search. List without details and match names\n  in code, then `get_person` the hits.\n- Projections rename Breeze's snake_case fields to camelCase and drop photo\n  paths and internal columns; `raw: true` returns Breeze's rows.\n\n## Pagination\n\n`list_people` pages by `cursor`: continue while `page.hasMore`. Breeze\nreports no total, so a full page sets `hasMore` and the next may be empty.\n`list_events` and `list_account_log` do not page: `truncated: true`\nmeans narrow the date range. Other lists return everything.\n\n## Giving\n\n`list_contributions` and `list_funds` call endpoints Breeze removed from\nits public reference in 2023 but still serves. They may change or vanish\nwithout notice; a failure there is not your argument's fault. Amounts are\ndecimal strings; `totalAmount` is an exact sum. Online gifts processed by\nTithe.ly arrive through its sync, batched per deposit, so the latest days\nmay be missing. Read the currency from `get_account_summary`.\n\n## Writes and the hatches\n\n- Every write, `add_person`, `assign_tag`, and `record_check_in`\n  included, follows the routing in the `usage` skill. Fetch it with\n  `skills({ name: \"usage\" })` for guest API and write rules.\n  Those three only add, and `add_person` never deduplicates.\n- `update_person` field values: text, date (M/D/YYYY), or option id in\n  `response`; email, phone, address, and family_role values in `details`.\n- Every Breeze call is a GET, writes included, so the hatches split by\n  endpoint. `breeze_api_get` admits only reviewed read endpoints and their\n  documented parameters, such as `/tags/list_folders`,\n  `/events/list_event`, `/events/attendance/eligible`, `/giving/view`,\n  and `/pledges/list_campaigns`; it refuses anything else. Everything else\n  — event, family, volunteer, and form writes, giving writes, check-out,\n  undocumented parameters — is `breeze_api_mutate`. Paths are below\n  `/api`; `*_json` values may be passed as objects.\n- `list_account_log` actions include person_created, person_updated,\n  person_deleted, tag_assign, tag_unassign, event_created,\n  attendance_deleted, form_entry_updated, contribution_added,\n  contribution_updated, contribution_deleted, and batch_updated.\n\n## Rate limits\n\nBreeze publishes no limit and sends no rate headers; a third party reports\nabout 20 requests per minute. Keep loops sequential and prefer one list call\nover many single reads.\n",
     "instructionsHeading": "Church instructions",
     "fragments": {
         "guide_0": ".breezechms.com (Breeze ChMS, now Tithely Church Management): people, tags, events, attendance, forms, volunteers, and giving.\n\nChurch purpose: ",
-        "guide_1": "\n\n## Sensitive data: reduce in code\n\nPeople records carry home addresses, phones, birthdates, and family ties, and\ngiving records reveal who gives and how much — religious affiliation by proxy.\nRead them inside `execute_code` and return only the counts, totals, or the\nfew fields the task needs. Never echo whole profiles or donor lists.\n\n## Ids and profile fields\n\n- Ids are numeric strings. Read them from a list tool; never guess one.\n- Events have two ids: an instance id (`list_events` `id`) for one\n  occurrence, and a series `eventId`. Attendance, volunteers, and\n  check-in take the instance id.\n- Person `details` are keyed by profile `fieldId`, not by name. Call\n  `list_profile_fields` once and map ids to names in code. Multiple-choice\n  values and `list_people` filters use option ids from the same call;\n  join several with `-`.\n- `list_people` has no name search. List without details and match names\n  in code, then `get_person` the hits.\n- Projections rename Breeze's snake_case fields to camelCase and drop photo\n  paths and internal columns; `raw: true` returns Breeze's rows.\n\n## Pagination\n\n`list_people` pages by `cursor`: continue while `page.hasMore`. Breeze\nreports no total, so a full page sets `hasMore` and the next may be empty.\n`list_events` and `list_account_log` do not page: `truncated: true`\nmeans narrow the date range. Other lists return everything.\n\n## Giving\n\n`list_contributions` and `list_funds` call endpoints Breeze removed from\nits public reference in 2023 but still serves. They may change or vanish\nwithout notice; a failure there is not your argument's fault. Amounts are\ndecimal strings; `totalAmount` is an exact sum. Online gifts processed by\nTithe.ly arrive through its sync, batched per deposit, so the latest days\nmay be missing. Read the currency from `get_account_summary`.\n\n## Writes and the hatches\n\n- Every write, `add_person`, `assign_tag`, and `record_check_in`\n  included, follows the routing in the `usage` skill. Fetch it with\n  `skills({ name: \"usage\" })` for guest API and trust rules.\n  Those three only add, and `add_person` never deduplicates.\n- `update_person` field values: text, date (M/D/YYYY), or option id in\n  `response`; email, phone, address, and family_role values in `details`.\n- Every Breeze call is a GET, writes included, so the hatches split by\n  endpoint. `breeze_api_get` admits only reviewed read endpoints and their\n  documented parameters, such as `/tags/list_folders`,\n  `/events/list_event`, `/events/attendance/eligible`, `/giving/view`,\n  and `/pledges/list_campaigns`; it refuses anything else. Everything else\n  — event, family, volunteer, and form writes, giving writes, check-out,\n  undocumented parameters — is `breeze_api_mutate`. Paths are below\n  `/api`; `*_json` values may be passed as objects.\n- `list_account_log` actions include person_created, person_updated,\n  person_deleted, tag_assign, tag_unassign, event_created,\n  attendance_deleted, form_entry_updated, contribution_added,\n  contribution_updated, contribution_deleted, and batch_updated.\n\n## Rate limits\n\nBreeze publishes no limit and sends no rate headers; a third party reports\nabout 20 requests per minute. Keep loops sequential and prefer one list call\nover many single reads.\n"
+        "guide_1": "\n\n## Sensitive data: reduce in code\n\nPeople records carry home addresses, phones, birthdates, and family ties, and\ngiving records reveal who gives and how much — religious affiliation by proxy.\nRead them inside `execute_code` and return only the counts, totals, or the\nfew fields the task needs. Never echo whole profiles or donor lists.\n\n## Ids and profile fields\n\n- Ids are numeric strings. Read them from a list tool; never guess one.\n- Events have two ids: an instance id (`list_events` `id`) for one\n  occurrence, and a series `eventId`. Attendance, volunteers, and\n  check-in take the instance id.\n- Person `details` are keyed by profile `fieldId`, not by name. Call\n  `list_profile_fields` once and map ids to names in code. Multiple-choice\n  values and `list_people` filters use option ids from the same call;\n  join several with `-`.\n- `list_people` has no name search. List without details and match names\n  in code, then `get_person` the hits.\n- Projections rename Breeze's snake_case fields to camelCase and drop photo\n  paths and internal columns; `raw: true` returns Breeze's rows.\n\n## Pagination\n\n`list_people` pages by `cursor`: continue while `page.hasMore`. Breeze\nreports no total, so a full page sets `hasMore` and the next may be empty.\n`list_events` and `list_account_log` do not page: `truncated: true`\nmeans narrow the date range. Other lists return everything.\n\n## Giving\n\n`list_contributions` and `list_funds` call endpoints Breeze removed from\nits public reference in 2023 but still serves. They may change or vanish\nwithout notice; a failure there is not your argument's fault. Amounts are\ndecimal strings; `totalAmount` is an exact sum. Online gifts processed by\nTithe.ly arrive through its sync, batched per deposit, so the latest days\nmay be missing. Read the currency from `get_account_summary`.\n\n## Writes and the hatches\n\n- Every write, `add_person`, `assign_tag`, and `record_check_in`\n  included, follows the routing in the `usage` skill. Fetch it with\n  `skills({ name: \"usage\" })` for guest API and write rules.\n  Those three only add, and `add_person` never deduplicates.\n- `update_person` field values: text, date (M/D/YYYY), or option id in\n  `response`; email, phone, address, and family_role values in `details`.\n- Every Breeze call is a GET, writes included, so the hatches split by\n  endpoint. `breeze_api_get` admits only reviewed read endpoints and their\n  documented parameters, such as `/tags/list_folders`,\n  `/events/list_event`, `/events/attendance/eligible`, `/giving/view`,\n  and `/pledges/list_campaigns`; it refuses anything else. Everything else\n  — event, family, volunteer, and form writes, giving writes, check-out,\n  undocumented parameters — is `breeze_api_mutate`. Paths are below\n  `/api`; `*_json` values may be passed as objects.\n- `list_account_log` actions include person_created, person_updated,\n  person_deleted, tag_assign, tag_unassign, event_created,\n  attendance_deleted, form_entry_updated, contribution_added,\n  contribution_updated, contribution_deleted, and batch_updated.\n\n## Rate limits\n\nBreeze publishes no limit and sends no rate headers; a third party reports\nabout 20 requests per minute. Keep loops sequential and prefer one list call\nover many single reads.\n"
     }
 };

package/dist/providers/cloudflare/skill.generated.js

@@ -3,7 +3,7 @@ export const skill = {
     "content": "- Resolve account and zone ids before acting; never guess one. Ids are 32-character hex strings, and a zone is found by its domain name. Defaults and pins route a connector; Cloudflare's permissions still decide what the credential may do.\n- Read state before replacing, rolling back, or purging. For DNS, PATCH changes the fields you send and PUT replaces the whole record, so read the record first and send its type, name, and content with the change. Prefer a targeted cache purge (files, tags, hosts, or prefixes) over purging everything.\n- Cloudflare reports failures in `errors` with numeric codes and returns `success: false`; read the message instead of retrying the same call.\n- Honor rate-limit waits. Cloudflare documents 1,200 requests per five minutes per user, counted across the dashboard and every token; Connecta's per-runtime window approximates it, and a limited user is blocked for the rest of the window.\n- Treat every create, update, delete, purge, deploy, and upload as a write. For guest calls, classification, and routing, fetch `skills({ name: \"usage\" })`.\n",
     "instructionsHeading": "Account instructions",
     "fragments": {
-        "oauth": "\n\n- The catalog is Cloudflare's own `search` and `execute`. `search` runs code against Cloudflare's OpenAPI document; `execute` runs code that may call any Cloudflare API endpoint the OAuth grant allows.\n- Connecta classifies `execute` as a write, even for a program that only reads, because one program can mix GET, POST, PUT, PATCH, and DELETE and no schema proves otherwise. A read-only pool therefore gets only `search` here. Deployments that need API reads from a read-only pool configure an API-token connector, whose `cloudflare_api_read` and named reads are reads.\n- Use `search` to find the exact method, path, and fields before writing an execute program. Do not guess an endpoint from product naming.\n- Keep returned values small. Filter and project inside the Cloudflare program, then reduce again inside Connecta's `execute_code` when several calls must be joined.\n- This connection has none of the REST connector's tools: no `cloudflare_api_*` validation against a pinned index, no `graphql_query`, no `cloudflare_api_upload`, and no account or zone pin. OAuth permissions are the boundary.\n",
+        "oauth": "\n\n- The catalog is Cloudflare's own `search` and `execute`. `search` runs code against Cloudflare's OpenAPI document; `execute` runs code that may call any Cloudflare API endpoint the OAuth grant allows.\n- Connecta classifies `execute` as a write, even for a program that only reads, because one program can mix GET, POST, PUT, PATCH, and DELETE and no schema proves otherwise. A read-only endpoint therefore gets only `search` here. Deployments that need API reads from a read-only endpoint configure an API-token connector, whose `cloudflare_api_read` and named reads are reads.\n- Use `search` to find the exact method, path, and fields before writing an execute program. Do not guess an endpoint from product naming.\n- Keep returned values small. Filter and project inside the Cloudflare program, then reduce again inside Connecta's `execute_code` when several calls must be joined.\n- This connection has none of the REST connector's tools: no `cloudflare_api_*` validation against a pinned index, no `graphql_query`, no `cloudflare_api_upload`, and no account or zone pin. OAuth permissions are the boundary.\n",
         "oauth_tail": "- An `auth_required` failure means this connector's Cloudflare authorization is missing or expired: run `authorize_connector` for this connector id, then retry the same call unchanged.\n",
         "global_warning": "\n\nThis connector holds a Global API Key. It acts as its Cloudflare user with every permission that user has, in every account and zone the user belongs to, and nothing on Cloudflare's side narrows it. A mistaken write can reach production domains, billing, and members across all of them. Prefer reads, state the account and zone of every write, and stop when a request is ambiguous. Writes under `/user` and `/memberships` are refused. R2 accepts API tokens only, so R2 operations fail with this key.\n",
         "key": "\n\n- This is Connecta's REST connector to the Cloudflare v4 API, holding one operator-managed credential. `cloudflare_api_search` finds API operations in a pinned index (not records) and names the tool that calls each; `cloudflare_api_details` returns one operation's parameters and body with types, enums, and required names. Neither sends a request.\n- `cloudflare_api_read` calls GET operations plus reviewed read-only POSTs: analytics queries, Analytics Engine and SQL API queries, Log Explorer SQL, Vectorize queries, KV bulk get, telemetry queries, and validation checks. `cloudflare_api_write` calls every other POST, PUT, PATCH, and DELETE with `method` and `path` stated. D1 `…/query` and `…/raw`, Durable Object queries, Workers AI `…/ai/run`, AI Search and AutoRAG search (query rewriting runs billed models), monetization checks, and flag evaluation are writes: they can change data, cost money, or activate something.\n- Paths are concrete: substitute ids into the template search returned (`/zones/<zone id>/dns_records/<record id>`). Pass `query` and `body` as JSON named as details lists them; text operations (Analytics Engine SQL, Log Explorer SQL, Worker scripts) take a string body, and Vectorize inserts a list of objects sent as NDJSON. R2 calls accept `headers` with `cf-r2-jurisdiction` or `cf-r2-storage-class`. Encode a `/` inside an R2 object key or KV key name as `%2F`.\n- Every call is checked against the pinned index before it is sent. An unknown path returns the nearest operations; an unknown or missing parameter returns `validation.issues` with the accepted names. Nothing reached Cloudflare, so fix the call from that answer.\n- Results arrive as `{ status, data, page? }` with Cloudflare's envelope unwrapped: `data` is the `result`. On a list, pass `page.next` as the `page.param` query argument (`page` for numbered lists, `cursor` for KV, R2, and other cursor lists). Lists belong inside `execute_code`; pass `select` (dot paths such as `id` and `name`) to keep only the fields the question needs.\n- `list_zones` and `list_accounts` resolve names to ids; `verify_credential` separates a bad credential from a missing permission. `graphql_query` runs read-only GraphQL Analytics queries (mutations are refused before sending); filter every `zones` or `accounts` field by `zoneTag` or `accountTag`. A pinned connector sends one query per document, with every fragment it defines used.\n- Multipart, binary, and file bodies go through `cloudflare_api_upload`: Worker scripts and versions, KV values, R2 objects, Pages deployments, Images, Stream, DNS zone-file import, and Snippets. It takes `textBody`, `base64Body`, or multipart `parts`, never a local file.\n- Refused by design: every operation that mints, rotates, or hands back a credential (API tokens, Access service tokens, R2 temporary credentials, tunnel and Mesh node tokens, signing keys, registry credentials, direct-upload URLs, deploy hooks, preview and participant tokens), payment client secrets, URL Scanner captures (results, HAR, DOM, raw responses: they hold the scanned session's cookies and headers; use the scan search for verdicts), and GETs that act (an email unsubscribe, a PagerDuty connect). Stored and embedded secrets (Turnstile, TSIG, webhook and identity-provider secrets, Stream keys, Logpush destination credentials, probe and custom-provider headers, BGP keys, Zaraz variables, Hyperdrive database passwords, RealtimeKit storage credentials, transform-rule header values) and every environment or plain-text binding value (Pages, Containers, Workers, Builds; names and types stay) come back as `\"[redacted]\"` on every method. Notification, RealtimeKit, and data security webhook destinations keep only their scheme and host. Workers KV values are application data and come back as stored. Reviewed operations, and operations that take credentials, report Cloudflare's error codes without its error text. Worker script content is readable: it is code, and secret bindings are not part of it.\n- An `auth_required` failure means the credential is missing, revoked, or malformed: an operator must replace it in this connection in the operator UI, and `authorize_connector` returns that handoff. `provider_permission_denied` means the credential works but lacks this permission or resource, or the call is outside the pin; ask rather than retry.\n",

package/dist/providers/docs/index.d.ts

@@ -48,7 +48,7 @@ export type DocsOptions = GoogleWorkspaceOptions;
  *
  * Reads run in programs. `create_document`, `append_text`, and `insert_text`
  * are additive writes the host approves through call_destructive_tool or a
- * trusted program; `replace_all_text` and `batch_update_document` are
+ * program on a writable endpoint; `replace_all_text` and `batch_update_document` are
  * destructive.
  */
 export declare const docs: import("../../provider.js").ProviderFactory<GoogleWorkspaceOptions>;

package/dist/providers/docs/index.js

@@ -935,7 +935,7 @@ function toolDefinitions(client) {
             name: "create_document",
             description: "Create a new Google Doc in the user's My Drive root with a title and optional plain-text body. Cannot choose a folder, apply a template, or copy a document.",
             // Additive: a new document changes nothing that existed. Not read-only,
-            // so program calls require a trusted pool; other writes use
+            // so program calls require a writable endpoint; other writes use
             // call_destructive_tool. The host controls approval.
             annotations: { readOnlyHint: false, destructiveHint: false },
             inputSchema: input({
@@ -1188,7 +1188,7 @@ function usageGuide(purpose, instructions) {
  *
  * Reads run in programs. `create_document`, `append_text`, and `insert_text`
  * are additive writes the host approves through call_destructive_tool or a
- * trusted program; `replace_all_text` and `batch_update_document` are
+ * program on a writable endpoint; `replace_all_text` and `batch_update_document` are
  * destructive.
  */
 export const docs = asProviderFactory({

package/dist/providers/drive/index.d.ts

@@ -48,6 +48,6 @@ export type DriveOptions = GoogleWorkspaceOptions;
  * The `drive` scope reaches everything the user can; the tool surface is what
  * keeps this connection from deleting a file permanently or transferring
  * ownership. Every write crosses host approval through call_destructive_tool
- * or a trusted program.
+ * or a program on a writable endpoint.
  */
 export declare const drive: import("../../provider.js").ProviderFactory<GoogleWorkspaceOptions>;

package/dist/providers/drive/index.js

@@ -1473,7 +1473,7 @@ function usageGuide(purpose, instructions) {
  * The `drive` scope reaches everything the user can; the tool surface is what
  * keeps this connection from deleting a file permanently or transferring
  * ownership. Every write crosses host approval through call_destructive_tool
- * or a trusted program.
+ * or a program on a writable endpoint.
  */
 export const drive = asProviderFactory({
     name: "drive",

package/dist/providers/forms/index.d.ts

@@ -48,7 +48,7 @@ export type FormsOptions = GoogleWorkspaceOptions;
  *
  * Listing forms needs Drive, which this connection does not request; pair it
  * with a Drive connection for that. `create_form` is an additive write the
- * host approves through call_destructive_tool or a trusted program;
+ * host approves through call_destructive_tool or a program on a writable endpoint;
  * `update_form_info` and `batch_update_form` are destructive.
  */
 export declare const forms: import("../../provider.js").ProviderFactory<GoogleWorkspaceOptions>;

package/dist/providers/forms/index.js

@@ -806,7 +806,7 @@ function tools(client) {
             name: "create_form",
             description: "Create an empty Google Form with a title in the user's Drive. Google sets only the title here: add questions and a description with batch_update_form.",
             // Additive: a new, empty form changes nothing that existed. Not
-            // read-only: program calls require a trusted pool; other writes use
+            // read-only: program calls require a writable endpoint; other writes use
             // call_destructive_tool. The host controls approval.
             annotations: { readOnlyHint: false, destructiveHint: false },
             inputSchema: input({
@@ -1168,7 +1168,7 @@ function usageGuide(purpose, instructions) {
  *
  * Listing forms needs Drive, which this connection does not request; pair it
  * with a Drive connection for that. `create_form` is an additive write the
- * host approves through call_destructive_tool or a trusted program;
+ * host approves through call_destructive_tool or a program on a writable endpoint;
  * `update_form_info` and `batch_update_form` are destructive.
  */
 export const forms = asProviderFactory({

package/dist/providers/github/skill.generated.js

@@ -1,8 +1,8 @@
 // Generated by scripts/generate-providers.mjs; do not edit.
 export const skill = {
-    "content": "## Setup\n\nCreate a GitHub App, generate its RSA private key, and install it on every\nconfigured owner. Org grants require **All repositories**, including future\nrepositories. Exact repo grants work with selected-repository installations.\nRead-only grants request read permissions; read-write grants request only the\npermissions needed by each operation. The App needs repository Metadata,\nContents, Issues, Pull requests, Actions, Checks and Commit statuses for the\nreviewed read tools. Grant Contents, Issues, Pull requests and Actions write\nonly for the operations the deployment needs. Workflow-file edits also need\nthe App's Workflows write permission and `workflows: \"write\"` on the effective\nscope. Org grants authorize repository operations, not organization administration.\n\nPass `app: { appId, privateKey }` with the key from an environment secret, or\nomit privateKey and populate the connector's encrypted `privateKey` vault field.\nNever put private keys or installation tokens in agent instructions. Tokens\nstay in bounded runtime memory, refresh a minute before expiry, and are never\npersisted. Key rotation partitions the caches by the key's fingerprint.\nConfigured repository names bind to repository IDs on first use. Bindings last\nfor the provider instance; name lookups expire after five minutes. A rename\nkeeps its grant, while a replacement repository at the old name does not.\nReconfigure to authorize a replacement. Transfers leave the original\ninstallation and cannot use its tokens. Org grants bind to installation IDs.\n\n## Choose the target first\n\n`list_scopes({})` returns configured org/repo grants without network access.\n`list_scopes({ owner })` resolves that owner's installation and pages reachable\nrepositories. Carry its `next_page`. The connection context lists configured\nscopes and access. A repo entry overrides and may narrow its parent org entry.\nAn org grant covers current and future repositories, as long as the installation\nkeeps All repositories selected.\n\nEvery hosted call requires explicit `owner` and `repo`. Connecta checks scope\nand write access before reading the key or minting a token, and narrows each\nrepo call's token with `repository_ids` and the reviewed permissions.\nAn internal metadata-only installation token resolves names through GitHub's\ninstallation repository list; it never authenticates hosted calls or search.\nExpiry and misses refresh the name lookup without rebinding configured grants.\nUse discovery or the configured name to refresh a rename before using its new\nname; names that cannot map to a configured grant fail before operation tokens\nare minted. Cross-owner\nPR heads, cross-repository issue parents, opaque comment/review-thread IDs and\nsymlink writes are refused. The first release acts as the App; personal OAuth\nattribution is planned separately. Classification describes behavior; scope\nchecks authorize targets regardless of the pool's trust.\n\n## Tools and paging\n\nHosted schemas and results come from GitHub. Reviewed reads cover files,\ncommits, branches, tags, releases, issues, labels, PR details/diffs/reviews,\nand Actions workflows/runs/jobs. Reviewed writes cover issues, comments, PR\ncreation/updates/reviews, branches, file edits and Actions dispatch/rerun/cancel.\nCompound `issue_write` is always a write, including update/close. Review methods\nare limited to create/submit_pending/delete_pending; resolve/unresolve by opaque thread ID are\nnot exposed. Scope-changing tools, repo creation/forks, deletion/transfer,\nadministration, secrets and Copilot delegation are absent. Unknown upstream\ntools, arguments and methods require review before use.\n\nUse `search_scoped` for repositories, issues, PRs or code across installations.\nSupply literal words and an optional subset of configured org/repo selectors.\nScope qualifiers and Boolean operators are refused. Results have a partition\nID, next page, and an incomplete-results flag. Pass pages keyed by those exact\npartition IDs. Each call makes at most 20 partition requests; select fewer\nscopes when needed. Search pages stop at 10 and retain incompleteness. Returned\nrepositories are checked by ID against both deployment scopes and selected\npartitions. Issue and PR results resolve their repository URL to an ID before\nany result is returned.\nInstallation tokens do not override GitHub's own code-search access restrictions.\n\nREST complements own `create_release`, `update_release`, `delete_release` and\n`merge_pull_request`. Publishing a draft is `update_release({ draft: false })`.\nMerge requires an expected head SHA, a same-repository head/base and explicit\nworkflow-write access on the effective scope. GitHub atomically guards only the\nhead SHA, so a concurrent base retarget can introduce workflow changes despite\nan earlier file comparison. Merge is therefore disabled by default.\nRead current state before updates. A dispatched write is attempted once;\nGitHub errors never trigger an automatic write retry. Honor retry timing on\nrate limits; an ambiguous 404 may mean absence or an installation permission\ngap. Fix the App installation/key/permissions for auth errors; the App has no\ninteractive OAuth reconnect flow.\n",
+    "content": "## Setup\n\nCreate a GitHub App, generate its RSA private key, and install it on every\nconfigured owner. Org grants require **All repositories**, including future\nrepositories. Exact repo grants work with selected-repository installations.\nRead-only grants request read permissions; read-write grants request only the\npermissions needed by each operation. The App needs repository Metadata,\nContents, Issues, Pull requests, Actions, Checks and Commit statuses for the\nreviewed read tools. Grant Contents, Issues, Pull requests and Actions write\nonly for the operations the deployment needs. Workflow-file edits also need\nthe App's Workflows write permission and `workflows: \"write\"` on the effective\nscope. Org grants authorize repository operations, not organization administration.\n\nPass `app: { appId, privateKey }` with the key from an environment secret, or\nomit privateKey and populate the connector's encrypted `privateKey` vault field.\nNever put private keys or installation tokens in agent instructions. Tokens\nstay in bounded runtime memory, refresh a minute before expiry, and are never\npersisted. Key rotation partitions the caches by the key's fingerprint.\nConfigured repository names bind to repository IDs on first use. Bindings last\nfor the provider instance; name lookups expire after five minutes. A rename\nkeeps its grant, while a replacement repository at the old name does not.\nReconfigure to authorize a replacement. Transfers leave the original\ninstallation and cannot use its tokens. Org grants bind to installation IDs.\n\n## Choose the target first\n\n`list_scopes({})` returns configured org/repo grants without network access.\n`list_scopes({ owner })` resolves that owner's installation and pages reachable\nrepositories. Carry its `next_page`. The connection context lists configured\nscopes and access. A repo entry overrides and may narrow its parent org entry.\nAn org grant covers current and future repositories, as long as the installation\nkeeps All repositories selected.\n\nEvery hosted call requires explicit `owner` and `repo`. Connecta checks scope\nand write access before reading the key or minting a token, and narrows each\nrepo call's token with `repository_ids` and the reviewed permissions.\nAn internal metadata-only installation token resolves names through GitHub's\ninstallation repository list; it never authenticates hosted calls or search.\nExpiry and misses refresh the name lookup without rebinding configured grants.\nUse discovery or the configured name to refresh a rename before using its new\nname; names that cannot map to a configured grant fail before operation tokens\nare minted. Cross-owner\nPR heads, cross-repository issue parents, opaque comment/review-thread IDs and\nsymlink writes are refused. The first release acts as the App; personal OAuth\nattribution is planned separately. Classification describes behavior; scope\nchecks authorize targets whether or not the endpoint is read-only.\n\n## Tools and paging\n\nHosted schemas and results come from GitHub. Reviewed reads cover files,\ncommits, branches, tags, releases, issues, labels, PR details/diffs/reviews,\nand Actions workflows/runs/jobs. Reviewed writes cover issues, comments, PR\ncreation/updates/reviews, branches, file edits and Actions dispatch/rerun/cancel.\nCompound `issue_write` is always a write, including update/close. Review methods\nare limited to create/submit_pending/delete_pending; resolve/unresolve by opaque thread ID are\nnot exposed. Scope-changing tools, repo creation/forks, deletion/transfer,\nadministration, secrets and Copilot delegation are absent. Unknown upstream\ntools, arguments and methods require review before use.\n\nUse `search_scoped` for repositories, issues, PRs or code across installations.\nSupply literal words and an optional subset of configured org/repo selectors.\nScope qualifiers and Boolean operators are refused. Results have a partition\nID, next page, and an incomplete-results flag. Pass pages keyed by those exact\npartition IDs. Each call makes at most 20 partition requests; select fewer\nscopes when needed. Search pages stop at 10 and retain incompleteness. Returned\nrepositories are checked by ID against both deployment scopes and selected\npartitions. Issue and PR results resolve their repository URL to an ID before\nany result is returned.\nInstallation tokens do not override GitHub's own code-search access restrictions.\n\nREST complements own `create_release`, `update_release`, `delete_release` and\n`merge_pull_request`. Publishing a draft is `update_release({ draft: false })`.\nMerge requires an expected head SHA, a same-repository head/base and explicit\nworkflow-write access on the effective scope. GitHub atomically guards only the\nhead SHA, so a concurrent base retarget can introduce workflow changes despite\nan earlier file comparison. Merge is therefore disabled by default.\nRead current state before updates. A dispatched write is attempted once;\nGitHub errors never trigger an automatic write retry. Honor retry timing on\nrate limits; an ambiguous 404 may mean absence or an installation permission\ngap. Fix the App installation/key/permissions for auth errors; the App has no\ninteractive OAuth reconnect flow.\n",
     "instructionsHeading": "Repository instructions",
     "fragments": {
-        "guide": "## Setup\n\nCreate a GitHub App, generate its RSA private key, and install it on every\nconfigured owner. Org grants require **All repositories**, including future\nrepositories. Exact repo grants work with selected-repository installations.\nRead-only grants request read permissions; read-write grants request only the\npermissions needed by each operation. The App needs repository Metadata,\nContents, Issues, Pull requests, Actions, Checks and Commit statuses for the\nreviewed read tools. Grant Contents, Issues, Pull requests and Actions write\nonly for the operations the deployment needs. Workflow-file edits also need\nthe App's Workflows write permission and `workflows: \"write\"` on the effective\nscope. Org grants authorize repository operations, not organization administration.\n\nPass `app: { appId, privateKey }` with the key from an environment secret, or\nomit privateKey and populate the connector's encrypted `privateKey` vault field.\nNever put private keys or installation tokens in agent instructions. Tokens\nstay in bounded runtime memory, refresh a minute before expiry, and are never\npersisted. Key rotation partitions the caches by the key's fingerprint.\nConfigured repository names bind to repository IDs on first use. Bindings last\nfor the provider instance; name lookups expire after five minutes. A rename\nkeeps its grant, while a replacement repository at the old name does not.\nReconfigure to authorize a replacement. Transfers leave the original\ninstallation and cannot use its tokens. Org grants bind to installation IDs.\n\n## Choose the target first\n\n`list_scopes({})` returns configured org/repo grants without network access.\n`list_scopes({ owner })` resolves that owner's installation and pages reachable\nrepositories. Carry its `next_page`. The connection context lists configured\nscopes and access. A repo entry overrides and may narrow its parent org entry.\nAn org grant covers current and future repositories, as long as the installation\nkeeps All repositories selected.\n\nEvery hosted call requires explicit `owner` and `repo`. Connecta checks scope\nand write access before reading the key or minting a token, and narrows each\nrepo call's token with `repository_ids` and the reviewed permissions.\nAn internal metadata-only installation token resolves names through GitHub's\ninstallation repository list; it never authenticates hosted calls or search.\nExpiry and misses refresh the name lookup without rebinding configured grants.\nUse discovery or the configured name to refresh a rename before using its new\nname; names that cannot map to a configured grant fail before operation tokens\nare minted. Cross-owner\nPR heads, cross-repository issue parents, opaque comment/review-thread IDs and\nsymlink writes are refused. The first release acts as the App; personal OAuth\nattribution is planned separately. Classification describes behavior; scope\nchecks authorize targets regardless of the pool's trust.\n\n## Tools and paging\n\nHosted schemas and results come from GitHub. Reviewed reads cover files,\ncommits, branches, tags, releases, issues, labels, PR details/diffs/reviews,\nand Actions workflows/runs/jobs. Reviewed writes cover issues, comments, PR\ncreation/updates/reviews, branches, file edits and Actions dispatch/rerun/cancel.\nCompound `issue_write` is always a write, including update/close. Review methods\nare limited to create/submit_pending/delete_pending; resolve/unresolve by opaque thread ID are\nnot exposed. Scope-changing tools, repo creation/forks, deletion/transfer,\nadministration, secrets and Copilot delegation are absent. Unknown upstream\ntools, arguments and methods require review before use.\n\nUse `search_scoped` for repositories, issues, PRs or code across installations.\nSupply literal words and an optional subset of configured org/repo selectors.\nScope qualifiers and Boolean operators are refused. Results have a partition\nID, next page, and an incomplete-results flag. Pass pages keyed by those exact\npartition IDs. Each call makes at most 20 partition requests; select fewer\nscopes when needed. Search pages stop at 10 and retain incompleteness. Returned\nrepositories are checked by ID against both deployment scopes and selected\npartitions. Issue and PR results resolve their repository URL to an ID before\nany result is returned.\nInstallation tokens do not override GitHub's own code-search access restrictions.\n\nREST complements own `create_release`, `update_release`, `delete_release` and\n`merge_pull_request`. Publishing a draft is `update_release({ draft: false })`.\nMerge requires an expected head SHA, a same-repository head/base and explicit\nworkflow-write access on the effective scope. GitHub atomically guards only the\nhead SHA, so a concurrent base retarget can introduce workflow changes despite\nan earlier file comparison. Merge is therefore disabled by default.\nRead current state before updates. A dispatched write is attempted once;\nGitHub errors never trigger an automatic write retry. Honor retry timing on\nrate limits; an ambiguous 404 may mean absence or an installation permission\ngap. Fix the App installation/key/permissions for auth errors; the App has no\ninteractive OAuth reconnect flow.\n"
+        "guide": "## Setup\n\nCreate a GitHub App, generate its RSA private key, and install it on every\nconfigured owner. Org grants require **All repositories**, including future\nrepositories. Exact repo grants work with selected-repository installations.\nRead-only grants request read permissions; read-write grants request only the\npermissions needed by each operation. The App needs repository Metadata,\nContents, Issues, Pull requests, Actions, Checks and Commit statuses for the\nreviewed read tools. Grant Contents, Issues, Pull requests and Actions write\nonly for the operations the deployment needs. Workflow-file edits also need\nthe App's Workflows write permission and `workflows: \"write\"` on the effective\nscope. Org grants authorize repository operations, not organization administration.\n\nPass `app: { appId, privateKey }` with the key from an environment secret, or\nomit privateKey and populate the connector's encrypted `privateKey` vault field.\nNever put private keys or installation tokens in agent instructions. Tokens\nstay in bounded runtime memory, refresh a minute before expiry, and are never\npersisted. Key rotation partitions the caches by the key's fingerprint.\nConfigured repository names bind to repository IDs on first use. Bindings last\nfor the provider instance; name lookups expire after five minutes. A rename\nkeeps its grant, while a replacement repository at the old name does not.\nReconfigure to authorize a replacement. Transfers leave the original\ninstallation and cannot use its tokens. Org grants bind to installation IDs.\n\n## Choose the target first\n\n`list_scopes({})` returns configured org/repo grants without network access.\n`list_scopes({ owner })` resolves that owner's installation and pages reachable\nrepositories. Carry its `next_page`. The connection context lists configured\nscopes and access. A repo entry overrides and may narrow its parent org entry.\nAn org grant covers current and future repositories, as long as the installation\nkeeps All repositories selected.\n\nEvery hosted call requires explicit `owner` and `repo`. Connecta checks scope\nand write access before reading the key or minting a token, and narrows each\nrepo call's token with `repository_ids` and the reviewed permissions.\nAn internal metadata-only installation token resolves names through GitHub's\ninstallation repository list; it never authenticates hosted calls or search.\nExpiry and misses refresh the name lookup without rebinding configured grants.\nUse discovery or the configured name to refresh a rename before using its new\nname; names that cannot map to a configured grant fail before operation tokens\nare minted. Cross-owner\nPR heads, cross-repository issue parents, opaque comment/review-thread IDs and\nsymlink writes are refused. The first release acts as the App; personal OAuth\nattribution is planned separately. Classification describes behavior; scope\nchecks authorize targets whether or not the endpoint is read-only.\n\n## Tools and paging\n\nHosted schemas and results come from GitHub. Reviewed reads cover files,\ncommits, branches, tags, releases, issues, labels, PR details/diffs/reviews,\nand Actions workflows/runs/jobs. Reviewed writes cover issues, comments, PR\ncreation/updates/reviews, branches, file edits and Actions dispatch/rerun/cancel.\nCompound `issue_write` is always a write, including update/close. Review methods\nare limited to create/submit_pending/delete_pending; resolve/unresolve by opaque thread ID are\nnot exposed. Scope-changing tools, repo creation/forks, deletion/transfer,\nadministration, secrets and Copilot delegation are absent. Unknown upstream\ntools, arguments and methods require review before use.\n\nUse `search_scoped` for repositories, issues, PRs or code across installations.\nSupply literal words and an optional subset of configured org/repo selectors.\nScope qualifiers and Boolean operators are refused. Results have a partition\nID, next page, and an incomplete-results flag. Pass pages keyed by those exact\npartition IDs. Each call makes at most 20 partition requests; select fewer\nscopes when needed. Search pages stop at 10 and retain incompleteness. Returned\nrepositories are checked by ID against both deployment scopes and selected\npartitions. Issue and PR results resolve their repository URL to an ID before\nany result is returned.\nInstallation tokens do not override GitHub's own code-search access restrictions.\n\nREST complements own `create_release`, `update_release`, `delete_release` and\n`merge_pull_request`. Publishing a draft is `update_release({ draft: false })`.\nMerge requires an expected head SHA, a same-repository head/base and explicit\nworkflow-write access on the effective scope. GitHub atomically guards only the\nhead SHA, so a concurrent base retarget can introduce workflow changes despite\nan earlier file comparison. Merge is therefore disabled by default.\nRead current state before updates. A dispatched write is attempted once;\nGitHub errors never trigger an automatic write retry. Honor retry timing on\nrate limits; an ambiguous 404 may mean absence or an installation permission\ngap. Fix the App installation/key/permissions for auth errors; the App has no\ninteractive OAuth reconnect flow.\n"
     }
 };

package/dist/providers/gmail/index.d.ts

@@ -46,6 +46,6 @@ export type GmailOptions = GoogleWorkspaceOptions;
  *
  * `gmail.compose` technically allows sending; this connection never does,
  * because no tool reaches a send method. Drafts are additive writes the host
- * approves through call_destructive_tool or a trusted program.
+ * approves through call_destructive_tool or a program on a writable endpoint.
  */
 export declare const gmail: import("../../provider.js").ProviderFactory<GoogleWorkspaceOptions>;