Query the Pulumi Context API

The Context API answers questions about an organization's cloud infrastructure as a graph: what exists, what depends on what, what a change would affect. It covers resources found through Pulumi Discovery, not just Pulumi-managed ones.

Prefer it over Resource Search whenever the question involves relationships. Resource Search finds individual resources but cannot follow edges, so answering "what depends on X" with repeated searches is slow and usually incomplete.

Public preview, for organizations on the Enterprise and Business Critical editions, and a role granting resources:search (the default Member and Admin roles do).

First: is a graph tool already in the session?

If one is — graph_query and get_graph_schema, under whatever prefix the server registers them — call it and skip Steps 1 and 2. Compose the selector from the graph_query tool's own description, which carries the grammar; the tool resolves the organization and credentials itself and drains pagination for you. When that description is not enough, get_graph_schema returns the live field vocabulary and limits, and will serve the full Step 1 primer when asked for it. Step 3 still governs what you do with the result.

Steps 1 and 2 are the path for an agent that has a shell and no such tool.

Step 1: fetch the primer, always

Needs Pulumi CLI v3.243.0 or newer and an active pulumi login.

pulumi api GetGraphQuerySchema --output=markdown

This returns a self-contained guide to composing selectors — vocabulary, edge types, engine caps, worked examples, pagination, completeness rules, the gates that deny a query, and the traps that produce a confident wrong answer instead of an error. It is served by the deployment that answers your queries, so it is the contract, and it moves between schema versions. This skill bootstraps you to it and stops there; everything below defers to it. Fetch it fresh in every session — a primer remembered from earlier may describe a schema this deployment no longer serves.

The operation takes no organization; one schema covers every org the login can reach. --output=json on it returns the same contract as a machine-readable payload, useful for reading limits or fieldValues programmatically, but compose from the markdown.

Read it in full — never truncate it with head, tail, or a byte cap. A clipped primer means malformed selectors and rejected queries.

If this call fails

You have no primer yet, so handle it here rather than looking it up there:

Entitlement gates are per-organization, so they cannot appear on this call — they surface in Step 2, by which point the primer's "When it denies you" table is in hand. If pulumi api doesn't know GetGraphQuerySchema at all, that is not a gate: run pulumi api list --refresh-spec to refresh the cached spec, then retry the fetch.

Step 2: query

pulumi api GraphQuery -F orgName=<org> --input selector.json

The body is a JSON selector, not query text. Compose it from the primer you just read, not from memory or from a grammar you recall from another session.

Name the org explicitly. Left off, -F orgName resolves from the selected stack or the default org, which is often an individual account with no entitlement; pulumi whoami -v lists every organization the login can reach. A denial here names its gate — the primer's "When it denies you" table says which are worth retrying and which to report to the user.

Step 3: apply the primer's completeness rules before answering

Every response carries fidelity signals — currently meta.resultMode, meta.visibility, and pageInfo.continuationToken; the primer names the authoritative set. Read the primer's rules for them and follow them; the remedies differ per signal and a stale paraphrase here would be worse than none.

What matters most: a completeness claim needs all of them clean. Impact analysis, "nothing depends on this", an exhaustive cleanup list, a total across groups — none of these survive a truncated result, a trimmed traversal, or an undrained page. When you can't get there, say what the answer does cover.

Scope of the graph

Resources, stacks, and the relationships between them, trimmed to the stacks and accounts the caller can see. The primer's "What it cannot answer yet" section is the live boundary — check it before concluding a question is unanswerable, and reach for a different API rather than approximating one of those gaps with a graph query.

One boundary worth knowing up front, because it decides which API to use: the graph returns a schema-declared subset of fields per node type, not full resource property bags. The primer lists which fields each node type can match on and which it can return; when the question needs the property values themselves, they come back from Resource Search.

Human-readable reference: Context API overview and query guide.