rush

by jamesdsizemore

Overview Schema Source Related Servers Discussions Admin

Python

Local

rush_fuzz

Import local fuzz reports or run fuzz tests to detect bugs and crashes.

Instructions

Import a local fuzz report or execute local fuzz tests under --allow-slow.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes
`seed`	No
`corpus`	No
`harness`	No
`options`	Yes
`max_runs`	No
`allow_slow`	No
`allow_build`	No
`report_path`	No
`allow_browser`	No
`allow_network`	No
`allow_download`	No
`timeout_seconds`	No
`allow_cache_write`	No
`allow_artifact_write`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`raw`	No
`tool`	No
`engine`	No
`status`	No
`metrics`	No
`summary`	No
`findings`	No
`metadata`	No
`artifacts`	No
`duration_ms`	No
`review_kind`	No
`engine_version`	No
`review_provider`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.2.2Sep 15, 2026

addedInput schema / properties / corpus

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Corpus"
+}

addedInput schema / properties / harness

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Harness"
+}

addedInput schema / properties / max_runs

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Runs"
+}

addedInput schema / properties / seed

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Seed"
+}

addedInput schema / properties / timeout_seconds

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Timeout Seconds"
+}

changedOutput schema / properties / metrics / anyOf

Previous value: -[
-  {
-    "additionalProperties": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "number"
-        },
-        {
-          "type": "string"
-        }
-      ]
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv0.3.0Aug 30, 2026

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses only that fuzz tests are slow enough to require --allow-slow; it does not mention build requirements, network/browser/download side effects (despite six allow_* flags in the schema), or what importing a report entails.

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?

One sentence with zero filler, and the two primary operations are front-loaded. It is appropriately compact for what it conveys, though the brevity borders on under-specification rather than pure efficiency.

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

Completeness2/5

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

For a complex 15-parameter tool with two distinct modes and no annotations, this description is incomplete. The output schema reduces the burden of explaining return values, but significant gaps remain: which parameters apply to import versus execution, what each allow_* flag gates, and whether import is a prerequisite for running tests.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for 15 undocumented parameters. It adds meaning only to allow_slow and vaguely frames path within the two modes; the remaining 13 parameters (seed, corpus, harness, max_runs, timeout_seconds, and the permission flags) receive no explanation.

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?

The description names two concrete operations with a specific resource: 'Import a local fuzz report' and 'execute local fuzz tests.' This is more specific than average and conveys the dual-mode nature of the tool, even though it does not explicitly differentiate it from siblings like rush_test, rush_pbt, or rush_mutation.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives such as rush_pbt or rush_test, and no exclusions are stated. The only usage signal is 'under --allow-slow,' which hints that execution requires that flag, but this is weak and implicit rather than explicit guidance.

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

Deploy Server