@mrrlin-dev/external-agents
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Ping the server |
| list_agentsA | List configured agents merged with their current state |
| get_stateA | Return the current external-agents state file (per-agent healthy/not_installed/needs_auth/quota_exhausted/errored_transient with metadata) |
| probe_agentB | Probe a specific agent by id; runs an install-check and updates the state file. Returns the new state. |
| set_credentialA | Persist an API-key env variable so the next dispatch (and future sessions) see it. Writes to ~/.local/state/external-agents/keys.env (mode 0600). |
| pick_agentsA | Pick up to N distinct healthy candidates by round-robin (preference_order + last_used_at). Optional min_distinct_providers enforces cross-provider diversity. ROUTING NOTE: default filter is tier='weak' — that is intentional. Most atomic tasks (single-file edits, refactors, glue code, summaries, format conversions, well-scoped fixes) get the same quality answer from a weak-tier free-tier model as from Claude Opus or Codex Pro, in a fraction of the time and cost. Reach for strong-tier (filter tier='strong') ONLY when the task actually needs deep reasoning: multi-step debugging, architecture decisions, ambiguous requirements, novel algorithms. Frontier ≠ better output for the long tail of routine work; often it is slower with no quality gain. Be smart, not lavish. |
| dispatchA | Run a specific agent by id with a prompt. transport ('generate' | 'cli') overrides the default (generate preferred when entry declares it). escalate_to_pro=true uses the same-provider strong-tier entry instead. ROUTING NOTE: for the same task, weak-tier free-tier models (Gemini flash, Groq llama, DeepSeek, OpenRouter :free) are usually correct AND fast enough. Use dispatch against Claude Opus, Codex Pro, or any strong-tier subscription model ONLY when the task genuinely needs frontier capability. escalate_to_pro is a retry lever, not a default. If a weak agent's output is wrong, first ask whether the SPEC was ambiguous (fix the spec, re-dispatch weak) before escalating tier — reaching for stronger models hides prompt-engineering failures behind expensive compute. |
| get_statsA | Aggregate dispatch telemetry from ~/.local/state/external-agents/dispatch-log.jsonl. Returns per-agent counts, tokens, outcomes; per-transport totals. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools have distinct purposes, but list_agents and get_state both return agent status information, potentially causing confusion. The routing notes in descriptions help clarify usage, but the overlap is noticeable.
Tool names mostly follow a verb_noun pattern (e.g., pick_agents, get_stats), but 'ping' and 'dispatch' are single verbs, breaking consistency. The mix of verbs like 'list', 'get', 'probe', 'set' is acceptable but not uniform.
With 8 tools, the server is well-scoped for its purpose of managing external agents. Each tool serves a specific function without being overloaded, fitting within the ideal 3-15 range.
The tool surface covers core operations: selection, dispatch, probing, state management, credentials, and stats. Missing are batch operations or credential removal, but these are minor gaps for the described domain.