eos-mcp

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation5/5
Each tool targets a specific resource and action: device inventory, facts, commands, configuration, sessions, and health. The only potential overlap is get_version vs get_device_facts, but the descriptions clearly distinguish the quick connectivity check from full facts. Batch variants are clearly differentiated by scope (single/multiple devices, single/multiple commands).
Naming Consistency4/5
The majority of tools follow a consistent verb_noun snake_case pattern (get_, list_, run_, push_, confirm_, abort_, collect_). A few names like health_check and daily_brief deviate from this pattern, but they are still readable and recognizable. Overall, the convention is predictable with minor exceptions.
Tool Count4/5
With 17 tools, the server is slightly above the ideal 3-15 range but still well-scoped for the domain of EOS device management. Each tool covers a distinct operational need, from inventory to configuration sessions to health monitoring. The count feels reasonable for a comprehensive network device MCP server.
Completeness4/5
The tool surface covers the core lifecycle: discover devices, retrieve facts, run commands, get/push config, manage config sessions, and monitor health. Minor gaps include no explicit save-config to startup and no device inventory update, but these can be worked around via command execution or configuration changes. Overall, the set is quite complete for common automation workflows.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 disclosing behavioral traits. It only states the action ('Abort') but does not explain what happens to the session, whether the action is reversible, any locking or cleanup behavior, or potential side effects. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which earns credit for conciseness. However, it is under-specified for the complexity of the tool, missing parameter context and usage guidance. It is appropriately front-loaded but not sufficiently informative.
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 the tool's mutating nature and lack of annotations, the description is incomplete. It does not cover when to use it, what happens on abort, or any requirements. An output schema exists, so return format is not needed, but the description still leaves critical context gaps.
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 0%, and the description does not mention any parameters. The tool has three parameters (hostname, config_path, session_name) with meaningful defaults, but the description adds no semantic value, leaving users to rely solely on the schema names.
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 ('Abort') and resource ('pending configure session'), clearly distinguishing it from siblings like confirm_config_session, list_config_sessions, and push_config. It also adds the target context ('on an EOS device'), 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 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 this tool versus alternatives. It does not mention scenarios for aborting versus confirming or listing sessions, nor any prerequisites or exclusions. Users are left to infer usage from the tool name.
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 states that facts are returned but does not mention read-only invariants, failure behavior, or auth requirements. The term 'return' implies a read operation, but explicit safety context is absent.
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 succinct sentence that conveys the tool's purpose and expected output. Every word earns its place, with no redundant phrasing.
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?
The description is minimal and lacks critical context: no mention of config_path purpose, no usage distinction from sibling tools, and no details about return encapsulation. Although an output schema exists, the description still leaves the parameter semantics and operation scope under-specified.
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 0%, and the description does not explain either parameter. 'hostname' is self-explanatory, but 'config_path' is not mentioned at all, leaving a required semantic gap for effective invocation.
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 clearly states the tool returns structured device facts and lists specific fields (hostname, model, serial, EOS version, uptime, memory). This distinguishes it from generic tools, though it does not explicitly differentiate from get_device_facts_batch.
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 like get_device_facts_batch or get_version. The description simply states what it does, leaving usage context entirely to the agent.
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. It states 'Retrieve,' implying a read-only operation, but does not explicitly confirm that it makes no changes, mention required permissions, or explain the effect of the optional config_path parameter. The absence of any side-effect or safety context leaves the agent with incomplete behavioral understanding.
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 with no filler or redundant information. It front-loads the core action and resource, achieving high conciseness, though its brevity lacks structural elements like parameter hints or usage context.
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 the presence of an optional config_path parameter and sibling tools for related operations, the description is under-specified. It does not explain the return structure (even though an output schema exists, the description adds no context about what the retrieved config contains), nor does it clarify how to invoke the tool correctly for different scenarios. The agent would need to infer too much.
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?
The input schema has zero description coverage for its two parameters (hostname and config_path), and the tool description does not mention or explain either parameter. The agent has no guidance on what config_path means or how it modifies the retrieval, making the parameters effectively opaque.
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: 'Retrieve the running-config from an EOS device.' It uses a specific verb ('retrieve') and resource ('running-config'), and it distinguishes itself from sibling tools like get_config_diff (which handles diffs) and list_config_sessions (which lists sessions).
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 such as get_config_diff, run_command, or push_config. The description does not mention any prerequisites, exclusions, or specific use cases beyond the basic retrieval action.
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 must carry the burden of disclosing behavioral traits. It mentions 'enable-mode' indicating a required privilege level and 'labelled output' indicating response format, but it does not disclose potential side effects of running commands, error handling, session behavior, or any prerequisites. This is insufficient transparency for a command 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?
The description is a single, well-structured sentence that is front-loaded with the primary action and scope. It is concise with no filler words, every word adding value, and perfectly sized for a straightforward command execution tool.
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?
Despite the presence of an output schema (which may cover return values), the overall description is incomplete for a tool with no annotations and no parameter documentation. It lacks safety warnings, prerequisite context, and guidance on when to use this tool versus siblings. A command execution tool should provide more context about enable mode requirements and potential impacts.
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 0%, and the description does not mention any parameters by name or provide semantics beyond implying 'commands' and 'hostname' through the phrase 'multiple commands on one EOS device'. The config_path parameter is completely unexplained. The description fails to compensate for the lack of schema descriptions.
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 function: 'Run multiple enable-mode commands on one EOS device and return labelled output.' It specifies the verb (run), resource (multiple enable-mode commands on one EOS device), and output format (labelled output), distinguishing it from sibling tools like run_command (single command) and run_commands_batch (likely multiple devices).
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 usage for multiple commands on a single device, but it does not explicitly state when to prefer this tool over alternatives such as run_command or run_commands_batch. There is no mention of exclusions or alternative selection guidance, so the usage context is only implied.
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?
The description discloses that the output is large and the operation takes over 30 seconds, which is useful behavioral context beyond annotations (there are none). However, it does not explain what happens with the output (e.g., return vs file), error conditions, or side effects, so transparency is partial.
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, efficient sentence that front-loads the action. No wasted 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?
The description captures the core action but leaves the optional config_path parameter unexplained and provides no guidance on usage compared to sibling tools. The output schema may cover return values, but the missing parameter semantics and lack of usage clarity make it incomplete.
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?
Schema coverage is 0%, and the description does not explain the parameters. 'Hostname' is implied as the target device via 'from an EOS device', but 'config_path' is entirely unexplained. The description adds minimal semantic value for parameters.
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 clearly identifies the verb 'collect' and the resource 'show tech-support from an EOS device', and adds context about large output and duration. However, it does not explicitly distinguish from sibling tools like run_command, though the size/time hint implies differentiation.
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 parenthetical '(large output, 30+ seconds)' provides context about when this tool is appropriate—for heavy outputs—but does not explicitly state when to use it over alternatives or any exclusion criteria. No alternatives are mentioned.
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. It does not explain the impact of confirming the timer (e.g., whether config changes are immediately applied), whether the action is reversible, or if any prerequisites exist. The term 'finalize' hints at a commit but leaves ambiguity about consequences.
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 purpose without any filler. It is appropriately sized for the tool's apparent simplicity.
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?
The description is too sparse for a config mutation tool that affects an EOS device. With three parameters and no annotations, the description fails to provide needed context about prerequisites, behavior, or parameter usage, making it incomplete for an agent to confidently invoke.
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?
The schema description coverage is 0%, and the description does not mention any of the three parameters (hostname, config_path, session_name). It adds no value in explaining what these parameters mean or how they should be used, which is essential given the lack of schema descriptions.
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 'Confirm (finalize)' with a clear resource 'pending configure session commit timer' on an EOS device. It naturally distinguishes itself from sibling tools like abort_config_session by indicating finalization rather than cancellation.
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 when to use the tool: when there is a pending configure session commit timer. While it does not explicitly list alternatives or exclusions, the context is clear enough that an agent could infer this is the finalization step in a config session workflow.
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 the full burden of behavioral disclosure. It only states the action and return type, but does not mention potential side effects (e.g., running destructive commands), privileges required, or error behavior. This is insufficient for a tool that executes arbitrary commands.
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 is front-loaded with the core action and resource. Every word contributes meaning, with no filler or repetition.
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?
While an output schema exists and can describe return values, the description is incomplete for a potentially mutating tool. It omits usage guidance for the optional config_path, fails to warn about command side effects, and does not address the distinction from siblings beyond the word 'single'. The tool is not fully specified for safe and 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?
The schema has 0% description coverage, and the description adds no parameter-level details. It does not explain the purpose of 'command', 'hostname', or 'config_path', nor how they interact. The description fails to compensate for the lack of schema documentation.
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 runs a single enable-mode command on an EOS device and returns text output. It specifies the verb (run), the resource (EOS device), and the scope (single command), distinguishing it from sibling batch tools like run_commands and run_command_batch.
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 implicitly provides usage context by emphasizing 'single' command execution, which contrasts with the batch/plural sibling tools. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit exclusions but still offers clear context.
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 provided, the description carries the full burden for behavioral disclosure. The verb 'List' implicitly suggests a read-only operation, but the description does not explicitly state that it has no side effects or require any special access, leaving room for interpretation.
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, short sentence that is front-loaded and contains no extraneous information. It efficiently states the core purpose and the only optional behavior.
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 list tool with an output schema, the return format is likely covered. However, the description lacks guidance on when to use this tool instead of sibling tools and fails to explain the config_path parameter, creating significant gaps in context.
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?
Schema description coverage is 0%, so the description must compensate. It explains the 'tags' parameter ('optionally filtered by tags') but completely omits 'config_path', leaving its purpose and usage unclear. This partial coverage is insufficient.
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 ('List') and resource ('EOS devices registered in config'), which clearly defines its function. It also differentiates from sibling tools like get_device_facts by focusing on device registration rather than device facts.
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 this tool versus alternatives, such as get_device_facts_batch or list_config_sessions. It only mentions an optional tag filter, which is not usage context.
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 burden. It discloses the parallel behavior and the specific facts returned, which implies a read-only operation. However, it does not mention error handling, limits on batch size, authentication requirements, or failures with invalid hostnames, so it is only partially transparent.
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, focused sentence that is front-loaded with the core action and return value. It contains no filler or redundant details, hitting the ideal level of conciseness.
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 batch tool with four parameters, no annotations, and an output schema, the description is too sparse. It does not explain how to specify devices, the relationship between tags and hostnames, or the role of config_path and max_workers. The output schema covers return values, but the input semantics are left wholly unexplained, making the tool difficult to invoke correctly.
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?
The schema coverage is 0% and the description does not explain any of the four parameters. It only says 'multiple devices' without indicating how they are selected (tags vs hostnames), what config_path is for, or the meaning of max_workers. The description adds no semantic value over the bare schema names.
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 what it does: return device facts (model, serial, EOS version, uptime) for multiple devices in parallel. The verb 'Return' is specific, and the 'multiple devices in parallel' distinguishes it from the sibling get_device_facts, which presumably handles single devices.
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 when to use this tool: when you need facts for multiple devices, and the parallel execution suggests efficiency. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent would not mistakenly use it for a single device. Lacking explicit 'when not to use' guidance prevents a 5.
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. It reveals parallel execution and enable-mode scope but omits critical safety context: executing arbitrary commands may have side effects, failure handling is unknown, and no authentication requirements are mentioned.
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 with no filler. The first sentence states the action and scope; the second gives essential targeting usage. It is appropriately front-loaded and easy to parse.
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?
With five parameters, no annotations, and no schema descriptions, this two-sentence description is insufficient. Output schema presence reduces the need to describe return values, but parameter semantics and risk disclosure remain major gaps.
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?
Schema coverage is 0%, so the description must explain parameters. It clarifies hostnames and tags as target selectors, but leaves command, config_path, and max_workers unexplained. config_path is especially opaque with no hint of its purpose.
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: 'Run an enable-mode command on multiple EOS devices in parallel.' It uses a specific verb and resource, and the phrase 'in parallel' plus 'multiple EOS devices' distinguishes it from single-device or multi-command siblings.
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?
It provides clear target-selection guidance: 'Specify targets via hostnames, tags, or both.' This gives a concrete usage pattern, though it does not explicitly state when to prefer this tool over run_command or run_commands_batch.
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. It reveals that execution is parallel and output is labelled by hostname and command, which is useful, but it does not disclose potential side effects or risks of running enable-mode commands, permissions needed, or failure handling semantics. Given that this tool can execute arbitrary commands on network devices, this omission is significant.
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 concise and well-structured. The first sentence states the core action and scope, the second explains targeting, and the third describes the output format. Each sentence adds value without redundancy, and the main purpose is 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?
Given the tool has 5 parameters and no annotations, the description covers core purpose and targeting but leaves gaps around config_path, max_workers, and failure/error behavior. The existence of an output schema reduces the need to describe return values, but the description is still not fully complete for a batch execution tool of this complexity.
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 schema has 0% description coverage, so the description must compensate. It explains the purpose of commands, hostnames, and tags ('multiple enable-mode commands', 'targets via hostnames, tags, or both'), but it fails to explain config_path and max_workers. These parameters are not self-evident from their names alone, and the description leaves them undefined.
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 runs multiple enable-mode commands on multiple EOS devices in parallel, which is a specific verb+resource+scope. It also distinguishes itself from sibling tools like run_command or run_commands by emphasizing 'multiple devices' and 'parallel execution'. The targeting via hostnames/tags adds further clarity.
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 provides clear context by stating that the tool is for running multiple commands on multiple devices in parallel, and it gives specific targeting instructions ('via hostnames, tags, or both'). However, it does not explicitly mention when to use this tool versus alternatives (e.g., run_command_batch for single command on multiple devices) or when not to use it, so it lacks explicit exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It does add the useful hint that this is a 'quick connectivity check', implying a lightweight, likely non-destructive operation. However, it does not disclose permissions, error behavior, or side effects, leaving some gaps.
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 with no redundant or extraneous words. Every word contributes to the tool's purpose and usage context.
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, the description is mostly adequate, but the unexplained 'config_path' parameter leaves ambiguity for the agent. The output schema exists, so return value details are covered, but the missing parameter semantics and lack of behavioral context make it less than fully complete for correct invocation.
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?
Schema description coverage is 0%, so the description must compensate. It implicitly explains 'hostname' via 'for a device' but completely fails to explain the optional 'config_path' parameter, which is not self-evident. The description adds no meaningful parameter semantics beyond the schema itself.
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 a specific verb ('Return') and resource ('EOS version string') with scope ('for a device'), and adds a purpose ('quick connectivity check'). This differentiates it from siblings like get_device_facts, which would provide broader device information.
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 provides clear context by labeling the tool as a 'quick connectivity check', implying it is for lightweight verification. However, it does not explicitly mention alternative tools or say when not to use it, so it falls short of full usage guidance.
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 the full burden. It discloses the types of sessions shown, but does not explicitly state that the operation is read-only, whether it has side effects, or any required permissions. This is a moderate gap.
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 three concise sentences: purpose, included states, and usage context. Every sentence adds value with no redundancy or fluff.
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 an output schema and a relatively simple purpose, but the description does not compensate for missing annotations or explain parameter semantics. It provides some context via the use case, but leaves gaps in behavioral guarantees and parameter guidance.
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?
Schema description coverage is 0% and the description does not explain the parameters 'hostname' or 'config_path'. The names are somewhat intuitive, but the description adds no meaning beyond the bare schema properties.
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 states a specific action ('List configure sessions and their state on an EOS device') and specifies the exact states covered (pending, pendingCommitTimer, completed). This clearly distinguishes it from siblings like push_config or get_config.
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?
It explicitly says 'Useful for tracking in-flight push_config operations,' giving a clear use case. It does not mention alternatives or exclusions, but the context is strong enough to guide selection.
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 the full burden. It discloses the default rollback behavior, the meaning of rollback_id values, and the EOS version condition with graceful fallback. However, it does not mention potential side effects (e.g., whether the operation is strictly read-only), authentication requirements, or behavior for invalid rollback_id or config_path. Some behavioral context is added, but gaps remain.
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 brief and well-structured. It leads with the primary purpose, then concisely explains rollback_id options, and adds a single version note. Every sentence contributes useful information without redundancy or fluff. The format is easily scannable for an AI agent.
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 reasonably complete for the core diff operation, covering rollback_id behavior and version constraints. An output schema exists, so return value details are not needed. However, the meaning of config_path is not clarified, and the absence of annotations leaves safety and side-effect context under-specified. Given the tool's moderate complexity, the description covers the main points but has notable gaps.
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?
With 0% schema description coverage, the description must compensate. It thoroughly explains rollback_id, including default and numeric semantics. However, config_path is entirely unexplained, and hostname is self-evident. The description adds meaning for one of three parameters, leaving config_path ambiguous. This partial compensation suggests a mid-range score.
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 opens with 'Show config diff on an EOS device,' which clearly specifies the verb ('Show'), the resource ('config diff'), and the target ('EOS device'). It distinguishes itself from sibling tools like get_config (which retrieves the full config) and list_config_sessions by focusing on the diff operation. The rollback_id semantics add further specificity.
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 provides clear context for when to use the tool by explaining the rollback_id default behavior and the version dependency for startup-config diffs. However, it does not explicitly state when not to use this tool or mention alternative tools such as get_config for retrieving full configs. This is clear enough for straightforward use, but lacks explicit exclusion guidance.
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 full burden of behavioral disclosure. It goes beyond a basic statement by detailing exactly what health checks are performed (environment, errdisabled interfaces, uptime, MLAG, syslog alerts) and the output format (CRITICAL/WARNING/OK per device with summary). It also explains the time-window behavior via 'since_hours' and the target selection default. Some gaps remain (e.g., read-only nature, concurrency via max_workers), but overall it is highly transparent.
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 well-structured and efficient. The opening sentence immediately conveys the purpose, followed by a concise list of checks, the output format, and target selection. There is no fluff or redundancy; every sentence contributes useful information. It is front-loaded with the primary action.
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?
The tool has 5 parameters, no annotations, and an output schema. The description is comprehensive for a health-check brief tool: it explains the checks, output statuses, time window, and target selection. It leaves some gaps (e.g., meaning of config_path and max_workers, explicit read-only guarantee), but given the output schema likely defines return structure and the checklist of checks is detailed, it is largely complete for typical usage.
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 does explain three parameters: 'hostnames' and 'tags' as target selectors, and 'since_hours' as the time window. However, 'config_path' and 'max_workers' are left unexplained both in the schema and description, leaving their purpose ambiguous. The description adds value for the majority but doesn't fully cover all 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 primary action ('Run health checks on EOS devices') and the deliverable ('return a Markdown daily brief'). It enumerates specific checks (environment, errdisabled, uptime, MLAG, syslog alerts) and distinguishes itself from siblings like 'health_check' by focusing on a comprehensive daily summary rather than a single health check.
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 provides clear context for using the tool: it's a daily brief, with target selection via 'hostnames'/'tags' and a default of all devices. However, it does not explicitly mention when to prefer this tool over alternatives like 'health_check' or 'get_device_facts', nor does it state exclusions. The usage guidance is implied rather than stated.
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 provided, the description fully carries the transparency burden and excels. It explicitly states the tool only reads and parses config.ini, does NOT open eAPI/pyeapi connections, and always returns a predictable key set including degraded/error behavior via a 'detail' field.
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 well-structured and front-loaded with the core purpose. It is somewhat longer than necessary, repeating 'lightweight' and emphasizing safety multiple times, but each sentence adds useful context (when to call, return keys, error handling). No fluff, but could be slightly trimmed.
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 (one optional param, no output schema) and lack of annotations, the description covers purpose, usage timing, safety, and return keys comprehensively. The main gap is the undocumented config_path parameter, which prevents a perfect completeness score.
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 schema has one optional parameter, config_path, with 0% description coverage in the schema. The tool description never explains this parameter. It only lists 'config_path' as a return key ('resolved config.ini path'), which hints at path resolution but does not clarify whether the parameter overrides the default path or how it affects behavior.
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 opens with a specific verb and resource: 'Report server version and configuration status (lightweight).' It clearly distinguishes this from sibling device-focused tools by emphasizing it checks the MCP server itself, not EOS devices, and explicitly states it does not open eAPI connections.
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 gives explicit when-to-use guidance: 'Call this at session start (or after a tool-call timeout) to confirm the MCP is up...' It also clarifies it is safe for large fleets because it doesn't touch the network. It doesn't name alternative tools, but the context clearly implies using this for server health rather than device operations.
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 discloses crucial behavior: dry_run shows diffs and aborts, dry_run=False commits with a rollback timer, and confirmation must occur before expiration. This goes beyond the schema and gives the agent a clear understanding of side effects.
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 sentences, front-loaded with purpose, and every sentence adds value; 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?
Given the tool's complexity with rollback and confirmation workflow, the description adequately covers the key decision points. The presence of an output schema covers return values, and the rollback/confirm flow is clearly described. Minor gaps remain around config_path and error conditions.
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 does explain dry_run and commit_timer semantics, and indirectly references hostname and config_lines, but config_path and session_name details are missing. Partial compensation only.
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 pushes configuration to an EOS device via a named configure session, using a specific verb and resource. This distinguishes it from sibling tools like confirm_config_session, abort_config_session, and get_config_diff.
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 explains when to use dry_run=True vs False and instructs the agent to call confirm_config_session before the timer expires. It provides clear usage context but does not explicitly mention alternatives or when-not-to-use cases.
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:

[![eos-mcp MCP server](https://glama.ai/mcp/servers/shigechika/eos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shigechika/eos-mcp)

Score Badge

Copy to your README.md:

[![eos-mcp MCP server](https://glama.ai/mcp/servers/shigechika/eos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shigechika/eos-mcp)

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/shigechika/eos-mcp'

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