Overview of the workspace ontology: entity counts and the concept index. Call this FIRST when answering product-analytics questions — it is the workspace's agreed vocabulary. Returns concept BRIEFS by default (name, truncated definition, tags, link counts) — fetch full detail for the one you need via get_concept. detail:"full" expands in place (paginated; use sparingly).

Full detail for ONE concept by id or (case-insensitive) name: definition, measurement hint, measured entities with pendoIds, all causes and playbook actions. Use after get_product_map identified the relevant concept.

Search the ontology by name (case-insensitive substring). Entity hits return kind/pendoId/product-area/linked concepts; productArea hits expand into member features; concept hits return the full definition, measurement hint, measured entities with pendoIds, causes, and actions.

The registered-entity catalogue (features grouped by product area), filterable and paginated. Use this to pick entity ids when linking a concept to what it measures ("map on meaning, not just literal words"). Prefer search/kind filters over paging through everything.

Create or update a business concept: a named definition (e.g. "Activation", "Agent Mode Retention") linked to the entities it measures, with likely causes when its metric moves and playbook actions. Set autoLink=true to also attach deterministic name-matched entities. This is how meaning gets INTO the ontology — prefer enriching it whenever the user defines or clarifies a business term.

Delete a concept by id. Links to it from other concepts' causes are scrubbed.

Deterministic candidates for what a concept measures: entities whose names phrase-match the given statement. This is the precision FLOOR — you (the model) should additionally pick semantically related entities from get_entity_catalogue that string matching cannot find.

Entities NOT measured by any concept — candidates for new business definitions. Join with usage data from the Pendo MCP server (e.g. entityUsage) to rank: high-usage unmeasured entities are the strongest concept candidates.

Register or update Pendo entities in the structural layer using an explicit, pre-shaped list. For raw Pendo MCP tool results, prefer ingest_pendo_payload — it normalizes them for you. Ids are derived as ":" and stay stable, so concept links survive re-registration.

EASIEST way to store Pendo objects: pass a RAW result from a Pendo MCP tool (listCountables, listProductAreas, segmentList, searchEntities, list_all_applications…) exactly as returned — array, wrapper object, or JSON string — and it is normalized and merged into the ontology. Provide kind as the default for items that carry no kind field (product areas and segments are bare {id,name}); per-item evidence (elementPathRules → feature, url → page, explicit type fields, kind-named wrapper keys like "features") overrides it.

OPTIONAL direct sync of features, pages, segments and product areas from the Pendo REST API. Requires the PENDO_INTEGRATION_KEY environment variable on this server; without it, use register_entities with data from the Pendo MCP server instead. Merges by stable id — concepts are never touched.