Orgvue US

Execute a sentinel-prefixed PQL script against the current data graph and return its result. PQL is Orgvue's query language for reading/deriving data from the graph (e.g. filtering, selecting, aggregating properties); a script must start with a sentinel such as @NODES or @ALL_NODES, which selects the query's starting scope. Read-only — this never writes to the data graph.

execute_pql_expression

Execute a PQL script against the current data graph and apply its result as a mutation to the working copy of the data — not a preview or read-only check. The script must evaluate to a raw frame whose _mutate field is an array of item-operation objects (e.g. produced by an @UPDATE-style PQL script); anything else is rejected with an error before any change is applied. Operations are grouped and applied by their _viewId (falling back to the current dataset's view when unset), so a single call can touch more than one dataset if the script's payload spans them. The change only affects the current working copy, not the saved/published data — it isn't persisted until the user (or a separate save action) saves. There's no dedicated undo for this: to reverse a mutation before it's saved, call this again with a script that applies the opposite change.

execute_pql_mutation

Get the id and title of the slide the user currently has open in the pack. Cheap, single-purpose check — call this before answering anything scoped to "this slide"/"the current slide" rather than trusting a slide id or title from earlier in the conversation, since the user may have navigated since then. activeSlideId is an internal identifier — never show it to the user; describe the slide to the user by title only from this tool. This tool does NOT return slide type or content detail — for what kind of slide it is (chart/multiViz/dashboard/etc) or how it's built (e.g. "a box grid of location against department"), use get_pack_structure and match this slide's id against its slides list. For the full list of slides, their sections, and content summaries, use get_pack_structure instead.

get_active_slide

Get the datasets that make up the currently open data graph: their human-readable name, dataset type (e.g. POSITIONS, PEOPLE, ROLES — a stable per-tenant dataset-type identifier), and dataset (their structural role relative to the open page: 'nodes' is the current dataset, 'target' is the dataset it's linked to, 'links' is the join dataset itself — the exact same 'nodes'/'target'/'links' values accepted by get_property_metadata's and summarize_properties' dataset parameter). The result is COLUMNAR: each field is a top-level array, parallel-indexed (e.g. name[i]/type[i]/dataset[i] describe the same dataset). Always includes 'nodes'; 'target'/'links' rows are only present if the current dataset has a Links-type join. Call this when you need to orient yourself on what data is available, or when the user asks what data/datasets are open. dataset ('nodes'/'target'/'links') is an internal role label for reasoning about structure and for other tools' dataset parameters — NEVER say 'nodes'/'target'/'links' to the user. When talking to the user (describing what's available, listing candidate properties, or asking them to choose a dataset), always identify each dataset by its name field (e.g. 'Positions file', 'People file') — that's the exact label the user recognizes from the product UI. Do NOT substitute the type field (e.g. 'POSITIONS', 'PEOPLE') as a stand-in for the name, even as a short parenthetical tag like '(People)' — type is a dataset category, not the dataset's identity, and two datasets can share the same type (e.g. two POSITIONS datasets) while having different names, so using type alone can be ambiguous or simply wrong. If you want to also mention the type for extra context, say both, e.g. 'People file (a PEOPLE dataset)', but the name must always be present. This output is for internal reasoning only, not for reciting to the user: describe the datasets in plain language (e.g. 'you have a Positions file dataset linked to a People file dataset').

get_data_graph

Get the structure of the currently open pack: its slides, in order, with id, title, slide type ('singleViz'/'multiViz'/'dashboard'), which section they sit in, and a one-line summary of their content (type + title only, e.g. '1 bar chart: Headcount by Department' — NOT full config). Also returns the currently active slide's id. Call this first to orient yourself on what's already in the pack before placing or editing a chart — don't guess. Every slide's id here is an internal identifier — never show it to the user; a person never knows or supplies a slide id, only its title. sectionPath is the section names from root to the slide's section, root-to-leaf order, empty if the slide is at the top level (not inside any section).

get_pack_structure

List properties with metadata for ONE dataset: key, name, description, type, tags, aliases, and flags (isRequired, isGenerated, isEvaluated, isOnDemand, isMultiline, isPack), plus lookup config where applicable. key/name/type are dense arrays, parallel-indexed across properties (e.g. name[i] and type[i] describe the same property as key[i]). isRequired/isGenerated/isEvaluated/isOnDemand/isMultiline/isPack are SPARSE: each is an array of the indices where that flag is true (e.g. isPack: [3, 17] means only properties at index 3 and 17 are pack properties; every other index is false). description/tags/aliases/lookup are also SPARSE: each is an object mapping index -> value, containing an entry ONLY for properties with a non-empty value at that index (e.g. lookup: {"5": {...}} means only the property at index 5 has lookup config; absence from the map means empty/null, not an error). A lookup config of type "dataset" or "expr" (a script-defined lookup) also includes allowedValues — the configured/permitted set for that property. For a "dataset" lookup these are always strings; for an "expr" lookup they keep their original JSON type, so the number 5 and the string "5" are reported as two distinct entries, never merged. Check allowedValues before writing a mutation that sets one of these properties to a new value — never guess a permitted value. allowedValues is capped at 100 entries; when truncated, allowedValuesTruncated: true is also present, meaning more values exist than are listed — call summarize_properties for that property if you need its full value distribution rather than assuming this list is complete. allowedValues is best-effort and may be absent even for a "dataset"/"expr" lookup if resolution fails (e.g. a broken dataset reference) — treat a missing field as "couldn't be resolved," not "nothing is allowed." A lookup config of type "join_lookup", or a property with no lookup config at all despite having lookupType "auto" in its underlying setup, never gets this field — there is no values-enumeration mechanism for those today. type uses PQL's vocabulary: 'boolean', 'text', 'number', 'date', or 'unknown' (not the dataset's dimension/measure/temporal terms). isGenerated means the property is Orgvue-generated (Depth, Span, Layers, etc.), not user data. isPack means it exists solely in the pack, not the underlying dataset. isEvaluated means the property's value is computed rather than static, though this is an approximate signal and may include properties that aren't specifically script-driven. isOnDemand means that computation is a calculation the user runs on demand rather than automatically. Use dataset to choose which single dataset to list properties for: 'nodes' is the current dataset, 'target' is the dataset it's linked to (e.g. People linked to Activities), 'links' is the join dataset itself. Each call covers exactly one dataset — if you need to check more than one (e.g. surveying where a property named 'fte' actually lives, across nodes/target/links), call this tool again for each dataset and compare the returned key/name lists yourself. If the current data graph has more than one dataset and you call this without datasetsConfirmed: true, this tool returns a message asking you to clarify with the user instead of property data — follow that message's instructions, then call again with dataset set accordingly and datasetsConfirmed: true. The underlying links dataset also has from_id:<key>/to_id:<key> properties that are pass-through copies of every nodes/target property — these are ALWAYS excluded from the returned links properties, since they're never links' own data; call this again with dataset: 'nodes' or 'target' to see the real property instead. 'target'/'links' only work if the current dataset has a Links-type join; requesting them otherwise returns an error. This output is for internal reasoning only, not for reciting to the user: describe properties in plain language grouped by type or purpose when summarizing, and when referring to which dataset a property came from, use its name field from get_data_graph (e.g. 'Positions file') — not 'nodes'/'target'/'links' (internal labels) and not the dataset's type field (e.g. 'POSITIONS') either, since type is a category, not the dataset's identity. If you're using results from multiple calls to ask the user which of several matching properties they mean (e.g. before calling summarize_properties), see summarize_properties' error message for the required presentation format (one enumerated line per candidate, dataset name repeated on every line).

get_property_metadata

Get the _id and _label of every node currently selected by the user in the canvas/sidebar. Returns { _id: [], _label: [] } (empty arrays, not an error) when nothing is selected. The result is COLUMNAR: _id[i] and _label[i] describe the same node. This only ever covers the nodes dataset — node selection is not a concept on target/links datasets. _id is an internal identifier for cross-referencing with other tools (e.g. execute_pql_mutation) — never recite raw _id values to the user. When describing the selection to the user, use _label (and count, e.g. "3 nodes selected: ..."); if multiple selected nodes share the same _label, distinguish them descriptively (e.g. by position or other context) rather than by showing their _id.

selected_nodes

Get the current browser tab title

get_tab_title

List the datasets available to the user in the current tenant, by name. Returns { datasets: [...] }, each with id, name, dataset type (e.g. POSITIONS, PEOPLE, ROLES — a stable per-tenant dataset-type identifier), and when it was last modified. At most 100 datasets come back at a time. If there are more, a truncated field gives the number shown and the total — say so rather than implying the list is complete, and narrow with nameContains or typeIs instead of asking for more. Call this to find a dataset before opening one with load_dataset_and_pack, and whenever the user asks what data they have. Don't guess a dataset id — it only ever comes from here. A dataset always opens together with a pack, so opening one also needs a pack id from list_packs. Every id here is an internal identifier — never show it to the user; a person never knows or supplies a dataset id, only its name. Always identify a dataset to the user by its name, never by its type: type is a category, not the dataset's identity, and two datasets can share a type (e.g. two POSITIONS datasets) while having different names. To give extra context, say both, e.g. 'People file (a PEOPLE dataset)', but the name must always be present. Dataset names are NOT unique — two datasets can have the same name and the same type, differing only by id. If more than one dataset matches what the user asked for, don't just pick one: tell them there are several of that name and ask which they mean, distinguishing them by when they were last modified (never by id). Archived datasets, and dataset types this user can't open, are not listed. Two filters, for two different questions, and they combine. Use nameContains when the user names a dataset ('open the headcount file'). Use typeIs when they ask about a category of data ('what people data do we have?'), or when you are exploring a tenant you know nothing about and have no name to search for. Filter here rather than listing everything and narrowing yourself — with the cap in play, what you'd be filtering may not be the whole set. typeIs matches the type exactly (case-insensitive), so pass a type string exactly as it appears in a previous result's type field. It narrows to a category, not to one dataset: a tenant can hold many datasets of the same type, so expect several results and still identify each by name. This lists the datasets the user could open; to see the datasets making up the data graph that is already open, use get_data_graph instead. An empty list means this tenant has no datasets matching the request, not that the tool failed.

list_datasets

List the packs available to the user in the current tenant, most recently modified first. Returns { packs: [...] }, each with id, name, description, and when it was last modified. At most 100 packs come back at a time. If there are more, a truncated field gives the number shown and the total — say so rather than implying the list is complete, and narrow with nameContains instead of asking for more. Call this to find a pack before opening one with load_dataset_and_pack, and whenever the user asks what packs they have. Don't guess a pack id — it only ever comes from here. A pack always opens together with a dataset, so opening one also needs a dataset id from list_datasets. Every id here is an internal identifier — never show it to the user; a person never knows or supplies a pack id, only its name. Always identify a pack to the user by its name. Only live packs are listed — archived ones are held separately and are not reachable from here, so a pack the user remembers but can't find here may have been archived or deleted. nameContains narrows the list to packs whose name contains that text — use it when the user names a pack, rather than listing everything and filtering yourself. An empty list means this tenant has no packs matching the request, not that the tool failed.

list_packs