Glide MCP

Promote user attachments into the project's public app-asset storage and return an app-local path — `/assets/<sha256>/<filename>` — for each. Use that value as-is in `src` / `href`: it resolves on the app's own origin, so it survives a clone or a change of asset origin untouched. To read one from SERVER code, `import { assets } from "./assets"` (server-only — importing it from client code fails the build) and call `assets(env).fetch(<that same app-local path>)` — never construct or fetch the canonical app-assets URL, which is refused without the helper's capability. Pass an `assets` array; a single upload is just an array of one, and a 93-image batch is a single call. Each path is content-addressed, immutable, and cached for a year. 100 MB each. Images, audio and video whose bytes match a known container (PNG/JPEG/WEBP/GIF, MP3/WAV/FLAC/OGG/M4A, MP4/MOV/WebM) are served under their real content type; anything else is served as generic binary, which a browser will download rather than play. Every asset is stored with a visibility class — see `visibility`, which defaults to `private`; only mark bytes `public` when they are meant to be world-readable forever. Returns `{ results }` — one entry per input asset, in order: a success is `{ path, id, url, sha256, bytes, alreadyExisted }` (`url` is that app-local path), a failure is `{ path, error }`. One bad file does NOT fail the rest of the batch. WIRING ASSETS TO DATA ROWS: when each asset belongs to a record in a table (one asset per record), set `writeUrlsToTable` and give each asset a `row: { key, column }`. The worker then writes every resulting app-local path straight into the table — do NOT, and do not need to, follow up with a `db_execute` UPDATE to store them. Emitting dozens of long content-addressed references as inline SQL is slow and burns output tokens; let this tool bind them server-side instead. What lands in the column is a PATH, not an absolute URL, so it resolves only on the app's own origin — anything reading those columns from outside the app (an export, a webhook payload) must join it to the app's origin itself.

List the AI models available to deployed apps that declare an `ai` binding. Each entry returns an `id`, a provider, and a tier. Pass the `id` verbatim — the compound `provider/model` form (e.g. anthropic/claude-haiku-4-5). Default to anthropic/claude-sonnet-4-6 unless you have a reason otherwise. Load the `ai` skill for the call patterns (`complete()`, `stream().toResponse()`), the server-side-only boundary, and the build-fail anti-patterns.

Query AI Gateway request logs for this project's deployed apps. Returns recent calls made through the `ai` binding — model, provider, success, tokens, cost, duration — with per-app attribution via metadata. Useful for diagnosing customer AI binding issues (401s, rate limits, unexpected models, quota consumption). Results are scoped to this project by filtering on metadata.projectId, so it never leaks other projects' usage. Requires CF_API_TOKEN to have the 'AI Gateway Read' permission.

Create a pre-authenticated link to an app. Use this to test/verify/screenshot.

Bind a custom domain to a published app (e.g. `mycoolapp.dev` or `app.example.com`). Platform subdomains (*.glideapps.dev, *.glideos.app, etc.) are not allowed — use app_claim_vanity_slug instead. Registers the hostname with Cloudflare for SaaS, writes the KV routing pointer, and stores the domain on the app. The customer must point a CNAME at the platform's custom hostname target for SSL to provision. BEFORE the first bind of a domain, the customer must also PROVE they control it by publishing a TXT record at `_glide-verify.<hostname>` (the required value is derived per organization). Without it the bind is refused with `code: "ownership_unverified"` and a `verification` object naming the exact record — relay those values to the user and wait for them to publish the record; do NOT retry blindly, retries cannot succeed until the record is live. `code: "ownership_check_unavailable"` means DNS could not be reached and IS worth retrying.

Claim a globally unique vanity subdomain for an app (e.g. `myapp.glideapps.dev`). The slug must follow DNS naming rules and be unique across all organizations.

Check the status of an app's custom domain: whether the SSL cert is active, still provisioning, or blocked. When blocked, returns the exact issue (commonly the customer's DNS CAA records not permitting the issuing CA — the message says which authority to allow). Use this to answer "is my domain live yet?" or to diagnose why a bound custom domain isn't working.

Delete an app. Soft-deletes the app record, removes the deployed worker (or dispatch-namespace script), and clears the production KV route. Best-effort cleanup — missing CF resources are ignored.

Get details of a specific app by slug. Returns user-facing name, latest deploy description, URL, status, version, script name, bindings, and timestamps.

