Skip to main content
Glama
ruegreen

Cisco MCP Pods Server

by ruegreen
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

Cisco MCP Pods Server

An MCP (Model Context Protocol) server that connects to the Cisco API Gateway pods endpoints. This server enables AI agents (like Claude Desktop or Webex Connect) to interact with pod management data, manage pod configurations, update pod credentials, and perform complete CRUD operations through natural language.

Table of Contents

Deployment Modes

This server supports three transport modes:

1. stdio (Standard I/O) - For Claude Desktop

  • File: src/index.js

  • Communication: stdin/stdout

  • Usage: Runs locally as a child process

  • Perfect for: Claude Desktop application

  • Remote Access: ❌ Cannot be accessed remotely

  • Command: npm start

2. SSE (Server-Sent Events) - For Remote AI Agents

  • File: src/server-sse.js

  • Port: 1013

  • Endpoint: /CiscoMCPPods/sse

  • Usage: HTTP server with one-way streaming

  • Perfect for: Legacy remote AI agents

  • Remote Access: ✅ Can be deployed in the cloud

  • Command: npm run start:sse

3. Streamable HTTP - For Modern Remote AI Agents (Recommended)

  • File: src/server-http.js

  • Port: 1013

  • Endpoint: /CiscoMCPPods/mcp

  • Usage: HTTP server with bidirectional communication, session management, and resumability

  • Perfect for: WxConnect and modern AI agents that support the latest MCP spec

  • Remote Access: ✅ Can be deployed in the cloud

  • Features: Session-based, event replay, connection resumability

  • Command: npm run start:http

Which Transport Should I Use?

Scenario

Recommended Transport

Why

Claude Desktop (local)

stdio

Fastest, most efficient for local use

WxConnect (cloud)

Streamable HTTP

Modern protocol with resumability and better error handling

Legacy AI agents

SSE

Older protocol, widely supported

Testing locally

Any

All modes support local testing

Features

Tools (7 available)

  • get_pod_keyword - Get the pod keyword/password record

  • update_pod_keyword - Update the pod keyword/password with a new value

  • get_all_pods - Get all pods from a specific collection (ciscolivepods, coelabpods, etc.)

  • get_pod_by_number - Get a specific pod by its number from a collection

  • create_pod - Create new pod records in a collection

  • update_pod - Update existing pod information (status, credentials, test data, etc.)

  • delete_pod - Delete pod records from a collection

Resources (2 available)

  • pods://keyword - Access the current pod keyword configuration

  • pods://config - View current API configuration and connection status

Prerequisites

  1. Node.js >= 18.0.0 (for built-in fetch support and ES modules)

  2. Cisco API Gateway - Remote: http://apigateway.cxocoe.us or Local: http://localhost:3002

  3. Valid API Key or JWT token for authentication

Installation

# Clone or navigate to the project directory
cd CiscoMCPPods

# Install dependencies
npm install

Configuration

Environment Variables

Copy the example environment file and edit it:

cp .env.example .env

Edit .env with your settings:

# Cisco API Gateway Configuration
API_BASE_URL=http://apigateway.cxocoe.us

# Authentication (API Key recommended)
API_KEY_PODS=f42a9c8e3d7b1f6a2c5e8d4b9f3a6c1e7b5d2f9a8c4e1b6d3f7a2c5e8b1d4f9a3c6
AUTH_MODE=apikey

# MCP Server Configuration (for SSE/HTTP transport modes only)
SERVER_PORT=1013
SERVER_PATH=/CiscoMCPPods

# Public hostname (for deployment)
PUBLIC_HOSTNAME=ciscomcppods.cxocoe.us

# MCP Server Authentication
# API key required for client connections to this MCP server
# Generate a secure random key: node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
MCP_API_KEY=your-mcp-api-key-here

# 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/
ANTHROPIC_API_KEY=sk-ant-api03-your-key-here

Important:

  • The API_BASE_URL points to your Cisco API Gateway (backend), not the MCP server itself.

  • The MCP_API_KEY is used to authenticate clients connecting to this MCP server (not the API Gateway).

Usage: Claude Desktop (Local)

Claude Desktop is a desktop application that can run MCP servers locally on your computer.

Step 1: Locate Configuration File

On macOS:

~/Library/Application Support/Claude/claude_desktop_config.json

