Query Bundled OpenAPI Specs

Search the bundled OpenAPI specs by evaluating a JavaScript function.

This MCP currently exposes the release (latest) bundled core OpenAPI snapshot together with the other bundled product specs for the query tool. Bundled specs on this connection: core (release), dtm (release). Enabled bundled OpenAPI parts for execute policy: core, dtm.

Use coreSpec for the main Cumulocity REST surface such as inventory, alarms, events, measurements, identity, device control, users, tenants, audit, and the broader platform APIs. Use dtmSpec for Digital Twin Manager work such as schema definitions, asset models, linked series, and DTM asset or definition APIs.

Available in your function:

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 CoreSpec = { paths: Record<string, PathItem> tags?: Array<{ name: string, description?: string }> }

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

type SpecsEnabled = { core: boolean dtm: boolean }

declare const coreSpec: CoreSpec declare const dtmSpec: DtmSpec declare const specsEnabled: SpecsEnabled

Your code must evaluate to a zero-parameter function — do NOT declare coreSpec, dtmSpec, or specsEnabled as function parameters. These are already declared as constants in the surrounding scope and are available inside the function body without any argument passing. Writing (dtmSpec) => ... would shadow the global binding with an undefined parameter and produce incorrect results.

The top-level bindings a) coreSpec — use this for the main Cumulocity REST APIs such as inventory, alarms, events, measurements, identity, device control, users, tenants, audit, and the broader platform REST surface

b) dtmSpec — use this for Digital Twin Manager work such as schema definitions, asset models, linked series, and DTM asset or definition APIs

c) specsEnabled — tells you which bundled spec families are enabled for execute policy on this connection

are available automatically. The sandbox assigns your function to a local variable, invokes it, and returns its result.

Recommended shapes (zero parameters — bindings come from scope, not arguments): (() => { ... }) async () => { ... }

If your function returns a string, it is returned as-is. Otherwise the result is returned as JSON text.

The specs exposed by query are the raw bundled OpenAPI snapshots. They are never hidden or rewritten for the current MCP connection policy. The current MCP connection may still block execute calls through restrictions and/or an allow list, so do not assume every operation visible in a spec is executable on this connection. Use specsEnabled to see which bundled spec families are enabled for execute policy on this connection.

Examples: () => specsEnabled

() => { return Object.keys(coreSpec.paths).filter((path) => path.includes('inventory')) }

() => { const results = [] for (const [path, methods] of Object.entries(dtmSpec.paths)) { for (const [method, op] of Object.entries(methods)) { if (op?.tags?.some(tag => tag.toLowerCase().includes('asset'))) { results.push({ method: method.toUpperCase(), path, summary: op.summary }) } } }

return results }

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