List all apps for the project (deployed, pending, or errored — excludes deleted). Each app includes app slug, user-facing name, latest deploy description, deployed URL, status, version, script name, and bindings.

Get version history for a deployed app. Shows all past deploys with version numbers, titles/descriptions, and URLs.

Promote a specific version of an app to production. Verifies the target version script exists in the dispatch namespace, updates the production KV pointer, and updates the app's production URL.

Promote a version of an app to production. After update_preview succeeds, pass its returned publishable content hash as this tool's `version`. Only available when Workers for Platforms is configured.

Release a vanity subdomain so it can be claimed by another app. The app's long-form production URL continues to work.

Make an authenticated HTTP request to THIS project's own app backend (the routes you write in server.ts) and get the response back — use it to verify an endpoint returns what you expect, walk a multi-step flow, or build a test suite against the app you just built. Defaults to the PREVIEW deployment (safe to hammer) and to calling as the current user. Only app-relative paths are allowed (e.g. "/api/invoices"); external URLs are refused. The response body is capped and returned as parsed JSON when possible. Pass `expect` to assert a status and/or a partial body shape in one call. This is for probing/testing — to change behavior, edit server.ts and redeploy. This is the read-only variant: methods GET, HEAD, and OPTIONS only, and it takes no request body.

Make an authenticated HTTP request to THIS project's own app backend (the routes you write in server.ts) and get the response back — use it to verify an endpoint returns what you expect, walk a multi-step flow, or build a test suite against the app you just built. Defaults to the PREVIEW deployment (safe to hammer) and to calling as the current user. Only app-relative paths are allowed (e.g. "/api/invoices"); external URLs are refused. The response body is capped and returned as parsed JSON when possible. Pass `expect` to assert a status and/or a partial body shape in one call. This is for probing/testing — to change behavior, edit server.ts and redeploy. This is the mutating variant: methods POST, PUT, PATCH, and DELETE, with an optional request body.

Roll an app back to a previous version. The target version must already exist in the app's version history. Updates the app record + production KV pointer so the public URL serves the older build. IMPORTANT: this changes ONLY what production serves — workspace source files and the preview are NOT restored, so after a rollback the preview and future edits still reflect the current (newer) source. If the user wants the source rolled back too, restore the relevant files (see file_history / file_restore) — and always tell the user about this divergence when rolling back.

Read build, client-runtime, and retained server-error history for this project. Read the top-level `verificationStatus` first: it is the canonical, server-authored interpretation of the current preview's build, reachability, and exact-version initial browser mount. `unverified` is inconclusive even when `runtime.text` is empty; `failed` has an actionable current build/runtime failure; `initial_runtime_passed` covers only this bounded initial-runtime scope and does not verify later interactions, visual correctness, or requested UI behavior; `not_applicable` is reserved for correlated checks of headless workflows. `verificationReasons` explains the status. The legacy nested build, deploy, and runtime fields remain as diagnostics. `server.scope` is `recorded_history`; each server row's `versionStatus` says only whether its recorded version is live, superseded, or unknown. A live version does not mean the error is ongoing, and an unchanged `lastSeenMs` and `count` do not prove recurrence. `runtime.stale` and `verificationStatus` do not classify server history. Each server row carries `trigger` — how the platform invoked the app (`fetch`, `rpc:<method>`, `scheduled`, `queue`, `alarm`). Any non-`fetch` trigger means there was no HTTP request: `route` is null for that reason rather than because a path could not be attributed, and the app's `fetch` handler is not on that code path, so changing it cannot affect the error. A `trigger: rpc:run` entry whose message is the runtime's "code had hung" abort is the platform's known false positive for workflow apps (the run() session is flagged after run() has returned); confirm with list_workflow_runs and treat it as actionable only when the matching run is errored. Read-only. Takes no input; runtime context and correlation metadata are supplied server-side. Errors from later user interactions still arrive asynchronously and surface in the next turn's automatic runtime-context block.