On Windows:

%APPDATA%/Claude/claude_desktop_config.json

Step 2: Edit Configuration

Open the file and add your MCP server configuration:

{
  "mcpServers": {
    "cisco-pods": {
      "command": "/Users/YOUR_USERNAME/.nvm/versions/node/v18.20.8/bin/node",
      "args": [
        "/FULL/PATH/TO/CiscoMCPPods/src/index.js"
      ]
    }
  }
}

Important Notes:

  • Replace /Users/YOUR_USERNAME/ with your actual user path

  • Replace /FULL/PATH/TO/ with the actual path to your project

  • Use full absolute paths, not relative paths

  • Point to Node.js 18+ (not the system default if it's older)

  • Use src/index.js for stdio mode, NOT src/server-sse.js or src/server-http.js

Step 3: Find Your Node.js Path

If using nvm:

which node
# or
nvm which 18

If using system Node.js:

which node

Use the full path in the config file.

Step 4: Restart Claude Desktop

  1. Quit Claude Desktop completely (Cmd+Q on Mac, or close completely on Windows)

  2. Reopen Claude Desktop

  3. The MCP server will start automatically

Step 5: Verify Connection

In Claude Desktop, try these prompts:

What tools do you have access to?
Get all pods from the ciscolivepods collection
Get pod keyword configuration

If connected successfully, AI agent will list the 7 pods tools and be able to execute them.

Troubleshooting Claude Desktop

If you see "Server disconnected":

  1. Check the logs:

    tail -f ~/Library/Logs/Claude/mcp-server-cisco-pods.log

  2. Common issues:

    • Wrong Node.js version: Must be 18+, check logs for syntax errors

    • .env not loading: Check that .env file exists in project root

    • API key missing: Check logs for "API_KEY_PODS is not configured"

    • Path errors: Make sure all paths in config are absolute, not relative

  3. Verify Node version:

    /path/to/your/node --version
# Should output v18.x.x or higher

Usage: Cloud Deployment (WxConnect)

Deploy the server to the cloud for remote AI agents like Webex Connect.

Step 1: Choose Your Transport Mode

Streamable HTTP (Recommended for WxConnect):

  • Modern protocol with session management

  • Automatic reconnection and event replay

  • Better error handling

  • Use npm run start:http

SSE (Legacy):

  • Simpler protocol

  • One-way streaming

  • Use npm run start:sse

For this guide, we'll use Streamable HTTP as it's the recommended approach.

Step 2: Prepare for Deployment

  1. Update .env for production:

    API_BASE_URL=http://apigateway.cxocoe.us
API_KEY_PODS=your-production-api-key
AUTH_MODE=apikey
SERVER_PORT=3010
SERVER_PATH=/CiscoMCPPods

  2. Ensure .gitignore excludes .env:

    # Check .gitignore includes:
.env
node_modules/

Step 3: Deploy to Your Server

Via SCP/SFTP:

# Copy project to server
scp -r CiscoMCPPods user@your-server:/path/to/apps/

Via Git:

# On your server
cd /path/to/apps
git clone your-repo-url CiscoMCPPods
cd CiscoMCPPods
npm install
cp .env.example .env
nano .env  # Edit with your settings

Step 4: Run Server

For testing:

# Streamable HTTP (Recommended)
npm run start:http

# OR SSE (Legacy)
npm run start:sse

For production (with PM2):

# Install PM2 globally
npm install -g pm2

# Start server with Streamable HTTP
pm2 start npm --name "mcp-pods-http" -- run start:http

# OR with SSE
pm2 start npm --name "mcp-pods-sse" -- run start:sse

# Save PM2 process list
pm2 save

# Set PM2 to start on boot
pm2 startup

For production (with systemd):

Create /etc/systemd/system/mcp-pods.service:

[Unit]
Description=MCP Pods Server (Streamable HTTP)
After=network.target

[Service]
Type=simple
User=your-user
WorkingDirectory=/path/to/CiscoMCPPods
ExecStart=/usr/bin/node src/server-http.js
Restart=always
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl enable mcp-pods
sudo systemctl start mcp-pods
sudo systemctl status mcp-pods

Step 5: Configure NGINX Reverse Proxy (Optional)

For Streamable HTTP, create NGINX configuration:

server {
    listen 80;
    server_name ciscomcppods.cxocoe.us ciscomcppods.cxocoe.us ciscomcphealth.cxocoe.us ciscomcpinsurance.cxocoe.us;

    # Pods MCP Server (Streamable HTTP)
    location /CiscoMCPPods/ {
        proxy_pass http://localhost:1013;
        proxy_http_version 1.1;

        # Required for Streamable HTTP
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header Mcp-Session-Id $http_mcp_session_id;
        proxy_set_header Last-Event-Id $http_last_event_id;

        # Required for API key authentication
        proxy_set_header X-API-Key $http_x_api_key;

        # Timeouts for long-lived connections
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_connect_timeout 75s;

        # SSE specific
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding off;
    }
}

Enable the site:

sudo ln -s /etc/nginx/sites-available/mcp-pods /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Step 6: Test Cloud Deployment

Test health endpoint:

curl http://ciscomcppods.cxocoe.us/CiscoMCPPods/health

Expected response:

{
  "status": "healthy",
  "service": "cisco-mcp-pods",
  "version": "1.0.0",
  "transport": "streamable-http",
  "apiBaseUrl": "http://apigateway.cxocoe.us",
  "timestamp": "2025-10-18T00:00:00.000Z"
}

Test MCP endpoint (with authentication):

curl -X POST http://ciscomcppods.cxocoe.us/CiscoMCPPods/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "X-API-Key: your-mcp-api-key" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": {"name": "test-client", "version": "1.0.0"}
    }
  }'

