Read first. The active tenant is global to this CLI session and can be flipped between calls by set-active-tenant. Every result ends with a footer line naming the active tenant (or noting there is none) so you can verify which tenant the result reflects before acting on it. If the footer says "no active tenant" you are looking at bundled reference snapshots — call status to see stored credentials and set-active-tenant to connect before relying on the result.

Search the bundled and discovered OpenAPI specs by evaluating a JavaScript function.

This MCP exposes a bundled Cumulocity core OpenAPI snapshot. Use coreSpec for inventory, alarms, events, measurements, users, tenants, and the broader Cumulocity REST surface. Bundled and discovered microservice APIs available on the current tenant are exposed via serviceSpecs (keyed by contextPath). Prefer endpoint-native parameters (filters, expansions, paging, sorting) over manual multi-call traversal when they can express the request.

Available bindings (all zero-parameter — do NOT declare these as function parameters):

type OperationInfo = {
  summary?: string
  description?: string
  tags?: string[]
  parameters?: Array<{ name: string, in: string, required?: boolean, schema?: unknown, description?: string }>
  requestBody?: { required?: boolean, content?: Record<string, { schema?: unknown }> }
  responses?: Record<string, { description?: string, content?: Record<string, { schema?: unknown }> }>
}

type PathItem = {
  get?: OperationInfo
  post?: OperationInfo
  put?: OperationInfo
  patch?: OperationInfo
  delete?: OperationInfo
}

type Spec = {
  paths: Record<string, PathItem>
  tags?: Array<{ name: string, description?: string }>
}

declare const coreSpec: Spec
declare const serviceSpecs: Record<string, Spec>

• coreSpec — the main Cumulocity REST surface. Always present.

• serviceSpecs — microservice APIs available on the active tenant, keyed by contextPath. An entry is present iff the service is reachable on this tenant. Paths are already prefixed (e.g. /service/myservice/items). Check with serviceSpecs.dtm (or 'dtm' in serviceSpecs) before reaching in.

• Prefer checking operation parameters before designing multi-step logic. If filters, expansions, or selectors exist, use them first.

• When an operation has tags, read the matching tag descriptions to discover domain-specific query language/functions and recommended usage patterns.

• Fall back to custom traversal/aggregation only when endpoint-native options cannot express the needed result shape.

Both coreSpec and each serviceSpecs entry have a top-level tags array with domain documentation. Each operation may reference one or more tags by name via its tags[] field. When you need deeper context about an API area or resource, look up the matching tag entry by name and read its description.

// Get all tag names to find relevant documentation areas — use first when you know the domain but not the exact path
() => serviceSpecs.dtm?.tags?.map(t => t.name)

// Find documentation for a known tag name
() => serviceSpecs.dtm?.tags?.find(t => t.name === 'Assets')?.description

// Follow the tag reference from a specific operation
() => {
  const op = serviceSpecs.dtm?.paths['/service/dtm/assets/linkedSeries']?.get
  const tagName = op?.tags?.[0]
  return tagName ? serviceSpecs.dtm?.tags?.find(t => t.name === tagName)?.description : null
}

If your function returns a string it is returned as-is. Any other value is returned as JSON. A footer line naming the active tenant (or noting there is none) is appended after a --- separator on every successful result. The current MCP connection may still block execute calls even when an operation is visible in a spec.

Examples: () => Object.keys(serviceSpecs) () => Object.keys(coreSpec.paths).filter((p) => p.includes('inventory')) () => serviceSpecs.dtm?.paths['/service/dtm/assets']?.get

() => {
  const op = coreSpec.paths['/inventory/managedObjects']?.get
  return { summary: op?.summary, parameters: op?.parameters }
}

Read first. Every result starts with an Executed against tenant: <url> marker line followed by a blank line. Verify it matches the tenant you intend to mutate before reporting the result. The active tenant is global to this CLI session and can be flipped between calls by set-active-tenant. If no tenant is active execute fails with a missing-auth error — call status and set-active-tenant to connect first.

An endpoint visible in query may still return 404 from execute when the service is not actually installed on the current tenant.

Execute JavaScript code against the Cumulocity API. Use the query tool first to find the right endpoint, then write an async function that calls cumulocity.request().

This MCP exposes a bundled Cumulocity core OpenAPI snapshot. Use coreSpec for inventory, alarms, events, measurements, users, tenants, and the broader Cumulocity REST surface. Bundled and discovered microservice APIs available on the current tenant are exposed via serviceSpecs (keyed by contextPath). Prefer endpoint-native parameters (filters, expansions, paging, sorting) over manual multi-call traversal when they can express the request.

Available in your function:

type CumulocityRequestOptions = {
  method: 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE'
  path: string
  body?: unknown
  headers?: Record<string, string>
}

declare const cumulocity: {
  request<T = unknown>(options: CumulocityRequestOptions): Promise<T>
}

Your code must evaluate to an async function. Return the final value you want.

Execution strategy:

• First inspect endpoint parameters with query and choose the lowest-call approach.

• Read relevant tag documentation to discover domain query language/features before writing custom control flow.

• Prefer native API filters/expansions/selectors over manual traversal loops when both satisfy the request.

• Use manual traversal only when endpoint-native options cannot express the needed result shape.

On success the result is returned in Toon format. On a blocked or failed execution a plain text message is returned. A blocked message means the operation was denied by connection policy — retrying through the same connection will not help.

Examples:

async () => {
  return await cumulocity.request({ method: 'GET', path: '/inventory/managedObjects?pageSize=5' })
}

async () => {
  return await cumulocity.request({
    method: 'GET',
    path: '/alarm/alarms?pageSize=10&type=myAlarmType',
  })
}

Show the current CLI status: stored tenant credentials, which tenant query and execute will hit, and the specs visible to query right now. If no tenant is active, query falls back to all bundled OpenAPI snapshots and execute is unavailable — set-active-tenant must be called first. This tool also self-heals: if the active tenant has lost its stored credentials it is automatically reset before the status is reported.

Pass refresh: true to force a fresh API spec discovery against the active tenant. Use this after subscribing or unsubscribing a microservice in the tenant — otherwise discovered specs stay cached for 30 minutes. If no tenant is active, refresh: true is a noop.

Set the Cumulocity tenant for this CLI session, or pass tenantUrl: null to clear the active tenant. The tenantUrl must match one returned by the status tool. The selection is persisted across sessions so you only need to call this once (or when switching tenants). Clearing falls back to bundled-only browsing — query still works but execute is unavailable until a tenant is set again.