Skip to main content
Glama
Sign In
call518

MCP-OpenStack-Ops

by call518
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

MCP-OpenStack-Ops

MCP OpenStack Operations Server: A comprehensive MCP (Model Context Protocol) server providing OpenStack project management and monitoring capabilities with built-in safety controls and single-project scope.

MCPVault: claimed

License: MIT Python Docker Pulls BuyMeACoffee

Deploy to PyPI with tag PyPI PyPI - Downloads

Architecture & Internal (DeepWiki)

Ask DeepWiki

Related MCP server: mcpdeployment

Features

Experimental per-user remote connections are available for testing with the opt-in --multi-user mode. See the phase 1 setup and validation guide for authentication, client limitations, and the test checklist. Administrator cross-project queries are outside this phase.

  • ✅ Project-Scoped Operations: Every tool enforces the configured OS_PROJECT_NAME, validating resource ownership so actions stay inside a single tenant.

  • ✅ Safety-Gated Writes: Modify (set_*) tooling only registers when ALLOW_MODIFY_OPERATIONS=true, keeping default deployments read-only and auditable.

  • ✅ 90+ Purpose-Built Tools: Broad coverage across compute, networking, storage, images, identity, Heat, and Octavia load balancing tasks. Project resources are scoped to the active project; cloud-wide administrative APIs remain subject to OpenStack policy.

  • ✅ Bulk & Filtered Actions: Instance, volume, network, image, snapshot, and keypair managers accept comma-delimited targets or filter criteria to orchestrate bulk changes intentionally.

  • ✅ Post-Action Feedback & Async Guidance: Mutating tools reuse a shared result handler that adds emoji status checks, asynchronous timing notes, and follow-up verification commands.

  • ✅ Monitoring & Usage Insights: get_service_status, get_resource_monitoring, get_usage_statistics, and quota tools report service probes, project allocations, separate quota limits, and API-backed compute allocation-hours. Live utilization and historical trends are not collected.

  • ✅ Unified Instance Queries: The get_instance tool consolidates name, ID, status, and free-form search paths with pagination plus summary/detailed modes.

  • ✅ Server Insight & Audit Trail: Dedicated tools expose server events, hypervisor details, availability zones, quotas, and resource ownership to speed diagnostics.

  • ✅ Load Balancer Management: Octavia tools cover listeners, pools, members, health monitors, flavors, quotas, and amphora operations with the same safety gates.

  • ✅ Connection & Deployment Flexibility: Connection caching, configurable service endpoints, Docker packaging, and both stdio/streamable-http transports support proxy/bastion and multi-project setups.

⚠️ Compatibility Notice: This MCP server is developed and optimized for OpenStack Epoxy (2025.1) as the primary target environment. However, it is compatible with most modern OpenStack releases (Dalmatian, Caracal, Bobcat, etc.) as the majority of APIs remain consistent across versions. Only a few specific API endpoints may require adaptation for full compatibility with older releases.

🚧 Coming Soon: Dynamic multi-version OpenStack API compatibility is actively under development and will be available in upcoming releases, providing seamless support for all major OpenStack deployments automatically.

🔧 OpenStackSDK Version Customization for Older Releases

Officially Supported Releases:

  • ✅ OpenStack Epoxy (2025.1) - Fully tested

  • ✅ OpenStack Dalmatian (2024.2) - Fully tested

For older OpenStack releases (Wallaby, Caracal, Bobcat, etc.), you may need to customize the OpenStackSDK version to match your environment. The SDK version must be changed in BOTH files:

Step 1: Modify Dockerfile.MCP-Server

RUN pip install \
        'uv>=0.8.5' \
        'mcpo>=0.0.17' \
        'fastmcp>=2.12.3' \
        'aiohttp>=3.12.0' \
        'openstacksdk==3.1.1' \  # ← Change to your required version (e.g., 3.1.1 for Wallaby)
        'python-dotenv>=1.0.0'

Step 2: Modify pyproject.toml

dependencies = [
    "fastmcp>=2.12.3",
    "openstacksdk==3.1.1",  # ← Must match Dockerfile version
    "python-dotenv>=1.1.1",
    # ... other dependencies
]

Step 3: Rebuild Docker Image

docker-compose build --no-cache mcp-server
docker-compose up -d

OpenStackSDK Version Reference:

OpenStack Release

Recommended SDK Version

Notes

Epoxy (2025.1)

>=3.3.0

Current default

Dalmatian (2024.2)

>=3.2.0

Fully compatible

Caracal (2024.1)

>=3.1.0

May require testing

Bobcat (2023.2)

>=3.0.0

May require testing

Wallaby (2021.1)

==3.1.1

Downgrade required

⚠️ Important: Both Dockerfile.MCP-Server and pyproject.toml must have the same version to avoid dependency conflicts during container runtime.

Screenshots

OpenStack Dashboard (Epoxy 2025.1)

OpenStack Dashboard (Epoxy 2025.1)

MCP Query Example - Cluster Status

Example Cluster Status

🆕 Latest Enhancements (v1.x)

Bulk Operations & Filter-based Targeting

Revolutionary approach to resource management enabling one-step operations:

# Traditional approach (multiple steps):
1. search_instances("test") → get list
2. set_instance("vm1", "stop") → stop individually  
3. set_instance("vm2", "stop") → stop individually

# NEW enhanced approach (single step):
set_instance(action="stop", name_contains="test")  # ✨ Stops ALL instances containing "test"

Supported Tools with Enhanced Capabilities:

  • set_instance: Bulk lifecycle management with filtering (name_contains, status, flavor_contains, image_contains)

  • set_volume: Bulk volume operations with filtering (name_contains, status, size filtering)

  • set_image: Bulk image management with filtering (name_contains, status)

  • set_networks: Bulk network operations with filtering (name_contains, status)

  • set_keypair: Bulk keypair management with filtering (name_contains)

  • set_snapshot: Bulk snapshot operations with filtering (name_contains, status)

Input Format Flexibility:

# Single resource
resource_names="vm1"

# Multiple resources (comma-separated)
resource_names="vm1,vm2,vm3"

# JSON array format
resource_names='["vm1", "vm2", "vm3"]'

# Filter-based (automatic target identification)
name_contains="test", status="ACTIVE"

Post-Action Status Verification

Every operation now provides immediate feedback with visual indicators:

✅ Bulk Instance Management - Action: stop
📊 Total instances: 3
✅ Successes: 2
❌ Failures: 1

Post-Action Status:
🟢 test-vm-1: SHUTOFF  
🟢 test-vm-2: SHUTOFF
🔴 test-vm-3: ERROR

Unified Resource Queries

New consolidated get_instance tool replaces multiple separate tools:

  • ❌ Old: get_instance_details, get_instance_info, get_instance_status, get_instance_network_info

  • ✅ New: get_instance(names="vm1,vm2") - Single tool, comprehensive information

📊 OpenStack CLI vs MCP Tools Mapping

Latest targeted validation — 2026-11-02: working tree based on 6a36b6e. See the fixes and final retest report and sanitized evidence. The final executable paths were tested with FastMCP 3.4.10 from uv.lock, two ordinary-user projects, 20 VMs and 20 one-GiB volumes. Post-test tool wording/prompt corrections are identified separately in the report's source fingerprints; Claude replay remains unverified.

Verification group

Item

Result

Live tool checks

Unique tools retested in limited scenarios

14/14 (100%), 0 failed/unverified within this scope

Live tool checks

Registered inventory not repeated in this final run

91 of 105 tools; historical evidence below is not a current full sweep

Named live harness cases

Fixture, isolation, lifecycle and grouped load checks

101/102, one Cinder storage-permission fixture failure, 0 skipped

Local unit tests

Locked environment, python -m pytest -q tests

199/199 (100%), 0 failed/skipped; 21 added regressions

Bounded load requests

Shared-server, two-project bursts

14/14, actual overlap up to 8

Bounded load requests

Same shared server, 120 seconds, four workers

209/209, median 2.03 s, p95 2.70 s, max 3.24 s

Backup recovery

After operator corrected one NFS directory permission

6/6 fresh backups available, both reader MCP state checks passed

Claude client

Minimal actual model API preflight

Blocked before tools: credit/balance error; no final-source Claude replay

Network creation now uses the backend's default MTU when omitted; automatic 1450 and explicit 1400 were verified. Both set_volume and set_server_volume attach/detach reached final states, with cross-project requests rejected. Both search wrappers now honor offset/case sensitivity and correct has_more. Default write restrictions remain in place. These successes do not certify all actions of those tools or all 105 registered tools.

The Cinder fixture failure occurred through its API, independently of MCP. The operator corrected the failing directory's group-write permission; the original failure remains recorded alongside the successful targeted recovery. Actual Claude same-URL duplicate registration was not established as a product defect; single-entry/distinct-URL attempts also failed before tools. Restoring model API access is required for that controlled comparison.

Earlier same-day results are consolidated in the final report's sanitized evidence, under historical_evidence.earlier_runs. The previous 33-tool classification and 41 actual Claude template attempts belong to the pre-fix source, not this final source. The complete 105-tool snapshot below is also historical.

Validation snapshot — 2026-10-30 (main working tree based on dd98993, with the uncommitted fixes described in the report):

State polling allowed 180 seconds; soft reboot completed in 131.66 seconds (previously it exceeded the 90-second check). No reboot implementation change was needed.

The 10 previously reproduced tool defects were corrected. The 28 unavailable paths are not live-validated successes: 24 Octavia tools, two Neutron QoS tools, one Aodh tool, and one Neutron port-forwarding tool. Each affected table row is marked ⚠️ Live unverified. An absent tool/action is marked ❌ Not implemented rather than presented as an available feature.

✅ means an implemented API path; it does not certify every action or backend. The live-pass count covers only the scenarios in the latest retest report, with sanitized evidence. API policy, asynchronous completion, production HTTPS/client compatibility, load, and guest I/O limits are stated there. All test resources were cleaned up; the final audit found zero remaining test resources across 24 categories. See also API prerequisites and result semantics.

Detailed Mapping by Category

1. 🖥️ Compute (Nova)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack server list

get_instance

✅

Separate reader projects each returned exactly ten owned VMs; bounded lab validation only

openstack server show

get_instance

✅

Own fixture queries completed; foreign private ID returned no details; no 16-owned-ID batch claim

openstack server create

set_instance (action="create")

✅

ENHANCED - Bulk creation support

openstack server start/stop/reboot

set_instance

✅

Bulk stop/start final states verified for two test VMs per project; reboot not retested in this round

openstack server delete

set_instance (action="delete")

✅

ENHANCED - Bulk deletion with name_contains filtering

openstack server backup create

set_server_backup

✅

Nova backup action with rotation; asynchronous, no custom metadata

openstack server image create

set_instance (action="snapshot")

✅

Image/snapshot creation

openstack server shelve/unshelve

set_instance

✅

Instance shelving

openstack server lock/unlock

set_instance

✅

Instance locking

openstack server pause/unpause

set_instance

✅

Instance pausing

openstack server suspend/resume

set_instance

✅

Instance suspension

openstack server resize

set_instance (action="resize")

✅

Instance resizing

openstack server resize confirm

set_instance (action="confirm_resize")

✅

Resize confirmation

openstack server resize revert

set_instance (action="revert_resize")

✅

Resize revert

openstack server rebuild

set_instance (action="rebuild")

✅

Instance rebuilding

openstack server rescue/unrescue

set_instance

✅

Recovery mode

openstack server migrate

set_server_migration (action="migrate")

✅

Live migration

openstack server evacuate

set_server_migration (action="evacuate")

✅

Server evacuation

openstack server migration list

set_server_migration (action="list")

✅

Migration listing

openstack server migration show

set_server_migration (action="show")

✅

Migration details

openstack server migration abort

set_server_migration (action="abort")

✅

Migration abort

openstack server migration confirm

set_server_migration (action="confirm")

✅

Migration confirmation

openstack server migration force complete

set_server_migration (action="force_complete")

✅

Force migration completion

openstack server add network

set_server_network (action="add_network")

✅

Network attachment

openstack server remove network

set_server_network (action="remove_network")

✅

Network detachment

openstack server add port

set_server_network (action="add_port")

✅

Port attachment

openstack server remove port

set_server_network (action="remove_port")

✅

Port detachment

openstack server add floating ip

set_server_floating_ip (action="add")

✅

Floating IP association

openstack server remove floating ip

set_server_floating_ip (action="remove")

✅

Floating IP disassociation

openstack server add fixed ip

set_server_fixed_ip (action="add")

✅

Fixed IP addition

openstack server remove fixed ip

set_server_fixed_ip (action="remove")

✅

Fixed IP removal

openstack server add security group

set_server_security_group (action="add")

✅

Security group addition

openstack server remove security group

set_server_security_group (action="remove")

✅

Security group removal

openstack server add volume

set_server_volume (action="attach")

✅

Member attach reached in-use via set_server_volume; guest I/O not tested

openstack server remove volume

set_server_volume (action="detach")

✅

Member detach reached available via set_server_volume

openstack server set

set_server_properties (action="set")

✅

Server property setting

openstack server unset

set_server_properties (action="unset")

✅

Server property unsetting

openstack server dump create

set_server_dump

❌ Unsupported

Returns an explicit unsupported result; no dump is created

openstack server event list

get_server_events

✅

Server event tracking

openstack server group list

get_server_groups

✅

Server group listing

openstack server group create/delete

set_server_group

✅

Server group management

openstack flavor list

set_flavor (action="list")

✅

Requires modification tools to be enabled for registration

openstack flavor create/delete

set_flavor

✅

Flavor management

openstack keypair list

get_keypair_list

✅

Empty scoped read completed; member keypair creation/deletion read-back tested separately

openstack keypair create/delete

set_keypair

✅

Explicit member MCP create/delete read-back passed; no successful Claude write workflow claimed

openstack hypervisor list

get_hypervisor_details

⚠️ Live unverified

Reader policy denial; successful administrator MCP lookup was not obtained in this round

openstack availability zone list

get_availability_zones

⚠️ Live unverified

Only policy-limited composite requests in this round; individual result not independently attributed

2. 🌐 Network (Neutron)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack network list

get_network_details

✅

Two owned private networks plus one policy-visible shared external network per reader; no other test project private networks

openstack network show

get_network_details (network_name)

⚠️ Live unverified

Foreign-ID negative checked; dual-project positive named reader lookup not independently asserted

openstack network create

set_networks (action="create")

✅

Default mtu=0 omits the wire field: backend MTU 1450 verified; explicit 1400 retained in both member projects

openstack network delete

set_networks (action="delete")

✅

Both default/explicit-MTU test networks removed through actual TCP MCP, API absence confirmed

openstack network set

set_networks (action="update")

✅

ENHANCED - Bulk updates

openstack subnet list

get_network_details (includes subnets)

✅

Owned and shared external network subnets returned; three visible subnets per test reader

openstack subnet create/delete

set_subnets

✅

Member TCP MCP subnet create read back; deletion allowed parent network removal in both projects

openstack router list

get_routers

⚠️ Live unverified

Only part of composite error requests in this round; no independent reader result attribution

openstack router create/delete

set_routers

✅

Project-owned routers; attached interfaces are not removed automatically

openstack floating ip list

get_floating_ips

✅

Floating IP listing

openstack floating ip create

set_floating_ip (action="create")

✅

Floating IP creation

openstack floating ip delete

set_floating_ip (action="delete")

✅

Floating IP deletion

openstack floating ip set

set_floating_ip (action="set")

✅

Floating IP property setting

openstack floating ip show

set_floating_ip (action="show")

✅

Floating IP details

openstack floating ip unset

set_floating_ip (action="unset")

✅

Floating IP property clearing

openstack floating ip pool list

get_floating_ip_pools

⚠️ Live unverified

Composite result not independently attributed; available global pool capacity remains unknown

openstack floating ip port forwarding create

set_floating_ip_port_forwarding (action="create")

⚠️ Live unverified

Implemented; test platform port-forwarding endpoint returns HTTP 404

openstack floating ip port forwarding delete

set_floating_ip_port_forwarding (action="delete")

⚠️ Live unverified

Implemented; test platform port-forwarding endpoint returns HTTP 404

openstack floating ip port forwarding list

set_floating_ip_port_forwarding (action="list")

⚠️ Live unverified

Implemented; test platform port-forwarding endpoint returns HTTP 404

openstack floating ip port forwarding set

set_floating_ip_port_forwarding (action="set")

⚠️ Live unverified

Implemented; test platform port-forwarding endpoint returns HTTP 404

openstack floating ip port forwarding show

set_floating_ip_port_forwarding (action="show")

⚠️ Live unverified

Implemented; test platform port-forwarding endpoint returns HTTP 404

openstack security group list

get_security_groups

✅

Scoped reader list completed; default and test groups visible

openstack security group create/delete

set_security_groups

✅

Project-owned security groups

openstack port list

set_network_ports (action="list")

⚠️ Live unverified

Implemented list action requires modification-tool registration; not exercised in this round

openstack port create/delete

set_network_ports

✅

Port management

openstack network qos policy list

get_network_qos_policies

⚠️ Live unverified

Implemented; test platform QoS endpoint returns HTTP 404

openstack network qos policy create

set_network_qos_policies

⚠️ Live unverified

Implemented; test platform QoS endpoint returns HTTP 404. Policy containers only; no bandwidth rules

