CyberQP MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | env (default, reads CYBERQP_ACCESS_TOKEN) or gateway (token arrives per-request via X-CyberQP-Access-Token header). | env |
| LOG_LEVEL | No | Log level. | info |
| MCP_TRANSPORT | No | stdio (default) or http. | stdio |
| CONDUIT_S2S_SECRET | No | When set, the HTTP transport requires a valid X-Gateway-S2S header on every /mcp request. | |
| CYBERQP_ACCESS_TOKEN | No | OAuth2 access token issued by CyberQP. |
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 | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cyberqp_list_customersA | List customers visible to the authenticated CyberQP technician account, filterable by directory type and name. Metadata only (customer id, name, attributes) - never returns account passwords or OTP codes. |
| cyberqp_get_customer_accountsA | List account METADATA for a customer (id, username, type, status) - never returns passwords or OTP codes. Optionally filter by account type (enduser/admin/service/jit). |
| cyberqp_get_customer_accounts_countB | Get counts of each account type (enduser/admin/service/jit) for a customer. |
| cyberqp_get_eventsA | Get the tenant's event log (technician/account activity, e.g. self-serve resets, admin actions), filterable by customer, account, event type, status, and date range. Never returns account passwords or OTP codes. |
| cyberqp_get_event_typesA | Get the full set of event-type values usable in cyberqp_get_events' eventType filter. |
| cyberqp_get_tenant_company_dataA | Get the authenticated tenant's own company profile (name, address, timezone, contact phone). |
| cyberqp_get_jit_policiesB | Get the configured JIT policy (approval requirements, max session duration) for a customer + account type. Policy configuration only - never returns credential material. |
| cyberqp_get_customer_jit_statusA | Get JIT account status (existence, enabled/disabled state, metadata) for a specific customer. Never returns a password or OTP code - use this to check the current state of JIT accounts, not to retrieve credentials. |
| cyberqp_check_jit_account_existsA | Check whether a JIT account exists for a customer + directory type (existence check only - returns account metadata if present, never a password or OTP code). |
| cyberqp_get_tenant_jit_statusA | Get JIT account status (existence, enabled/disabled state, metadata) across the entire tenant. Never returns a password or OTP code. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools cleanly map to distinct resources and actions: customers, accounts, event logs, JIT policies, and tenant profile. The only possible confusion is among the JIT status/existence tools, especially get_customer_jit_status and check_jit_account_exists, but their descriptions sufficiently differentiate scope.
All tools share the cyberqp_ prefix, use snake_case, and follow a clear verb_noun pattern such as list_customers, get_events, and check_jit_account_exists. The naming is consistent and predictable.
Ten tools is well within the ideal range for a focused read-only utility server. Each tool covers a meaningful slice of the domain, and none feels redundant or unnecessary.
For a read-only visibility/verification server, the surface is fairly complete: customer listing, account metadata and counts, event logs, tenant profile, and JIT policy/status checks. Minor gaps exist, such as lack of a single-customer detail endpoint or pagination tooling, but agents can complete typical monitoring and verification workflows.