Step 7: Register with WxConnect

Once deployed, register your MCP server with Webex Connect:

For Streamable HTTP:

  • Endpoint URL: http://ciscomcppods.cxocoe.us/CiscoMCPPods/mcp

  • Transport Type: Streamable HTTP

  • Authentication: Include X-API-Key header with your MCP API key

For SSE (Legacy):

  • Endpoint URL: http://ciscomcppods.cxocoe.us/CiscoMCPPods/sse

  • Transport Type: SSE (Server-Sent Events)

  • Authentication: Include X-API-Key header with your MCP API key

WxConnect will validate the connection and start using your MCP server.

Testing

Local Testing (stdio mode)

Use Claude Desktop - see Usage: Claude Desktop

Cloud Testing (HTTP/SSE modes)

1. Health Check

curl http://localhost:1013/CiscoMCPPods/health

2. Server Info

curl http://localhost:1013/

3. Streamable HTTP Connection Test

# Initialize session
curl -X POST http://localhost:1013/CiscoMCPPods/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": {"name": "test", "version": "1.0.0"}
    }
  }'

4. SSE Connection Test

curl -N http://localhost:1013/CiscoMCPPods/sse

5. Automated Test Script

Run the included test script:

npm test

This comprehensive test suite includes:

  • Server status check

  • Health endpoint validation

  • SSE connection test

  • Message endpoint test

  • Beautiful colored output with test results

6. Interactive MCP Client with Anthropic AI (NEW!)

Test your MCP server end-to-end with a full AI agent integration:

npm run test:client

This interactive test tool:

  • ✅ Connects to your production MCP server with X-API-Key authentication

  • ✅ Integrates with Anthropic AI to demonstrate real agent-tool interaction

  • ✅ Provides an interactive chat interface - ask questions in natural language

  • ✅ AI agent automatically discovers and uses your MCP tools

  • ✅ See real-time tool execution and results

  • ✅ Validates the complete MCP workflow before WxConnect integration

Requirements:

Example session:

You: Show me all pods from ciscolivepods collection
[AI agent uses get_all_pods tool and displays results]

You: Get pod number 1 from ciscolivepods
[AI agent uses get_pod_by_number tool with the collection and number]

You: What's the pod keyword?
[AI agent uses get_pod_keyword tool]

You: quit
[Exits the interactive session]

This is the closest simulation to how WxConnect will use your MCP server!

7. MCP Inspector (Official Tool)

For Streamable HTTP:

npx @modelcontextprotocol/inspector http http://localhost:1013/CiscoMCPPods/mcp

For SSE:

npx @modelcontextprotocol/inspector sse http://localhost:1013/CiscoMCPPods/sse

