Crevio

An AI agent that runs your online business: products, orders, customers, email, and sites.

От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

    Какие данные видит

    Нужен ли аккаунт

    Не нужен: сервер работает без входа

    An AI agent that runs your online business: products, orders, customers, email, and sites.

    Список инструментов сервера (14)

    Технические названия из tools/list. Нужны только разработчикам.

    whoamiIdentify the account, user, and credential behind this connection, with plan, credit balance, rate limits, and the tools available. Call it first to verify the setup.
    ask_crevioDelegate a job to the Crevio agent and wait for the result. Starts a run that works your account through the Crevio API (products, customers, orders, email, socials, sites, research), waits up to timeout_seconds, and returns the run with the agent's final reply in `result`. For anything longer, use start_task and wait_for_run.
    start_chatOpen a chat with the Crevio agent and queue a run, without waiting. Returns the run immediately — its `chat_id` is the conversation to continue with send_message. Follow the run with wait_for_run or get_run.
    list_chatsList the account's chats, newest first.
    get_chatGet a chat's title, kind, and latest run.
    send_messageContinue a chat with follow-up instructions or answers — the agent keeps its context. Resumes a run waiting in needs_input, or queues a new run when the last one finished. Returns run_busy while a run is still in progress. Optionally waits for the reply.
    list_messagesRead a chat's messages, oldest first. Returns the most recent `limit` messages; page back through older ones with starting_after.
    wait_for_runWait for a run to settle (completed, failed, or needs_input) and return it with the agent's final reply. Returns wait_timed_out if it is still running when the timeout passes; call again.
    get_runFetch a run's current status, summary, pending approvals, and (once settled) the agent's final reply.
    list_runsList the account's task runs, newest first — delegated jobs and scheduled tasks alike. Filter by status or task.
    resolve_approvalsApprove or deny the integration actions a run is paused on (status needs_input with pending_approval_ids). Submit a decision for every pending id at once; the run resumes in the background.
    cancel_runStop a run that is pending, running, or waiting for input. The run is finalized as failed with 'Cancelled by the caller'.
    api_searchDiscover available Crevio API endpoints. Use this BEFORE `api_execute` when you're unsure which endpoint to call, need to check parameter names, or want to explore what's available for a domain (e.g. "experiences", "discounts"). A `tools` method returns the full API catalog — an array of hashes keyed with strings: "method", "path", "summary", "description", "tags", "parameters", "request_body". Examples: `tools.select { |t| t["tags"]&.include?("Products") }.map { |t| "#{t["method"]} #{t["path"]} — #{t["summary"]}" }` `tools.find { |t| t["path"].include?("price_variants") && t["method"] == "POST" }["request_body"]` `tools.map { |t| t["tags"] }.flatten.compact.uniq.sort` — list all API domains
    api_executeExecute Ruby in a sandboxed VM against the Crevio REST API. Use `api_search` first to find the endpoint and its body fields, then call it here. Chain calls, transform results, return the final expression. ## Available in your code ``` get(path, params = {}) # paths auto-prefixed with /v1, routed in-process post(path, **body) # body as keyword args or a hash — both work patch(path, **body) delete(path) find_endpoints(query) # -> ["METHOD /path — summary", ...] iso8601(offset_seconds = 0) # mruby Time has no strftime/iso8601 ``` Returns the **last expression**; `puts` is side-channel only. Every run answers `{result:, calls:, output:}` — `calls` audits each REST call (`method`, `path`, `status`, plus `error_code`/`param` on failure). When `result` has unexpected nils, read `calls` for a non-2xx. Never project only success fields (`{id: r["id"]}`) — that hides the error from `result`. ## Rules that the schema does not tell you - Params are unwrapped, Stripe-style: fields at the TOP level. `{product: {...}}` is silently dropped by most endpoints. - Associations take the bare resource name and a prefix_id string — `product: "prod_x"`, never `product_id:`. Some required ones never appear in a schema's `properties`. - Courses and content live under `/experiences`, NOT `/products`. - Lists answer `{object: "list", data: [...], has_more}`; single resources answer the object directly. - Connected integrations go through the same REST surface: `post("/connections/<id>/execute", tool: "<tool>", arguments: {...})`, with ids from `get("/connections", search: "<service>")`. - Sandboxed mruby: no `File`, `ENV`, `Net::HTTP`, `Process`. 10s, 10 MB. ## Example — publishing a product (the ordering trap) A product cannot be created active: it needs a price variant first, or the call 422s. ```ruby product = post("/products", name: "...") post("/price_variants", product: product["id"], name: "Standard", amount_type: "fixed", amount: 4900, currency: "u
    Crevio: подключить к Claude, ChatGPT, Cursor · Connectors.fun