Roar AI

**Roar AI Cloud** gives your company one API key to the leading AI models, plus simple hosting for internal apps and their databases. This server lets your AI assistant do the console work for you. ### What it can do - **API keys** — create keys scoped to exactly what an app needs, set spend caps and expiry, revoke them - **Usage and spend** — check what you've spent, by app or project, and watch budgets - **Apps** — deploy from GitHub, add a database or custom domain, set environment variables, read build and runtime logs, roll back - **Projects and teams** — organise apps into projects and manage who can access them - **Webhooks and scheduled jobs** — set up and test integrations ### How it works Sign in with your Roar AI account the first time you connect — there's no API key to copy. Every action goes through the same permission checks as the Roar console, so your assistant can never do more than you can. ### Try asking - "What did we spend on AI this month, and which app spent the most?" - "Why did the last deploy of the support bot fail? Show me the build log." - "Create an API key for our reporting script that can only read usage, and make it expire in 60 days." ### Requirements A Roar AI Cloud account that belongs to an organisation. [Get started](https://roar-ai.com) [Documentation](https://roar-ai.com/docs/mcp?utm_source=smithery) · [Privacy](https://roar-ai.com/privacy)

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://roar-ai--cloud-1o14.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "Roar AI": {
      "url": "https://roar-ai--cloud-1o14.run.tools"
    }
  }
}

能力清单