openstack network agent list

get_service_status (includes agents)

⚠️ Live unverified

Reader service-policy restrictions; partial data is not proof of global health

openstack network agent set

set_network_agents

✅

Enable/disable cloud-wide agents; usually admin-only

3. 💾 Storage (Cinder)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack volume list

get_volume_list

✅

Exactly ten owned volumes per reader; no other test project volume IDs returned

openstack volume show

get_volume_list

✅

Listing-based client filtering; no dedicated get_volume_list filter argument

openstack volume create/delete

set_volume

✅

Volume creation/deletion

openstack volume set

—

❌ Not implemented

set_volume has no modify/update action; do not send this unsupported action

openstack volume type list

get_volume_types

✅

Volume type listing

openstack volume type create/delete

set_volume_types

✅

Volume type management; usually admin-only

openstack volume snapshot list

get_volume_snapshots

✅

Two owned base snapshots per reader; API final states checked

openstack volume snapshot create/delete

set_snapshot

✅

Explicit member MCP snapshots reached available and were deleted; no restore/I/O claim

openstack backup list

get_volume_backups

✅

Three owned available backups per reader; base backup creation used real Cinder APIs

openstack backup create/delete

set_volume_backups

✅

Volume backup management

openstack volume transfer request list

get_volume_transfers

✅

Request listing only; authorization keys are excluded

openstack server volume list

get_server_volumes

✅

Server volume listing

openstack server add/remove volume

set_server_volume / set_volume (action="attach"/"detach")

✅

Both paths reached in-use then available in both member projects; foreign endpoints rejected; guest I/O not tested

openstack volume group list

get_volume_groups

✅

Requires Cinder generic groups (API >= 3.13)

openstack volume group create

set_volume_groups

✅

Create/list/show/delete; create requires group_type and volume_types

openstack volume qos list

get_volume_qos

✅

Cinder QoS specifications; subject to cloud policy

openstack volume qos create

set_volume_qos

✅

Create/list/show/set/delete specifications; no automatic type association

4. 🖼️ Image (Glance)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack image list

get_image_detail_list

✅

Image listing

openstack image show

get_image_detail_list (filtering)

✅

Specific image query

openstack image create

set_image (action="create")

✅

Enhanced image creation with min_disk, min_ram, properties

openstack image delete

set_image (action="delete")

✅

Image deletion

openstack image set

set_image (action="update")

✅

Image property modification

openstack image save

set_image (action="save")

✅

Image download

openstack image add project

set_image_members (action="add")

✅

Add a project to an image with shared visibility

openstack image member list

get_image_members

✅

Image member listing

openstack image member create

set_image_members

✅

Image member management

openstack image set --property

set_image_metadata

✅

Image metadata

openstack image set --public/private

set_image_visibility

✅

Image visibility setting

5. 👥 Identity (Keystone)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack user list

get_user_list

⚠️ Live unverified

Reader denied by Keystone; explicit MCP failure observed; successful listing not validated in this round

openstack user show

get_user_list

⚠️ Live unverified

Depends on policy-limited user listing; not independently validated for the new readers

openstack user create/delete

set_users

✅

Password from a server environment variable; no role grants

openstack project list

get_project_details

✅

Project listing

openstack project show

get_project_details (name param)

✅

Specific project query

openstack project create/delete

set_project

✅

Project management

openstack role list

get_role_assignments

✅

Role listing

openstack role assignment list

get_role_assignments

⚠️ Live unverified

Reader Keystone policy denial; not a successful data lookup

openstack role create/delete

set_roles

✅

Role management

openstack domain list

get_domains

✅

Subject to Keystone policy

openstack domain create/delete

set_domains

✅

Disable explicitly with update before delete

openstack group list

get_identity_groups

✅

Subject to Keystone policy

openstack group create/delete

set_identity_groups

✅

Group management

openstack service list

get_service_status

⚠️ Live unverified

Reader service-policy restrictions; partial data is not proof of global health

openstack service create/delete

set_services

✅

Service management

openstack endpoint list

get_service_status (includes endpoints)

⚠️ Live unverified

Reader service-policy restrictions; partial data is not proof of global health

6. 🔥 Orchestration (Heat)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack stack list

get_heat_stacks

✅

Stack listing

openstack stack show

get_heat_stacks (filtering)

✅

Specific stack query

openstack stack create

set_heat_stack (action="create")

✅

Stack creation

openstack stack delete

set_heat_stack (action="delete")

✅

Stack deletion

openstack stack update

set_heat_stack (action="update")

✅

Stack update

openstack stack suspend/resume

set_heat_stack

✅

Stack suspend/resume

openstack stack resource list

get_heat_stack_details (section="resources")

✅

Actual Heat resources

openstack stack event list

get_heat_stack_details (section="events")

✅

Actual Heat events

openstack stack template show

get_heat_stack_details (section="template")

✅

Original template document

openstack stack output list

get_heat_stack_details (section="outputs")

✅

Resolved stack outputs

7. ⚖️ Load Balancer (Octavia)

OpenStack CLI Command

MCP Tool

Status

Notes

openstack loadbalancer list

get_load_balancer_list

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer listing with pagination

openstack loadbalancer show

get_load_balancer_details

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer detailed information

openstack loadbalancer create