This opens a web UI where you can:

  • View all available tools

  • Test each tool with different parameters

  • View resources

  • See JSON-RPC message flow

  • Monitor session state (for Streamable HTTP)

API Endpoints Mapping

This MCP server connects to the following Cisco API Gateway endpoints:

MCP Tool

API Endpoint

Method

get_pod_keyword

/api/v2/pods/keyword

GET

update_pod_keyword

/api/v2/pods/keyword

PATCH

get_all_pods

/api/v2/pods/{collection}

GET

get_pod_by_number

/api/v2/pods/{collection}/{number}

GET

create_pod

/api/v2/pods/{collection}

POST

update_pod

/api/v2/pods/{collection}/{number}

PATCH

delete_pod

/api/v2/pods/{collection}/{number}

DELETE

Project Structure

CiscoMCPPods/
├── src/
│   ├── index.js          # MCP server (stdio mode for Claude Desktop)
│   ├── server-sse.js     # MCP server (SSE mode for legacy AI agents)
│   ├── server-http.js    # MCP server (Streamable HTTP for modern AI agents)
│   ├── podsClient.js     # API client for pods endpoints
│   └── config.js         # Configuration management
├── .env                  # Environment variables (not in git)
├── .env.example          # Environment template
├── test-server.js        # Comprehensive test suite
├── nginx.conf.example    # NGINX reverse proxy configuration
├── package.json          # Project configuration
├── .gitignore           # Git ignore rules
└── README.md            # Documentation

Troubleshooting

Claude Desktop Issues

Server Disconnected:

# Check logs
tail -f ~/Library/Logs/Claude/mcp-server-cisco-pods.log

# Common fixes:
# 1. Use Node.js 18+ (check path in config)
# 2. Use absolute paths in claude_desktop_config.json
# 3. Ensure .env file exists with API_KEY_PODS

API Authentication Errors:

  • Check .env file exists in project root

  • Verify API_KEY_PODS is set correctly

  • Check API_BASE_URL points to Cisco API Gateway

Cloud Deployment Issues

Port Already in Use:

# Find what's using port 1013
lsof -i :1013
# or
netstat -tulpn | grep 1013

# Kill the process or use different port

Health Check Fails:

# Check if server is running
ps aux | grep server-http.js

# Check server logs
journalctl -u mcp-pods -f  # if using systemd
pm2 logs mcp-pods          # if using PM2

Session Issues (Streamable HTTP):

  • Verify Mcp-Session-Id header is being sent correctly

  • Check server logs for session initialization messages

  • Ensure NGINX passes through session headers

NGINX Issues:

# Test NGINX config
sudo nginx -t

# Check NGINX error log
sudo tail -f /var/log/nginx/error.log

# Restart NGINX
sudo systemctl restart nginx

Firewall Issues:

# Allow port 3010 (if not using NGINX)
sudo ufw allow 3010/tcp

# Allow port 80 (if using NGINX)
sudo ufw allow 80/tcp

API Gateway Connection Issues

Cannot reach API Gateway:

  • Verify API_BASE_URL in .env

  • Test connection manually:

    curl http://apigateway.cxocoe.us/api/v2/pods/keyword \
  -H "x-api-key: YOUR_API_KEY"

Authentication Failures:

  • Verify API key matches your Cisco API Gateway configuration

  • Check if API key has 'pods' permissions

  • Try with master API key for testing

Running Multiple MCP Servers

To run Pods, Healthcare, Insurance, and Retail MCP servers together:

  1. Each server has its own directory:

    CiscoMCPPods/       (Port 1013)
CiscoMCPPods/     (Port 3010)
CiscoMCPHealthcare/ (Port 3011)
CiscoMCPInsurance/  (Port 3012)

  2. Each has unique configuration in .env:

    # Pods
SERVER_PORT=1013
SERVER_PATH=/CiscoMCPPods
API_KEY_PODS=f42a9c8e3d7b1f6a2c5e8d4b9f3a6c1e7b5d2f9a8c4e1b6d3f7a2c5e8b1d4f9a3c6

# Healthcare
SERVER_PORT=3011
SERVER_PATH=/CiscoMCPHealthcare
API_KEY_HEALTH=b81108cab4b0d0db3beccc9c2a71888d43d4d7acddc7b9024ee715c15474a856

