Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@junos-mcp-server show interfaces brief on router01"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only JUNOS troubleshooting MCP server. Discovers devices dynamically from
the SURF orchestrator's gNMI-targets endpoint and runs show commands only
over NETCONF (PyEZ). It has no configuration/write capability by design.
list_devices() — device names from the orchestrator.
run_show_command(device, command) — runs a show command; rejects anything else.
Related MCP server: netmiko-mcp
Var | Required | Default | Purpose |
| yes¹ | — | orchestrator base URL, e.g. |
| yes¹ | — | Basic Auth user for the targets endpoint |
| yes¹ | — | Basic Auth password for the targets endpoint |
| yes | — | read-only device login user |
| yes | — | device login password |
| no |
| NETCONF port |
| no |
| development mode — serve |
| dev² |
| JSON list of node hostnames, e.g. |
¹ Not required when JUNOS_DEV_MODE is set. ² Required (non-empty) when JUNOS_DEV_MODE is set.
Set JUNOS_DEV_MODE=1 and JUNOS_DEV_TARGETS to a JSON list of your own nodes
to bypass the orchestrator entirely — list_devices() then returns exactly that
list and run_show_command connects to those hostnames. SSH credentials are
still required; orchestrator/Basic-Auth vars are not.
JUNOS_DEV_MODE=1 JUNOS_DEV_TARGETS='["r1.lab.net","r2.lab.net"]' \
JUNOS_SSH_USER=ro JUNOS_SSH_PASSWORD=... uvx --from . junos-mcp-serveruvx --from . junos-mcp-server # from a local checkout
uvx --from git+<repo-url> junos-mcp-server # from git{
"mcpServers": {
"junos": {
"command": "uvx",
"args": ["--from", "git+<repo-url>", "junos-mcp-server"],
"env": {
"ORCHESTRATOR_URL": "https://api.automation.surf.net",
"GNMIC_HTTP_BASIC_USER": "gnmic",
"GNMIC_HTTP_BASIC_PASSWORD": "...",
"JUNOS_SSH_USER": "...",
"JUNOS_SSH_PASSWORD": "..."
}
}
}
}Requires NETCONF enabled on devices (set system services netconf ssh).
List JUNOS device names discovered from the orchestrator gNMI targets endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it lists device names, which implies a read-only operation, but no additional behavioral context (e.g., pagination, caching) given the absence of parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (no params, output schema exists). The description fully covers what the tool does. No gaps given the context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description adds no parameter info, but baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists JUNOS device names from a specific source (orchestrator gNMI targets). Distinguishes from sibling 'run_show_command' which runs commands on devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly clear: use to retrieve device names before running commands. No explicit exclusions or alternatives mentioned, but the sibling tool's name suggests different usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only JUNOS 'show' command on a device and return its text output.
| Name | Required | Description | Default |
|---|---|---|---|
| device | Yes | ||
| command | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 read-only nature and text output, but lacks details on error handling, authentication requirements, rate limits, or behavior on invalid commands/devices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, directly states core function with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and an output schema, the description covers the essential functionality. It could hint at using list_devices for device identifiers or specifying valid show commands, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description merely mentions 'device' and 'command' without adding meaningful context like expected format, possible values, or relationship to other tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (run), the resource (read-only JUNOS 'show' command on a device), and the output (text). It distinguishes from the sibling tool list_devices which focuses on device listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is read-only, implying it should be used for non-mutating queries. However, it does not explicitly exclude commands that modify state or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_devicesrun_show_commandScored across 2 tools
The two tools have completely distinct purposes: one lists devices, the other runs a show command. There is no ambiguity or overlap between them.
Both tools follow the verb_noun pattern consistently: 'list_devices' and 'run_show_command'.
With only two tools, the server feels very minimal for managing JUNOS devices. It lacks essential operations like configuration or detailed device status beyond show commands.
The server covers only listing devices and running show commands. There are no CRUD operations, configuration management, or filtering capabilities, leaving significant gaps for typical device management tasks.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Read-only ArcadeOps discovery for developer docs, OAuth, OpenAPI and synthetic sandbox.
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Discover MCP servers, A2A agents, and shared agent knowledge through a read-only MCP gateway.