set_load_balancer (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer creation

openstack loadbalancer delete

set_load_balancer (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer deletion

openstack loadbalancer set

set_load_balancer (action="update")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer property update

openstack loadbalancer stats show

set_load_balancer (action="stats")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer statistics

openstack loadbalancer status show

set_load_balancer (action="status")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer status tree

openstack loadbalancer failover

set_load_balancer (action="failover")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer failover

openstack loadbalancer unset

set_load_balancer (action="unset")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Load balancer property unset

Listener Management

openstack loadbalancer listener list

get_load_balancer_listeners

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener listing for load balancer

openstack loadbalancer listener create

set_load_balancer_listener (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener creation (HTTP/HTTPS/TCP/UDP)

openstack loadbalancer listener delete

set_load_balancer_listener (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener deletion

openstack loadbalancer listener show

get_load_balancer_listeners

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener detailed information

openstack loadbalancer listener set

set_load_balancer_listener (action="update")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener property update

openstack loadbalancer listener stats show

set_load_balancer_listener (action="stats")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener statistics

openstack loadbalancer listener unset

set_load_balancer_listener (action="unset")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Listener property unset

Pool Management

openstack loadbalancer pool list

get_load_balancer_pools

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool listing (all or by listener)

openstack loadbalancer pool create

set_load_balancer_pool (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool creation with algorithms

openstack loadbalancer pool delete

set_load_balancer_pool (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool deletion

openstack loadbalancer pool set

set_load_balancer_pool (action="set")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool property update

openstack loadbalancer pool show

get_load_balancer_pools

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool detailed information

openstack loadbalancer pool stats show

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer pool unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Member Management

openstack loadbalancer member list

get_load_balancer_pool_members

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool member listing

openstack loadbalancer member create

set_load_balancer_pool_member (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool member creation

openstack loadbalancer member delete

set_load_balancer_pool_member (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool member deletion

openstack loadbalancer member set

set_load_balancer_pool_member (action="set")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool member property update

openstack loadbalancer member show

get_load_balancer_pool_members

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Pool member detailed information

openstack loadbalancer member unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Health Monitor Management

openstack loadbalancer healthmonitor list

get_load_balancer_health_monitors

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Health monitor listing

openstack loadbalancer healthmonitor create

set_load_balancer_health_monitor (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Health monitor creation

openstack loadbalancer healthmonitor delete

set_load_balancer_health_monitor (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Health monitor deletion

openstack loadbalancer healthmonitor set

set_load_balancer_health_monitor (action="set")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Health monitor update

openstack loadbalancer healthmonitor show

get_load_balancer_health_monitors

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Health monitor detailed information

openstack loadbalancer healthmonitor unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

L7 Policy Management

openstack loadbalancer l7policy list

get_load_balancer_l7_policies

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 policy listing

openstack loadbalancer l7policy create

set_load_balancer_l7_policy (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 policy creation

openstack loadbalancer l7policy delete

set_load_balancer_l7_policy (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 policy deletion

openstack loadbalancer l7policy set

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer l7policy show

get_load_balancer_l7_policies

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 policy details

openstack loadbalancer l7policy unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

L7 Rule Management 🆕

openstack loadbalancer l7rule list

get_load_balancer_l7_rules

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 rule listing

openstack loadbalancer l7rule create

set_load_balancer_l7_rule (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 rule creation

openstack loadbalancer l7rule delete

set_load_balancer_l7_rule (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 rule deletion

openstack loadbalancer l7rule set

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer l7rule show

get_load_balancer_l7_rules

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. L7 rule details

openstack loadbalancer l7rule unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Amphora Management 🆕

openstack loadbalancer amphora list

get_load_balancer_amphorae

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Amphora listing

openstack loadbalancer amphora show

set_load_balancer_amphora (action="show")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Amphora details

openstack loadbalancer amphora configure

set_load_balancer_amphora (action="configure")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Amphora configuration

openstack loadbalancer amphora failover

set_load_balancer_amphora (action="failover")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Amphora failover

openstack loadbalancer amphora delete

N/A

❌

Not supported by OpenStack SDK

openstack loadbalancer amphora stats show

N/A

❌

Not supported by OpenStack SDK

Provider Management

openstack loadbalancer provider list

get_load_balancer_providers

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Provider listing

openstack loadbalancer provider capability list

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Availability Zone Management 🆕

openstack loadbalancer availabilityzone list

get_load_balancer_availability_zones

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Availability zone listing

openstack loadbalancer availabilityzone show

get_load_balancer_availability_zones

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Availability zone details

openstack loadbalancer availabilityzone create

set_load_balancer_availability_zone (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Availability zone creation

openstack loadbalancer availabilityzone delete

set_load_balancer_availability_zone (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Availability zone deletion

openstack loadbalancer availabilityzone set

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer availabilityzone unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Flavor Management 🆕

openstack loadbalancer flavor list

get_load_balancer_flavors

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Flavor listing

openstack loadbalancer flavor show

get_load_balancer_flavors

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Flavor details

openstack loadbalancer flavor create

set_load_balancer_flavor (action="create")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Flavor creation

openstack loadbalancer flavor delete

set_load_balancer_flavor (action="delete")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Flavor deletion

openstack loadbalancer flavor set

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavor unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Flavor Profile Management

openstack loadbalancer flavorprofile list

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavorprofile show

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavorprofile create

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavorprofile set

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavorprofile unset

N/A

❌ Not implemented

No registered tool/action for this CLI operation

openstack loadbalancer flavorprofile delete

N/A

❌ Not implemented

No registered tool/action for this CLI operation

Quota Management 🆕

openstack loadbalancer quota list

get_load_balancer_quotas

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Quota listing

openstack loadbalancer quota show

get_load_balancer_quotas

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Quota details

openstack loadbalancer quota set

set_load_balancer_quota (action="set")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Quota setting

openstack loadbalancer quota reset

set_load_balancer_quota (action="reset")

⚠️ Live unverified

Implemented; Octavia unavailable in the test platform. Quota reset

8. 📊 Monitoring & Logging

OpenStack CLI Command

MCP Tool

Status

Notes

Resource monitoring

get_resource_monitoring

⚠️ Live unverified

Reader physical-capacity policy restrictions; allocations are separate from capacity; no live utilization

Service status

get_service_status

⚠️ Live unverified

Reader service-policy restrictions; partial data is not proof of global health

Cluster overview

get_service_status + get_resource_monitoring

⚠️ Live unverified

Reader physical-capacity policy restrictions; allocations are separate from capacity; no live utilization

Service log metadata

set_service_logs

Partial

Service listing only; log retrieval is unavailable without a logging backend

Resource metadata

set_metrics

Partial

list/summary only; telemetry sample retrieval is unavailable

Alarm management

set_alarms

⚠️ Live unverified

Implemented; Aodh/Gnocchi unavailable in the test platform. Requires services and collected metrics

Compute agents

set_compute_agents

✅

Compute agent management

Usage statistics

get_usage_statistics

✅

Period compute allocation-hours plus separately labeled current snapshots

9. 📏 Usage & Quota

OpenStack CLI Command

MCP Tool

Status

Notes

openstack quota show

get_quota

✅

Quota query

openstack quota set

set_quota (action="set")

✅

Routes supplied fields to Nova/Neutron/Cinder; partial failures are reported

openstack quota delete

set_quota (action="delete")

✅

Resets all three service quotas to defaults; requires modification tools

openstack usage show

get_usage_statistics

✅

Current-project Nova simple tenant usage; not monetary charges

openstack limits show

get_quota (includes limits)

✅

Limits query

Resource allocations

get_resource_monitoring

⚠️ Live unverified

Reader physical-capacity policy restrictions; allocations are separate from capacity; no live utilization

API prerequisites and result semantics

The feature table marks implemented API paths, not verification against every OpenStack deployment. The management and query paths have local mocked API tests. Selected paths also passed live tests on a single-node Kolla Ansible deployment; see integration validation for coverage and skipped operations. A missing service, extension, required microversion, or permission is an operation failure, not an empty successful result.

  • Modification tools: the MCP server registers set_* management tools only when ALLOW_MODIFY_OPERATIONS=true. Existing action guards also reject writes when disabled. Dedicated read-only get_* tools remain available. API authorization is enforced by the target cloud; agent, user, domain, type and QoS administration may require elevated OpenStack roles.

  • Alarms: set_alarms calls the Keystone catalog's alarming endpoint for the configured interface/region. It supports list/create/show/delete of project alarms and creates gnocchi_resources_threshold alarms. Aodh, Gnocchi, the specified resource and a collected metric are required. The default metric is cpu_util, which is not collected by every deployment. metric, resource_type, aggregation_method, granularity, evaluation_periods, and alarm_actions can be supplied. An empty action list creates an alarm without notifications. There is no simulation fallback.

  • Usage: get_usage_statistics calls Nova simple tenant usage for the current project. Requires Nova API microversion 2.40 or newer for complete pagination. Date bounds are UTC midnight, start inclusive and end exclusive; start must precede end. usage_statistics.period_compute contains paginated Nova allocation-hours, not actual CPU load, billed currency, or network/storage history. Nova accounts using VM lifetime and the latest flavor; stop/pause/resize history is not reconstructed. Existing compute, network, and storage fields are current snapshots, labeled by snapshot_fields and snapshot_timestamp. An unavailable period API returns failure. A failed snapshot section is reported as partial failure.

  • Capacity: get_resource_monitoring separates flavor allocations from project quota limits and the physical totals of visible hypervisors. Missing physical totals or incomplete flavor allocations return null, not invented capacity or zero usage. Physical totals and project allocations have different scopes. This tool does not collect live utilization or trends.

  • Floating IP pools: total_ips is the exact sum of visible subnet allocation ranges; used_ips counts visible Floating IP objects. Global available_ips is null: other projects and non-floating ports may consume addresses that are not visible to the caller.

  • Volume groups: the cloud must support Cinder generic groups (microversion 3.13 or newer). Create requires an existing group_type and comma-delimited volume_types. Deletion does not delete member volumes unless delete_volumes=true is explicitly supplied. Async creation/deletion responses mean accepted, not finished.

  • Identity and images: set_users reads a new user's password from the server variable named by password_env; never put passwords in prompts. It does not grant project roles. Disable a domain explicitly with set_domains(action="update", enabled=false) before deleting it. Image member modifications require an image owned by the current project, shared visibility, and appropriate Glance policy; adding a member does not automatically accept the recipient's membership.

  • Logs and telemetry: set_service_logs(action="show") and set_metrics(action="show") return explicit unsupported errors. No centralized logging or telemetry sample backend is implemented. Their list/summary operations expose service or resource metadata only.

Quick Start

💡 Need an OpenStack Cluster for Testing?
Check out this comprehensive guide: Tutorial: Install OpenStack Multinode Cluster /w Kolla-Ansible (Epoxy/Dalmatian)
Perfect for setting up a test environment to explore MCP-OpenStack-Ops capabilities.

Flow Diagram of Quickstart/Tutorial

1. Environment Setup

# Clone and navigate to project
cd MCP-OpenStack-Ops

# Install dependencies
uv sync

# Configure environment
cp .env.example .env
# Edit .env with your OpenStack credentials

Environment Configuration

Configure your .env file with OpenStack credentials:

# OpenStack Authentication (required)
OS_AUTH_HOST=your-openstack-host
OS_AUTH_PORT=5000
OS_AUTH_PROTOCOL=http  # Use 'https' for production with SSL/TLS
# OS_CACERT=/etc/ssl/certs/openstack-ca.pem  # Required for HTTPS (optional for HTTP)
OS_IDENTITY_API_VERSION=3
OS_USERNAME=your-username
OS_PASSWORD=your-password
OS_PROJECT_NAME=your-project
OS_PROJECT_DOMAIN_NAME=default
OS_USER_DOMAIN_NAME=default
OS_REGION_NAME=RegionOne

# OpenStack Service Ports (customizable)
OS_COMPUTE_PORT=8774
OS_NETWORK_PORT=9696
OS_VOLUME_PORT=8776
OS_IMAGE_PORT=9292
OS_PLACEMENT_PORT=8780
OS_HEAT_STACK_PORT=8004
OS_HEAT_STACK_CFN_PORT=8000

# MCP Server Configuration (optional)
MCP_LOG_LEVEL=INFO
ALLOW_MODIFY_OPERATIONS=false
FASTMCP_TYPE=stdio
FASTMCP_HOST=127.0.0.1
FASTMCP_PORT=8080

HTTPS Configuration for Production Environments

For secure OpenStack deployments with SSL/TLS:

# Enable HTTPS protocol
OS_AUTH_PROTOCOL=https
OS_AUTH_HOST=your-secure-openstack-host
OS_AUTH_PORT=13000  # Your HTTPS Keystone port

# SSL Certificate Configuration
# Option 1: Use custom CA certificate (recommended for production)
OS_CACERT=/etc/ssl/certs/openstack-ca.pem

# Option 2: Skip CA certificate (SSL verification disabled - insecure)
# Just omit OS_CACERT - the server will warn you about insecure connection

# Docker: Mount CA certificate into container
# Add to docker-compose.yml volumes:
#   - /path/to/your/ca-cert.pem:/etc/ssl/certs/openstack-ca.pem:ro

Protocol Configuration Notes:

  • OS_AUTH_PROTOCOL=http: Use for local development or HTTP-only OpenStack deployments

  • OS_AUTH_PROTOCOL=https: Use for production environments with SSL/TLS enabled

  • When https is set without OS_CACERT, SSL verification is disabled (insecure but functional)

  • For secure production deployments, always provide OS_CACERT with your CA certificate path

2. Run Server

# Start all services
docker-compose up -d

# Check logs
docker-compose logs mcp-server
docker-compose logs mcpo-proxy

Container Architecture:

  • mcp-server: OpenStack MCP server with tools

  • mcpo-proxy: OpenAPI (REST-API)

  • open-webui: Web interface for testing and interaction

📌 Note: Web-UI configuration instructions are based on OpenWebUI v0.6.22. Menu locations and settings may differ in newer versions.

Service URLs - Docker Internal:

  • MCP Server: localhost:8080 (HTTP transport)

  • MCPO Proxy: localhost:8000 (OpenStack API proxy)

  • Open WebUI: localhost:3000 (Web interface)

Service URLs - Docker External:

  • MCP Server: host.docker.internal:18005 (HTTP transport)

  • MCPO Proxy: host.docker.internal:8005 (OpenStack API proxy)

  • Open WebUI: host.docker.internal:3005 (Web interface)

For Claude Desktop Integration

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "mcp-openstack-ops": {
      "command": "uvx",
      "args": ["--python", "3.12", "mcp-openstack-ops"],
      "env": {
        "OS_AUTH_HOST": "your-openstack-host",
        "OS_AUTH_PORT": "5000",
        "OS_PROJECT_NAME": "your-project",
        "OS_USERNAME": "your-username",
        "OS_PASSWORD": "your-password",
        "OS_USER_DOMAIN_NAME": "Default",
        "OS_PROJECT_DOMAIN_NAME": "Default",
        "OS_REGION_NAME": "RegionOne",
        "OS_IDENTITY_API_VERSION": "3",
        "OS_INTERFACE": "internal",
        "OS_COMPUTE_PORT": "8774",
        "OS_NETWORK_PORT": "9696",
        "OS_VOLUME_PORT": "8776",
        "OS_IMAGE_PORT": "9292",
        "OS_PLACEMENT_PORT": "8780",
        "OS_HEAT_STACK_PORT": "8004",
        "OS_HEAT_STACK_CFN_PORT": "18888",
        "ALLOW_MODIFY_OPERATIONS": "false",
        "MCP_LOG_LEVEL": "INFO"
      }
    }
  }
}

Claude Code Integration

Install Claude Code and start the MCP server in streamable-http mode first. Register the MCP server's /mcp URL, not the MCPO/OpenAPI proxy URL. The example below uses the Docker host port 18005; replace the host/port for your deployment and use HTTPS for remote connections. Registration does not start the server.

For the existing single-account mode with REMOTE_AUTH_ENABLE=true, enter the server's REMOTE_SECRET_KEY without saving its literal value in shell history:

read -rsp 'MCP Bearer token: ' OPENSTACK_MCP_TOKEN
echo
export OPENSTACK_MCP_TOKEN

claude mcp add-json --scope user openstack-ops '{"type":"http","url":"http://127.0.0.1:18005/mcp","headers":{"Authorization":"Bearer ${OPENSTACK_MCP_TOKEN}"}}'
claude mcp list
claude

Keep OPENSTACK_MCP_TOKEN exported in the terminal that launches Claude Code. --scope user saves the registration in your normal user configuration. If server authentication is disabled, use this registration command instead:

claude mcp add --transport http --scope user openstack-ops http://127.0.0.1:18005/mcp

In Claude Code, check /mcp and ask, for example:

Use openstack-ops to list all instances in the project.

Remove the registration when no longer needed (this does not stop the server):

claude mcp remove --scope user openstack-ops
unset OPENSTACK_MCP_TOKEN

This Bearer configuration uses the server's configured OpenStack account. For experimental per-user authentication, see the phase 1 guide. See also the Claude Code MCP documentation.

Server Configuration

Command Line Options

uv run python -m mcp_openstack_ops --help

Options:
  --log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL}
                        Logging level
  --type {stdio,streamable-http}
                        Transport type (default: stdio)
  --host HOST          Host address for HTTP transport (default: 127.0.0.1)
  --port PORT          Port number for HTTP transport (default: 8080)
  --auth-enable        Enable Bearer token authentication for streamable-http mode
  --secret-key SECRET  Secret key for Bearer token authentication

Environment Variables

Variable

Description

Default

Usage

OpenStack Authentication

OS_AUTH_HOST

OpenStack Identity service host

Required

Authentication host address

OS_AUTH_PORT

OpenStack Identity service port

Required

Authentication port

OS_AUTH_PROTOCOL

Connection protocol (http or https)

http

Use https for production with SSL/TLS

OS_CACERT

SSL CA certificate path for HTTPS

Optional

Required for secure HTTPS connections (e.g., /etc/ssl/certs/ca.pem). If not set with HTTPS, SSL verification is disabled (insecure)

OS_USERNAME

OpenStack username

Required

User credentials

OS_PASSWORD

OpenStack password

Required

User credentials

OS_PROJECT_NAME

OpenStack project name

Required

Project scope

OS_IDENTITY_API_VERSION

Identity API version

3

API version

OS_PROJECT_DOMAIN_NAME

Project domain name

default

Domain scope

OS_USER_DOMAIN_NAME

User domain name

default

Domain scope

OS_REGION_NAME

OpenStack region

RegionOne

Regional scope

OpenStack Service Ports

OS_COMPUTE_PORT

Compute service port

8774

Nova endpoint

OS_NETWORK_PORT

Network service port

9696

Neutron endpoint

OS_VOLUME_PORT

Volume service port

8776

Cinder endpoint

OS_IMAGE_PORT

Image service port

9292

Glance endpoint

OS_PLACEMENT_PORT

Placement service port

8780

Placement endpoint

OS_HEAT_STACK_PORT

Heat orchestration service port

8004

Heat API endpoint

OS_HEAT_STACK_CFN_PORT

Heat CloudFormation service port

18888

Heat CFN API endpoint (default: 8000, changed to avoid Docker port conflicts)

MCP Server Configuration

MCP_LOG_LEVEL

Logging level

INFO

Development debugging

ALLOW_MODIFY_OPERATIONS

Enable modify operations

false

Safety control for state modifications

FASTMCP_TYPE

Transport type

stdio

Rarely needed to change

FASTMCP_HOST

HTTP host address

127.0.0.1

For HTTP mode only

FASTMCP_PORT

HTTP port number

8080

For HTTP mode only

Authentication (Optional)

REMOTE_AUTH_ENABLE

Enable Bearer token authentication for streamable-http mode

false

Production security

REMOTE_SECRET_KEY

Secret key for Bearer token authentication

Required when auth enabled

Production security

🔒 Project Isolation & Security

Single Project Scope Operation

MCP-OpenStack-Ops operates within a strictly defined project scope determined by the OS_PROJECT_NAME environment variable. This provides complete tenant isolation and data privacy in multi-tenant OpenStack environments.

Key Security Features:

  • 100% Complete Resource Isolation: All operations are restricted to resources within the specified project with enhanced security validation

  • Zero Cross-tenant Data Leakage: Advanced project ownership validation prevents access to resources from other projects

  • Multi-layer Security Filtering: Each service implements intelligent resource filtering by current project ID with additional validation

  • Secure Resource Lookup: All resource searches use project-scoped lookup with ownership verification

  • Shared Resource Access: Intelligently includes shared/public resources (networks, images) while maintaining strict security boundaries

  • Cross-Project Access Prevention: Enhanced protection against accidental operations on similarly-named resources in other projects

Filtered Resources by Project:

Service

Project-Scoped Resources

Notes

Identity

Users (via role assignments), Role assignments

Only users with roles in current project

Compute

Instances, Flavors (embedded data), Keypairs

All instances within project scope

Image

Private images (owned), Public/Community/Shared images

Smart filtering prevents zero-image issues

Network

Networks, Subnets, Security Groups, Floating IPs, Routers

Includes shared/external networks for access

Storage

Volumes, Snapshots, Backups

All storage resources within project

Orchestration

Heat Stacks, Stack Resources

All orchestration within project

Load Balancer

Load Balancers, Listeners, Pools

All load balancing within project

Monitoring

Resource usage, Project quotas

Project-specific monitoring data

Security Validation & Testing

Project Isolation Security Test

To verify that project isolation is working correctly, run the included security test:

# Run project isolation security test
python test_project_isolation.py

Expected Test Results:

🔒 OpenStack Project Isolation Security Test
==================================================
📋 Testing project isolation for: your-project

1️⃣ Testing Connection and Project ID...
✅ Connection successful
✅ Current project ID: abc123-def456-ghi789
✅ Project name 'your-project' matches project ID

2️⃣ Testing Resource Ownership Validation...
✅ Found 5 compute instances
   Instance web-server-01: ✅ Owned
   Instance db-server-01: ✅ Owned
✅ Found 3/8 owned networks
✅ Found 10/10 owned volumes

3️⃣ Testing Service-Level Project Filtering...
✅ Compute service returned 5 instances
✅ Network service returned 3 networks  
✅ Storage service returned 10 volumes

4️⃣ Testing Secure Resource Lookup...
ℹ️  Network 'admin' not found or not accessible in current project
ℹ️  Instance 'demo' not found or not accessible in current project

🎯 Project Isolation Test Results
========================================
✅ All security tests passed!
✅ Project 'your-project' isolation verified
✅ Cross-project access prevention confirmed

🔒 Your OpenStack MCP Server is properly secured!

Security Features Validated:

  • ✅ Project ID verification and matching

  • ✅ Resource ownership validation for all services

  • ✅ Service-level project filtering

  • ✅ Secure resource lookup with cross-project protection

  • ✅ Prevention of accidental operations on other projects' resources

For managing multiple OpenStack projects, deploy multiple MCP server instances with different OS_PROJECT_NAME values:

Example: Managing 3 Projects

# Project 1: Production Environment
OS_PROJECT_NAME=production
# ... other config
python -m mcp_openstack_ops --type stdio

# Project 2: Development Environment  
OS_PROJECT_NAME=development
# ... other config  
python -m mcp_openstack_ops --type streamable-http --port 8001

# Project 3: Testing Environment
OS_PROJECT_NAME=testing  
# ... other config
python -m mcp_openstack_ops --type streamable-http --port 8002

Claude Desktop Multi-Project Configuration Example:

{
  "mcpServers": {
    "openstack-production": {
      "command": "python",
      "args": ["-m", "mcp_openstack_ops", "--type", "stdio"],
      "env": {
        "OS_PROJECT_NAME": "production",
        "OS_USERNAME": "admin",
        "OS_PASSWORD": "your-password",
        "OS_AUTH_HOST": "192.168.35.2"
      }
    },
    "openstack-development": {
      "command": "python", 
      "args": ["-m", "mcp_openstack_ops", "--type", "stdio"],
      "env": {
        "OS_PROJECT_NAME": "development",
        "OS_USERNAME": "admin",
        "OS_PASSWORD": "your-password", 
        "OS_AUTH_HOST": "192.168.35.2"
      }
    },
    "openstack-testing": {
      "command": "python",
      "args": ["-m", "mcp_openstack_ops", "--type", "stdio"], 
      "env": {
        "OS_PROJECT_NAME": "testing",
        "OS_USERNAME": "admin",
        "OS_PASSWORD": "your-password",
        "OS_AUTH_HOST": "192.168.35.2"
      }
    }
  }
}

This allows Claude to access each project independently with complete isolation between environments.

📁 Ready-to-use Configuration File:

A complete multi-project configuration example is available at mcp-config.json.multi-project:

  • Production: Read-only operations for safety (ALLOW_MODIFY_OPERATIONS=false)

  • Development: Full operations enabled (ALLOW_MODIFY_OPERATIONS=true)

  • Testing: Debug logging enabled (MCP_LOG_LEVEL=DEBUG)

# Copy and customize the multi-project configuration
cp mcp-config.json.multi-project ~/.config/claude-desktop/mcp_servers.json
# Edit with your OpenStack credentials

Safety Controls

Modification Operations Protection

By default, all operations that can modify or delete OpenStack resources are disabled for safety:

# Default setting - Only read-only operations allowed
ALLOW_MODIFY_OPERATIONS=false

Protected Operations (when ALLOW_MODIFY_OPERATIONS=false):

  • Instance management (start, stop, restart, pause, unpause)

  • Volume operations (create, delete, attach, detach)

  • Keypair management (create, delete, import)

  • Floating IP operations (create, delete, associate, disassociate)

  • Snapshot management (create, delete)

  • Image management (create, delete, update)

  • Heat stack operations (create, delete, update)

Always Available (Read-Only Operations):

  • Cluster status and monitoring

  • Resource listings (instances, volumes, networks, etc.)

  • Service status checks

  • Usage and quota information

  • Search and filtering operations

⚠️ To Enable Modify Operations:

# Enable all operations (USE WITH CAUTION)
ALLOW_MODIFY_OPERATIONS=true

Tool Registration Behavior:

  • When ALLOW_MODIFY_OPERATIONS=false: Only read-only tools are registered with the MCP server

  • When ALLOW_MODIFY_OPERATIONS=true: All tools (read-only + modify operations) are registered

  • Tool availability is determined at server startup - restart required after changing this setting

Best Practices:

  • Keep ALLOW_MODIFY_OPERATIONS=false in production environments

  • Enable modify operations only in development/testing environments

  • Use separate configurations for different environments

  • Review operations before enabling modify capabilities

  • Restart the MCP server after changing the ALLOW_MODIFY_OPERATIONS setting

💬 Example Queries & Usage Patterns

For comprehensive examples of how to interact with this MCP server, including natural language queries and their corresponding tool mappings, see:

📖 Example Queries & Usage Patterns

This section includes:

  • 🎯 Cluster overview and status queries

  • �️ Instance management operations

  • 🌐 Network configuration tasks

  • � Storage management workflows

  • 🔥 Heat orchestration examples

  • ⚖️ Load balancer operations

  • � Advanced search patterns

  • 📊 Monitoring and troubleshooting

  • 🧠 Complex multi-tool query combinations

Performance Optimization

Large-Scale Environment Support

The MCP server is optimized for large OpenStack environments with thousands of instances:

Pagination Features:

  • Default limits prevent memory overflow (50 instances per request)

  • Configurable safety limits (maximum 200 instances per request)

  • Offset-based pagination for browsing large datasets

  • Performance metrics tracking (processing time, instances per second)

Search Optimization:

  • 2-phase search process (basic info filtering → detailed info retrieval)

  • Intelligent caching with connection reuse

  • Selective API calls to minimize overhead

  • Case-sensitive search options for precise filtering

Connection Management:

  • Global connection caching with validity testing

  • Automatic retry mechanisms for transient failures

  • Connection pooling for high-throughput scenarios

Usage Examples:

# Safe large environment browsing
get_instance_details(limit=50, offset=0)     # First 50 instances
get_instance_details(limit=50, offset=50)    # Next 50 instances

# Emergency override for small environments
get_instance_details(include_all=True)       # All instances (use with caution)

# Optimized search for large datasets
search_instances("web", "name", limit=20, offset=0, case_sensitive=False)

Development

Adding New Tools

Edit src/mcp_openstack_ops/mcp_main.py to add new MCP tools:

@mcp.tool()
async def my_openstack_tool(param: str) -> str:
    """
    Brief description of the tool's purpose.
    
    Functions:
    - List specific functions this tool performs
    - Describe the operations it enables
    - Mention when to use this tool
    
    Use when user requests [specific scenarios].
    
    Args:
        param: Description of the parameter
        
    Returns:
        Description of return value format.
    """
    try:
        logger.info(f"Tool called with param: {param}")
        # Implementation using functions.py helpers
        result = my_helper_function(param)
        
        response = {
            "timestamp": datetime.now().isoformat(),
            "result": result
        }
        
        return json.dumps(response, indent=2, ensure_ascii=False)
        
    except Exception as e:
        error_msg = f"Error: Failed to execute tool - {str(e)}"
        logger.error(error_msg)
        return error_msg

Helper Functions

Add utility functions to src/mcp_openstack_ops/functions.py:

def my_helper_function(param: str) -> dict:
    """Helper function for OpenStack operations"""
    try:
        conn = get_openstack_connection()
        
        # OpenStack SDK operations
        result = conn.some_service.some_operation(param)
        
        logger.info(f"Operation completed successfully")
        return {"success": True, "data": result}
        
    except Exception as e:
        logger.error(f"Helper function error: {e}")
        raise

Testing & Validation

Local Testing

# Test with MCP Inspector (recommended)
./scripts/run-mcp-inspector-local.sh

# Test with debug logging
MCP_LOG_LEVEL=DEBUG uv run python -m mcp_openstack_ops

# Validate OpenStack connection
uv run python -c "from src.mcp_openstack_ops.functions import get_openstack_connection; print(get_openstack_connection())"

🔐 Security & Authentication

Bearer Token Authentication

For streamable-http mode, this MCP server supports Bearer token authentication to secure remote access. This is especially important when running the server in production environments.

Configuration

Enable Authentication:

# In .env file
REMOTE_AUTH_ENABLE=true
REMOTE_SECRET_KEY=my-test-secret-key-12345

Or via CLI:

uv run python -m mcp_openstack_ops --type streamable-http --auth-enable --secret-key your-secure-secret-key-here

Security Levels

  1. stdio mode (Default): Local-only access, no authentication needed

  2. streamable-http + REMOTE_AUTH_ENABLE=false/undefined: Remote access without authentication ⚠️ NOT RECOMMENDED for production

  3. streamable-http + REMOTE_AUTH_ENABLE=true: Remote access with Bearer token authentication ✅ RECOMMENDED for production

🔒 Default Policy: REMOTE_AUTH_ENABLE defaults to false if undefined, empty, or null. This ensures the server starts even without explicit authentication configuration.

Client Configuration

When authentication is enabled, MCP clients must include the Bearer token in the Authorization header:

{
  "mcpServers": {
    "mcp-openstack-ops": {
      "type": "streamable-http",
      "url": "http://your-server:8000/mcp",
      "headers": {
        "Authorization": "Bearer your-secure-secret-key-here"
      }
    }
  }
}

Security Best Practices

  • Always enable authentication when using streamable-http mode in production

  • Use strong, randomly generated secret keys (32+ characters recommended)

  • Use HTTPS when possible (configure reverse proxy with SSL/TLS)

  • Restrict network access using firewalls or network policies

  • Rotate secret keys regularly for enhanced security

  • Monitor access logs for unauthorized access attempts

Error Handling

When authentication fails, the server returns:

  • 401 Unauthorized for missing or invalid tokens

  • Detailed error messages in JSON format for debugging

🎯 Recent Improvements & Enhancements

🔒 Complete Project Isolation Security Implementation ✨

100% Project Isolation Guarantee:

  • ✅ Multi-layer Security Validation: Added comprehensive project ownership validation for all resource operations

  • ✅ Enhanced Delete Operation Security: All delete operations now use secure project-scoped lookup with ownership verification

  • ✅ Create Operation Security: Resource references during creation (networks, images, etc.) verified for project ownership

  • ✅ Query Security Enhancement: All list/get operations include explicit project validation with resource ownership checks

  • ✅ Cross-Project Access Prevention: Advanced protection against accidental operations on similarly-named resources in other projects

  • ✅ Security Test Suite: Added test_project_isolation.py for comprehensive security validation

Technical Implementation:

  • ✅ New Security Utilities: Added get_current_project_id(), validate_resource_ownership(), find_resource_by_name_or_id() functions

  • ✅ Service-Level Security: Enhanced all service modules (compute, network, storage, etc.) with project ownership validation

  • ✅ Secure Resource Lookup: Replaced unsafe name-based loops with secure project-scoped resource lookup

  • ✅ Error Message Enhancement: Improved error messages to clearly indicate project access restrictions

Complete Project Scoping Implementation

Enhanced Security & Tenant Isolation:

  • ✅ All Services Project-Scoped: Identity, Compute, Network, Storage, Image, Orchestration, Load Balancer, and Monitoring services now filter resources by current project ID

  • ✅ Zero Cross-Tenant Data Leakage: Automatic filtering at OpenStack SDK level using current_project_id

  • ✅ Smart Resource Access: Intelligent handling of shared/public resources (networks, images) while maintaining security boundaries

Fixed Image Service Issues 🖼️

Resolved Zero-Image Count Problems:

  • ✅ Enhanced Image Filtering: Now includes public, community, shared, and project-owned images

  • ✅ Intelligent Visibility Handling: Proper handling of different image visibility types

  • ✅ Prevented Empty Results: Fixed filtering logic that was too restrictive

Improved vCPU/RAM Calculation ⚡

Fixed Instance Resource Display:

  • ✅ Embedded Flavor Data Usage: Uses server.flavor attributes directly, avoiding 404 API errors

  • ✅ Accurate Resource Reporting: Proper vCPU and RAM values in cluster status reports

  • ✅ Eliminated API Failures: No more flavor lookup failures causing zero resource values

Enhanced Documentation 📚

Comprehensive Project Scoping Documentation:

  • ✅ Multi-Project Management Guide: Complete setup instructions for managing multiple OpenStack projects

  • ✅ Security & Isolation Details: Detailed explanation of tenant isolation features

  • ✅ Ready-to-Use Configuration: Pre-configured mcp-config.json.multi-project for quick setup

  • ✅ Updated Environment Variables: Enhanced .env.example with project scoping guidance

🚀 Adding Custom Tools

This MCP server is designed for easy extensibility. Follow these steps to add your own custom tools:

Step-by-Step Guide

1. Add Helper Functions (Optional)

Add reusable data functions to src/mcp_openstack_ops/functions.py:

async def get_your_custom_data(target_resource: str = None) -> List[Dict[str, Any]]:
    """Your custom data retrieval function."""
    # Example implementation - adapt to your OpenStack service
    conn = get_openstack_connection()
    results = []
    
    try:
        # Example: Custom query using OpenStack SDK
        resources = conn.your_service.list_resources(
            filters={'name': target_resource} if target_resource else {}
        )
        
        for resource in resources:
            results.append({
                'name': resource.name,
                'id': resource.id,
                'status': resource.status,
                'created_at': resource.created_at,
                # Add your custom fields
            })
            
    except Exception as e:
        logger.error(f"Failed to get custom data: {e}")
        return []
        
    return results

2. Create Your MCP Tool File

Create a new file src/mcp_openstack_ops/tools/get_your_custom_analysis.py:

"""Tool implementation for get_your_custom_analysis."""

import json
from datetime import datetime
from typing import Optional
from ..functions import get_your_custom_data  # Import your helper function
from ..mcp_main import (
    logger,
    mcp,
)

@mcp.tool()
async def get_your_custom_analysis(limit: int = 50, target_name: Optional[str] = None) -> str:
    """
    [Tool Purpose]: Brief description of what your tool does
    
    [Exact Functionality]:
    - Feature 1: Data aggregation and analysis
    - Feature 2: Resource monitoring and insights
    - Feature 3: Performance metrics and reporting
    
    [Required Use Cases]:
    - When user asks "your specific analysis request"
    - Your business-specific monitoring needs
    
    Args:
        limit: Maximum results (1-100)
        target_name: Target resource/service name
    
    Returns:
        Formatted analysis results
    """
    try:
        limit = max(1, min(limit, 100))  # Always validate input
        
        logger.info(f"Getting custom analysis, limit: {limit}, target: {target_name}")
        
        results = await get_your_custom_data(target_resource=target_name)
        
        if not results:
            return f"No custom analysis data found" + (f" for '{target_name}'" if target_name else "")
        
        # Apply limit
        results = results[:limit]
        
        # Format results as table
        table_data = []
        for item in results:
            table_data.append({
                'Name': item.get('name', 'N/A'),
                'ID': item.get('id', 'N/A'),
                'Status': item.get('status', 'N/A'),
                'Created': item.get('created_at', 'N/A'),
            })
        
        # Return formatted JSON
        return json.dumps({
            'title': f'Custom Analysis (Top {len(results)})',
            'data': table_data,
            'total_count': len(results),
            'timestamp': datetime.now().isoformat()
        }, indent=2)
        
    except Exception as e:
        logger.error(f"Failed to get custom analysis: {e}")
        return f"Error: {str(e)}"

3. For Modify Operations (Optional)

If your tool performs modify operations, use the @conditional_tool decorator instead:

"""Tool implementation for set_your_custom_resource."""

from ..mcp_main import (
    conditional_tool,  # Use this instead of @mcp.tool()
    handle_operation_result,
    logger,
)
from ..functions import set_your_custom_resource

@conditional_tool  # Only registers when ALLOW_MODIFY_OPERATIONS=true
async def set_your_custom_resource(resource_name: str, action: str) -> str:
    """
    Manage your custom OpenStack resources.
    
    Use when user requests custom resource management.
    """
    try:
        result = set_your_custom_resource(resource_name, action)
        
        return handle_operation_result(
            result=result,
            operation_name="Custom Resource Management",
            details={
                'Resource': resource_name,
                'Action': action
            }
        )
        
    except Exception as e:
        logger.error(f"Custom resource operation failed: {e}")
        return f"Error: {str(e)}"

4. Update Prompt Template (Recommended)

Add your tool description to src/mcp_openstack_ops/prompt_template.md for better natural language recognition:

### **Your Custom Analysis Tool**

### X. **get_your_custom_analysis**
**Purpose**: Brief description of what your tool does
**Usage**: "Show me your custom analysis" or "Get custom analysis for resource_name"
**Features**: Data aggregation, resource monitoring, performance metrics
**Optional**: `target_name` parameter for specific resource analysis

5. Test Your Tool

# Local testing
./scripts/run-mcp-inspector-local.sh

# Or with Docker
docker-compose up -d
docker-compose logs -f mcp-server

# Test with natural language:
# "Show me your custom analysis"
# "Get custom analysis for target_name"

Tool Registration System

The MCP server uses automatic tool discovery. When you create a new file in src/mcp_openstack_ops/tools/, it's automatically registered through the register_all_tools() function in tools/__init__.py. No manual import registration needed!

Safety System

  • Read-only tools: Use @mcp.tool() - always available

  • Modify tools: Use @conditional_tool - only available when ALLOW_MODIFY_OPERATIONS=true

  • Connection: Always use get_openstack_connection() for OpenStack API access

  • Project isolation: All operations are automatically scoped to OS_PROJECT_NAME

That's it! Your custom tool is ready to use with natural language queries.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add some amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

Available Tools

50 tools
get_availability_zonesB

List availability zones and their status

Returns: JSON string with availability zones information

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description only states that it returns a JSON string with availability zones information. It does not disclose read-only behavior, authentication requirements, or any side effects. The description carries the full burden and is insufficient.

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 very short (two lines) and front-loaded with the purpose. However, it could be slightly more informative while still concise. It is not bloated, but it lacks detail.

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 that the tool has no parameters and an output schema exists, the description is minimally adequate. However, it could mention that the output returns status information. Compared to the sibling complexity, it is incomplete in guiding the agent on when to use this tool.

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 zero parameters, so the schema already covers everything. The description adds no extra parameter information, but with no parameters, the baseline is 4. It does not detract but also does not add value beyond the schema.

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 states 'List availability zones and their status', which clearly indicates the action and resource. However, it does not explicitly differentiate from the sibling tool 'get_load_balancer_availability_zones', which could cause confusion despite being contextually different.

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, such as the load balancer-specific availability zones tool. There is no mention of prerequisites or exclusions.

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

get_domainsB

List Keystone domains subject to cloud policy.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description relies entirely on itself, and it is extremely brief. It fails to disclose critical behavioral traits like pagination limits, common constraints on 'cloud policy,' or whether the returned list is comprehensive.

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, well-formed sentence. It is perfectly concise and front-loads the most critical information—the resource and its specific scope—without any unnecessary fluff.

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 that it takes no parameters, the description defines the scope well. However, because it is a 'list' tool, it is not fully complete; it would benefit from clarifying if this is a paginated list or if there are default filtering criteria for 'cloud policy' adherence.

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?

Since the tool takes zero parameters, the input schema coverage is 100%. Per the rules, the baseline score of 3 applies, as the description adds no additional semantic meaning to the zero required inputs.

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 uses a specific verb ('List') and resource ('Keystone domains'). It distinguishes itself by adding a vital scope constraint: 'subject to cloud policy,' which sets it apart from generic domain listings among its many 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 what the list includes, but it does not explain when to use this specific tool versus another listing tool (e.g., a more general 'get_keystone_domains'). The usage is simply implied by the need to query policy compliance.

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

get_floating_ip_poolsA

Get list of floating IP pools (external networks).

Functions:

  • List all external networks that can provide floating IPs

  • Show available and used IP counts for each pool

  • Display network configuration for floating IP allocation

  • Provide pool capacity and utilization information

Use when user requests:

  • "Show floating IP pools"

  • "List available floating IP networks"

  • "Check floating IP capacity"

  • "What external networks are available?"

Returns: List of floating IP pools with capacity information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes read-only operations like listing and showing capacity, but does not explicitly state that the tool is non-destructive or has no side effects. It is clear enough but lacks explicit safety disclosure.

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 with a clear header, bullet points for functions, example queries, and return type. It is front-loaded with the main purpose. Slightly verbose with 'Functions:' and 'Use when user requests:' but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description provides sufficient context on what the tool does and what information it returns. It covers pool capacity and utilization, which is relevant for floating IP allocation.

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?

Input schema has no parameters, so the baseline is 4. The description adds value by explaining what the output contains (capacity information) and the purpose of the returned data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets a list of floating IP pools, with specific verb 'Get' and resource 'floating IP pools'. It distinguishes from siblings like get_floating_ips by focusing on pools and capacity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides example user queries indicating when to use the tool, such as 'Show floating IP pools' and 'Check floating IP capacity'. However, it does not explicitly mention when not to use or alternatives among siblings.

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

get_floating_ipsA

Get list of floating IPs with their associations.

Functions:

  • Query floating IPs and their current status

  • Display associated fixed IPs and ports

  • Show floating IP pool and router associations

  • Provide floating IP allocation and usage information

Use when user requests floating IP information, external connectivity queries, or IP management tasks.

Returns: List of floating IPs with detailed association information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral transparency burden. The description adequately implies a read-only operation via the 'get' verb and lists what information is returned, but does not explicitly state that it is safe or describe any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description includes some redundancy, with bullet points that essentially repeat the main function. It is structured but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and has an output schema (indicated). The description mentions the return format and covers the necessary context for a straightforward list retrieval tool.

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 input schema has no parameters, so coverage is 100%. The description does not need to add parameter semantics. According to guidelines, zero-parameter tools have a baseline score of 4.

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 that the tool returns a list of floating IPs with associations. However, it does not explicitly differentiate from sibling tools like get_floating_ip_pools, which is a closely related tool.

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 provides usage context ('when user requests floating IP information, external connectivity queries, or IP management tasks'), but lacks exclusions or mention of alternative tools for specific scenarios.

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

get_heat_stack_detailsC

Query a Heat stack by name or ID. section: resources, events, template, outputs.

NameRequiredDescriptionDefault
sectionNoresources
stack_nameYes

Output Schema

NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. It does not state that this is a read-only operation, disclose any permission requirements, or explain how the section parameter changes behavior or defaults; it only lists possible section labels tersely.

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?

Very compact and front-loaded, with no filler. The second sentence is telegraphic ('section: resources, events, template, outputs.') but still readable and appropriately sized for a simple lookup.

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?

For a two-parameter read tool with an output schema, the description covers the basic purpose and the section choices, but leaves gaps around read-only behavior and section semantics. It is minimally adequate rather than complete.

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 0%, so the description must compensate. It does add meaning by clarifying that stack_name accepts a name or ID and by listing section values (resources, events, template, outputs), but it does not explain what each section returns or that section defaults to 'resources'.

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?

States a specific verb ('Query') and resource ('Heat stack') and notes retrieval is by name or ID. It is clearly a detail-fetch tool distinct from the list-oriented sibling get_heat_stacks, though it does not explicitly name that sibling.

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?

Provides no guidance on when to use this versus get_heat_stacks or other stack tools, and states no exclusions or preconditions. Usage is only implied by 'Query a Heat stack'.

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

get_heat_stacksA

Get list of Heat orchestration stacks.

Functions:

  • Query Heat stacks and their current status

  • Display stack creation and update timestamps

  • Show stack templates and resource information

  • Provide orchestration deployment information

Use when user requests stack information, orchestration queries, or infrastructure-as-code status.

Returns: List of Heat stacks with detailed information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It indicates a read-only operation and mentions return format (JSON) and functions (query status, timestamps, etc.), but lacks details on permissions, rate limits, or pagination behavior.

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?

Description is front-loaded with key purpose and includes a bullet list of functions, but has some redundancy (e.g., 'Get list' in title and description). Could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema present, the description sufficiently explains what the tool does and returns. However, it does not mention if results are paginated or limited, which would enhance completeness.

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?

No parameters exist, so schema coverage is 100%. Description adds no param info, which is acceptable since there are none. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'list of Heat orchestration stacks', with specific functions listed. It distinguishes from sibling tools like get_instance or get_routers by focusing on orchestration stacks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use when user requests stack information, orchestration queries, or infrastructure-as-code status', providing clear context. However, it does not mention when not to use or suggest alternatives among the many siblings.

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

get_hypervisor_detailsC

Get detailed information about hypervisors

NameRequiredDescriptionDefault
hypervisor_nameNoName/ID of specific hypervisor or "all" for all hypervisorsall

Output Schema

NameRequiredDescription
resultYes

TDQS

C2.6/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 behavioral burden and does not deliver: it does not confirm this is a read-only operation, does not mention required permissions or whether 'all' could be expensive, and says nothing about the nature of the returned details. An output schema exists, which relieves it of explaining return values, but the safety and cost profile remains undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no wasted words and the resource front-loaded. However, the brevity comes at the cost of under-specification rather than genuine economy.

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?

For a simple one-parameter read tool with a full output schema, the minimum needed to call it correctly is present. Missing are the behavioral cues normally expected when no annotations exist: read-only confirmation and the cost of requesting all hypervisors.

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% and the single parameter is fully documented, including the 'all' default. The description adds nothing beyond that, which meets the baseline for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a verb ('Get') and resource ('hypervisors') so the target is unambiguous, but 'detailed information' is vague about what details are returned. Unlike siblings such as get_load_balancer_details, the description gives no hint of scope or content, so differentiation rests entirely on the resource noun.

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 statement of when to use this versus alternatives, and no prerequisites or exclusions. The only scoping hint is the schema's 'all' default, not the description itself.

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

get_identity_groupsB

List Keystone groups subject to cloud policy.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It does not mention that this is a read-only operation, whether it requires specific permissions, how results are ordered or paginated, or what 'subject to cloud policy' entails behaviorally. The output schema covers return values, but key behavioral traits remain undisclosed.

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?

A single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose without unnecessary elaboration.

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?

For a zero-parameter list tool with an output schema, the description is minimally adequate but leaves ambiguity around what 'subject to cloud policy' means and whether all groups are returned or only a filtered subset. It could benefit from a brief clarifier about scope or read-only nature.

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 zero parameters, so there is nothing to document beyond the schema. Baseline score of 4 applies for zero-parameter tools.

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 states a specific verb ('List') and resource ('Keystone groups') with a scope qualifier ('subject to cloud policy'). It distinguishes the resource from siblings like get_user_list and get_role_assignments, though the phrase 'subject to cloud policy' is somewhat vague about what exactly is returned.

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?

There is no guidance on when to use this tool versus alternatives such as get_user_list, get_role_assignments, or get_domains. The description only states what it does, leaving the agent to infer appropriate usage contexts.

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

get_image_detail_listA

Get detailed list of all images with comprehensive metadata.

Functions:

  • List all images available in the project

  • Show image status, size, and format information

  • Display image properties and metadata

  • Provide ownership and visibility details

Use when user requests image listing, image information, or image metadata details.

Returns: Comprehensive image list in JSON format with detailed metadata, properties, and status information.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the tool returns a comprehensive list with metadata but does not disclose potential volume, pagination, or performance implications. The read-only nature is implied by 'get' but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat verbose with bullet points and a separate 'Returns' section that largely duplicates the initial sentence. It could be more concise by merging the first sentence and summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no annotations, the description adequately explains what the tool does and its output (metadata, properties, status). It does not mention pagination or rate limits, but for a simple list tool without filters, it is sufficient.

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 zero parameters, and schema coverage is 100% (trivially). The description adds value by confirming no input is needed and explaining the output scope ('all images'). This clarifies the tool's lack of filtering options, which is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Get detailed list of all images with comprehensive metadata' and lists specific functions (status, size, format). It clearly distinguishes from sibling tools which target other resources like volumes, instances, or load balancers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Use when user requests image listing, image information, or image metadata details.' This clearly indicates when to invoke this tool, though it does not mention when not to use it or suggest alternatives.

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

get_image_membersA

List member projects for an image by name or ID.

NameRequiredDescriptionDefault
image_nameYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

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

Since there are no annotations provided, the description must carry the full burden of behavioral disclosure. It provides no information regarding error states, whether the operation is read-only, or potential limitations on the returned member list.

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, highly efficient sentence that contains all necessary operational information without unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval function like listing members, the description provides sufficient context for the AI agent to understand how and when to call the tool, despite lacking return-value specifics.

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 schema provides only a generic string type. The description adds crucial semantic value by stating that this single parameter can accept either an 'image name' or an 'ID,' compensating for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific terminology ('List member projects') and clearly defines the resource ('for an image'). Given the context of many infrastructure siblings, this purpose is instantly recognizable and distinct.

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 mentions the accepted input types ('name or ID'), which helps guide usage. However, it provides no guidance on prerequisites (e.g., what permissions are needed) or when to use alternatives, limiting the score.

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

get_instanceA

Unified instance query tool supporting all instance retrieval patterns. Consolidates functionality from get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances.

Functions:

  • Get specific instances by names or IDs

  • Filter instances by status (ACTIVE, SHUTOFF, ERROR, etc.)

  • Search instances across multiple fields (name, flavor, image, host, etc.)

  • List all instances with pagination

  • Support both summary and detailed information modes

Use when user requests instance information, status checks, or instance searches.

NameRequiredDescriptionDefault
idsNoSpecific instance ID(s) to retrieve (comma-separated)
limitNoMaximum instances to return (default: 50, max: 200)
namesNoSpecific instance name(s) to retrieve (comma-separated: "vm1,vm2,vm3")
offsetNoNumber of instances to skip for pagination
statusNoFilter by instance status (e.g., "ACTIVE", "SHUTOFF", "ERROR")
detailedNoIf True, return detailed information; if False, return summary only
search_inNoFields to search in ("name", "status", "host", "flavor", "image", "availability_zone", "all")name
search_termNoSearch term for partial matching across fields
all_instancesNoIf True, retrieve all instances (ignores other filters)
case_sensitiveNoCase-sensitive search (default: False)

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses supported retrieval modes, pagination, and summary/detailed output, but does not state that the operation is read-only, how multiple filters interact, or any permission/rate-limit considerations.

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 front-loaded with its unified purpose and then lists concrete supported functions. It is efficient overall, though the function list and final usage sentence have some overlap.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 100% schema coverage and an output schema, the description does not need to explain return values. It adequately summarizes the main retrieval patterns for a ten-parameter tool, though it could clarify filter precedence and the relationship to duplicate sibling tools.

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 coverage is 100%, so the schema already documents all ten parameters. The description adds useful pattern-level grouping (by names/IDs, status, search fields, pagination), but does not add syntax, precedence, or combination semantics beyond what the schema provides.

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 states a specific resource and verb ('Unified instance query tool') and enumerates retrieval patterns it supports. It also names the sibling tools whose functionality it consolidates, which helps distinguish it, though those siblings still appear as separate tools and no explicit selection rule is given.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage condition: 'Use when user requests instance information, status checks, or instance searches.' However, it does not explicitly say when to use this consolidated tool versus the still-present specialized siblings such as get_instance_details or search_instances.

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

get_instance_by_nameC

Get detailed information for a specific instance by name.

NameRequiredDescriptionDefault
instance_nameYesName of the instance to retrieve

Output Schema

NameRequiredDescription
resultYes

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 behavioral burden, and it discloses almost nothing: not whether instance names are unique, what happens when the name is not found (error vs empty), or whether any permissions are required. The presence of an output schema excuses it from describing return fields, but the missing-not-found behavior is a real gap for a lookup 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?

A single front-loaded sentence with zero waste and the lookup key surfaced early. It is appropriately sized, though there is little content to be concise about given the omitted guidance.

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?

With one documented parameter and an output schema covering return values, the definition is minimally servable. The unresolved ambiguity against get_instance, get_instance_details, and search_instances in a crowded namespace is the main completeness gap an agent would care about.

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?

Only one parameter exists and the schema documents it fully at 100% coverage ('Name of the instance to retrieve'), so the schema does the work. The description adds nothing beyond restating the parameter, matching the baseline 3 for high-coverage schemas.

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?

States a specific verb and resource ('Get detailed information for a specific instance') plus the lookup key ('by name'), so the operation itself is unambiguous. However, it does not distinguish itself from the closely related siblings get_instance, get_instance_details, and search_instances, leaving the agent to guess which instance accessor to pick.

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?

There is no explicit when-to-use statement, no exclusions, and no mention of when to prefer the ID-based get_instance or the broader search_instances. The 'by name' phrasing faintly implies the ID-based alternative, but the agent must infer that from the tool name alone.

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

get_instance_detailsA

Provides detailed information and status for OpenStack instances with pagination support.

Functions:

  • Query basic instance information (name, ID, status, image, flavor) with efficient pagination

  • Collect network connection status and IP address information

  • Check CPU, memory, storage resource usage and allocation

  • Provide instance metadata, keypair, and security group settings

  • Support large-scale environments with configurable limits

Use when user requests specific instance information, VM details, server analysis, or instance troubleshooting.

NameRequiredDescriptionDefault
limitNoMaximum number of instances to return (default: 50, max: 200)
offsetNoNumber of instances to skip for pagination (default: 0)
include_allNoIf True, ignore pagination limits (use with caution in large environments)
instance_idsNoComma-separated list of instance IDs to query (optional)
all_instancesNoIf True, returns all instances (default: False)
instance_namesNoComma-separated list of instance names to query (optional)

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose pagination behavior and large-scale support, and implicitly signals a read operation, but it never states that results are returned as a collection, whether the query is scoped to a project, or what the cost of the include_all-style bulk path is beyond the schema's own warning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, which is good, but the five-bullet 'Functions' list contains filler that restates the schema ('Support large-scale environments with configurable limits') and mixes 'basic instance information' against the 'detailed' framing. A tighter two-sentence description would serve better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema is present, so return values need not be explained, and all parameters are fully described in the schema. The remaining need is purpose and usage framing, which the description supplies, making it complete enough to invoke correctly.

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 all six parameters are already documented in the schema, and the description adds only a general note about 'configurable limits' and pagination. It does not explain the relationship between instance_ids, instance_names, all_instances, and include_all, which is the one place narrative could have added real value.

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 states a clear verb+resource (retrieve detailed information and status for OpenStack instances) and enumerates the specific data it returns (network/IPs, CPU/memory/storage, metadata, keypair, security groups). However, it does not differentiate itself from close siblings like get_instance, get_instance_by_name, get_instances_by_status, or search_instances, and the bullet 'Query basic instance information' partially undercuts the 'details' framing of the name.

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 closing sentence gives usage triggers (VM details, server analysis, instance troubleshooting), which is better than nothing. But those triggers overlap almost entirely with what get_instance, get_instance_by_name, and search_instances would also claim, and no alternative or exclusion is named despite four closely related siblings.

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

get_instances_by_statusB

Get instances filtered by status.

NameRequiredDescriptionDefault
statusYesInstance status to filter by (ACTIVE, SHUTOFF, ERROR, BUILDING, etc.)

Output Schema

NameRequiredDescription
resultYes

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 behavioral burden. The word 'Get' implies a read operation, but the description does not disclose pagination, permissions, or other read-behavior details beyond the operation type.

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 front-loaded sentence with no redundant or wasted wording. It is appropriately sized for a simple filtered-list tool.

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?

The tool is simple, has a fully described single parameter, and has an output schema, so the description is sufficient for invocation. However, it lacks context for selecting this tool over sibling tools such as search_instances.

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 single parameter has 100% schema description coverage, including example status values. The description repeats that filtering is by status but adds no syntax or format details beyond the schema, fitting the baseline of 3 when schema coverage is high.

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 gives a clear verb and resource: it gets instances and filters them by status. It is specific enough to distinguish the tool from generic instance retrieval, but it does not explicitly differentiate it from the sibling tool search_instances.

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 implies the tool is used when filtering by status, but gives no explicit guidance on when to use it versus search_instances or other sibling tools. There are no exclusions or prerequisites.

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

get_keypair_listA

Get list of SSH keypairs for the current user.

Functions:

  • Query SSH keypairs and their fingerprints

  • Display keypair types and creation dates

  • Show public key information (truncated for security)

  • Provide keypair management information

Use when user requests SSH key management, keypair information, or security key queries.

Returns: List of SSH keypairs with detailed information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the return content (fingerprints, types, dates, truncated public key) but does not explicitly state that the operation is read-only or any authentication requirements. The name implies a read operation, but transparency is moderate.

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 well-structured with bullet points and sections (Functions, Use when, Returns). It is concise and front-loaded with the main purpose. Minor redundancy could be trimmed but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and an output schema (implied), the description covers the purpose, usage scenarios, and return content. Missing explicit read-only declaration or auth notes, but it is generally complete for a simple list tool.

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?

No parameters exist, so schema coverage is 100%. The description adds context about the returned fields (fingerprints, types, dates), which adds value beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get list of SSH keypairs for the current user' which is a clear verb+resource combination. It further enumerates specific information returned (fingerprints, types, dates, public key). Among sibling tools, this is distinct from other get_* tools (e.g., get_security_groups, get_volume_list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when user requests SSH key management, keypair information, or security key queries.' This provides clear context, though it does not mention when not to use or alternatives.

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

get_load_balancer_amphoraeB

Get amphora instances for a load balancer or all amphorae.

NameRequiredDescriptionDefault
lb_name_or_idNoOptional load balancer name or ID. If empty, shows all amphorae.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.2/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, yet it only implies a read via the verb 'Get'. It says nothing about permissions/scope required, whether the result includes amphora health or status, or behavior when the LB has no amphorae; only the output schema partially compensates.

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?

A single front-loaded sentence with no filler. Minor redundancy between 'amphora instances' and 'all amphorae', but nothing wasteful.

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?

For a one-optional-parameter read tool with an output schema, the description is barely sufficient: return contents are covered by the output schema, but with no annotations the description should at least confirm the operation is read-only and note what permissions or LB state it depends on.

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% and the single optional parameter already documents the empty-string-means-all behavior. The description merely restates that dual mode and adds no format hints (name vs. UUID, required prefix) beyond the schema.

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?

States a specific verb and resource ('Get amphora instances') and covers both scopes: for a named load balancer or all amphorae. It is distinguishable from the many get_load_balancer_* siblings because amphorae is a distinct resource, though it doesn't explicitly contrast itself with get_load_balancer_details or get_load_balancer_list.

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 'or all amphorae' clause implies the two usage modes and the schema makes the empty-string case explicit, but there is no guidance on when to prefer this over sibling load balancer tools or any stated prerequisites (e.g., requiring an LB ID from get_load_balancer_list).

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

get_load_balancer_availability_zonesB

Get load balancer availability zones.

Returns: JSON string containing availability zones information

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, so the description should disclose behavioral traits. It only states it returns a JSON string, but does not indicate if the operation is read-only, requires authentication, or has any side effects.

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 and no wasted words. It is front-loaded with the purpose.

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 no parameters and an existing output schema, the description is minimal but could be more helpful by clarifying the scope relative to the sibling tools and the meaning of availability zones in this context.

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 tool has no parameters, so the schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, but given the lack of parameters, it is minimally sufficient.

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 'Get' and resource 'load balancer availability zones', making the purpose apparent. However, it does not differentiate from the sibling tool 'get_availability_zones', which may cause confusion.

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, such as get_availability_zones. There is no mention of prerequisites or context for use.

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

get_load_balancer_detailsA

Get detailed information about a specific OpenStack load balancer.

Functions:

  • Shows comprehensive load balancer details including VIP configuration

  • Lists all listeners with their protocols and ports

  • Shows pools and members for each listener

  • Displays health monitor information if configured

  • Provides provisioning and operating status

Use when user requests:

  • "Show details for load balancer [name/id]"

  • "Get load balancer configuration"

  • "Show load balancer listeners and pools"

  • "What's the status of load balancer [name]?"

NameRequiredDescriptionDefault
lb_name_or_idYesLoad balancer name or ID to query

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden, and it does disclose the composite nature of the call: it aggregates listeners, pools/members, and health monitors in one response, which tells an agent this is a heavier read than a single-resource fetch. Read-only semantics are implied by "Get"/"Shows", but permissions, not-found behavior, and cost of the aggregation are not stated.

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?

Front-loaded with the purpose, then two scannable bullet groups (Functions, Use when). The four trigger phrases are slightly repetitive but each maps to a distinct query pattern; there is no filler or redundancy elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be described in detail, and one required parameter is fully documented. The description is sufficient to call the tool correctly; only error/edge behavior (nonexistent LB, empty listeners) is unaddressed.

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 coverage is 100% with a single required parameter whose description ("Load balancer name or ID") already covers it. The description adds nothing about acceptable formats (UUID vs. name, ambiguity resolution) beyond what the schema states, so baseline 3 applies.

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?

States a specific verb and resource ("Get detailed information about a specific OpenStack load balancer") and enumerates exactly what detail is bundled: VIP config, listeners, pools/members, health monitors, status. It doesn't explicitly name a sibling like get_load_balancer_list as the alternative, but "specific" vs. the sibling list tool is readily inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The "Use when user requests" block gives four concrete trigger utterances (show details, get configuration, show listeners/pools, check status), which maps well to how an agent routes natural-language requests. It lacks explicit when-not/exclusion guidance pointing to get_load_balancer_listeners, get_load_balancer_pools, etc., for narrower lookups.

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

get_load_balancer_flavorsB

Get load balancer flavors.

Returns: JSON string containing flavors information

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations provided and the description only states it returns a JSON string. It lacks disclosure of behavioral traits such as read-only nature, authentication needs, or performance characteristics. The word 'Get' implies read-only, but no explicit details.

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 with two sentences, front-loading the purpose. It could be slightly more structured but is not verbose.

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 no parameters and presence of an output schema, the description is mostly adequate. However, it does not explain what 'flavors' are or how the result relates to other load balancer operations, which could help overall 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?

With zero parameters and 100% schema coverage, the description adds minimal value but does not need to. Baseline for 0 parameters is 4; the description confirms there are no inputs, which is consistent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Get load balancer flavors', clearly identifying the verb and resource. It distinguishes from sibling tools like get_load_balancer_amphorae or get_load_balancer_availability_zones.

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 on when to use this tool versus alternatives. The description does not specify context, prerequisites, or exclude cases, leaving the agent to infer usage from the name alone.

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

get_load_balancer_health_monitorsA

Get health monitors, optionally filtered by pool.

Functions:

  • Lists all health monitors or monitors for a specific pool

  • Shows monitor types (HTTP, HTTPS, TCP, PING, UDP-CONNECT)

  • Displays health check intervals, timeouts, and retry settings

  • Provides HTTP-specific settings (method, URL path, expected codes)

Use when user requests:

  • "Show all health monitors"

  • "List health monitors for pool [name/id]"

  • "What health checks are configured?"

  • "Show health monitor configuration"

NameRequiredDescriptionDefault
pool_name_or_idNoOptional pool name or ID to filter monitors (empty for all)

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must carry behavioral disclosure. The verbs 'Get' and 'Lists' plus the enumerated output fields make clear this is a non-mutating read, and the Functions list usefully previews what the response contains. However, it says nothing about permissions/auth requirements, result volume, or pagination behavior.

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 lead sentence is front-loaded and the two bulleted lists are scannable rather than prose-heavy. There is mild redundancy between the Functions list and the trigger-phrase list, but each section serves a different reader need and no sentence is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter read tool with an output schema, the definition covers purpose, return contents, and invocation triggers adequately, so return-value explanation is rightly left to the schema. The remaining gap is edge-case behavior, such as what happens when the supplied pool name or ID does not match any pool.

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% for the single optional parameter, and the schema already documents the 'empty for all' convention. The description only restates the pool filtering at a high level, adding no format hints (e.g., name vs. UUID resolution) beyond what the schema provides. Baseline 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 opens with a specific verb and resource ('Get health monitors') plus scope ('optionally filtered by pool'), and the Functions list enumerates exactly what is returned (monitor types, intervals, timeouts, HTTP settings). This makes the tool clearly distinct from adjacent siblings like get_load_balancer_pools or get_load_balancer_pool_members, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when user requests' section gives four concrete trigger phrases covering both the unfiltered ('Show all health monitors') and filtered ('List health monitors for pool [name/id]') cases. It lacks any explicit when-not-to-use guidance or named alternative tools, which keeps it from a 5.

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

get_load_balancer_l7_policiesB

Get L7 policies for a listener or all L7 policies.

NameRequiredDescriptionDefault
listener_name_or_idNoOptional listener name or ID to filter policies. If empty, shows all policies.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/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 behavioral-disclosure burden. 'Get' implies a read operation, but it says nothing about permissions, pagination, result size, or other operational traits; the output schema helps with return values, but the description itself is minimal.

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 definition is a single, front-loaded sentence with no wasted words. It states the resource and the optional filtering scope immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one optional, fully documented parameter and an output schema, the description supplies enough context to invoke it correctly. The main gap is the absence of guidance on when to prefer this tool over related L7 rules or listener tools.

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 listener_name_or_id parameter is already fully documented as optional and empty-means-all. The description mirrors that behavior ('for a listener or all L7 policies') but does not add format, identification, or filtering details beyond the schema.

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 states a specific verb and resource (Get L7 policies) and gives the scope (for a listener or all policies). It is clear enough to distinguish from siblings like get_load_balancer_l7_rules by resource name, though it does not explicitly call out when this tool should be chosen over that sibling.

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 the optional filter behavior: pass a listener to scope policies, or omit it to retrieve all. It does not state when to use this tool versus alternatives such as get_load_balancer_l7_rules or get_load_balancer_listeners, so the usage guidance remains implicit.

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

get_load_balancer_l7_rulesA

Get L7 rules for a specific L7 policy.

NameRequiredDescriptionDefault
policy_name_or_idYesL7 policy name or ID (required)

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden; 'Get' implies a safe read, but it says nothing about permissions, pagination, or behavior when the policy has zero rules. An output schema exists, which relieves it of explaining return structure, so the remaining gap is moderate rather than severe.

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?

One short sentence, front-loaded with the verb and resource, with the scoping condition stated immediately. There is no filler to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-required-parameter read tool with full schema coverage and an output schema, the description covers what is needed to select and call it. Only the absence of any hint about empty-result behavior keeps it from being fully complete.

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% and the single parameter is already documented as 'L7 policy name or ID (required)'. The description only restates that the value identifies a specific policy, adding no format, lookup, or resolution semantics beyond the schema.

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 states a specific verb ('Get') and resource ('L7 rules') scoped to an L7 policy, which distinguishes it from the sibling get_load_balancer_l7_policies that returns policies rather than rules. It stops short of explicitly naming that sibling or contrasting the two.

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?

Mentioning 'for a specific L7 policy' implies a policy identifier is required and that this is a drill-down call after listing policies, but it never states when to use this versus get_load_balancer_l7_policies or what happens if the policy has no rules.

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

get_load_balancer_listA

Retrieve comprehensive list of OpenStack load balancers with detailed information.

Functions:

  • Lists all load balancers in the OpenStack cluster

  • Provides detailed load balancer information including VIP, status, listeners

  • Supports pagination for large environments (limit/offset)

  • Shows listener count and basic listener information for each load balancer

  • Displays provisioning and operating status for troubleshooting

Use when user requests:

  • "Show me all load balancers"

  • "List load balancers with details"

  • "What load balancers are available?"

  • "Show load balancer status"

NameRequiredDescriptionDefault
limitNoMaximum load balancers to return (1-200, default: 50)
offsetNoNumber of load balancers to skip for pagination (default: 0)
include_allNoReturn all load balancers ignoring limit/offset (default: False)

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does disclose useful traits: it lists all load balancers, includes VIP/status/listener information, supports pagination, and shows provisioning and operating status. The read-only nature is strongly implied by 'Retrieve', 'Lists', and 'Shows', though it is not explicitly declared as non-destructive.

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 front-loaded and organized into useful sections for capabilities and user requests. It is slightly repetitive in restating listing and detail behavior, but the examples and bullet structure earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with a rich input schema and an output schema, the description gives enough context to invoke it correctly for listing and status inspection. The main remaining gap is sibling differentiation from get_load_balancer_details and listener-specific tools, but the core operation is well covered.

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 limit, offset, and include_all precisely. The description adds only general pagination context via limit/offset and does not mention include_all or add format details beyond the schema, making 3 the appropriate baseline.

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 that this tool retrieves a list of all OpenStack load balancers with detailed information, including VIP, status, and listeners. It is distinguishable as the list-all tool, but it does not explicitly contrast itself with the sibling get_load_balancer_details or subresource tools such as get_load_balancer_listeners.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when user requests' section gives clear example phrases that map to listing and status-checking scenarios. However, it does not state when not to use this tool or point to alternatives like get_load_balancer_details for a single load balancer or get_load_balancer_listeners for listener-specific queries.

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

get_load_balancer_listenersA

Get listeners for a specific OpenStack load balancer.

Functions:

  • Lists all listeners attached to a load balancer

  • Shows listener protocols, ports, and configurations

  • Displays admin state and default pool associations

  • Provides creation and update timestamps

Use when user requests:

  • "Show listeners for load balancer [name/id]"

  • "List load balancer listeners"

  • "What ports are configured on load balancer [name]?"

  • "Show listener configuration for [lb_name]"

NameRequiredDescriptionDefault
lb_name_or_idYesLoad balancer name or ID

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It clearly implies a read-only listing operation and describes returned fields (protocols, ports, admin state, timestamps), but it does not disclose permissions, pagination, or error behavior.

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 purpose is front-loaded and the bullet structure is easy to scan. There is some redundancy between the opening sentence, the 'Lists all listeners' function line, and near-duplicate usage examples, but the definition remains reasonably tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one fully described parameter and an output schema, the description provides enough purpose, output-field context, and usage examples to call it correctly. Minor operational details like pagination or not-found behavior are absent but not critical.

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?

There is only one parameter, and schema description coverage is 100%. The description does not add syntax or format detail beyond the schema's 'Load balancer name or ID', so baseline 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 states a specific verb and resource: getting listeners for a specific OpenStack load balancer. It distinguishes the resource from sibling load balancer tools implicitly, though it does not explicitly name alternatives like pools or health monitors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'Use when user requests' examples that map user intent to this tool. However, it does not state when not to use it or name a sibling alternative for related listener-adjacent questions.

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

get_load_balancer_pool_membersA

Get members for a specific OpenStack load balancer pool.

Functions:

  • Lists all members in a specific pool

  • Shows member addresses, ports, weights, and health status

  • Displays member admin state and operational status

  • Provides monitor configuration for each member

Use when user requests:

  • "Show members for pool [name/id]"

  • "List pool members"

  • "What members are in pool [name]?"

  • "Show pool member status"

NameRequiredDescriptionDefault
pool_name_or_idYesPool name or ID to query members for

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/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, and it does reasonably well: it enumerates the returned data (addresses, ports, weights, health status, admin/operational state, monitor config), making clear this is a read-only enumeration. It does not mention behavior for a nonexistent pool, pagination, or permissions.

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?

Front-loaded one-sentence purpose followed by an optional function list and phrasing examples; each block is useful and skimmable. The 'Functions' bullets partially overlap with the opening sentence, adding mild redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not document return shape, and it still summarizes the visible fields. For a one-parameter read tool with no annotations this is nearly complete; only error/empty-result behavior is unaddressed.

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?

Single parameter at 100% schema coverage, so the schema already explains 'pool_name_or_id'. The description only implies the argument via 'a specific ... pool' and adds no format hints or accepted-ID notes beyond what the schema states.

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?

Opens with a specific verb+resource: 'Get members for a specific OpenStack load balancer pool.' This is clearly distinct from siblings like get_load_balancer_pools, though it doesn't explicitly state the relationship (use get_load_balancer_pools to discover a pool, then this tool to enumerate members).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when user requests' block gives four concrete, quoted invocation phrases, which makes selection easy. It lacks any when-not guidance or pointer to alternatives (e.g. get_load_balancer_pools for listing pools or get_load_balancer_health_monitors for pool-level health).

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

get_load_balancer_poolsA

Get load balancer pools, optionally filtered by listener.

Functions:

  • Lists all pools or pools for a specific listener

  • Shows pool protocols, load balancing algorithms

  • Displays members in each pool with their status

  • Provides health monitor associations

Use when user requests:

  • "Show all load balancer pools"

  • "List pools for listener [name/id]"

  • "What pools are configured on [listener_name]?"

  • "Show pool members and their status"

NameRequiredDescriptionDefault
listener_name_or_idNoOptional listener name or ID to filter pools

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

Annotation coverage is zero, so the description carries the full burden; it does disclose that results include protocols, algorithms, member statuses, and health monitor associations, and the 'Get/Lists/Shows' framing implies a read-only operation. However, it says nothing about permissions, pagination, or behavior when the listener filter matches nothing.

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 main purpose is front-loaded in the first line and the function bullets are scannable. The four quoted user phrases are somewhat repetitive padding, but each is short and supports retrieval matching.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema and full schema coverage, the description covers what is returned at a useful level of detail. Only minor gaps remain (filter-miss behavior, pagination) and are not critical for correct invocation.

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% and the single parameter is already documented as an optional listener name/ID filter. The description's phrase 'optionally filtered by listener' merely restates the schema, so baseline 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?

States a specific verb and resource (get load balancer pools) plus the filter scope, which is clear and distinct from the sibling get_load_balancer_pool_members. It does not explicitly name that sibling as the alternative for member-only queries, but the primary purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when user requests' block with four verbatim example queries gives an agent concrete triggers for selecting this tool. There is no explicit 'do not use when' or named alternative, so it stops short of a 5 despite clear usage context.

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

get_load_balancer_providersB

Get load balancer providers.

Returns: JSON string containing providers information

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It only states that the tool returns a JSON string, omitting any side effects, authentication needs, or rate limits. As a read operation, it lacks necessary behavioral context.

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, using a single sentence and a line about the return type. It is front-loaded and contains no unnecessary words, earning its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description is nearly complete for its simplicity. However, it could briefly explain what load balancer providers are to improve completeness.

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 zero parameters, so the baseline is 4. The description does not need to add parameter meaning, but it correctly implies no input is required.

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 gets load balancer providers, with a specific verb and resource. It distinguishes it from sibling tools which target other resources. However, it does not clarify what 'providers' means in this context.

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 on when to use this tool versus alternatives. The description does not mention any prerequisites or context where this tool is appropriate, leaving the agent without decision criteria.

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

get_load_balancer_quotasB

Get load balancer quotas for a project or all projects.

NameRequiredDescriptionDefault
project_idNoOptional project ID. If empty, shows quotas for all projects.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/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 disclosure burden, and it is thin: 'Get' implies a read, but nothing is said about permission/admin requirements, whether empty project_id triggers a cross-project listing that could be expensive, or what the quota values represent.

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?

A single well-formed sentence with no wasted words and the scope qualifier placed up front. It is minimal but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the single parameter is fully documented, so return values and param meaning need not be restated. The only real gap is the absence of guidance relative to the similar get_quota sibling.

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 coverage is 100% and the schema already documents that an empty project_id means all projects; the description merely restates that same contrast. Baseline 3 applies since the schema does the heavy lifting.

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?

States a specific verb and resource ('Get load balancer quotas') plus the scoping dimension ('for a project or all projects'). It is distinguishable from the sibling get_quota (generic quotas) and from get_load_balancer_list, though it never names those alternatives.

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?

Usage is only implied: the phrase 'for a project or all projects' hints at when the parameter is omitted, but there is no explicit statement about when to call this instead of get_quota or get_load_balancer_details, and no prerequisites given.

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

get_network_detailsA

Provides detailed information for OpenStack networks, subnets, routers, and security groups.

Functions:

  • Query configuration information for specified network or all networks

  • Check subnet configuration and IP allocation status per network

  • Collect router connection status and gateway configuration

  • Analyze security group rules and port information

Use when user requests network information, subnet details, router configuration, or network troubleshooting.

NameRequiredDescriptionDefault
network_nameNoName of network to query or "all" for all networks (default: "all")all

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose the data collected (config info, subnet IP allocation, router connection status, security group rules and port info), which is useful. It does not state that the operation is read-only (implied by 'get'/'Provides'), nor mention scope limitations such as whether routers/SGs are included only when referenced by the network.

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?

It is front-loaded with the core purpose, then a compact bullet list of covered resources, followed by a usage line. The bullet list partly restates the opening sentence, but overall it is efficient and appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary, and the single optional parameter is fully documented in the schema. The description sufficiently conveys what is retrieved for a read-only query tool, though it could better clarify boundaries with the router and security-group siblings.

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% and there is a single optional parameter with a documented default ('all'), so the schema does the heavy lifting. The description adds no syntax, format, or default behavior details beyond the schema; baseline 3 applies.

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 first sentence states a clear verb and resource set ('Provides detailed information for OpenStack networks, subnets, routers, and security groups'), so an agent knows roughly what it returns. However, it does not distinguish itself from siblings such as get_routers and get_security_groups, leaving ambiguity about whether those are covered here or should use the dedicated tools.

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 final sentence gives usage scenarios ('network information, subnet details, router configuration, or network troubleshooting'), which implies when to call it. But there are no exclusions or alternatives named, and the overlap with get_routers/get_security_groups is unresolved, so an agent cannot confidently route between them.

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

get_network_qos_policiesB

List project-owned Neutron QoS policy containers; no bandwidth rules are created.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the disclosure burden; 'List' plus 'no bandwidth rules are created' signals a read-only, non-mutating operation, which is useful. However, it says nothing about scoping rules, pagination, or what 'project-owned' means in practice (current project vs. all visible projects).

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?

A single compact sentence with the core purpose front-loaded. The trailing clause about bandwidth rules is slightly cryptic but earns its place by scoping what is and is not returned.

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?

Zero parameters and a present output schema mean little description is strictly required. Still, for a listing tool with no annotations, it could state the returned scope (e.g., all policies in the current project, unfiltered) to remove ambiguity about 'project-owned'.

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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is fully described and empty. Baseline 4 applies for a no-parameter tool.

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?

States a specific verb (List) and a specific resource (project-owned Neutron QoS policy containers), and clarifies it returns containers rather than bandwidth rules. It does not explicitly differentiate from the nearby get_volume_qos sibling, but the network-vs-volume distinction is inferable from 'Neutron'.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative tool is named despite get_volume_qos and get_network_details being plausible confusions. Usage is only implied by the word 'List'.

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

get_project_detailsB

Get OpenStack project details (similar to 'openstack project list/show').

NameRequiredDescriptionDefault
project_nameNoName of specific project to show details for (optional, lists all if empty)

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.2/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 disclosure burden. It does not mention that listing projects typically requires elevated/admin privileges, nor whether the response is scoped to the caller's token, nor any pagination behavior; 'Get ... details' only weakly implies a read.

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?

One compact sentence, front-loaded with the verb and resource, with the CLI analogy as a compact mental model. Nothing is wasted, though the parenthetical does more work than a direct statement of scope would.

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?

An output schema exists, so return values need not be explained, and the tool has only one optional parameter. Still, for a no-annotation tool the description leaves out permission requirements and the list-vs-show distinction, which are the pieces an agent would otherwise need.

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% and the single optional 'project_name' parameter is fully documented in the schema (including the empty-string-means-list-all behavior). The description adds nothing beyond that, so baseline 3 applies.

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?

States a specific verb ('Get') and resource ('OpenStack project details'), and the 'openstack project list/show' analogy pins down the domain. No sibling tool covers projects, so the description does not need to differentiate, though it never says whether this is admin-scoped or tenant-scoped.

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 'list/show' analogy implies two modes (enumerate all vs. inspect one), but the description never states when to use which or any prerequisite; the actual list-vs-show rule lives only in the schema's parameter description, not here.

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

get_quotaB

Get quota information for projects (similar to 'openstack quota show').

NameRequiredDescriptionDefault
project_nameNoName of the project (optional, defaults to current project if empty)

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden; 'Get' implies a safe read with no side effects, and the tool is simple, so the risk of miscommunication is low. However, it does not state auth/permission expectations, whether the default 'current project' behavior differs, or what quota categories come back.

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?

A single, front-loaded sentence with the CLI analogy attached; no filler. It is arguably too terse rather than too long, but structurally sound.

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?

An output schema exists, so return values need not be explained, and the tool is a simple single-parameter read. Still, with no annotations and no guidance on which quota categories (compute/network/storage) it returns, an agent must guess at scope.

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 coverage is 100% and the single optional `project_name` parameter already documents the 'empty means current project' default. The description adds no syntax, format, or naming details beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('Get quota information for projects') and the parenthetical maps it to the familiar `openstack quota show`, which pins down scope. It is distinguishable from the sibling `get_load_balancer_quotas`, though it never says so explicitly.

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?

Usage is only implied: the reader must infer this is the general project-quota tool versus `get_load_balancer_quotas` or `get_usage_statistics`. No explicit when/when-not guidance or prerequisites are given beyond 'projects'.

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

get_resource_monitoringA

Read current project allocations and visible hypervisor capacity.

Functions:

  • Report project flavor allocations, not live CPU or memory utilization

  • Collect hypervisor statistics and resource allocation

  • Separate project quota limits from visible physical capacity

  • Return null for unavailable capacity or incomplete flavor allocations

Use for current inventory and capacity planning. No historical trends or telemetry samples are collected. Physical totals and project allocations have different scopes and should not be divided into a utilization rate.

Returns: Resource monitoring data in JSON format with cluster summary, hypervisor details, and usage statistics.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that values are allocations rather than live utilization, that null is returned for unavailable capacity or incomplete flavor data, and that physical totals and project quotas have different scopes. It omits any mention of permissions or identity scope needed to see "visible" capacity.

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 scope statement is front-loaded and the bulleted function list is scannable. The closing "Returns:" paragraph largely restates fields already covered by the output schema, which is the one piece of expendable text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with an output schema and no annotations, the description supplies the essential interpretive caveats (allocation vs. utilization, null semantics, scope mismatch warning). The only real gap is authorization/scoping expectations for what capacity is 'visible'.

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 takes no parameters, so there is nothing for the description to clarify beyond the schema; this is the baseline case.

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?

Opens with a specific verb+resource ("Read current project allocations and visible hypervisor capacity") and explicitly carves out what it does not report ("not live CPU or memory utilization"). It never names the sibling tools it overlaps with (get_hypervisor_details, get_usage_statistics, get_quota), so differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use for current inventory and capacity planning" gives a clear intended context, and "No historical trends or telemetry samples are collected" functions as a de facto exclusion steering agents away from it for time-series needs. It stops short of naming which alternative tool to use instead when historical data is wanted.

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

get_role_assignmentsA

Get role assignments for the current project.

Functions:

  • Query role assignments for users and groups

  • Display project-level and domain-level permissions

  • Show scope of role assignments

  • Provide comprehensive access control information

Use when user requests permission information, access control queries, or security auditing.

Returns: List of role assignments with detailed scope information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

Discloses that it returns a JSON list of role assignments with scope information and implies read-only behavior. No annotations exist, so the description carries full burden; it covers the main behavior but doesn't detail authentication or implicit project context.

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?

Well-structured with bullet points for functions and a separate returns section, but slightly verbose. Could be tightened without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately covers the return format and use cases. It lacks details on error handling or permissions, but for a straightforward get operation, it is sufficient.

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?

With zero parameters, the schema already covers all inputs. The description adds context by specifying the project is 'current' (implied from authentication), which clarifies the implicit parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets role assignments for the current project, covering specific aspects like project-level and domain-level permissions and scope. It distinguishes itself from sibling tools by focusing on access control, not general resource listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: for permission information, access control queries, or security auditing. However, it does not mention when not to use or alternative tools, leaving some ambiguity.

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

get_routersA

Get list of routers with their configuration.

Functions:

  • Query routers and their external gateway configurations

  • Display router interfaces and connected networks

  • Show routing table entries and static routes

  • Provide comprehensive network routing information

Use when user requests router information, network connectivity queries, or routing configuration.

Returns: List of routers with detailed configuration in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It accurately describes the operation as a read-only list operation returning configuration details. Since there are no side effects or destructive actions, the description sufficiently conveys the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat redundant. The first sentence already conveys the purpose, but the 'Functions' bullet list essentially repeats it with more words. A more concise version could combine the core idea without the bullet list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and the presence of an output schema, the description adequately explains that the return is a JSON list of routers with detailed configuration. It is complete enough for an agent to understand the tool's output.

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 no parameters, so the baseline score is 4. The description adds no parameter-level detail, but none is needed. The schema covers 100% of parameters (none), so the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a list of routers with their configuration. It uses specific verb+resource ('Get routers'), and the 'Functions' bullet list reinforces the scope. This distinguishes it from sibling tools that target other resources like instances or networks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when user requests router information, network connectivity queries, or routing configuration.' This provides clear context for when to employ the tool, though it does not explicitly state when not to use it or contrast with alternatives.

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

get_security_groupsA

Get list of security groups with their rules.

Functions:

  • Query security groups and their rule configurations

  • Display ingress and egress rules with protocols and ports

  • Show remote IP prefixes and security group references

  • Provide comprehensive network security information

Use when user requests security group information, firewall rules, or network security queries.

Returns: List of security groups with detailed rules in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description fully covers behavior. It explains it's read-only (list), details what is returned (ingress/egress rules, protocols, ports), but does not mention any potential permissions or rate limits.

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?

Well-structured with a clear purpose, bullet points for functions, and usage guidance. Slightly verbose but overall effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and presence of output schema, the description is complete: it explains what the tool does, when to use it, and the content of the response.

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?

No parameters exist (schema coverage 100%). Baseline for 0 params is 4; description adds no further meaning but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a list of security groups with their rules, distinguishing it from sibling tools like get_instance or get_volume_list which deal with different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'when user requests security group information, firewall rules, or network security queries.' No conflicting alternatives exist among siblings.

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

get_server_eventsC

Get recent events for a specific server

NameRequiredDescriptionDefault
limitNoMaximum number of events to return (default: 50)
instance_nameYesName or ID of the server instance

Output Schema

NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It says 'recent' without defining a time window, does not state whether events are paginated, ordered, or require any permissions, and gives no indication of volume or rate behavior.

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?

A single sentence that is front-loaded and waste-free. It is appropriately short, though that brevity comes at the cost of missing behavioral detail.

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?

An output schema exists and the input schema is fully documented, so the description need not explain return values. However, for a read tool with no annotations, the lack of information about the 'recent' time window and event scope leaves a meaningful gap for an agent deciding whether to call it.

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 both parameters (instance_name and limit) are already fully documented in the schema. The description adds no extra meaning such as format expectations for instance_name or behavior when limit is omitted.

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 gives a clear verb and resource ('Get recent events') and scopes it to 'a specific server'. It does not differentiate itself from siblings like get_instance_details or get_resource_monitoring, but the purpose is unambiguous.

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?

There is no guidance on when to use this tool versus alternatives such as get_instance_details or get_service_status, and no mention of what 'recent' means or when the tool is inappropriate. Usage is only implied by the phrase 'recent events'.

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

get_server_groupsA

List all server groups with their details

Returns: JSON string with server groups information

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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

As no annotations are provided, the description carries the burden for behavioral disclosure. It implies a read-only operation ('list') but does not mention pagination, error handling, or side effects. Adequate but not rich.

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 two sentences: the first concisely states purpose, the second notes the return format. Every sentence is necessary; no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and the presence of an output schema, the description is complete. It provides essential information (list all groups, with details) and does not need to explain return structure.

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?

With zero parameters and 100% schema coverage, the description adds no parameter details beyond the schema. Baseline is 4 for no parameters, and no additional information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'server groups', specifying scope 'all server groups' with details. This distinguishes it from sibling tools, which target different resources.

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 on when to use this tool versus alternatives. Among many sibling 'get_*' tools, the description does not provide any usage 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_server_volumesA

Get all volumes attached to a specific server

NameRequiredDescriptionDefault
instance_nameYesName or ID of the server instance

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, but 'Get' clearly signals a read-only operation and the output schema covers the return shape. The description does not add details about permissions, missing-server behavior, or rate limits, which is a gap for an unannotated 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 a single front-loaded sentence with no filler. Every word contributes to stating the resource and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter with an output schema, the description is mostly complete. It could mention server-not-found behavior or note the distinction from get_volume_list, but nothing essential for correct invocation is missing.

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 coverage is 100% and the single instance_name parameter is documented as name or ID. The description reinforces that the server is specific but does not add format or syntax detail beyond the schema.

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 states a specific verb and resource: get all volumes attached to a specific server. It distinguishes the result from a general volume list by scoping to one server, though it does not explicitly name sibling alternatives.

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?

Usage is implied by 'attached to a specific server', which tells the agent this is the server-scoped volume lookup. It does not explicitly say when to use this instead of get_volume_list or other volume-related tools.

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

get_service_statusA

Provides status and health check information for each OpenStack service.

Functions:

  • Check active status of all OpenStack services

  • Verify API endpoint responsiveness for each service

  • Collect detailed status and version information per service

  • Detect and report service failures or error conditions

Use when user requests service status, API status, health checks, or service troubleshooting.

Returns: Service status information in JSON format with service details and health summary.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. It mentions detecting and reporting failures, but lacks details on side effects (e.g., read-only nature), authentication needs, or rate limits. It does state the output format, but could be more transparent about behavior.

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 well-structured with bullet points and a clear use-case statement. It is front-loaded with the primary purpose. Slightly verbose with the 'Functions:' list, but every sentence adds value. Appropriate length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description adequately summarizes the return format ('JSON format with service details and health summary'). However, it does not detail the specific fields, which might be needed for call chaining. Still, it is sufficiently complete for a simple tool.

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 input schema has zero parameters, so baseline is 4. The description does not need to add parameter details, but it confirms the tool takes no arguments, matching the schema. No additional semantic value needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool provides status and health check information for each OpenStack service, listing specific functions like checking active status and API responsiveness. It clearly distinguishes from sibling tools (e.g., get_instances_by_status, get_availability_zones) by targeting OpenStack services specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: 'Use when user requests service status, API status, health checks, or service troubleshooting.' This helps the agent decide when to invoke, though it does not explicitly mention when not to use or name alternative tools.

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

get_usage_statisticsA

Get current-project Nova allocation-hours and separate current snapshots.

Functions:

  • Show project usage statistics over a specified time period

  • Display servers, RAM MB-Hours, CPU Hours, and Disk GB-Hours

  • Provide detailed server usage breakdown when available

  • Keep current compute/network/storage snapshots separate from period data

Use for project usage reports. Period data comes from Nova simple tenant usage. It measures allocation-hours, not live utilization or monetary charges. Missing or denied usage API returns failure without synthetic fallback.

NameRequiredDescriptionDefault
end_dateNoExclusive end date at UTC midnight (YYYY-MM-DD; defaults to today)
start_dateNoInclusive start date at UTC midnight (YYYY-MM-DD; defaults to 30 days ago)

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses useful behavior: data comes from Nova simple tenant usage, snapshots are kept separate, and missing/denied usage API returns failure without synthetic fallback. It does not explicitly mention permissions or read-only semantics, but the key data-source and failure behavior are covered.

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 front-loaded and structured with a short functions list. There is minor repetition between the opening sentence and the first bullet, but overall it is efficiently organized and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and both parameters are fully documented, the description provides enough additional context: usage-report purpose, Nova simple tenant usage source, allocation-hours semantics, snapshot separation, and failure behavior. An agent has what it needs to invoke the tool correctly.

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 coverage is 100%, and the schema already documents the date parameters, their UTC-midnight behavior, defaults, and inclusive/exclusive semantics. The description adds only general 'specified time period' context, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: retrieving current-project Nova allocation-hours and separate current snapshots. It also distinguishes the measurement from live utilization and monetary charges, which helps separate it from monitoring-oriented siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states 'Use for project usage reports' and clarifies that the tool measures allocation-hours rather than live utilization or monetary charges. It does not name a direct alternative sibling, but the intended context and exclusions are clear.

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

get_user_listA

Get list of OpenStack users in the current domain.

Functions:

  • Query user accounts and their basic information

  • Display user status (enabled/disabled)

  • Show user email and domain information

  • Provide user creation and modification timestamps

Use when user requests user management information, identity queries, or user administration tasks.

Returns: List of users with detailed information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses key behaviors: it queries user accounts, shows enabled/disabled status, email, domain, and creation/modification timestamps. It states the return format as JSON. Without annotations, it adequately covers behavior, though it omits potential error conditions or pagination.

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 concise, with a clear main sentence, a bullet list summarizing functions, a usage note, and a return statement. Every sentence adds value, and the structure front-loads the essential purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with an output schema, the description covers the purpose, scope ('current domain'), returned fields, and usage context. It is complete without extraneous information.

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?

There are 0 parameters, so baseline is 4. The description does not need to explain parameters and does not add misleading information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a list of OpenStack users in the current domain, specifying included details like status, email, and timestamps. This distinguishes it from sibling tools which focus on other resources (e.g., floating IPs, instances).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Use when user requests user management information, identity queries, or user administration tasks.' It lacks explicit when-not-to-use or alternatives, but given no direct sibling for user listing, this is sufficient.

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

get_volume_backupsA

List Cinder backups visible in the current project.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and its one real contribution is the tenancy scope — results are limited to the current project, not all backups. It says nothing about pagination, ordering, empty-project behavior, or permissions, which is a meaningful gap for an unannotated read 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?

A single sentence with no filler, front-loading both the action and the scoping constraint. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A parameterless read tool with an output schema, so return values need not be described; the tenancy scope is the key fact and it is present. Only minor omissions (ordering/pagination behavior, since output is presumably a list) keep it from a 5.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies no filtering arguments are accepted.

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?

States a specific verb and resource ('List Cinder backups') plus a scope ('visible in the current project'), which lets an agent separate it from siblings like get_volume_list, get_volume_snapshots, and get_volume_transfers. It does not explicitly name or contrast those siblings, so it stops short of a 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?

The description offers no when-to-use framing, no exclusions, and no reference to the near-neighbor tools (snapshots, volume list) that an agent must choose between. Usage is only inferable from the resource name.

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

get_volume_groupsA

List current-project Cinder generic groups. Requires API microversion >= 3.13.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/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. It does disclose a real operational prerequisite (API microversion >= 3.13), which is valuable context an agent cannot get from the schema. It says nothing about pagination, result ordering, or empty-list behavior, leaving meaningful gaps for a zero-annotation 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?

Two short sentences, zero filler, with the resource and scope front-loaded and the prerequisite second. Nothing could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and no parameters, the description need not explain return values, and it covers the one hidden requirement (microversion). A brief note on whether an empty result is possible or how results are ordered would make it fully complete.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the microversion note is a bonus constraint rather than 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?

Specific verb ("List") plus a specific resource ("Cinder generic groups") plus an explicit scope ("current-project"). This clearly separates it from siblings like get_volume_list, get_volume_types, and get_volume_backups, though it doesn't name any sibling explicitly to reinforce the distinction.

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 never states when to reach for this tool versus get_volume_list or get_volume_types, nor does it mention any exclusions. The "current-project" phrase hints at a scoping constraint, but that is inference rather than guidance.

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

get_volume_listA

Get list of all volumes with detailed information.

Functions:

  • List all volumes in the project

  • Show volume status, size, and type information

  • Display attachment information for volumes

  • Provide detailed metadata for each volume

Use when user requests volume listing, volume information, or storage overview.

Returns: Detailed volume list in JSON format with volume information, attachments, and metadata.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It explains that the tool returns a detailed list in JSON with volume information, attachments, and metadata. This is transparent for a read operation, though it does not disclose potential limitations like pagination.

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 well-structured with bullet points and a 'Returns' section, making it easy to parse. However, it is slightly verbose; part of it lists functions that are already implied by the main statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no annotations, and an existing output schema, the description adequately covers the tool's purpose and output. It could be more explicit about scope (e.g., project-level listing) but is otherwise complete.

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 no parameters, so the description adds value by explaining what information the listing includes. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get list of all volumes with detailed information' and explicitly lists the types of information returned (status, size, type, attachments, metadata). It differentiates from siblings like get_volume_snapshots and get_volume_types by focusing solely on volumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Use when user requests volume listing, volume information, or storage overview.' This provides clear use cases, though it does not explicitly mention when not to use or name alternatives.

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

get_volume_qosA

List Cinder QoS specifications. Cloud policy may require admin rights.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden, and it does disclose a genuine behavioral trait: some deployments require admin rights, which affects whether the call will succeed. It also implies a read-only listing. It says nothing about ordering, pagination, or empty results, though the output schema covers return shape.

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?

Two short sentences, zero waste, with the what-is-it statement front-loaded ahead of the caveat. Nothing could be cut without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with an output schema and no annotations, this covers the essentials: what is returned and the permission risk. A brief note on how this differs from network QoS policies would close the remaining gap.

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 takes zero parameters, so there are no semantics to explain; the baseline of 4 applies. Nothing in the description is needed or missing on the parameter front.

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?

States a specific verb and resource: 'List Cinder QoS specifications.' The qualifier 'Cinder' implicitly separates it from the sibling get_network_qos_policies, so an agent can distinguish the volume-side QoS lister. It stops short of an explicit contrast statement, keeping it from a 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, even though get_network_qos_policies sits right next to it in the sibling list. The only operational note is 'Cloud policy may require admin rights,' which is a permission prerequisite rather than selection guidance.

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

get_volume_snapshotsA

Get list of volume snapshots.

Functions:

  • Query volume snapshots and their status

  • Display source volume information

  • Show snapshot creation and modification dates

  • Provide snapshot size and usage information

Use when user requests snapshot information, backup queries, or volume restoration planning.

Returns: List of volume snapshots with detailed information in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/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. It describes the returned information (source volume, dates, size) and implies a read-only operation by listing functions. It does not disclose potential limits or performance, but it is transparent enough for a get operation.

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 clear and front-loaded with the main purpose, followed by bullet points and use cases. It could be slightly more concise, but it effectively communicates the tool's capabilities without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no parameters and an output schema exists. The description explains the return value (JSON with detailed info) and covers key aspects. For a simple list tool, this is complete and provides sufficient context.

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?

There are no parameters, and the schema coverage is 100%. The description does not add parameter semantics because none are needed. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get list of volume snapshots' and lists specific functions (query, display source volume info, show dates, provide size/usage). This distinguishes it from siblings like get_volume_list (volumes) and get_image_detail_list (images).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: 'when user requests snapshot information, backup queries, or volume restoration planning.' It does not mention when not to use or alternatives, but the context is sufficient for a simple list tool.

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

get_volume_transfersA

List current-project Cinder volume transfer requests without authorization keys.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one meaningful trait beyond the name — that authorization keys are omitted from the results, and that scope is limited to the current project — but it says nothing about pagination, ordering, or whether pending-only filters apply, which matters for a listing 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler; the resource is front-loaded and the scoping plus key-redaction qualifiers follow immediately. Nothing could be cut without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with an output schema, the description needn't explain return values, and it covers scope and the key-redaction behavior. The remaining gap is minor: no hint about ordering, volume of results, or whether the caller needs admin rights to see project-wide transfers.

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 takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter schema applies. The mention of current-project scope is a helpful extra, though it is not a parameter.

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?

States a specific verb ('List') and a specific resource ('Cinder volume transfer requests') scoped to the current project, which is clearly distinct from all the get_volume_* siblings (list, backups, groups, types, snapshots). It stops short of naming any sibling alternative, so it is clear but not fully differentiated.

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?

'List current-project ... transfer requests' implies the retrieval context and the project scoping, but there is no explicit statement of when to reach for this over the volume-level siblings or any prerequisite/exclusion. Usage is inferable rather than stated.

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

get_volume_typesA

Get list of volume types with their specifications.

Functions:

  • Query volume types and their capabilities

  • Display extra specifications and backend configurations

  • Show public/private volume type settings

  • Provide storage backend information

Use when user requests volume type information, storage backend queries, or volume creation planning.

Returns: List of volume types with detailed specifications in JSON format.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description fully bears the transparency burden. It clearly indicates a read-only retrieval of volume types with specifications, including extra specs, backend config, and public/private settings. No side effects or contradictions.

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 concise, well-structured with a purpose statement, bullet-point functions, usage guidance, and return info. Every sentence is relevant and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter list tool, the description covers all needed context: what it returns (volume types with detailed specs), and hints at fields like extra specifications and backend configurations. The existence of an output schema further fills details.

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?

There are zero parameters, so baseline is 4. The description adds value by detailing the output content (specifications, backend info, settings) beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Get list of volume types with their specifications' and lists specific functions, clearly distinguishing it from siblings like get_volume_list and get_volume_snapshots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage contexts: 'Use when user requests volume type information, storage backend queries, or volume creation planning.' It doesn't mention when not to use, but given no direct sibling for volume types, this is sufficient.

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

search_instancesB

Search for OpenStack instances based on various criteria with efficient pagination.

Functions:

  • Search instances by name, status, host, flavor, image, or availability zone

  • Support partial matching with configurable case sensitivity

  • Return detailed information for matching instances with pagination

  • Optimized for large-scale environments with intelligent filtering

NameRequiredDescriptionDefault
limitNoMaximum number of matching instances to return (default: 50, max: 200)
offsetNoNumber of matching instances to skip for pagination (default: 0)
search_inNoField to search in ('name', 'status', 'host', 'flavor', 'image', 'availability_zone', 'all')name
search_termYesTerm to search for (supports partial matching)
case_sensitiveNoIf True, performs case-sensitive search (default: False)

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose pagination behavior, partial matching, and that detailed records are returned, but it omits read-only/safety profile, permission requirements, and the cap on result size that actually lives in the schema, so the disclosure is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a clear purpose sentence, which is good, but the bullet list largely duplicates the input schema's field/parameter descriptions, and the closing line ("optimized for large-scale environments with intelligent filtering") is unverifiable marketing filler.

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?

The output schema covers return shape and the schema covers all parameters, so the description only needs to add routing and behavioral context. It provides pagination context but leaves the critical gap: no guidance on disambiguating from the numerous get_instance* siblings in a crowded namespace.

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 all five parameters are already documented in the schema. The description restates the same facts (partial matching, case sensitivity, searchable fields) without adding new syntax, ordering, or edge-case meaning, which makes baseline 3 correct.

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?

States a specific verb+resource ("Search for OpenStack instances") and enumerates the searchable fields, so the agent knows what the tool does. However, it never distinguishes itself from the many overlapping siblings (get_instance, get_instance_by_name, get_instance_details, get_instances_by_status), so an agent cannot tell from this text which one to pick.

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?

Usage is only implied by the word "search" plus the criteria list; there is no explicit guidance on when to use this over get_instance_by_name (exact lookup) or get_instances_by_status (filter by status). No prerequisites or exclusions are stated.

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.

  1. 10 tool updatesv3.6.0
    • Addedget_domains
    • Addedget_heat_stack_details
    • Addedget_identity_groups
    • Addedget_image_members
    • Addedget_network_qos_policies
    • Changedget_usage_statistics2 fields changed
      • changedInput schema / properties / end_date / description
        Previous value: -"End date in YYYY-MM-DD format (optional, defaults to today)"New value: +"Exclusive end date at UTC midnight (YYYY-MM-DD; defaults to today)"
      • changedInput schema / properties / start_date / description
        Previous value: -"Start date in YYYY-MM-DD format (optional, defaults to 30 days ago)"New value: +"Inclusive start date at UTC midnight (YYYY-MM-DD; defaults to 30 days ago)"
    • Addedget_volume_backups
    • Addedget_volume_groups
    • Addedget_volume_qos
    • Addedget_volume_transfers
  2. 22 tool updatesv3.5.8
    • Changedget_hypervisor_details1 field changed
      • addedInput schema / properties / hypervisor_name / description
        Added value: +"Name/ID of specific hypervisor or \"all\" for all hypervisors"
    • Changedget_instance10 fields changed
      • addedInput schema / properties / all_instances / description
        Added value: +"If True, retrieve all instances (ignores other filters)"
      • addedInput schema / properties / case_sensitive / description
        Added value: +"Case-sensitive search (default: False)"
      • addedInput schema / properties / detailed / description
        Added value: +"If True, return detailed information; if False, return summary only"
      • addedInput schema / properties / ids / description
        Added value: +"Specific instance ID(s) to retrieve (comma-separated)"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum instances to return (default: 50, max: 200)"
      • addedInput schema / properties / names / description
        Added value: +"Specific instance name(s) to retrieve (comma-separated: \"vm1,vm2,vm3\")"
      • addedInput schema / properties / offset / description
        Added value: +"Number of instances to skip for pagination"
      • addedInput schema / properties / search_in / description
        Added value: +"Fields to search in (\"name\", \"status\", \"host\", \"flavor\", \"image\", \"availability_zone\", \"all\")"
      • addedInput schema / properties / search_term / description
        Added value: +"Search term for partial matching across fields"
      • addedInput schema / properties / status / description
        Added value: +"Filter by instance status (e.g., \"ACTIVE\", \"SHUTOFF\", \"ERROR\")"
    • Changedget_instance_by_name1 field changed
      • addedInput schema / properties / instance_name / description
        Added value: +"Name of the instance to retrieve"
    • Changedget_instance_details6 fields changed
      • addedInput schema / properties / all_instances / description
        Added value: +"If True, returns all instances (default: False)"
      • addedInput schema / properties / include_all / description
        Added value: +"If True, ignore pagination limits (use with caution in large environments)"
      • addedInput schema / properties / instance_ids / description
        Added value: +"Comma-separated list of instance IDs to query (optional)"
      • addedInput schema / properties / instance_names / description
        Added value: +"Comma-separated list of instance names to query (optional)"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of instances to return (default: 50, max: 200)"
      • addedInput schema / properties / offset / description
        Added value: +"Number of instances to skip for pagination (default: 0)"
    • Changedget_instances_by_status1 field changed
      • addedInput schema / properties / status / description
        Added value: +"Instance status to filter by (ACTIVE, SHUTOFF, ERROR, BUILDING, etc.)"
    • Changedget_load_balancer_amphorae1 field changed
      • addedInput schema / properties / lb_name_or_id / description
        Added value: +"Optional load balancer name or ID. If empty, shows all amphorae."
    • Changedget_load_balancer_details1 field changed
      • addedInput schema / properties / lb_name_or_id / description
        Added value: +"Load balancer name or ID to query"
    • Changedget_load_balancer_health_monitors1 field changed
      • addedInput schema / properties / pool_name_or_id / description
        Added value: +"Optional pool name or ID to filter monitors (empty for all)"
    • Changedget_load_balancer_l7_policies1 field changed
      • addedInput schema / properties / listener_name_or_id / description
        Added value: +"Optional listener name or ID to filter policies. If empty, shows all policies."
    • Changedget_load_balancer_l7_rules1 field changed
      • addedInput schema / properties / policy_name_or_id / description
        Added value: +"L7 policy name or ID (required)"
    • Changedget_load_balancer_list3 fields changed
      • addedInput schema / properties / include_all / description
        Added value: +"Return all load balancers ignoring limit/offset (default: False)"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum load balancers to return (1-200, default: 50)"
      • addedInput schema / properties / offset / description
        Added value: +"Number of load balancers to skip for pagination (default: 0)  "
    • Changedget_load_balancer_listeners1 field changed
      • addedInput schema / properties / lb_name_or_id / description
        Added value: +"Load balancer name or ID"
    • Changedget_load_balancer_pool_members1 field changed
      • addedInput schema / properties / pool_name_or_id / description
        Added value: +"Pool name or ID to query members for"
    • Changedget_load_balancer_pools1 field changed
      • addedInput schema / properties / listener_name_or_id / description
        Added value: +"Optional listener name or ID to filter pools"
    • Changedget_load_balancer_quotas1 field changed
      • addedInput schema / properties / project_id / description
        Added value: +"Optional project ID. If empty, shows quotas for all projects."
    • Changedget_network_details1 field changed
      • addedInput schema / properties / network_name / description
        Added value: +"Name of network to query or \"all\" for all networks (default: \"all\")"
    • Changedget_project_details1 field changed
      • addedInput schema / properties / project_name / description
        Added value: +"Name of specific project to show details for (optional, lists all if empty)"
    • Changedget_quota1 field changed
      • addedInput schema / properties / project_name / description
        Added value: +"Name of the project (optional, defaults to current project if empty)"
    • Changedget_server_events2 fields changed
      • addedInput schema / properties / instance_name / description
        Added value: +"Name or ID of the server instance"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of events to return (default: 50)"
    • Changedget_server_volumes1 field changed
      • addedInput schema / properties / instance_name / description
        Added value: +"Name or ID of the server instance"
    • Changedget_usage_statistics2 fields changed
      • addedInput schema / properties / end_date / description
        Added value: +"End date in YYYY-MM-DD format (optional, defaults to today)"
      • addedInput schema / properties / start_date / description
        Added value: +"Start date in YYYY-MM-DD format (optional, defaults to 30 days ago)"
    • Changedsearch_instances5 fields changed
      • addedInput schema / properties / case_sensitive / description
        Added value: +"If True, performs case-sensitive search (default: False)"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of matching instances to return (default: 50, max: 200)"
      • addedInput schema / properties / offset / description
        Added value: +"Number of matching instances to skip for pagination (default: 0)"
      • addedInput schema / properties / search_in / description
        Added value: +"Field to search in ('name', 'status', 'host', 'flavor', 'image', 'availability_zone', 'all')"
      • addedInput schema / properties / search_term / description
        Added value: +"Term to search for (supports partial matching)"
  3. 41 tool updatesv0.1.0
    • First observedget_availability_zones
    • First observedget_floating_ip_pools
    • First observedget_floating_ips
    • First observedget_heat_stacks
    • First observedget_hypervisor_details
    • First observedget_image_detail_list
    • First observedget_instance
    • First observedget_instance_by_name
    • First observedget_instance_details
    • First observedget_instances_by_status
    • First observedget_keypair_list
    • First observedget_load_balancer_amphorae
    • First observedget_load_balancer_availability_zones
    • First observedget_load_balancer_details
    • First observedget_load_balancer_flavors
    • First observedget_load_balancer_health_monitors
    • First observedget_load_balancer_l7_policies
    • First observedget_load_balancer_l7_rules
    • First observedget_load_balancer_list
    • First observedget_load_balancer_listeners
    • First observedget_load_balancer_pool_members
    • First observedget_load_balancer_pools
    • First observedget_load_balancer_providers
    • First observedget_load_balancer_quotas
    • First observedget_network_details
    • First observedget_project_details
    • First observedget_quota
    • First observedget_resource_monitoring
    • First observedget_role_assignments
    • First observedget_routers
    • First observedget_security_groups
    • First observedget_server_events
    • First observedget_server_groups
    • First observedget_server_volumes
    • First observedget_service_status
    • First observedget_usage_statistics
    • First observedget_user_list
    • First observedget_volume_list
    • First observedget_volume_snapshots
    • First observedget_volume_types
    • First observedsearch_instances
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 50 tools

Disambiguation2/5

Several instance tools overlap heavily: get_instance claims to consolidate get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances, yet all remain exposed. Network-related tools also overlap, since get_network_details covers subnets, routers, and security groups while separate get_routers and get_security_groups tools exist. Many load balancer tools are distinct by resource level, but the instance and network duplication makes tool selection error-prone.

Naming Consistency4/5

All tools use a get_ prefix with snake_case, giving a predictable read-only naming convention. There are minor awkward or redundant forms such as get_image_detail_list, get_volume_list, and get_instance_details versus get_instance, but the overall pattern remains readable and consistent.

Tool Count2/5

At 50 tools, the surface is very large for the apparent purpose and includes many redundant or overlapping retrieval tools. The tool count is inflated by having separate get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances despite a unified get_instance tool. This exceeds a well-scoped read-only OpenStack operations interface.

Completeness2/5

The surface broadly covers read-only queries across Keystone, Nova, Neutron, Cinder, Glance, Heat, and Octavia, but it is almost entirely get/list operations. There are no create, update, delete, attach/detach, start/stop, or other lifecycle operations, which are significant gaps for an OpenStack ops server. Even within read-only scope, some resources are only partially covered.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Multi Cluster Kubernetes MCP

    feibai406
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables interaction with multiple Kubernetes clusters simultaneously, providing comprehensive tools for cluster management, resource operations, and diagnostics across different environments.
    -

  • proxmox-mcp

    plgonzalezrx8
    A
    license
    B
    quality
    D
    maintenance
    An MCP server for Proxmox VE that enables read-only cluster inspection, VM/container lifecycle operations, snapshots, migration, and provisioning with safe confirmation gates.
    28
    MIT