Skip to main content
Glama
Sign In

Runtime Cloud

by com.withruntime
OverviewDiscussionsAdmin

runtime_account

Read-only

Read the account. Money is integer microdollars (1,000,000 = $1). get: Who you are (organization, agent, credential) and the account's usage: balance, open holds, free usage left and per-resource charges. limits: Whether this key is read-only; the daily spending limit an owner set on your agent (the limit, what you committed in the last 24 hours and what is left; owners set it at https://withruntime.com/account/keys); and the machine time the account can still run without credit, in milliseconds (free hours given before 5 October 2026: total, used, reserved; available, which counts this month's free usage too), or null with none; and every limit the account is held to with what it uses of each (sandbox.count, sandbox.vcpu, sandbox.memory_mib and the rest), the numbers a create past one is refused quota_exceeded by; and the account's credit: what is left, the days it lasts at this month's pace (state low under 5, empty at none), and who adds more (addedBy agent: no person pays for this account, so add credit yourself with npx withruntime billing topup <usd>). referrals: The referral link, the companies that signed up with it and the credit each earned. compare(provider, days?): What this key's sandboxes would have cost at a rival (e2b, daytona, vercel, modal, cloudflare, fly-sprites, fly-machines, blaxel, codesandbox, morph, northflank, runloop, lambda-microvms, freestyle, prime, fly for Sprites): the account's settled usage over the last days (default 30), priced at Runtime's rates (what free usage paid for at the standard rates) and at the rival's published list rates, with the date they were checked. Returns the saving, a 30-day projection, a note on what was left out, the switch on record and the welcome match's state; with no usage yet, a stated example workload is priced. sso: Identity providers (OIDC or SAML), the email domains they answer for and whether each is proven, the role new people join with, whether SSO is required, and SCIM sync. Needs an owner or admin key; changed on the website. emails: Which of Runtime's optional emails your person gets for this account (own-deletions, billing, usage, tips). Read only: change them with POST /v1/account/emails:update, runtime account emails, or Settings, Emails.

Input Schema

NameRequiredDescriptionDefault
daysNo
actionYes
providerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "get",
-  "limits",
-  "referrals",
-  "compare",
-  "sso"
-]New value: +[
+  "get",
+  "limits",
+  "referrals",
+  "compare",
+  "sso",
+  "emails"
+]
  2. Changed3 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "get",
-  "limits",
-  "referrals",
-  "sso"
-]New value: +[
+  "get",
+  "limits",
+  "referrals",
+  "compare",
+  "sso"
+]
    • addedInput schema / properties / days
      Added value: +{
+  "maximum": 90,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / provider
      Added value: +{
+  "enum": [
+    "e2b",
+    "daytona",
+    "vercel",
+    "modal",
+    "cloudflare",
+    "fly-sprites",
+    "fly-machines",
+    "blaxel",
+    "codesandbox",
+    "morph",
+    "northflank",
+    "runloop",
+    "lambda-microvms",
+    "freestyle",
+    "prime",
+    "fly"
+  ],
+  "type": "string"
+}
  3. Added

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds real behavioral context: sso requires an owner or admin key and is changed on the website, emails is explicitly read-only with where to mutate it, and the credit paragraph explains addedBy agent and the topup command. This is useful context beyond the safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a short "Read the account", but each action then becomes a dense run-on with nested parentheticals, URLs and asides (e.g. the credit/topup clause inside limits). Most content does earn its place given there is no output schema, but the wall-of-text structure makes it hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description rightly describes what each action returns (balance, holds, free usage, quota_exceeded limits, referral credit, cost comparison, SSO state, email flags). Coverage is strong for all six actions, with only minor gaps like pagination and general error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage the description must carry the params, and it does: each action enum value is defined in prose, compare documents its provider and days arguments, and it states the days default (30) which the schema does not. The provider list is largely mirrored from the schema rather than adding meaning, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("Read the account") and then enumerates each of the six actions with what it returns, so an agent knows exactly what is on offer. It is distinguishable from sandbox/volume siblings by being the account-wide introspection tool, though it never explicitly names a sibling to contrast with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the per-action breakdown and a few conditional hints ("with no usage yet, a stated example workload is priced", "Needs an owner or admin key" for sso). The only alternative routing is for emails, where it points at POST /v1/account/emails:update and the Settings UI; there is no general when-to-use/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Runtime Cloud toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources