Provides tools for managing Docker containers and Docker Compose services, including reading logs with advanced filtering, inspecting container details, listing containers, and executing commands within containers.
Enables interaction with Kubernetes clusters to manage pods and deployments, providing capabilities to read logs, list pods, describe resources, fetch events, and execute commands within pods across different namespaces and contexts.
Click on "Install 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., "@MCP Container Tools show me the last 50 error logs from the api pod in the production namespace"
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.
A Model Context Protocol (MCP) server for Docker, Kubernetes, and Azure Application Insights with advanced log filtering and monitoring capabilities.
🐳 Docker — Container logs, inspect, exec, list containers
🐙 Docker Compose — Service logs, start/stop/restart services
☸️ Kubernetes — Pod logs, deployment logs, events, exec into pods
☁️ Azure Application Insights — Exceptions, traces, requests, metrics
🔍 Log Filtering — Filter by log level, regex patterns, exclude patterns
🌐 Remote Support — Connect to remote Docker hosts via SSH or TCP
Related MCP server: debugpy-mcp
Requirement | Version | Required For |
🐍 Python | 3.11+ | All |
🐳 Docker | Latest | Docker tools |
☸️ kubectl | Latest | Kubernetes tools |
☁️ Azure CLI | Latest | Azure tools (optional) |
# Basic installation
pip install mcp-container-tools
# With Azure Application Insights support
pip install mcp-container-tools[azure]# Latest version from GitHub
pip install git+https://github.com/simseksem/mcp-container-tools.git
# With Azure support
pip install "mcp-container-tools[azure] @ git+https://github.com/simseksem/mcp-container-tools.git"git clone https://github.com/simseksem/mcp-container-tools.git
cd mcp-container-tools
pip install -e ".[all]"mcp-server --helpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"container-tools": {
"command": "/path/to/mcp-container-tools/.venv/bin/python",
"args": ["-m", "mcp_server.server"],
"env": {
"AZURE_LOG_ANALYTICS_WORKSPACE_ID": "your-workspace-id",
"AZURE_APP_INSIGHTS_RESOURCE_ID": "/subscriptions/.../resourceGroups/.../providers/microsoft.insights/components/..."
}
}
}
}Add to ~/.claude/settings.json or create .mcp.json in your project:
{
"mcpServers": {
"container-tools": {
"command": "/path/to/mcp-container-tools/.venv/bin/python",
"args": ["-m", "mcp_server.server"]
}
}
}Azure tools use DefaultAzureCredential which supports:
Azure CLI (az login)
Environment variables
Managed Identity
Visual Studio Code
# Easiest: Login with Azure CLI
az login# Read container logs
docker_logs(container="my-app", tail=100)
# Read logs from last 30 minutes
docker_logs(container="my-app", since="30m")
# Filter by log level (only errors and above)
docker_logs(container="my-app", min_level="error")
# Search for patterns
docker_logs(container="my-app", pattern="timeout|connection refused")
# Exclude health checks
docker_logs(container="my-app", exclude_pattern="GET /health")
# Remote Docker host via SSH
docker_logs(container="my-app", host="ssh://user@server.com")
# List containers
docker_ps(all=True)# Read service logs
compose_logs(service="api", tail=200)
# Read all services logs
compose_logs(project_dir="/path/to/project")
# Service management
compose_up(service="api", project_dir="/path/to/project")
compose_down(project_dir="/path/to/project")
compose_restart(service="api")# Read pod logs
k8s_logs(pod="api-7d4b8c6f9-x2k4m", namespace="production")
# Read logs from all pods in a deployment
k8s_deployment_logs(deployment="api", namespace="production")
# Filter logs
k8s_logs(pod="api-*", min_level="warn", pattern="database")
# Use different context
k8s_logs(pod="my-pod", context="production-cluster", namespace="backend")
# List pods
k8s_pods(namespace="all", selector="app=api")
# Get events
k8s_events(namespace="production")
# Execute command in pod
k8s_exec(pod="api-xyz", command="printenv", namespace="production")# Query exceptions from last hour
azure_exceptions(timespan="PT1H", limit=50)
# Get only critical exceptions
azure_exceptions(severity="critical", search="NullReference")
# Query application traces
azure_traces(timespan="PT1H", severity="error")
# Query HTTP requests
azure_requests(timespan="PT1H", failed_only=True)
# Get slow requests (>1 second)
azure_requests(min_duration_ms=1000, limit=20)
# Query external dependencies (SQL, HTTP, etc.)
azure_dependencies(timespan="PT1H", failed_only=True, type_filter="SQL")
# Get metrics
azure_metrics(metric_name="requests/count", timespan="P1D", interval="PT1H")
# Query availability test results
azure_availability(timespan="P1D", failed_only=True)
# Run custom Kusto query
azure_query(query="""
requests
| where success == false
| summarize count() by bin(timestamp, 1h), resultCode
| order by timestamp desc
""", timespan="P1D")All log tools support these filtering options:
Option | Description | Example |
| Minimum log level |
|
| Regex to include |
|
| Regex to exclude |
|
| Lines around matches |
|
Supported log levels: trace → debug → info → warn → error → fatal
Azure tools use ISO 8601 duration format:
Format | Duration |
| 1 hour |
| 30 minutes |
| 1 day |
| 7 days |
Tool | Description |
| 📄 Read container logs with filtering |
| 📋 List containers |
| 🔎 Get container details |
| ⚡ Execute command in container |
Tool | Description |
| 📄 Read service logs |
| 📋 List services |
| ▶️ Start services |
| ⏹️ Stop services |
| 🔄 Restart services |
Tool | Description |
| 📄 Read pod logs |
| 📚 Read deployment logs |
| 📋 List pods |
| 🔎 Describe pod |
| ⚡ Execute in pod |
| 📢 Get events |
| 🌐 List contexts |
Tool | Description |
| 🔍 Run custom Kusto queries |
| ❌ Query application exceptions |
| 📝 Query application traces |
| 🌐 Query HTTP requests |
| 🔗 Query external dependencies |
| 📊 Query metrics |
| ✅ Query availability tests |
pip install -e ".[all]"pytestruff check .
mypy src/mcp-container-tools/
├── 📂 src/mcp_server/
│ ├── 📄 __init__.py
│ ├── 📄 server.py # Main server entry point
│ ├── 📂 tools/
│ │ ├── 🐳 docker.py # Docker tools
│ │ ├── 🐙 docker_compose.py # Compose tools
│ │ ├── ☸️ kubernetes.py # K8s tools
│ │ ├── ☁️ azure_insights.py # Azure App Insights
│ │ └── 📁 file_operations.py # File tools
│ ├── 📂 resources/
│ │ ├── ⚙️ config.py # Config resources
│ │ └── 📊 data.py # Data resources
│ ├── 📂 prompts/
│ │ └── 📝 templates.py # Prompt templates
│ └── 📂 utils/
│ └── 🔍 log_filter.py # Log filtering
├── 📂 tests/
├── 📄 pyproject.toml
└── 📄 README.mdVariable | Description |
| Azure Log Analytics workspace ID |
| Azure Application Insights resource ID |
MIT License - see LICENSE for details.
Query availability test results
| Name | Required | Description | Default |
|---|---|---|---|
| timespan | No | ISO 8601 duration | P1D |
| limit | No | Maximum number of results | |
| test_name | No | Filter by test name | |
| failed_only | No | Show only failed tests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or required permissions. It only states the basic purpose, offering no transparency.
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?
The description is a single concise sentence, but it lacks details that could be included without significant bloat. It is front-loaded but minimal.
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 the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, pagination, or error handling.
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 100%, so the baseline is 3. The description does not add any extra meaning beyond the schema, merely restating the tool's function.
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 'Query availability test results' uses a specific verb and resource, clearly distinguishing this tool from siblings like azure_dependencies or azure_metrics.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query external dependencies (HTTP, SQL, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| timespan | No | ISO 8601 duration | PT1H |
| limit | No | Maximum number of results | |
| failed_only | No | Show only failed dependencies | |
| type_filter | No | Filter by type (HTTP, SQL, Azure, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether the query is read-only, expected response format, or any side effects. The description carries the full burden but fails to provide this context.
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?
The description is very short (one phrase) and directly conveys the core purpose. It is not overly verbose, but could benefit from a bit more detail without becoming lengthy. It strikes a reasonable balance.
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?
The description lacks information about output format, pagination, or any prerequisites. Given the absence of an output schema and annotations, the agent may struggle to use the tool effectively. More context is needed for completeness.
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?
All four parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The tool description does not add additional semantics beyond what the schema already provides, which is acceptable given the schema coverage.
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 verb 'Query' and the resource 'external dependencies (HTTP, SQL, etc.)', distinguishing it from sibling tools like azure_requests or azure_traces which focus on other aspects. However, it could be more specific about the context (e.g., Application Insights dependencies).
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?
No guidance is provided on when to use this tool versus alternatives like azure_requests or azure_traces. The agent is left to infer the appropriate context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query application exceptions and errors
| Name | Required | Description | Default |
|---|---|---|---|
| timespan | No | ISO 8601 duration | PT1H |
| limit | No | Maximum number of results | |
| severity | No | Filter by severity level | |
| search | No | Search in exception messages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, rate limits, or result ordering. The description merely repeats the basic purpose without additional transparency.
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?
The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient, though slightly under-specified.
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 4 well-described parameters and no output schema, the description is minimally adequate. It does not explain return format or behavior, but the schema covers inputs adequately.
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 coverage is 100% with all parameters having descriptions (timespan, limit, severity, search). The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
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 uses a specific verb 'Query' and clearly identifies the resource 'application exceptions and errors'. It distinguishes from sibling tools like azure_availability, azure_traces, etc., which focus on other telemetry types.
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?
No guidance is provided on when to use this tool vs. alternatives (e.g., azure_traces for distributed traces). There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query Application Insights metrics
| Name | Required | Description | Default |
|---|---|---|---|
| metric_name | Yes | Metric name (e.g., requests/count, exceptions/count) | |
| timespan | No | ISO 8601 duration | PT1H |
| interval | No | Aggregation interval | PT5M |
| aggregation | No | Aggregation type | avg |
| resource_id | No | Azure resource ID (uses AZURE_APP_INSIGHTS_RESOURCE_ID env if not set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. The minimal description 'Query Application Insights metrics' does not state whether the tool is read-only, has side effects, requires permissions, or has rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and efficient, though it could benefit from additional context for a tool with five parameters.
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 the tool's complexity (5 parameters, no output schema, no annotations), the description is severely inadequate. It fails to explain what the tool returns, any constraints, or how to interpret results, leaving the agent with insufficient information to use it effectively.
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 100% (all parameters have descriptions). The baseline for high coverage is 3. The description adds no additional meaning beyond what the schema already provides, earning a score of 3.
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 'Query Application Insights metrics' clearly identifies the action (query) and the resource (Application Insights metrics). However, it does not explicitly differentiate from sibling tools like azure_availability or azure_requests, which may also query Azure resources.
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 provides no guidance on when to use this tool versus alternatives. It lacks context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a custom Kusto query on Application Insights logs
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Kusto query to execute | |
| timespan | No | ISO 8601 duration (PT1H=1 hour, P1D=1 day, P7D=7 days) | PT1H |
| workspace_id | No | Log Analytics workspace ID (or set AZURE_LOG_ANALYTICS_WORKSPACE_ID) |
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 only states 'run a query,' implying read-only behavior, but does not explicitly confirm non-destructiveness, rate limits, authentication requirements, or failure handling. The schema covers parameters but not runtime behavior.
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, front-loaded with purpose. Efficient with no wasted words. However, it could be slightly restructured to include usage hints or formatting for clarity. Still above average.
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?
No output schema is provided, so the description should explain return values or result format, but it does not. For a complex tool involving Kusto queries, users need examples, constraints on query complexity, or hints about result limits. The description is too minimal.
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 100%, so baseline is 3. The description adds no extra meaning beyond the schema. The schema itself describes the query, timespan, and workspace_id parameters adequately. The tool name and description already imply the query parameter.
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 tool runs a custom Kusto query on Application Insights logs, using a specific verb and resource. It distinguishes from sibling tools like azure_requests or azure_metrics, which are pre-defined for specific data types, by emphasizing custom queries.
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?
No guidance on when to use this tool versus the pre-defined sibling tools. An agent would not know whether to use azure_query or a specialized tool like azure_requests for specific tasks. No exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query HTTP requests to your application
| Name | Required | Description | Default |
|---|---|---|---|
| timespan | No | ISO 8601 duration | PT1H |
| limit | No | Maximum number of results | |
| failed_only | No | Show only failed requests | |
| min_duration_ms | No | Minimum duration in milliseconds | |
| url_filter | No | Filter by URL pattern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Query HTTP requests', which implies read-only operation but doesn't confirm. There's no mention of side effects, rate limits, or data scope, leaving significant ambiguity.
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?
The description is a single sentence, which is concise but under-specifies the tool's functionality for a tool with 5 parameters. It could benefit from additional context without being verbose.
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 the lack of output schema and annotations, the description should explain what the tool returns or any side effects. It does not, leaving the agent without crucial context for effective invocation.
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 coverage is 100%, and all parameters have descriptions in the schema (e.g., 'ISO 8601 duration'). The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline but offers no extra value.
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 'Query HTTP requests to your application' uses a verb and resource, clearly indicating the tool deals with HTTP requests. However, it fails to distinguish from sibling tools like 'azure_traces' which may also relate to request data. The scope of 'query' is vague—does it list, filter, or aggregate?
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?
No guidance is provided on when to use this tool versus alternatives. There are no preconditions, exclusions, or mentions of sibling tools, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query application traces and logs
| Name | Required | Description | Default |
|---|---|---|---|
| timespan | No | ISO 8601 duration | PT1H |
| limit | No | Maximum number of results | |
| severity | No | Filter by severity level | |
| search | No | Search in trace messages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read operation ('Query'), but lacks details on permissions, rate limits, or other behavioral traits. Adequate but minimal.
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?
The description is a single sentence, which is concise. However, it lacks structure and could benefit from summarizing key parameters or usage context without being overly verbose.
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?
For a simple query tool with no output schema and well-documented parameters, the description is minimally complete. However, given the sibling tools, additional context on what makes this tool unique would improve completeness.
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 coverage is 100%, with all four parameters fully described in the input schema. The description adds no additional meaning beyond what the schema provides, resulting in the baseline score.
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 'Query application traces and logs' clearly states the verb and resource, making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like azure_query or azure_dependencies, which could cause confusion.
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 implies the tool is for querying traces and logs, but provides no explicit guidance on when to use it versus alternatives like azure_metrics or azure_exceptions. No when-not or prerequisites are mentioned.
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. Dates show when Glama detected each change.
v0.1.0azure_availabilityazure_dependenciesazure_exceptionsazure_metricsazure_queryazure_requestsazure_tracesEach tool targets a distinct data type in Application Insights (availability, dependencies, exceptions, metrics, custom query, requests, traces), with clear boundaries and no overlap in purpose.
All tools follow a consistent 'azure_<noun>' pattern in snake_case, making them predictable and easy to navigate.
7 tools is well-scoped for querying Azure Application Insights – not too few to miss essential data types, not too many to overwhelm.
Covers all major telemetry types (availability, dependencies, exceptions, metrics, requests, traces) plus custom queries; missing only niche features like live metrics streams or application map, which are minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
MCP server for Appcircle mobile CI/CD platform.
MCP Server for JFrog, providing tools for development and artifact management.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/simseksem/mcp-container-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
