Skip to main content
Glama
Secret-art-stack

spillway-mcp

by Secret-art-stack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

local_exec_and_triage

Read-only

Execute allow-listed test, build, typecheck, or lint commands and scrub verbose output into a concise digest of exit codes, failing tests, file locations, and stack traces.

Instructions

Execute allow-listed test, build, typecheck, or lint commands (pytest, npm test, npx tsc, cargo check, go test) in a managed subprocess with Windows process-tree kill protection (taskkill /T /F) and scrub verbose output on the Local GPU (0x cloud quota). WHEN TO USE: Running any test suite, compiler check, or linter that may produce >40 lines of noisy output. DO NOT USE FOR: Chained shell commands (&&, ;, | are blocked) or file edits. RETURNS: Full output directly if <=40 lines; otherwise a Local GPU-scrubbed digest containing only exit code, failing test names, <file>:<line> locations, and isolated stack traces.

Input Schema

NameRequiredDescriptionDefault
commandYesSingle allow-listed test/build/lint command line without chaining operators (e.g. "pytest", "npm test", "npx tsc --noEmit", "cargo check").
timeout_msNoOptional subprocess timeout in milliseconds (default 120000).
working_dirYesWorking directory path for command execution.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / command / description
      Previous value: -"Command line to execute (e.g. \"pytest\", \"npm test\", \"npx tsc --noEmit\", \"cargo check\")."New value: +"Single allow-listed test/build/lint command line without chaining operators (e.g. \"pytest\", \"npm test\", \"npx tsc --noEmit\", \"cargo check\")."
    • addedInput schema / properties / command / minLength
      Added value: +1
    • addedInput schema / properties / timeout_ms / default
      Added value: +120000
    • addedInput schema / properties / timeout_ms / maximum
      Added value: +600000
    • addedInput schema / properties / timeout_ms / minimum
      Added value: +500
    • changedInput schema / properties / working_dir / description
      Previous value: -"Working directory for command execution (defaults to workspace root)."New value: +"Working directory path for command execution."
    • addedInput schema / properties / working_dir / minLength
      Added value: +1
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Goes well past the annotations by disclosing process-tree kill protection via `taskkill /T /F`, the 40-line output threshold, and what the scrubbed digest actually contains (exit code, failing test names, file:line, isolated stack traces). It does not contradict readOnlyHint/destructiveHint=false, since running tests and linters is a non-mutating read of the codebase. Minor gap: no note on whether the subprocess inherits env or has network access, which matters given openWorldHint=false.

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?

Front-loaded with the action and the concrete command set, then cleanly segmented into WHEN TO USE, DO NOT USE FOR, and RETURNS. Dense but every clause carries operational information; there is no filler.

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?

With no output schema, the RETURNS section is essential and present, explaining both the pass-through case and the digest format. Combined with the safety mechanism and the exclusion list, an agent has everything needed to call this correctly against a 3-parameter, non-idempotent execution tool.

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

Parameters3/5

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

Schema coverage is 100%, so command, timeout_ms, and working_dir are already documented in structured fields. The description reinforces the allow-list and no-chaining rule for `command`, but adds no syntax or format detail the schema lacks, and says nothing about timeout semantics beyond the schema's default/max. Baseline 3 applies.

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 (execute) plus the exact resource class (allow-listed test/build/typecheck/lint commands) and enumerates concrete examples (pytest, npm test, npx tsc, cargo check, go test). Nothing overlaps with siblings like local_file_scout or local_draft_leaf_code, so an agent can route on the first clause alone.

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?

Has an explicit WHEN TO USE clause (>40 lines of noisy output from tests/compilers/linters) and an explicit DO NOT USE FOR clause (chained shell operators, file edits). Both the selection condition and the exclusion are spelled out rather than inferred.

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