Cisco MCP Pods Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | Authentication mode for the API Gateway | apikey |
| MCP_API_KEY | No | API key required for client connections to this MCP server | |
| SERVER_PATH | No | Path prefix for the MCP server endpoints | /CiscoMCPPods |
| SERVER_PORT | No | Port for the MCP server (for SSE/HTTP transport modes only) | 1013 |
| API_BASE_URL | No | The base URL for the Cisco API Gateway | http://apigateway.cxocoe.us |
| API_KEY_PODS | Yes | Your API key for authentication with the Cisco API Gateway | |
| PUBLIC_HOSTNAME | No | Public hostname for deployment (e.g., ciscomcppods.cxocoe.us) | |
| ANTHROPIC_API_KEY | No | Anthropic API key (optional - for test-mcp-client.js only). Required for the interactive MCP client tester with Anthropic AI integration. Get your key from: https://console.anthropic.com/ |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_pod_keywordB | Get the pod keyword/password record. Returns the current keyword configuration. |
| update_pod_keywordC | Update the pod keyword/password record with a new value. |
| get_all_podsB | Get all pods from a specific collection. Works with any collection name like ciscolivepods, coelabpods, testpods, etc. |
| get_pod_by_numberC | Get a specific pod by its number from a collection. Returns pod details including login credentials, phone numbers, and status. |
| create_podC | Create a new pod in a collection. All required fields must be provided. |
| update_podC | Update an existing pod in a collection. Can update status, credentials, test information, etc. |
| delete_podC | Delete a pod from a collection by its number. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Pod Keyword | Current pod keyword/password configuration |
| API Configuration | Current API Gateway configuration and connection status |
TDQS
Scored across 7 tools
Most tools have distinct purposes targeting pods (create, delete, get_all, get_by_number, update) and pod keywords (get_keyword, update_keyword), with clear separation between pod management and keyword operations. However, 'get_pod_by_number' and 'update_pod' could potentially overlap in retrieval/update scenarios, but their descriptions clarify distinct primary functions.
All tools follow a consistent verb_noun pattern with snake_case (e.g., create_pod, delete_pod, get_all_pods). The naming is predictable and uniform across the set, making it easy for agents to understand and navigate the tool surface without confusion.
With 7 tools, the server is well-scoped for managing pods and keywords in a collection. Each tool serves a clear purpose (CRUD operations for pods, plus keyword handling), and the count is appropriate for the domain without being overwhelming or insufficient.
The tool set provides complete CRUD coverage for pods (create, get_all, get_by_number, update, delete) and dedicated tools for keyword management (get and update). There are no obvious gaps for the stated purpose of pod and keyword management in collections, ensuring agents can handle full lifecycles without dead ends.