Neumann

Check your account, credits and free runs left

check_account_and_credits

Read-onlyIdempotent

Shows who Neumann thinks you are and what you can still do: your credit balance if you have an account, or your free runs left today and when they reset if you do not. Use this when you need to know, before or after a run, whether a call will use credits or a free run, how much is left, or whether you are signed in. A bearer credential that is not recognized returns an unauthorized error. It returns whether you are anonymous or an account, your account id and status, credit balance, free runs left today with the reset time and the no-account size limits, the price of one credit in US dollars, and your last 10 credit transactions. To get an account and API key, call POST https://neumann.kromatic.com/api/v1/accounts; setup docs are at https://kromatic.com/mcp/neumann. Cost: free; uses no credits and no free runs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_account_and_credits"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`billing`	No	Who you are and what this call cost: principal, auth source, credits debited and balance, or the anonymous allowance left today.
`recent_ledger`	No	Your last 10 credit transactions, newest first. Null without an account.
`price_per_credit_usd`	Yes	Current price of one credit in US dollars.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

removedInput schema / properties / api_key

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Your Neumann API key. Optional. Leave it out to ask about your current connection, signed in or not. Get one by creating an account (POST https://neumann.kromatic.com/api/v1/accounts, which returns the key once); setup docs: https://kromatic.com/mcp/neumann.",
-  "title": "Api Key"
-}

changedOutput schema / $defs / BillingInfo / properties / auth_source / description

Previous value: -"How you were identified: bearer (a signed-in connection token), api_key (the api_key argument) or anonymous."New value: +"How you were identified: bearer (a credential sent in the Authorization: Bearer header) or anonymous."

changedOutput schema / $defs / BillingInfo / properties / auth_source / enum

Previous value: -[
-  "bearer",
-  "api_key",
-  "anonymous"
-]New value: +[
+  "bearer",
+  "anonymous"
+]

changedOutput schema / $defs / BillingInfo / properties / charged_to / enum

Previous value: -[
-  "anonymous_allowance",
-  "credits",
-  "none"
-]New value: +[
+  "anonymous_allowance",
+  "free_daily_run",
+  "credits",
+  "none"
+]

addedOutput schema / $defs / BillingInfo / properties / free_run_limits

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/SignedInLimits"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The free signed-in tier's bounds. Null unless the account signed in with Kromatic."
+}

addedOutput schema / $defs / BillingInfo / properties / free_runs_remaining_today

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Free signed-in runs left in the current UTC day, counting this call. Null unless the account signed in with Kromatic.",
+  "title": "Free Runs Remaining Today"
+}

addedOutput schema / $defs / BillingInfo / properties / free_runs_reset_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "ISO-8601 instant the free signed-in runs next refill (the next UTC midnight). Null unless the account signed in with Kromatic.",
+  "title": "Free Runs Reset At"
+}

addedOutput schema / $defs / SignedInLimits

Added value: +{
+  "description": "The free signed-in tier's bounds (neumann#334), rendered from ``Settings``.",
+  "properties": {
+    "max_nodes": {
+      "description": "Maximum nodes in a free run's graph.",
+      "title": "Max Nodes",
+      "type": "integer"
+    },
+    "max_trials": {
+      "description": "Maximum trials in a free run.",
+      "title": "Max Trials",
+      "type": "integer"
+    },
+    "runs_per_day": {
+      "description": "Free runs per UTC calendar day.",
+      "title": "Runs Per Day",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "runs_per_day",
+    "max_trials",
+    "max_nodes"
+  ],
+  "title": "SignedInLimits",
+  "type": "object"
+}

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, non-destructive, idempotent, and closed-world behavior, and the description adds meaningful context beyond that: unrecognized bearer credentials return an unauthorized error, the response includes account identity and status, credit balance, free-run limits, reset time, credit price, and the last 10 transactions. It also discloses that the operation is free and uses no credits or free runs, which is important behavioral context for an agent deciding whether to call it.

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

Conciseness4/5

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

The description is front-loaded with purpose and usage, followed by error behavior, return contents, account setup, and cost. It is longer than a minimal definition, but nearly every sentence adds useful operational context; the account-creation endpoint and docs link are slightly ancillary but still helpful.

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

Completeness5/5

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

Given a zero-parameter, read-only status tool with an output schema, the description is complete: it covers purpose, when to call it, auth failure behavior, returned information, cost, and how to obtain an account. An agent has everything needed to decide whether and how to invoke it.

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?

The tool has zero input parameters, so there are no parameter semantics to explain and the baseline is 4. The description appropriately spends no words on nonexistent parameters.

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

Purpose5/5

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

The description uses a specific verb and resource: it 'Shows who Neumann thinks you are and what you can still do', then names credit balance, free runs left, reset timing, and sign-in state. It clearly separates the account case from the anonymous case, so an agent can understand what the tool is for without opening the schema.

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

Usage Guidelines4/5

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

It gives clear usage context: 'Use this when you need to know, before or after a run, whether a call will use credits or a free run, how much is left, or whether you are signed in.' It also states the call is free and consumes no credits or free runs. However, it does not explicitly compare against sibling tools such as buy_credits or estimate_simulation_size_and_cost, so the alternative-selection guidance is implied rather than fully explicit.

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

All Neumann tools Inspect

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

Need Help?