# Insurance
SERVER_PORT=3012
SERVER_PATH=/CiscoMCPInsurance
API_KEY_INSURANCE=e64d49daa3709f4ebaa60d6cd0513162b3216860961315a34646e99666900b0a

  3. Update NGINX to proxy all four (add location blocks for each)

  4. Register each with WxConnect (with API key authentication):

    • Pods: http://ciscomcppods.cxocoe.us/CiscoMCPPods/mcp

    • Retail: http://ciscomcppods.cxocoe.us/CiscoMCPPods/mcp

    • Healthcare: http://ciscomcphealth.cxocoe.us/CiscoMCPHealthcare/mcp

    • Insurance: http://ciscomcpinsurance.cxocoe.us/CiscoMCPInsurance/mcp

    Important: Include X-API-Key header with each server's unique API key

Security Considerations

For Production Deployment:

  1. Use HTTPS - Update NGINX config with SSL certificates

  2. Firewall - Only expose necessary ports (1013 for Pods)

  3. API Keys - Store in environment variables, never commit to git

  4. NGINX - Use as reverse proxy instead of exposing Node.js directly

  5. Rate Limiting - Configure in NGINX

  6. Monitoring - Set up health check monitoring

  7. Session Security - For Streamable HTTP, consider implementing session timeout policies

Transport Comparison

Feature

stdio

SSE

Streamable HTTP

Local Use

✅ Best

❌ Not needed

❌ Not needed

Remote Use

❌ No

✅ Yes

✅ Yes

Session Management

N/A

❌ No

✅ Yes

Resumability

N/A

❌ No

✅ Yes

Event Replay

N/A

❌ No

✅ Yes

Bidirectional

✅ Yes

❌ One-way

✅ Yes

Connection Recovery

N/A

⚠️ Manual

✅ Automatic

WxConnect Support

❌ No

✅ Yes (Legacy)

✅ Yes (Recommended)

Author

Rue Green Customer Care Architect and Developer Cisco Systems, INC.

License

MIT

Support

For issues or questions:

  1. Check logs (Claude Desktop or server logs)

  2. Verify .env configuration

  3. Test API Gateway connection directly

  4. Review error messages for specific issues

  5. Run npm test to verify server functionality

Version: 1.0.0 Last Updated: October 2025

Available Tools

7 tools
create_podC

Create a new pod in a collection. All required fields must be provided.

ParametersJSON Schema
NameRequiredDescriptionDefault
AdminLoginYesAdmin email login (e.g., admin1@coelab.wbx.ai)
AgentLoginYesAgent email login
CRMLoginYesCRM username
CRMPasswordYesCRM password
NumberYesUnique pod number
PODYesPod name (e.g., Pod1, TestPod1)
PasswordYesPod password
SMSNumberYesSMS number (e.g., 14085386001)
StatusYesPod status (e.g., unassigned, assigned)
SupervisorLoginYesSupervisor email login
TelephoneNumberYesTelephone number (e.g., 16692845001)
TestDateNoTest date (optional)
TestStatusNoTest status (optional)
collectionYesCollection name to add the pod to

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Create a new pod' implying a write/mutation operation, but doesn't disclose permissions needed, side effects (e.g., if it affects existing pods), rate limits, or what happens on failure. The requirement for all fields is noted, but overall transparency is lacking for a creation 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 extremely concise with two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds a critical constraint. Every word earns its place, making it easy to parse quickly.

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 complexity (14 parameters, 12 required) and lack of annotations or output schema, the description is incomplete. It doesn't explain what a 'pod' is, the creation process, expected outcomes, error handling, or how it interacts with the collection. For a tool with many parameters and no structured safety hints, more context is needed to guide effective use.

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 100%, so the schema fully documents all 14 parameters. The description adds no additional parameter semantics beyond stating 'All required fields must be provided,' which is implied by the required array. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like field relationships or examples.

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 action ('Create a new pod') and resource ('in a collection'), making the purpose evident. It distinguishes from siblings like delete_pod or update_pod by focusing on creation, but doesn't explicitly differentiate from tools like get_all_pods beyond the verb. The mention of 'All required fields must be provided' adds specificity about prerequisites.

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 like update_pod or delete_pod. It mentions that required fields must be provided, which is a prerequisite but not usage context. There's no indication of scenarios, dependencies, or comparisons with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_podC

