@mrrlin-dev/external-agents

by mrrlin-dev

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.29.0
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 169 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the side effect (updates state file) and return value (new state). Since no annotations are provided, it carries the full burden; however, it does not explain what 'probe' means in detail or mention permissions.
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?
The description is a single sentence with no unnecessary words. It is front-loaded with the main action. Could be slightly improved with structured bullet points.
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?
For a simple tool with one parameter and no output schema, the description covers the action, side effect, and return value. However, lacking usage guidelines and parameter details, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'agent_id' has no schema description (0% coverage). The description adds minimal meaning beyond the parameter name and label, saying 'by id' but not clarifying format or constraints.
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 action (probe an agent), the specific operation (install-check and state update), and the return value (new state). This distinguishes it from siblings like 'list_agents' or 'get_state'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ping' or 'get_state'. The description implies it's for installation checking but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility for behavioral disclosure. It only states 'Ping the server,' which implies a read-only connectivity check but provides no details about side effects, error behavior, or response format.
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?
The description is a single, concise sentence with no wasted words. It is appropriately front-loaded and efficient.
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?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. However, it could benefit from stating what the response indicates (e.g., success/failure), but this is a minor gap for a trivial ping tool.
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 has zero parameters with 100% schema coverage, so the description adds no parameter info, but none is needed. The baseline for no parameters is 4.
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 'Ping the server' uses a clear verb ('Ping') and resource ('server'), and it is distinct from sibling tool names like pick_agents, get_stats, etc., which are all agent-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For a simple health-check tool, usage is implied but not explicitly stated, and there are no exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states the tool 'lists' (implying read-only) but does not clarify permissions, pagination, rate limits, or what 'merged with their current state' means concretely. Minimal transparency beyond basic action.
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?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. No extraneous words or details. Highly concise and front-loaded.
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 tool is simple with no parameters and no output schema. The description covers the core function but omits details about output format, potential errors, or limitations. For a list tool, it could be more complete (e.g., mention if it returns all agents or paginated). Adequate but not comprehensive.
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?
Baseline is 4 for 0 parameters. The input schema has no parameters, so the description does not need to add parameter semantics. It correctly conveys that no inputs are required.
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 verb ('list') and the resource ('configured agents') with a specific qualifier ('merged with their current state'). This distinguishes it from sibling tools like 'pick_agents' (selection) and 'get_state' (single agent state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when not to use it or compare with siblings like 'get_stats' or 'probe_agent'. Usage is implied by the simple listing action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals data source file path but does not mention read-only nature, error handling, or permissions. No annotations to contradict.
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?
Two concise sentences; front-loaded with action and source, followed by output details. No wasted words.
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?
Complete for a simple read-only tool; includes source and output. Minor gap: no note on file existence or size implications.
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 covers the only parameter well; description adds no extra parameter context beyond confirming ISO 8601.
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?
Clearly states it aggregates dispatch telemetry from a specific file path and lists output categories. Distinct from sibling tools which focus on agent interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for retrieving telemetry, but no explicit guidance on when to use vs alternatives or conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a state file, which implies a read-only operation with no side effects. However, it does not explicitly confirm safety or disclose any permissions needed, which is acceptable for a simple read-only tool but leaves some ambiguity.
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?
The description is a single sentence that conveys all necessary information without extraneous words. It is front-loaded with the action and resource, and every word adds value.
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?
Given that there is no output schema, the description provides key return value semantics (possible states and metadata). It is sufficient for a simple read tool, though additional details about metadata format could be added.
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 input schema has zero parameters, so the description does not need to add parameter details. Per the scoring guidelines, 0 parameters yields a baseline of 4.
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 uses a specific verb 'Return' and clearly identifies the resource as 'the current external-agents state file', listing the possible per-agent states (healthy, not_installed, etc.) and noting it includes metadata. This distinguishes it from sibling tools like list_agents and probe_agent, which operate on individual agents or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the overall state of external agents, but it does not explicitly state when to use it versus alternatives (e.g., probe_agent for a single agent, list_agents for just listing). No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains that transport overrides default and escalate_to_pro switches to stronger tier. It does not mention side effects or destruction, but the behavior of dispatching is well-covered.
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?
The description is front-loaded with the core action and then adds a valuable routing note. It is somewhat lengthy but every sentence adds information. The mismatch in transport enum values is a minor structural flaw.
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?
Given the lack of output schema and 4 parameters, the description provides complete context: what the tool does, how parameters work, and when to use it. The routing note answers likely follow-up questions, making it fully actionable.
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 0%, so the description must compensate. It explains transport and escalate_to_pro, but a mismatch exists: description says 'generate'|'cli' while schema enum is ['generate_new','edit_exists']. Prompt and agent_id are left to inference. Partial but flawed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Run a specific agent by id with a prompt', clearly stating the verb (run) and resource (agent). It distinguishes from sibling tools like list_agents or get_stats, though it does not explicitly contrast. The purpose is immediately clear.
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?
The description provides explicit guidance on when to use strong-tier models vs weak-tier, and treats escalate_to_pro as a retry lever. The ROUTING NOTE gives clear when-not and alternatives (fix spec before escalating). This is exemplary usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the round-robin algorithm using preference_order and last_used_at, and mentions healthiness and cross-provider diversity. It does not mention side effects, rate limits, or authorization, but the selection behavior is well-described.
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?
The main description is concise and front-loaded. The ROUTING NOTE adds length but provides essential usage guidance. The structure separates core functionality from usage notes, but could be slightly more succinct.
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 tool has 3 parameters with nested objects and no output schema. The description explains selection logic and usage contexts, but does not specify the return value format (e.g., list of agent IDs or objects). This gap makes it incomplete for an agent to understand what to expect.
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 0%, so the description must compensate. It briefly describes each parameter: n count, filter with default tier, and min_distinct_providers for diversity. However, it does not explain sub-properties of filter (tags, exclude_ids) in detail, leaving some ambiguity.
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 picks up to N distinct healthy candidates using round-robin with preference_order and last_used_at. It also mentions optional min_distinct_providers for cross-provider diversity. This distinguishes it from sibling tools like list_agents (which lists without selection logic) and get_stats (which provides metrics).
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?
The ROUTING NOTE provides explicit guidance on when to use the default weak tier versus the strong tier. It explains that weak tier is intentional for most routine tasks and strong tier should only be used for deep reasoning tasks. This directly helps the agent decide when to invoke this tool with different filter settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it writes to a specific file (~/.local/state/external-agents/keys.env) with permissions (mode 0600) and persists across sessions. It also explains the impact on dispatch. This is comprehensive.
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?
A single sentence that front-loads the purpose ('Persist an API-key env variable') and includes specific details (file path, permissions, effect on dispatch) without any redundant information.
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?
For a simple credential-setting tool with 2 required parameters and no output schema, the description covers all essential aspects: what it does, where it writes, persistence behavior, and impact on dispatch. No gaps remain.
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 description adds meaning beyond the schema by stating the tool deals with API-key env variables, implying env_name is the variable name and value is the key value. Though schema coverage is 0%, the description provides enough context to infer parameter roles.
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 persists an API-key environment variable for future sessions, specifying the verb 'persist', the resource 'API-key env variable', and the effect on dispatch and future sessions. It also includes the file path and permissions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting persistent environment variables that affect dispatch and future sessions. While it does not explicitly state alternatives or when not to use, the sibling tools are unrelated, so no confusion arises. A clear when-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![external-agents MCP server](https://glama.ai/mcp/servers/mrrlin-dev/external-agents/badges/card.svg)](https://glama.ai/mcp/servers/mrrlin-dev/external-agents)

Score Badge

Copy to your README.md:

[![external-agents MCP server](https://glama.ai/mcp/servers/mrrlin-dev/external-agents/badges/score.svg)](https://glama.ai/mcp/servers/mrrlin-dev/external-agents)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrrlin-dev/external-agents'

If you have feedback or need assistance with the MCP directory API, please join our Discord server