3.5.0

[call518]

MCP-OpenStack-Ops v3.5.0 — First Official Release 🎉

This is the first official GitHub Release of MCP-OpenStack-Ops, a comprehensive
Model Context Protocol (MCP) server that brings
OpenStack operations directly into AI assistants such as Claude Desktop, OpenWebUI, and any
MCP-compatible client.

---

What is MCP-OpenStack-Ops?

MCP-OpenStack-Ops exposes 90+ purpose-built MCP tools covering every major OpenStack
service — all scoped to a single project/tenant for safety and auditability.
You can ask your AI assistant questions like:

• "Show me all running instances with less than 10 % CPU usage"
• "Create a load balancer listener on port 443 for pool web-pool"
• "What is the current quota usage for project dev?"

and get structured, actionable answers backed by real OpenStack API calls.

---

Key Features

Safety-First Design

• Project-scoped by default — every tool enforces OS_PROJECT_NAME, preventing
  cross-tenant accidents.
• Read-only by default — write/modify tools (set_*) only activate when
  ALLOW_MODIFY_OPERATIONS=true is explicitly set.
• Bearer token authentication — optional HTTP Bearer token to secure the MCP endpoint
  itself.

Broad OpenStack Coverage

Domain	Highlights
Compute	Instances, server groups, migrations, console, server events, hypervisors
Networking	Networks, subnets, routers, floating IPs, port-forwarding, security groups, QoS
Storage (Cinder)	Volumes, snapshots, backups, volume groups, QoS
Images (Glance)	Image list/detail, metadata, visibility, members
Identity (Keystone)	Users, roles, role assignments, projects, domains, groups
Orchestration (Heat)	Stack list, details, create/update/delete
Load Balancing (Octavia)	Load balancers, listeners, pools, members, health monitors, L7 policies/rules, amphorae, flavors, AZs
Monitoring	Cluster status, resource monitoring, usage statistics, service status

Deployment Flexibility

• stdio mode — embed directly in Claude Desktop / local AI clients
• HTTP/SSE mode — run as a standalone server behind any reverse proxy
• Docker — pre-built images on Docker Hub (call518/mcp-server-openstack-ops)
• MCPO proxy — expose as a standard OpenAI-compatible tool API for OpenWebUI
• PyPI — install with pip install mcp-openstack-ops or uvx mcp-openstack-ops

Bulk Operations

set_* tools support multi-target filtering and bulk execution, so you can act on dozens
of resources in a single natural-language request.

---

Changes Since Project Inception

Architecture & Code Quality

• Modular file structure: tools/ (90+ individual tool files) + services/ (per-domain service layers)
• Python runtime upgraded from 3.11 → 3.12
• Dynamic versioning via setuptools-scm (version derived from git tags)
• Refactored auth setup and CLI argument handling for cleaner startup

Security

• pre-commit with gitleaks integration to prevent secret leaks
• .gitleaks.toml custom configuration
• ALLOW_MODIFY_OPERATIONS flag for strict read-only enforcement

Connectivity

• Added OS_PROTOCOL and OS_CACERT / OS_VERIFY configuration for SSL/TLS and
  custom CA certificate support (resolves #7)
• OpenStackSDK version pinning for compatibility with older OpenStack releases

CI/CD

• Automated PyPI publish workflow triggered on git tags
• GitHub Actions artifact action upgrades (upload-artifact v7, download-artifact v8)

Dependency Updates (since v3.4.0)

Package	From	To
fastmcp	2.14.4	3.2.0
cryptography	46.0.5	46.0.7
authlib	1.6.9	1.6.11
python-multipart	0.0.22	0.0.26
requests	2.32.5	2.33.0
pyjwt	2.10.1	2.12.0
pygments	2.19.2	2.20.0
pytest	9.0.2	9.0.3
python-dotenv	1.2.1	1.2.2
openstacksdk	≤4.10.0	≤4.11.0

---

Quick Start

# Install from PyPI
pip install mcp-openstack-ops

# Or run directly
uvx mcp-openstack-ops --help


<hr /><em>This discussion was created from the release <a href='https://github.com/call518/MCP-OpenStack-Ops/releases/tag/3.5.0'>3.5.0</a>.</em>

[musaabhasan]

For an OpenStack MCP server with this many operational tools, the most important next layer is safety profiles.

I would separate tools into at least three profiles: read-only observer, operator-assisted change, and change executor. Any create, update, delete, quota, networking, keypair, security group, or load-balancer action should support dry-run output before execution. The dry run should show project or tenant, region, service, resource identifiers, quota impact, expected side effects, rollback note, and approval requirement.

Audit events should include OAuth or client subject, OpenStack project, service, action, resource ID, request ID, MCP session, and policy decision. Useful negative tests include cross-tenant access, missing project scope, destructive action without approval, stale token, and attempting to bypass read-only mode through a different tool name.

That keeps the operational value while making the blast radius understandable to cloud and security teams.

[richardchen874-sys]

The part that stands out to me is "3.5.0". That is usually where agent workflow routing starts to matter in practice, because the integration works at small scale but gets harder once real users, retries, and longer sessions show up.

I would make provider/model choice explicit per agent step, then log usage and fallback reason for each tool loop. That makes it easier to move simple steps to cheaper routes while keeping stronger models for planning or final synthesis.

I am testing an OpenAI-compatible multi-model API layer around official Chinese models, so this kind of agent workflow routing is directly relevant. For MCP-OpenStack-Ops, would routing be configured per agent role, per tool call, or dynamically from runtime signals?