Delete a pod from a collection by its number.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionYesCollection name
numberYesPod number to delete

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the basic action without disclosing critical behavioral traits. It doesn't warn that deletion is irreversible, mention permission requirements, indicate if confirmation is needed, or describe what happens to associated data. For a destructive tool, this leaves significant gaps in understanding its behavior.

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, direct sentence with zero wasted words. It front-loads the core action ('Delete') and efficiently specifies the target, making it easy to parse quickly. Every word earns its place without redundancy or fluff.

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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on side effects, error conditions, return values, or safety considerations. For a tool that permanently removes resources, more context is needed to use it appropriately and safely.

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 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'collection' and 'number' identify the pod to delete, which is already clear from the schema. This meets the baseline for high schema coverage without enhancing parameter understanding.

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 action ('Delete') and target resource ('a pod from a collection'), making the purpose immediately understandable. However, it doesn't differentiate this destructive operation from sibling tools like 'update_pod' or 'get_pod_by_number' beyond the obvious verb difference, missing explicit contrast in scope or consequences.

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 prerequisites (e.g., pod must exist), exclusions (e.g., cannot delete if in use), or suggest alternatives like 'update_pod' for modifications instead of deletion. The agent must infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_all_podsB

Get all pods from a specific collection. Works with any collection name like ciscolivepods, coelabpods, testpods, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionYesCollection name (e.g., ciscolivepods, coelabpods, testpods)

TDQS

B3.1/5.0
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 states the tool 'Get all pods' and works with collections, but doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the return format looks like (e.g., list of pod objects). For a tool with no annotation coverage, this is a significant gap in transparency.

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 concise and front-loaded with the core purpose in the first sentence. The second sentence adds useful context about collection examples without redundancy. It avoids unnecessary details, making it efficient, though it could be slightly more structured by explicitly stating the tool's scope or limitations.

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 complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'pods' are, the format of the returned data, potential errors, or behavioral aspects like safety or performance. For a tool interacting with collections and pods, more context is needed to ensure proper agent 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?

The description adds minimal value beyond the input schema, which has 100% coverage for the single parameter 'collection'. It provides examples of collection names ('ciscolivepods, coelabpods, testpods, etc.') that mirror the schema's description, but doesn't explain semantics like what a 'collection' represents, if there are constraints beyond being a string, or how it relates to pods. With high schema coverage, the 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 clearly states the tool's purpose: 'Get all pods from a specific collection.' It specifies the verb ('Get') and resource ('pods'), and distinguishes it from siblings like get_pod_by_number (which retrieves a single pod by number) and get_pod_keyword (which likely filters by keyword). However, it doesn't explicitly differentiate from other list-like operations if any exist beyond the named siblings.

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 by stating it works with 'any collection name like ciscolivepods, coelabpods, testpods, etc.,' which suggests it's for retrieving all pods from a known collection. It doesn't provide explicit guidance on when to use this tool versus alternatives like get_pod_by_number or get_pod_keyword, nor does it mention prerequisites or exclusions, leaving usage context somewhat inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pod_by_numberC

Get a specific pod by its number from a collection. Returns pod details including login credentials, phone numbers, and status.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionYesCollection name (e.g., ciscolivepods)
numberYesPod number (e.g., 1, 2, 3)

TDQS

C2.9/5.0
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 mentions that the tool returns pod details including login credentials, phone numbers, and status, which adds some context about sensitive data. However, it lacks critical behavioral traits such as whether this is a read-only operation, authentication requirements, error handling, or rate limits, leaving significant gaps for a mutation-free tool.

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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second specifies return details. There is minimal waste, though it could be slightly more structured by explicitly separating purpose from output.

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's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return details but lacks information on usage guidelines, behavioral traits, and error handling. With no output schema, it should ideally explain return values more thoroughly, but it provides a basic overview.

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 100%, so the input schema already fully documents both parameters (collection and number) with descriptions and types. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in the baseline score of 3.

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 action ('Get a specific pod by its number') and resource ('from a collection'), with specific return details mentioned. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_pod_keyword' or 'get_all_pods', which would require sibling differentiation for a score of 5.

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_pod_keyword' (which might fetch by keyword instead of number) or 'get_all_pods' (which retrieves all pods). The description implies usage for retrieving a specific pod by number but offers no explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pod_keywordB