Set the app's access level — the same setting the user sees in the Share dialog. When you describe org access to the user, always call it their "Glide org" / "Glide organization", never a bare "org". Three options: `org-member` = "Members with project access" (default; must sign in AND belong to the owning Glide org AND be able to view the app's project — project permissions can exclude a member from one project, and Glide enforces that before the app's code runs); `authenticated` = "Public with sign in" (must sign in; the app does its own authorization); `public` = "Public for anyone with the link" (no sign-in — exposes all the app's data to anyone with the URL). Access is the user's call and ALWAYS needs explicit confirmation: first call `suggest_answers` to confirm the exact change with the human, THEN call this tool with `confirmAccessChange: true`. Never set `confirmAccessChange` without a fresh suggest_answers confirmation for this specific change. Take extra care with `public` — it drops sign-in entirely. Note: some plans don't include externally-shared access (`public`, and on newer plans `authenticated` too) — the call then returns a `public_access_not_allowed_on_plan` denial and an upgrade card is shown to the user. Entitlements decide, not plan names: never refuse pre-emptively — attempt the call and relay the denial. Changes apply to the live app within about a minute of a successful call — no republish is needed; if a check within that first minute still shows the old behavior, wait and re-check before diagnosing. Builder preview URLs always require sign-in regardless of this setting — only the published URL reflects it.

Set the icon for one of the project's apps. Provide `name` (the app to retint) and EITHER a short `description` of what the icon should evoke — e.g. 'task tracker', 'expense reports', 'rocket' — OR `path` (the `attachments/...` path of an image the user uploaded). With `description`, the shared icon library picks a matching glyph, rendered on demand in the project's current accent color, so a later `project_set_accent_color` call retints it automatically. With `path`, the uploaded image is center-cropped to a square PNG, stored at a public URL, and set as a custom icon — custom icons are NOT accent-retinted. Always overwrites the existing icon; the previous stored value is returned in `previousIcon` so the change can be talked about or undone. When the user asks to change the icon without giving a direction (no attached image, no desired look), don't pick one silently: use `suggest_answers` to propose a few concrete icon ideas that fit the app as options and say they can also upload an image to use instead. Skip the question when the request already carries a direction (an attached image, or a concrete description like 'make it a rocket'). If the app is published, follow with `update_preview` so the new icon lands in a publishable version.

Rename an app's user-facing name when the user explicitly asks to rename it. This does not change the app slug, dispatch script names, or production URLs.

Set how one of the project's apps presents itself when installed, shared, or indexed: the web-manifest and <head> fields the platform otherwise fills with defaults. Pass `name` (the app) and `presentation`, a partial object — only the fields given are written, `null` clears one, everything else is left as it was; `presentation: null` clears every field. Fields: `shortName` (home-screen label, ≤12 chars), `lang` (BCP-47 tag for the page), `display` (standalone / fullscreen / minimal-ui / browser), `orientation`, `themeColor` and `backgroundColor` (`#rrggbb`; the status-bar / splash colours), `socialTitle` and `socialDescription` (the link-preview / search-result title and description — the only source of the description metas; the app's internal description is never published), and `metaTags` (a small allowlisted set of <meta name> tags such as robots or author). Only call this when the user explicitly asks for one of these changes; never adjust presentation on your own initiative. To create or replace the icon image use `app_set_icon`; to rename the app use `app_set_name`. The change lands on the app's next `update_preview`, and on the published app after its next publish.

Unbind a custom domain from an app. Removes the CF for SaaS hostname registration, deletes the KV routing pointer, and clears the domain from the app. The app's production URL and any vanity URL continue to work.

Query recent tool-dispatch audit rows for this project. Every mutating tool call (and every denied call of any kind) produces an audit entry with the verified actor, delegation chain, traceId, decisionId, and truncated input/result. Javascript/bash sandbox workspace mutations log as `sandbox_workspace_state` (see `detail.input.method`). Optional filters: `actor` (match principal like 'user:u_123' or 'agent:sess_abc'), `onBehalfOfUser` (human principal for delegated agent calls), `tool` (exact tool name), `allowed` (true/false to isolate denials), `sinceMinutes` (time window, default 60). Returns entries newest-first.

Fetch every audit entry sharing a given `traceId`, reconstructing one turn's full effect chain. A traceId is carried end-to-end on every ActorContext, so this surfaces every tool the agent called on behalf of a user within a single chat turn — including denials. Pairs with `auth_whoami` (returns the current traceId) and with the `decisionId` emitted by the authz client.

Dry-run an authorization check for the caller without executing anything. Returns `{ allowed, decisionId, reason? }` — same shape the registry's dispatch() uses to gate every tool call. Useful for 'can I do X?' questions ahead of time, and for debugging denials by correlating the returned `decisionId` with the external authz service's decision log. Agent actors are evaluated as their delegated human principal (same policy the registry applies for real dispatches).