工具	说明
whoami	Identify this connection: the organisation, the acting key or person and their role, the scopes granted, the scopes NOT granted, and the projects reachable with the role held in each. Tool visibility reflects scopes only, while calls are also gated per project, so this is the only place per-project access is visible.
list_organizations	The organisations this person belongs to, and which one this connection is currently acting in, with the ids set_default_organization accepts. An API key always acts in the organisation it was minted in and returns an empty list.
set_default_organization	Set which organisation this connection acts in, from now on and across future sessions. The choice is the person’s; it takes an organizationId from list_organizations. Refuses an organisation the caller does not belong to, one that is not active, and any API key (a key is bound to the organisation it was minted in).
list_models	List the models this account can call, with modalities, capabilities and published rates. Use a returned model `id` as the `model` field when calling the OpenAI-compatible API.
list_keys	List this account's API keys (prefix, scopes, project, budget, recent usage). Never returns key plaintext.
create_key	Mint a new roar_live_ API key. The plaintext is returned ONCE — store it immediately. Any MANAGEMENT scope you grant must be one your own key already holds; `inference` may always be granted.
revoke_key	Stop an API key working, immediately and permanently. The key stays listed as revoked so it is clear what was withdrawn. Refused for a key one of your hosted apps runs on — the error names the app. Use this to clean up a key you created by mistake; a revoked key cannot be resumed.
update_key	Rename a key, change what it may do, or pause and resume it. Scopes you set must be ones your own key already holds. Spend caps and expiry are not settable here — those are set by a person in the console. A REVOKED key cannot be changed; mint a new one.
get_key	Everything about one key: its label, project, scopes, spend cap, status and recent usage. The plaintext is never returned — it is shown once at creation and never again.
check_usage	Token counts, request volume, latency, and cost over a window. Optional ISO `from`/`to` and `projectId` filters.
list_requests	Individual model calls through the gateway, newest first: model, endpoint, HTTP status, error code, tokens, cost and latency (tool gateway calls are list_tool_calls). Use `band: 'errors'` to see only failures. This is how you get from 'something is failing' to WHICH call failed — it returns each call's requestId, which get_request takes. It does NOT return prompts or responses.
check_tool_usage	Calls your agents made through the tool gateway over a window: per tool, failures by error code, what the guardrail masked or stopped, latency, and which key calls which tool. Tool calls are free and are NOT in check_usage. Optional ISO `from`/`to` and `keyId`.
list_tool_calls	Individual tool gateway calls, newest first: tool, key, status, latency, guardrail outcome and error code. Use `band: 'errors'` for failures (a `tool_error` is an HTTP 200 and still counts). It never returns a call's arguments or result — they are not stored.
get_request	The full stored prompt and response for ONE gateway call, plus its model, endpoint and status. Get the requestId from list_requests. This reads what was actually typed, so it needs a separate permission you will be asked to approve. It returns nothing if request logging is off for the account or the retention window has passed — that is not an error, and it is the commonest reason for an empty answer.
check_budget	Real-time spend vs. cap for every budgeted scope (key / project / client), each with state (ok / alerting / exceeded).
list_apps	List the hosted apps for this account, each with its live URL and status.
deploy_app	Deploy an internal app from a git repo. Returns immediately while it provisions; poll get_deploy_status for progress and the live URL.
redeploy_app	Rebuild and redeploy an app from its current branch — the same action as pressing Redeploy in the console. Use this to retry a failed deploy, or to apply a change made outside a git push. Returns immediately; poll get_deploy_status for progress. If the app has database migrations enabled they run as part of this.
list_deploys	Every deploy of an app, newest first: its id, status, commit, when it ran and why it failed. Use it to find the deploymentId for rollback_app, or to see whether the deploy you started has finished.
rollback_app	Put an app back on an earlier deploy — for a GitHub app this rebuilds that exact commit. Get the deploymentId from list_deploys. This is how you undo a bad deploy; it starts a new deploy, so poll get_deploy_status. Rolling back does NOT revert your repository: the next push deploys the new code again.
cancel_deploy	Cancel a deploy that is still queued for this app. A build already running is not stopped; rollback_app reverts it once it finishes.
stop_app	Take an app offline. Its address stops answering and it stops using resources; nothing is deleted and start_app brings it back. Use this to park an app, not to fix one — a crashed container already restarts on its own.
start_app	Bring a stopped app back online with the build it already had. The counterpart to stop_app.
fix_failed_deploy	USES THE CUSTOMER'S AI CREDITS. Asks the platform's own model to diagnose a failed build, write a fix into the repository, and redeploy. Applies only to a deploy that FAILED; the failure is described by get_build_logs, and repeating the call on the same failure spends credits again without new information. Returns {ok:false} when it has nothing to offer, which is not an error.
run_app_migrations	Apply this app's pending database migrations WITHOUT rebuilding or redeploying it — the same step a deploy runs, on its own. Covers the case where Database updates was turned on after deploying, and retrying a migration after fixing what made it fail, without shipping a code change. Returns immediately; the app keeps serving throughout and nothing is switched. Refuses when the app has no migration step or Database updates is off.
list_env_vars	List the NAMES of an app's environment variables. Values are never returned by this tool — someone with access can read them in the console. Use it to check whether a variable is already set before writing one.
set_env_vars	Set one or more of an app's environment variables. MERGES with what is already there — variables you do not name are left untouched. Names the platform reserves are refused, and so is a DATABASE_URL the project is not allowed to override. The app is redeployed where the platform does that automatically; otherwise redeploy_app applies the new values.
delete_env_var	Remove ONE environment variable from an app. Names the platform reserves are refused. The app is redeployed where the platform does that automatically; if the app still sees the old value, call redeploy_app.
get_deploy_status	Build/deploy progress and URL for an app you deployed. `phase` is how the last DEPLOY went; `runState` is whether the app is running right now — a paused app reports phase "live" and runState "paused", and its URL will not answer until it is started.
get_build_settings	What the platform DECIDED about this app's repo: the framework it detected, the build mode, the root directory, the migrate command, and whether it is using the repo's own Dockerfile. Read this BEFORE debugging a build — a repo detected as the wrong framework produces symptoms that look like application bugs, and no amount of log-reading finds it.
get_app_logs	The most recently collected tail of an app's own output. `collectedAt` says WHEN it was captured; refresh_app_logs collects a newer tail. `source` says whether these are the app's own lines or the build fallback, and `withheld` how many lines were filtered out.
refresh_app_logs	Ask the node running this app for a fresh tail of its output, then call get_app_logs to read it. Use this when get_app_logs returns a collectedAt older than what you are investigating. Returns only an acknowledgement — the lines come from get_app_logs.
get_build_logs	The build output for one deploy of an app — what the builder printed while installing, compiling and packaging. Defaults to the most recent deploy, which is the one you just watched fail. Pass deploymentId to read an earlier one. If the build itself succeeded and the app is still wrong, read get_app_logs and get_build_settings instead.
query_app_database	Run ONE read-only SQL statement against a hosted app's own PostgreSQL database, in the PostgreSQL SQL dialect (https://www.postgresql.org/docs/current/sql.html). Writes are refused by the database itself. Returns immediately with a runId; the rows are fetched with get_query_result. Table and column names come from get_app_database_schema, because the app's schema is its own, not ours.
get_query_result	The rows a query returned, by runId. Results are bounded and expire — a run that has aged out keeps its SQL and its counts but not its rows. `truncated` means you are not seeing everything.
get_app_database_schema	The tables, columns and types in a hosted app's own database, from the last reading we hold. Call this BEFORE writing SQL for query_app_database. Returns null when no reading is held yet — that means 'ask for one' (refresh_app_database_schema), not 'this database is empty'. `truncated` means there are more tables than listed.
refresh_app_database_schema	Take a FRESH reading of a hosted app's tables and columns. Returns immediately with a runId; poll get_query_result for it, then call get_app_database_schema. Only needed when no reading is held or the app's schema has changed since — a stored reading is free and this is not.
create_project	Create a project to group keys and apps under a shared budget.
get_app_usage	What ONE hosted app has cost, per service — compute, bandwidth and the hosting fee over a window. This is the per-app answer; check_usage is the whole account. Use it to tell someone whether the app you deployed is expensive.
get_app_analytics	Views, visitors, requests and errors for one hosted app over the last N days, with a daily series. Use it to answer 'is anyone using this?' — it counts visits to the app itself, not gateway calls.
list_app_requests	Individual HTTP requests to a hosted app, newest first: path, status, duration and the request id. Use `band: 'errors'` to see only failures. This is how you get from 'the app is erroring' to WHICH request erred.
list_app_domains	Every domain attached to an app: the address, whether it is a Roar subdomain or the customer's own, its status, and — for a custom domain — the DNS target to point at. Use it before adding one, and to check whether one you added has gone live.
add_app_domain	Attach a domain the customer owns to an app. THIS DOES NOT MAKE IT LIVE: it returns the DNS records they must create at their registrar, and the domain stays pending until those records resolve and a certificate is issued. Tell them the records, then use list_app_domains to check whether it has gone live. For a free address on our own domain, use add_roar_domain instead.
check_app_domain	Ask DNS where a custom domain currently points, and get back the records the customer still needs to create. Use it after add_app_domain to tell them whether their change has taken effect: 'pointed' means done (a certificate follows on its own), 'missing' means the record is not published yet, 'elsewhere' means a record exists but sends traffic somewhere else — report what it found. 'unknown' means WE could not check, not that anything is wrong. Get the domainId from list_app_domains.
add_roar_domain	Give an app a free address on our own domain, derived from the app's name. Nothing for the customer to configure — no DNS, no certificate, it works immediately. The name cannot be chosen; use add_app_domain if they need a specific one.
remove_app_domain	Remove a domain from an app. The address stops serving. Get the domainId from list_app_domains — it is the `id`, not the domain name. This does not touch the customer's DNS records; they should remove those too.
set_primary_domain	For a custom apex domain, choose whether the bare name or its www is the primary address — the one to give people, and the one the DNS instructions lead with. Both keep serving either way, and you can change it back. Pass the exact hostname you want as `primary`. Refused for a Roar address or a plain subdomain, which have no second name to choose between.
get_app_database	Whether this app has a managed database and what state it is in: none, creating, ready, or error. Also reports `selfManaged` when the customer set their own DATABASE_URL instead. Read this before add_app_database, and poll it after — provisioning is not instant. The connection string is never returned.
add_app_database	Provision a managed PostgreSQL database for an app. THIS RETURNS BEFORE THE DATABASE EXISTS: the work is queued, and the app's DATABASE_URL is injected when provisioning completes. The database does not exist until get_app_database reports status `ready` (poll get_app_database for it), and the app needs a redeploy afterwards to pick up the connection. There is no tool to remove a database; removal is a console action because it destroys data.
list_jobs	Every scheduled job on an app: its id, name, the path it calls, its cron schedule, whether it is enabled, and how the last run went. Use it to find the jobId for the other job tools, or to answer why something that runs on a timer did not happen.
create_job	Add a scheduled job: we call a path on the app on a cron schedule. `path` is a route on the app itself, e.g. `/api/cron/nightly-report`. `schedule` is standard 5-field cron in UTC, e.g. `0 3 * * *` for 03:00 daily. The app must check the `x-roar-cron-secret` header on that route - the secret is in the app's environment as ROAR_CRON_SECRET and is shown in the console, not here.
update_job	Change a scheduled job, or disable it without deleting it. Send only the fields you are changing - `enabled: false` pauses a job whose target is broken, and everything else stays as it was. Get the jobId from list_jobs.
delete_job	Remove a scheduled job and its run history. To stop a job temporarily, use update_job with `enabled: false` instead - this cannot be undone.
run_job	Run a scheduled job immediately, without waiting for its next scheduled time. This is how you test a job you just created or fixed. It returns the run, including the HTTP status the app answered with - read that rather than assuming success, since a job that returns 500 has still 'run'.
list_job_runs	Recent runs of one scheduled job, newest first: when it ran, how long it took, the HTTP status the app returned, and the error if it failed. This is the tool that answers 'why didn't my nightly report go out?'.
list_projects	The projects in this account: name, status, budget and how much of it is spent, and how many keys and apps each holds. Use it to find the projectId for create_key or deploy_app.
get_project	One project in full: its budget and spend, and the keys, apps and members filed under it.
list_webhooks	List the outbound webhooks registered for this account (url, subscribed events, status).
create_webhook	Register a webhook to be notified of platform events (deploy.succeeded/failed, budget.alerting/exceeded). Returns a signing secret ONCE — store it to verify the HMAC signature on delivery.
get_overview	The state of the account in one call: spend and request totals over the window, spend by model, every budget and how close it is, and how many apps and keys exist. Defaults to the last 30 days. Start here before reaching for check_usage or check_budget separately.
get_usage_series	Usage bucketed by hour, day or week — requests, tokens and cost per bucket, and the same split by model. Use it to see a trend or find WHEN spend changed; check_usage gives the totals.
update_project	Rename a project, archive or reactivate it, or change its spend cap. Fields you omit are left as they are.
delete_project	Remove a project for good. Keys and apps filed under it are NOT deleted — they become ungrouped, so move them first if grouping matters. To hide a project without losing anything, archive it with update_project instead.
list_project_members	Who can reach a project and with which role (viewer, developer, manager). Members are existing colleagues; inviting a new person to the company is done by a person in the console.
add_project_member	Give an existing colleague access to a project. Role defaults to viewer, the least that can be granted. The userId comes from list_project_members on another project or from get_project.
set_project_member_role	Change what an existing member may do in a project: viewer, developer or manager.
remove_project_member	Take a colleague’s access to a project away. They stay in the company; only this project’s access goes.
delete_app	Take an app down and remove it, including its deployments and its database if it has one. Irreversible. You must pass the app’s exact name as well as its id; the call is refused if they do not match. Prefer stop_app if you only want it to stop serving.
move_app_to_project	File an app under a different project, or under none (projectId null). Its spend counts against the new project from now on. Needs deploy rights in both places.
deploy_app_from_github	Deploy an app from a repository the connected GitHub installation can reach, choosing which region it runs in and whether it gets a database. Requires GitHub to be connected — check with get_github_status. Use list_app_regions for the region codes, and pass withDatabase there if this app will have one. Returns immediately while it provisions; poll get_deploy_status. When you do not need a region or a database, deploy_app is the simpler call.
set_deploy_on_push	Whether a push to the app’s branch deploys it automatically. Off means only redeploy_app or the console deploys it.
set_app_branch	Point the app at another branch of its repository. Refused unless the branch exists. Deploys nothing: the next push to that branch ships it, or call redeploy_app to ship its head now. analyze_github_repo with detail=branches lists the choices.
set_migrations_on_deploy	Whether the app’s database migrations run as part of each deploy. Turn it off for an app that manages its own schema; run_app_migrations still works on demand.
get_pending_migration	What run_app_migrations would execute for this app right now, and whether it can: the command, and the reason if it cannot (no database, migrations disabled, framework not recognised). Call it before run_app_migrations.
list_app_regions	The regions an app can be placed in, as codes for deploy_app’s `region`. Ask with withDatabase when the app will have a database — a region may host apps but not databases.
get_github_status	Whether this workspace has a GitHub installation connected, which is what deploy_app needs. Connecting one is done by an owner in the console — there is no tool for it, because it is a browser sign-in flow.
list_github_repos	The GitHub repositories the connected installation can deploy from. Use a returned full name as deploy_app’s `repo`.
analyze_github_repo	What we make of a repository before deploying: `roots` lists the directories that could each be an app (monorepos), `framework` is what the builder detects and the commands it would run, `insight` is a plain-language read of what the app is and what it needs, `branches` lists its branches with the default first. Call with framework before deploy_app on an unfamiliar repo.
update_webhook	Change a webhook’s URL, the events it receives, its description, or pause and resume it with `enabled`. Fields you omit are left as they are. The signing secret does not change.
delete_webhook	Remove a webhook and stop all delivery to it. To pause instead, use update_webhook with enabled false.
test_webhook	Deliver a `ping` event to a webhook now, signed like a real one. Returns the delivery id; read the outcome with list_webhook_deliveries.
list_webhook_deliveries	The recent delivery attempts for a webhook: event, status, attempts, the response code your endpoint gave, and the error if it failed. This is how to find out why a webhook is not arriving.

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。