Runzumi

Get CI duration and queue statistics

get_run_statistics

Read-onlyIdempotent

Use this to get job duration, queue time, success rate and cost for a Runzumi workspace and time range. Omit repositoryId for complete totals across all authorized repositories; provide it only to narrow the scope. Do not enumerate repositories to calculate workspace totals. durationSum and queueSum are in seconds. Divide them by durationCount and queueCount to get averages. costUnits: 3000000 units = 1 USD. costCount is the number of attempts with a cost. If costUnits is missing, cost data is not available. Filters use the GitHub status. start, end and job timestamps are in epoch milliseconds. Omit revision to get current data. A null result for a revision means that the data changed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceId": "<workspaceId>",
      "start": "<start>",
      "end": "<end>"
    },
    "name": "get_run_statistics"
  }
}

Input Schema

Name	Required	Description	Default
`end`	Yes	End of the time range in Unix epoch milliseconds. It must not be before start. Ranges are limited to 366 days.
`start`	Yes	Start of the time range in Unix epoch milliseconds. Example: 1790812800000.
`status`	No	Job status filter. Use all for general performance. Use failure for failed attempts.	all
`revision`	No	Statistics revision from a previous result. Omit it to get current data.
`workspaceId`	Yes	Runzumi workspace ID from list_workspaces.
`repositoryId`	No	Omit for all repositories you can access in the workspace; supply an ID to narrow to one repository.

Output Schema

Name	Required	Description	Default
`data`	Yes
`demo`	No
`appUrl`	Yes
`observedAt`	Yes
`completeness`	Yes
`compatibility`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedOutput schema / properties / compatibility / oneOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "contractVersion": {
-        "const": "legacy",
-        "type": "string"
-      },
-      "diagnosticsAvailable": {
-        "const": false,
-        "type": "boolean"
-      }
-    },
-    "required": [
-      "contractVersion",
-      "diagnosticsAvailable"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "contractVersion": {
-        "const": "0.1.4",
-        "type": "string"
-      },
-      "diagnosticsAvailable": {
-        "const": true,
-        "type": "boolean"
-      }
-    },
-    "required": [
-      "contractVersion",
-      "diagnosticsAvailable"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "contractVersion": {
+        "const": "legacy",
+        "type": "string"
+      },
+      "diagnosticsAvailable": {
+        "const": false,
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "contractVersion",
+      "diagnosticsAvailable"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "contractVersion": {
+        "enum": [
+          "0.1.6",
+          "0.1.4"
+        ],
+        "type": "string"
+      },
+      "diagnosticsAvailable": {
+        "const": true,
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "contractVersion",
+      "diagnosticsAvailable"
+    ],
+    "type": "object"
+  }
+]

First observedOct 18, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial operational detail: units for durationSum and queueSum, how to derive averages, the costUnits-to-USD conversion, what costCount means, and that a null result for a supplied revision signals the data changed. That revision-staleness contract is behavior an agent could not infer elsewhere.

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?

Front-loaded with purpose, then units and aggregation rules, then filtering/timestamp notes. Every sentence carries information, but it is an unstructured run-on block of short declarative sentences; grouping the unit rules together would improve scanability.

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?

Complete for a read-only statistics tool: scope, required time range with a 366-day cap, unit conventions, aggregation math, revision semantics, and cost availability are all covered, and a versioned revision parameter makes repeated calls safe.

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?

Schema coverage is 100%, so baseline is 3, and the description earns more by explaining repositoryId omission semantics and revision omission/newer-data behavior. It also clarifies that status filters use GitHub status values, matching the enum. Notable gap: it never explains cost visibility rules tied to authorization, only that missing costUnits means no data.

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?

Names a specific verb and resource plus the exact metrics returned (job duration, queue time, success rate, cost) and the scoping dimensions (workspace, time range). It is clearly distinguishable from list_runs or get_dashboard, though it never explicitly contrasts itself with those siblings.

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?

Gives explicit when/when-not guidance for two key parameters: omit repositoryId for workspace totals, supply it only to narrow scope, and never enumerate repositories to build totals. Also states when to omit revision. It stops short of naming alternative tools for related questions.

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

All Runzumi tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?