techzone-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoamiA | Validate the TechZone API token and return the current user's profile (name, email, roles, persona, and API entitlement). |
| list_reservationsA | List all of my TechZone reservations with name, status (e.g. Ready, Provisioning, Scheduled, Deleted), environment, region, and start/end dates. Credentials are never included here - use get_reservation for full details on one reservation. |
| get_reservationA | Get full details for one reservation by its id (from list_reservations), including service links, access details, lifecycle dates, and extension count. Output may contain environment credentials - only call this when the user asks about a specific reservation. |
| search_collectionsA | Search reservable TechZone collections by name. THIS is how to find something to reserve: pick a result id, inspect it with get_collection (a result with no platforms is an umbrella collection - not reservable), then create_reservation. Distinct from search_catalog, which searches the separate Backstage deployer catalog. |
| get_collectionA | Get a TechZone collection's deployment options (platforms, regions, datacenters, templates) by collection id - from a catalog entry or a reservation's collectionId. Consult this before create_reservation to pick a region. |
| create_reservationA | Create a TechZone reservation from a collection. THIS CHANGES STATE and consumes real environment capacity - always confirm the collection, name, region, and duration with the user before calling. The collection must be a reservable environment (its get_collection output has platforms), not an umbrella collection. template picks the deployment variant and region_name the region, both from get_collection (each defaults to the first available); start is an ISO timestamp (defaults to now); days is the duration (default 2, may be capped by policy). On success returns the new reservation id - poll get_reservation until status is Ready. |
| cancel_reservationA | Cancel (delete) a TechZone reservation and its environment. THIS IS DESTRUCTIVE AND IRREVERSIBLE - always confirm with the user first. confirm_name must be the reservation's exact name (from list_reservations); the call is refused if it does not match. |
| extend_reservationA | Extend a TechZone reservation's end date by N days (default 1) past its current provisionUntil. THIS CHANGES STATE on TechZone - always confirm with the user (reservation name + how many days) before calling. Returns outcome 'extended' (with the new end date), 'not_extendable' (extension limit reached or not allowed for this environment), 'rejected' (request refused, e.g. expired/deleted reservation - nothing applied), or 'ambiguous' (verify with get_reservation). |
| check_expiringA | Flag active reservations ending within the next N days (default 3), soonest first, each with an hoursRemaining countdown. Use this to answer 'is anything about to expire?' - already-deleted/expired reservations are excluded. |
| search_catalogB | Search the TechZone catalog (catalog.techzone.ibm.com) for environments, collections, and products. Returns matching entries with title, kind, owner, and catalog location path. |
| get_catalog_entryA | Get one TechZone catalog entry by kind and name (e.g. kind='system', name='redhat-openshift'). Kind and name come from a search_catalog result's location path: /catalog/{namespace}/{kind}/{name}. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| reservations_resource | Live summary of my TechZone reservations. |
TDQS
Scored across 11 tools
Most tools target a clearly distinct resource+action: whoami (auth), list/get/create/cancel/extend_reservation (reservation lifecycle), search/get_collection (find reservable things), search/get_catalog_entry (separate Backstage catalog), check_expiring (proactive monitoring). The only mild overlap is search_collections vs search_catalog, but the descriptions explicitly differentiate them. create vs cancel vs extend are all distinct lifecycle operations with clear confirmations.
The naming follows a consistent verb_noun pattern: list_reservations, get_reservation, create_reservation, cancel_reservation, extend_reservation, search_collections, search_catalog, get_collection, get_catalog_entry. 'whoami' and 'check_expiring' are minor deviations but both are still readable single-action verbs. The pattern is highly predictable across the reservation lifecycle.
11 tools is well within the ideal range (3-15). Each tool earns its place: the reservation lifecycle needs at least 5 (list/get/create/cancel/extend), discovery needs 4 (search/get for both collections and catalog), plus whoami and check_expiring for auth and proactive monitoring. No fat to trim, no obvious missing pieces that would inflate the count.
The reservation lifecycle is complete: create, list, get, cancel, extend, plus check_expiring for monitoring. Discovery is covered for both the reservable collections and the separate Backstage catalog. The only minor gap is that once you get a reservation or collection, you can't modify things like name/region without cancel+recreate, but that matches typical reservation semantics. Overall the domain is well covered with no dead ends.