Skip to main content
Glama
tomgould

Mullet

by tomgould
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mullet_run

Executes analysis, planning, research, review, and text-generation tasks without writing files, routing each request to a suitable local or cloud provider based on task complexity.

Instructions

For code editing tasks (reading/modifying files), use mullet_opencode instead: it runs the edit as a gated Mullet job and applies the result to the working tree only after the gates pass. Use mullet_run only for: analysis, planning, research, review, or text generation tasks where no files need to be written. Routes to the optimal provider (local GPU or cloud) based on complexity.

Input Schema

NameRequiredDescriptionDefault
taskYesThe task to execute.
tierNoForce routing tier (optional). PREMIUM routes to Opus when budget pressure is low (<0.30), falling back to Sonnet → Haiku → Kimi as pressure rises.
applyNoDeprecated. Always returns an error. Use mullet_opencode for file edits.
filesNoFile paths to include as context for the delegate (ignored — use mullet_opencode for file edits).
clientNoTrove client for project context (optional).
providersNoComma-separated allowlist of providers for this task. Restricts routing to only these providers. Example: 'kimi,haiku,sonnet' excludes local and gemini. Valid: local, kimi, gemini, openrouter, haiku, sonnet, opus-4-8, opus-4-7, opus-4-6
target_dirNoDirectory to resolve file paths against and apply changes to. Defaults to current working directory.
force_singleNoIf true, disable auto-swarm routing and always use a single provider call even when the heuristic would fan out to a swarm. Default: false (auto-swarm fires when signals are detected).
max_iterationsNoMax iterations. Default: 90.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.4.1

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that no files are written and that routing is provider- and complexity-based, but it does not address return behavior, execution time, cost implications, authentication, or whether the call is synchronous. These omissions are significant for a nine-parameter task-execution tool.

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 tight sentences, each earning its place: the first prevents misuse by routing code-editing tasks to mullet_opencode, the second defines the allowed use cases, and the third explains provider routing. It is front-loaded and free of repetition.

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

Completeness3/5

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

The description is strong on usage boundaries and sibling differentiation, which is important given the large sibling set. However, with no annotations and no output schema, it does not explain what the tool returns or how results are delivered, leaving a notable gap for a complex execution tool. The schema covers parameters, but behavioral completeness is only partially addressed.

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 the input schema already documents all nine parameters in detail. The description adds only the high-level routing context based on complexity, which aligns with the tier parameter but does not add meaningful semantics beyond the schema. The baseline of 3 is appropriate.

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?

The description clearly states the tool's scope: analysis, planning, research, review, or text generation tasks where no files need to be written. It explicitly distinguishes this tool from mullet_opencode, which handles code editing, and notes that it routes to the optimal provider based on complexity. An agent can identify both what the tool does and what it does not do.

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?

It gives explicit when-to-use and when-not-to-use guidance, naming the alternative mullet_opencode for code editing and listing the exact task categories appropriate for mullet_run. The exclusion is front-loaded and unambiguous, leaving little inference required.

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