SDN MCP Template
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Host address for the MCP server | 127.0.0.1 |
| MCP_PORT | No | Port for the MCP server | 8000 |
| SDN_TOKEN | No | Bearer token for SDN controller authentication (required if auth_type=bearer) | |
| SDN_PASSWORD | No | Password for basic auth with SDN controller (required if auth_type=basic) | |
| SDN_USERNAME | No | Username for basic auth with SDN controller (required if auth_type=basic) | |
| MCP_LOG_LEVEL | No | Log level for the MCP server | INFO |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Echo back a message to verify the MCP server is reachable. |
| sdn_healthA | Check connectivity to the SDN controller. Returns a structured status dict {ok, configured, detail?, status_code?, latency_ms?}. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
ping and sdn_health have clearly distinct purposes: one is a generic echo, the other is a specific health check for the SDN controller. No overlap.
The naming conventions are inconsistent: 'ping' is a single verb, while 'sdn_health' is a compound noun with underscore. No discernible pattern between the two tools.
With only 2 tools, the server feels too minimal for an SDN-related MCP server. A template might justify this, but the implied scope requires more tools for practical use.
The tool surface is severely incomplete for any SDN-related workflow. Only a ping and a health check are provided, lacking any operational tools like listing devices or configuring the controller.