Skip to main content
Glama
vivek5200

astrix

by vivek5200
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Run Impacted Go Tests

astrix_run_impacted_tests
Destructive

Recompute the Git diff blast radius and run the impacted Go test packages to verify changed code.

Instructions

Recompute the blast radius from the current staged and unstaged Git diff against HEAD in the opened repository, then execute the selected Go test packages (or the full Go suite if no test symbols map to packages). Use this to verify changed code after reviewing impact with astrix_get_blast_radius; it recomputes from the workspace and does not reuse a prior tool call's state. Test code runs locally with the current process permissions and may access the network or create or modify files. Returns selected test symbols on success; test failures are returned as tool errors. It accepts no arguments.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
testsYesTest symbols selected and executed from the current diff's blast radius.
passedYesTrue when all selected test packages pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.3
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "passed": {
+      "description": "True when all selected test packages pass.",
+      "type": "boolean"
+    },
+    "tests": {
+      "description": "Test symbols selected and executed from the current diff's blast radius.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "tests",
+    "passed"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations flag destructive/openWorld/non-idempotent, and the description goes beyond them by disclosing that test code runs locally with the current process permissions and may access the network or create/modify files. It also states success returns selected test symbols and that test failures surface as tool errors, which is not derivable from the annotations.

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

Conciseness5/5

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

Three sentences, front-loaded with the core action, followed by routing guidance, then safety and return semantics. No filler and nothing a caller must infer.

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?

Covers the recompute-from-workspace behavior, the fallback to the full Go suite when no symbols map, the zero-argument contract, permission/network/file side effects, and error semantics. With an output schema present, return-value detail is already handled, so nothing material is missing.

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 takes zero parameters, which sets the baseline at 4. The description reinforces this with 'It accepts no arguments,' matching the empty schema, but there is no additional parameter-level meaning to convey.

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?

States a specific verb chain ('recompute the blast radius ... then execute the selected Go test packages') with a named resource and diff scope (staged/unstaged against HEAD). It also names the sibling it complements, so an agent can separate it from astrix_get_blast_radius without reading either schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('verify changed code after reviewing impact with astrix_get_blast_radius') and adds a critical exclusion: it recomputes from the workspace and does not reuse a prior tool call's state. That tells the agent this is not a cheap follow-up to a previous blast-radius call.

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

Deploy Server

Other Tools