Get the pod keyword/password record. Returns the current keyword configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
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 the tool returns configuration data, which hints at read-only behavior, but doesn't clarify permissions, rate limits, error conditions, or what 'current' means in terms of freshness or caching. This is a significant gap for a tool with zero annotation coverage.

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, efficient sentence that front-loads the purpose and outcome. It avoids redundancy and wastes no words, though it could be slightly more structured by separating intent from result for clarity.

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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output specifics, leaving gaps that could hinder effective agent invocation without additional context.

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 0 parameters with 100% schema description coverage, so the schema fully documents the input structure. The description adds no parameter-specific information, which is acceptable given no parameters exist, aligning with the baseline expectation for such cases.

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 action ('Get') and resource ('pod keyword/password record'), specifying it returns configuration data. It distinguishes from siblings like create_pod or delete_pod by focusing on retrieval, though it doesn't explicitly differentiate from get_all_pods or get_pod_by_number.

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 like get_pod_by_number or update_pod_keyword. It implies usage for retrieving keyword configuration but offers no context on prerequisites, exclusions, or comparative scenarios with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_podC

Update an existing pod in a collection. Can update status, credentials, test information, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionYesCollection name
numberYesPod number to update
updatesYesFields to update

TDQS

C2.9/5.0
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. While 'Update' implies a mutation operation, the description lacks details on permissions required, whether updates are reversible, rate limits, error handling, or what happens to unspecified fields. It mentions updating 'credentials' which could imply security implications, but doesn't elaborate on authentication needs or data sensitivity.

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, efficient sentence that front-loads the core action ('Update an existing pod in a collection') and adds brief examples of updatable fields. There's no unnecessary verbiage, and it effectively communicates the tool's scope without redundancy. However, it could be slightly more structured by explicitly separating purpose from usage examples.

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 complexity (mutation operation with 3 parameters including a nested object), lack of annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly and interpret results.

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 100%, so the schema already documents all parameters ('collection', 'number', 'updates') and nested properties. The description adds minimal value beyond the schema by listing example fields ('status, credentials, test information') that map to the 'updates' object, but doesn't provide additional syntax, format, or constraint details. This meets 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 clearly states the verb ('Update') and resource ('an existing pod in a collection'), making the purpose evident. It distinguishes from 'create_pod' by specifying 'existing' and from 'delete_pod' by focusing on updates rather than removal. However, it doesn't explicitly differentiate from 'update_pod_keyword', which might handle different aspects of pod updates.

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 like 'update_pod_keyword' or other sibling tools. It mentions updating 'status, credentials, test information, etc.', but doesn't specify prerequisites, exclusions, or contextual triggers for choosing this tool over others in the server.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_pod_keywordC

Update the pod keyword/password record with a new value.

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesNew keyword/password value (e.g., Cisco1234!)

TDQS

C2.9/5.0
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 states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether the change is reversible, potential side effects, or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding, achieving optimal 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?

Given the tool's complexity as a mutation operation, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances. For a tool that modifies data, this level of detail is inadequate, leaving the agent with insufficient context for reliable use.

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 description mentions updating 'with a new value', which aligns with the single parameter 'keyword' in the schema. Since schema description coverage is 100% (the parameter is well-documented with an example), the description adds minimal value beyond what the schema provides. The baseline score of 3 is appropriate as the schema does the heavy lifting for parameter semantics.

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 action ('update') and the target resource ('pod keyword/password record'), making the purpose understandable. It specifies what gets updated ('with a new value'), which is specific. However, it doesn't explicitly differentiate from sibling tools like 'update_pod' or 'get_pod_keyword', leaving some ambiguity about when to choose this tool over others.

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 doesn't mention prerequisites (e.g., needing an existing pod), exclusions, or comparisons to siblings like 'update_pod' or 'get_pod_keyword'. Without such context, an agent must infer usage from the tool name alone, which is insufficient for optimal selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • First observedcreate_pod
    • First observeddelete_pod
    • First observedget_all_pods
    • First observedget_pod_by_number
    • First observedget_pod_keyword
    • First observedupdate_pod
    • First observedupdate_pod_keyword
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Latest Blog Posts

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/ruegreen/CiscoMCPPods'

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