Introspect the project worker's tool registry — returns every registered tool with its authz-relevant metadata: name, domain, scope, readOnly, destructive, idempotent, supportsDryRun, and whether it declares a custom `authz.action`/`authz.resource` override. Agents and ops use this to answer 'which tools exist?' and 'which mutations would require which grants?' without grep. The dashboard worker has an equivalent tool for its own registry.

Return the verified ActorContext for the caller — actorId, actorType, orgId, projectId, delegation chain (if any), and correlation IDs (requestId, traceId) — enriched with the organization name from project metadata. Use this to confirm a tool call is running under the expected user and organization, or to trace the full actor chain for a delegated agent session.

Run a short Bash script in a sandboxed shell. Use this for shell-style text and data work: pipes, heredocs, grep/sed/awk/jq, sorting, diffs, checksums, zip/unzip for .zip archives, and quick text/CSV/JSON transforms. The bundled `zip` / `unzip` are a simplified Info-ZIP subset, not the full CLI. Supported flags: `zip [-r] [-o] [-q] archive.zip path [paths...]` (`-o` / `-q` accepted as no-ops) and `unzip [-l|-p] [-o] [-q] [-d outdir] archive.zip [entry...]` — `-l` lists entries without extracting, `-p` streams entry contents to stdout (filter by trailing entry names; omit to concatenate all files). Other flags (`-j`, `-v`, passwords, etc.) are not supported — invoke without them. `zip` updates an existing archive in place (existing entries are kept; same names are replaced). Project-mount I/O is budgeted per tool call (a few hundred file reads / writes). Archive whole directories in one shot — `zip -r backup.zip apps lib` — instead of looping `zip` once per file; per-file loops burn the budget on repeated stats and reads. When this chat has an active project open, the project workspace is mounted at `/project` and the shell starts there. Paths like `/tmp` are ephemeral scratch space for this call only—nothing persists after the tool returns. Reads and writes under the mount update the project's files. `curl` and `wget` work only when this deployment allows outbound HTTP to public URLs (same rules as the `javascript` tool). If a command is missing, assume outbound is off and use other tools or data already in the project. No host machine filesystem, Python, js-exec, sqlite3, yq, or xan. Always include a short user-facing `label` for the intent, e.g. "Summarize CSV rows", "Filter error logs", or "Compare JSON payloads".

Look up live Glide pricing and billing facts: the org's current plan and subscription, credit balance and quota usage, the full plan catalog with current prices, per-plan baseline features, and the official billing/credits docs. Call this for ANY question about pricing, plans, upgrades, costs, credits, seats, limits, refunds, or billing — never answer those from memory. Takes no input.

Stop an in-flight workflow run (running / paused / waiting) by its run id — the same Stop the dashboard offers. Terminates execution at the current step; completed steps are NOT rolled back, and a finished run (complete / errored / stopped) can't be cancelled. This stops ONE run only — the workflow stays enabled and future triggers still fire (use set_workflow_enabled to turn the workflow itself off). Get the run id from list_workflow_runs or the run_workflow result.

Register that a deployed app in this project may start a workflow from its own server code — the way a button in the app kicks off a run. Then the app's server route calls `workflows(c.env).start("<workflow slug>", { data })` from the injected `./workflows` helper. Do this BEFORE writing the route; calling it again for the same app + workflow only refreshes the label. Returns the exact code to paste.

Start a workflow whenever rows in one of this project's tables are inserted, updated or deleted — by the app's users (a form submit), in the Data Editor, by agent SQL, or by another workflow. The run gets the change as `event.payload.change` (`{ table, op, rows: [{ new?, old? }], rowCount, truncated, … }`, one run per statement, up to 100 rows). There are no per-row conditions: check them in the workflow's run() and return early. A workflow's own writes do not re-fire it. Changes made through a direct database connection are not supported. Deploy the workflow first; confirm the table and which changes with the user before calling.

