random-agent

by randomchips

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct: metrics, status, and logs each read different data sources (DB, live coordinator state, files), while inject, orchestrate, handle_stuck, and coordinator manage different aspects of the system. However, metrics and status could be confused for overlapping system information.
Naming Consistency2/5
Tool names mix nouns (metrics, status, logs, coordinator) with imperative verbs (inject, handle_stuck, orchestrate, assert). There is no consistent verb_noun or noun_verb pattern, making the set feel ad hoc.
Tool Count5/5
Eight tools is well within the ideal 3-15 range for this domain. Each tool serves a distinct operational purpose without redundancy or bloat.
Completeness4/5
The set covers core operations: observability (metrics, status, logs), task injection, failure recovery, coordinator control, high-level orchestration, and assertion. Minor gaps exist (e.g., no direct task result retrieval outside orchestrate), but workflows are largely complete.
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a mutation ('inject') but fails to mention side effects, required permissions, failure modes, or what happens after injection. This lack of detail fails to inform the agent of potential risks or constraints.
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, front-loaded sentence with no unnecessary words. It effectively communicates the core purpose, though given the tool's complexity (4 parameters), it might benefit from a bit more detail. Still, it is appropriately concise for stating the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, including an assertions array), lack of annotations, and no output schema, this description is severely incomplete. It does not explain return values, verification steps, or how this tool integrates with siblings like assert or handle_stuck, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (name and command have descriptions, but priority and assertions do not). The description adds no parameter information, forcing the agent to rely solely on the schema. It does not compensate for the missing descriptions of priority and assertions, nor does it clarify the role of the required parameters in the injection process.
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 ('inject') and the target ('pending queue'), making it distinct from sibling tools like metrics, status, and logs, which are read-only. The verb+resource structure is specific and unambiguous.
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 vs alternatives such as orchestrate or assert. The description only states what it does, leaving the agent to infer usage context without any exclusions or alternative recommendations.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it reads logs, but does not disclose any side effects, access requirements, output format, or limits. It does not contradict anything, but offers very little beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the action and subject without padding. It is front-loaded and easy to parse, though it could arguably be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has four parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain what the logs contain, how parameters combine, what the return format is, or how it relates to sibling tools, leaving significant gaps for an agent.
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?
All four parameters have descriptions in the schema (100% coverage), so the schema already documents their meaning. The tool description itself adds nothing about how parameters like 'search' or 'worker_id' interrelate, so it stays at the baseline for high schema coverage.
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 uses a specific verb ('Read') and a clear resource ('real log files from the agent-os system'), making the core purpose obvious. It does not explicitly differentiate from sibling tools like metrics or status, but the term 'real log files' helps distinguish it from aggregated metrics or system status.
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 should be used when you need to inspect actual log file contents, which suggests a basic use case. However, it provides no explicit guidance on when to choose this over sibling tools such as metrics or status, and no exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read real metrics' implies a non-mutating operation, but it offers no details about output format, filtering behavior beyond the schema, or any caveats about data freshness or access.
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, front-loaded sentence that states the core action and resource without any filler. It is appropriately sized for a simple read tool with two optional parameters.
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 relatively simple with only two optional parameters and no output schema, so a one-sentence description is nearly sufficient. However, in the context of seven sibling tools, the lack of any usage context or clarification of what 'real metrics' means leaves a gap in completeness.
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%, with parameters 'task' and 'limit' already documented as filtering and limiting results. The description adds no additional meaning beyond what the input schema provides, so a baseline score of 3 is appropriate.
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 uses a specific verb ('Read') and identifies the resource ('metrics database'), clearly indicating this is a read operation for metrics. It distinguishes itself from mutation tools like inject and orchestrate, though it does not explicitly contrast with read-like siblings such as status or logs.
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 given about when to use this tool versus alternatives like status or logs. The description only states what it does, not the context in which it should be selected.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it fails to mention critical behaviors such as side effects (e.g., 'update-snapshot' may modify state), failure semantics (does it throw an error?), or whether it requires specific permissions. The schema hints at a write capability through 'update-snapshot', but the description omits this entirely.
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 that is front-loaded with the core purpose. Every word contributes meaning, and there is no redundant or filler content. It is appropriately terse for the level of detail it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a wide range of assertion types, no output schema, and no annotations, the description is far too brief. It does not explain how assertions are structured, what happens on success/failure, or how the 'task_name' and 'output' parameters relate. The current description only scratches the surface, leaving the agent to infer most context from the schema.
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 75%, and the schema provides reasonable descriptions for output, task_name, and assertions, while format has an enum. The tool description adds no parameter-specific meaning. At 75% coverage (between 50% and 80%), the schema does most of the work, and the description does not compensate for the remaining gaps.
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 'Run' and the resource 'output comparison assertions' with scope 'on tasks or arbitrary text'. This is specific and distinguishes the tool from its siblings (metrics, status, logs, etc.), none of which suggest assertion functionality.
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 vs alternatives. The description does not mention any exclusions, prerequisites, or sibling tools that might be more appropriate in certain contexts. The only hint is that it operates on tasks or arbitrary text, but this is implicit rather than actionable guidance.
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 carries the full burden of behavioral disclosure. It tells what can be done (start/stop/restart) but does not disclose side effects, such as whether restart causes downtime, if operations are asynchronous, or what impact stopping has on other tools. This is minimal disclosure.
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?
One concise sentence contains both the action and resource. It is appropriately sized for a simple lifecycle tool, with no redundant wording or filler.
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?
Given the tool has one parameter and no output schema, the description is minimally sufficient, but it lacks context about what the coordinator is, what happens on each action, or what the result will be. With no annotations or output schema, the agent needs more contextual details to use it reliably.
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?
The schema fully defines the single required parameter 'action' with an enum (start/stop/restart) and a description ('Action'). The tool description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate given 100% schema coverage.
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 'Start, stop, or restart the coordinator' clearly identifies the tool's action (start/stop/restart) and its target resource (the coordinator). This distinguishes it from sibling tools like metrics, status, logs, or inject, which are not lifecycle management actions.
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?
The description provides no guidance on when to use the coordinator tool versus alternatives (e.g., orchestrate, handle_stuck) or any prerequisites/preconditions. It simply states the action without context, leaving the agent to infer usage.
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 carries full burden. It only gives high-level steps without disclosing whether execution blocks (wait param), how failures are handled, or if there are side effects. The description omits key behavioral details like async behavior and results structure.
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 with a clear action verb and a concise list of capabilities. It is front-loaded and contains no wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex orchestration tool with 5 parameters and no output schema, but the description fails to explain return value structure, error handling, or how assertions and timeout factor in. It is insufficient for an agent to invoke correctly.
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 high (80%), so baseline is 3. The description does not add meaning beyond the schema; the parameter details are left to the schema, which already covers most parameters.
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 orchestrates a complex task and lists specific capabilities (decompose, inject subtasks, monitor, return results), which distinguishes it from siblings like metrics or assert.
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 use for complex tasks require decomposition and monitoring, but it does not explicitly state when to use this tool versus alternatives like coordinator or inject, nor any exclusions or prerequisites.
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 exist, so the description carries the burden. It only lists the content ('coordinator, queue counts, workers') but doesn't disclose any behavioral traits such as read-only nature, response format, or potential side effects, leaving 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 extremely concise—single sentence, front-loaded with the essential verb and resource. Every word earns its place with no redundancy.
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 zero-param, no-output-schema tool, the description is minimal but adequate. However, it lacks any detail about response structure or when to use it, so it's not fully complete for an agent to predict behavior.
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, so the baseline is 4. The description adds no parameter-level detail, but none is needed since there is nothing to configure.
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 purpose: 'Get live status: coordinator, queue counts, workers'. It uses a specific verb and resource and distinguishes itself from sibling tools like metrics and logs by focusing on current operational 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 is provided on when to use this tool versus alternatives. It doesn't mention exclusions or context, leaving the agent to infer when 'status' is appropriate compared to 'metrics' or 'logs'.
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?
With no annotations, the description carries the full behavioral disclosure burden. It does state that the tool kills workers and retries, which signals destructiveness, but omits side effects, reversibility, privilege requirements, and the meaning of the force option.
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, front-loaded sentence of eight words with zero filler. Every word contributes to the core purpose.
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 one-parameter tool with no output schema, the description covers the main action well. However, it lacks usage context, side-effect details, and clarification of the force parameter, so it is not fully complete.
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?
The schema fully describes the 'force' parameter with a clear description, and schema coverage is 100%. The tool description adds no additional parameter semantics, so the baseline of 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?
The description uses specific action verbs ('Detect', 'kill', 'retry') and names the resource ('stuck/failed workers'), clearly distinguishing handle_stuck from read-only siblings like metrics, status, and logs.
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?
It implies the tool should be used when workers are stuck or failed, but gives no explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternatives like assert or coordinator.
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:

[![random_agent MCP server](https://glama.ai/mcp/servers/randomchips/random_agent/badges/card.svg)](https://glama.ai/mcp/servers/randomchips/random_agent)

Score Badge

Copy to your README.md:

[![random_agent MCP server](https://glama.ai/mcp/servers/randomchips/random_agent/badges/score.svg)](https://glama.ai/mcp/servers/randomchips/random_agent)

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/randomchips/random_agent'

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