Skip to main content
Glama
julianbei

ARNO

by julianbei
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

arno.run_command

Destructive

Run a repository-declared command by name and wait for its pass/fail verdict with decisive output. Omit the name to list declared commands.

Instructions

Run a command the repository declares, by name, and wait for the verdict: pass/fail with the decisive output. Use it instead of a shell for anything check does not cover. No name lists the declared commands. Nothing fits? declare_command it once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDeclared command to run. Omit to list the declared commands.
rootNoWorktree for this call. Default: the one set with workspace, else the start tree.
waitNoWait for the result (default true). False returns a job ID to poll.
timeoutSecondsNoBound on the wait (default 90, max 300).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.17
    • changedInput schema / properties / root / description
      Previous value: -"Worktree of this repository to act in. Defaults to the session's workspace."New value: +"Worktree for this call. Default: the one set with workspace, else the start tree."
  2. Changed1 schema field changedv0.0.15
    • addedInput schema / properties / root
      Added value: +{
+  "description": "Worktree of this repository to act in. Defaults to the session's workspace.",
+  "type": "string"
+}
  3. Addedv0.0.12

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, so the safety profile is carried by structured data. The description adds the pass/fail verdict framing and the wait-for-result behavior, but never elaborates that executing a repo-declared command can mutate state or what auth/working-tree requirements apply, which is what the destructive hint warrants.

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 and compact, and each sentence carries a distinct instruction. The telegraphic fragments ('Nothing fits? declare_command it once') verge on cryptic, costing some clarity for brevity.

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

Completeness4/5

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

For a mutation-capable command runner with no output schema, the description conveys the result shape (pass/fail plus decisive output) and the listing fallback. The destructive/mutating nature implied by annotations is not spelled out, leaving a small gap.

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 description coverage is 100%, so all four parameters are already documented (name, root, wait, timeoutSeconds). The description only reinforces 'no name lists the declared commands', which the schema already states; it adds no syntax or format detail beyond the schema.

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 (run) and resource (a declared repository command) with the outcome (pass/fail verdict plus decisive output). It actively distinguishes itself from siblings by naming 'check' and 'declare_command', so an agent can route correctly without opening a sibling 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?

Explicit routing: use this instead of a shell for what 'check' does not cover, omit 'name' to list declared commands, and fall back to 'declare_command' when nothing fits. When-to-use, when-to-list, and the alternative path are all named.

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