Schedule a deployed workflow to run automatically — either RECURRING or ONE-TIME. Use this after the workflow is deployed; actually create the schedule, do NOT just tell the user how. Provide EXACTLY ONE of: `cron` (recurring), `delaySeconds` (one-time, relative — best for 'in N minutes/hours'), or `runAt` (one-time, absolute instant). `cron` is 5-field (minute hour dom month dow) read on the wall clock of `timezone` — write the user's local time as-is and pass their IANA zone; do NOT convert to UTC yourself. The result carries `estimate` (runs/day, runs/month, and steps-only credits/month at this workflow's usual size) and `existingSchedules` (the workflow's other schedules) — relay the cadence AND the estimate to the user in one line. A recurring schedule that STACKS on an enabled one (every fire of one is a fire of the other: a duplicate, hourly beside every-15-minutes) is REFUSED — edit the existing schedule with update_workflow_schedule instead; `allowOverlap` is only for a user who, told of the overlap, still asks for both.

Give a deployed workflow a PUBLIC URL that an external POST fires a run on — for EXTERNAL systems only (Stripe, Zapier, partner callbacks, curl). An app in THIS project must NEVER call the webhook: a deployed app's server code cannot reach the webhook host (the fetch fails with a 522), and its client must not hold the URL (the token is the credential). To start or resume a workflow from an app's own code — a button, a form submit — use create_workflow_app_trigger and the injected `./workflows` helper instead; never add a schedule to stand in for a button. The request body becomes the run's event.payload. Returns the URL — show it to the user. The token in the URL is the only credential BY DEFAULT, so treat it as a secret; for defense in depth, set_workflow_webhook_header_auth can additionally require a secret header on every request. MVP: one webhook per workflow (use rotate_workflow_webhook to regenerate it).

Return a read-only connection string for a G3-managed backup branch. Requires editor access even though the branch endpoint is read-only.

Create a read-only backup branch from a timestamp or Postgres LSN within the Neon history window.

Delete a G3-managed database backup branch. Refuses non-G3 branches and the active branch.

List all G3-managed database backup branches for this project. Backup metadata is parsed from branch names.

Show whether the project database is provisioned, the Neon history window, and the active branch.

Read or change the project database's compute ceiling. With no input it reports the current autoscaling range (min and max CU), the suspend timeout, the compute state, and the largest ceiling this organization's plan allows. With maxCu it raises or lowers the ceiling to that size (one of 0.25, 0.5, 1, 2, 4, 8 CU), clamped to the plan's allowance; a value above the allowance is refused with the plan code and nothing changes. Raising costs the organization more per hour of active compute, so it needs the human's confirmation on each call, and it is not a fix for a query that runs the compute out of memory: run db_health first and fix the failing route; raise only for genuine load. Lowering is always allowed.

Run any SQL statement against the project's Postgres database — SELECT, INSERT, UPDATE, DELETE, or DDL. When creating or materially changing a table or view, also add/update a Postgres relation comment with COMMENT ON TABLE or COMMENT ON VIEW explaining what it stores or queries. The tool is marked destructive because the caller can mutate state; use `dryRun: true` to get the planner output via EXPLAIN without executing. Result sets are capped at 1,000 rows / 256 KB — add a LIMIT or aggregate if a statement returns more.

Get details for a single project database by name. Returns engine, provisioning state, and Neon project ID. Does not return the connection string — that stays inside the worker.

Health check for the project database, read-only: compute size and suspend timeout, data size, largest tables, tables read by full scans, dead-row bloat, open connections against the limit, the slowest statements when statistics are available, and every route in this project's apps that has recently failed against the database with its classification and reading. Returns ordered findings; the first ones are what to fix. Call it whenever a database error appears in runtime context or app_runtime_errors, whenever the user reports the app slow or failing, and before saying a database problem is transient.

Bulk-load a CSV/JSON/XLSX attachment into a Postgres table in one step. The destination table must already exist — create it first with db_execute. `columns` is REQUIRED and acts as the inclusion list: only source columns named as keys in the map are loaded; any other source column in the file is silently dropped. Hard cap of 100k rows per call.

List the databases provisioned for this project. Each project currently has at most one Neon Postgres database (`project-db`), auto-provisioned on first deploy; the return shape is an array to stay forward-compatible with multi-DB projects.

List all public tables and SQL views in the project's Postgres database (if provisioned), including relation comments plus column schemas or view definitions. Prefer relevant views over raw tables when building read-only screens.

Restore the live project database from a G3-managed backup branch. The current state is first preserved as a backup branch.

Restore the live project database to a timestamp or LSN. The current state is first preserved as a backup branch.

Run a single read-only statement (`SELECT …` or `WITH … SELECT …`) against the project's Postgres database, inside a `SET TRANSACTION READ ONLY` envelope. Use this for dashboard questions, summaries, comparisons, charts, and analysis that need existing project data. For writes, DDL, or multi-statement SQL, use db_execute. Results are capped at 1,000 rows / 256 KB — add a LIMIT/WHERE, select fewer columns, or aggregate (COUNT/SUM/GROUP BY) to narrow large reads.

Permanently remove a live integration trigger — the external event stops starting the workflow. The toolkit CONNECTION is untouched (other triggers and action calls keep working). Get the `triggerId` from list_active_triggers. This cannot be undone; to pause temporarily use set_trigger_enabled instead.

Delete an app trigger by id (from list_workflow_app_triggers). The app's `workflows(env).start()` call then refuses with trigger_not_found until the app is registered for that workflow again. To only pause it, use set_workflow_app_trigger_enabled with enabled:false instead.

Delete a data trigger by id (from list_workflow_data_triggers). Changes to its table stop starting the workflow. To only pause it, use set_workflow_data_trigger_enabled with enabled:false instead.

Permanently delete a webhook by id (from list_workflow_webhooks). The URL stops working. To only temporarily pause it (keeping the URL), use set_workflow_webhook_enabled with enabled:false instead.

Make an external event START A WORKFLOW (e.g. "when a new inbound message arrives, run the triage workflow"). A trigger is just another source that kicks off a workflow run — the integration counterpart to a cron schedule. In order: (1) build the workflow first with update_preview({ kind: "workflow" }) so it exists and is deployed; its `run(event, step, env)` receives the trigger payload as `event.payload = { triggerSlug, toolkit, data }` (branch on `event.payload.triggerSlug`; `event.payload.data` is the provider's raw event, so log it once to learn its shape). (2) connect the toolkit with connect_integration. (3) call this with the toolkit you connected, a trigger slug from list_triggers, the workflow's slug, the `config` filters from the trigger's config schema (elicit values from the user — filter upstream, not inside the workflow), and a user-facing `title`. Re-enabling the same workflow+slug REPLACES the existing trigger (it's an edit — pass keepExisting only to deliberately add a second instance). The run is durable with full run history — there is NO publish step and NO onEvent handler in a server file; the trigger fires on the DEPLOYED workflow. Act on the event inside the workflow via integrations(env).execute(...).

Copy a file in the project workspace from `source` to `destination` without removing the original.

Delete a file from the project workspace.

In-place edit of a workspace file: apply one or more exact replacement entries in a single call. Prefer one file_edit invocation with multiple edits[] entries over several separate file_edit calls when changing the same file. Every edits[] old_string is matched against the original file contents, must identify exactly one non-overlapping region, and is replaced with new_string. Supports multiline edits plus whitespace-tolerant matching when indentation or trailing spaces drift. Fails if the file is missing, if no match is found, if any match is ambiguous, or if edits overlap, and returns structured retry guidance so the caller can recover. Provide a short human-readable label (8 words max) describing what's changing for the chat transcript UI — e.g. "Update navigation labels", "Fix validation bugs". MUST start with a capitalized verb; never a lowercase word or noun-first phrase.

List the mutation history of workspace files — every write, edit, delete, move, and copy, newest first, with a ledger id per entry. Pass `path` for one file's history, `prefix` for a directory subtree, or neither for the whole workspace. Use the returned ids with file_restore (one file) or workspace_restore (point-in-time). Content is never lost on this platform: any prior state listed here can be restored.

Inspect a file from the workspace. For images (PNG/JPG/GIF/WEBP/AVIF/HEIC), returns the visual content. For PDFs and text files, returns the extracted text (truncated at 32 KB; when the result is truncated, use `file_read` for a specific line range or `file_search` to grep for the rest instead of re-inspecting). For spreadsheets (XLSX), CSV, or JSON, returns structured data. For ZIP archives, returns the entry listing (names + sizes) only. Other binary files (audio, video, archives, executables, fonts, databases) return `{type: "binary"}` metadata — size and sniffed media type — rather than failing. Use this before working with any attachment — logos, screenshots, mockups, reference photos, PDFs, data files, etc. The tool automatically optimizes images for vision (downscaling, JPEG re-encoding) and detects file types automatically.