Use Zentrik MCP well

Use the product surface for canonical facts about what the product is and how users get value from it:

• Product fields: name, description, mission, type, KPIs, and concrete technologies.
• Features: a product-native map of capability areas and workflows. Roots are real value areas or workflow stages; parents orient; leaves explain actionable capabilities. There is no fixed feature count or required depth. A simple product may be shallow, while a complex product may need nested capabilities.
• Personas: real buyers, users, operators, administrators, or other product roles, with goals, pain points, and use cases.
• Questions: unresolved product knowledge that should remain visible for review.

Do not use features for setup steps, documents, screens copied from a source, generic architecture, deployment details, or technology names. Do not use a persona for the person configuring the Zentrik workspace.

When repairing a product surface, read the current state and propose a patch. Preserve useful existing IDs and relationships; do not regenerate the entire map because one source added a capability.

Use context for durable knowledge that should guide future work but is not itself a product field or a customer-evidence record.

• Context units: focused, reusable rules, definitions, terminology, boundaries, strategy, constraints, operating models, trust requirements, integration assumptions, or durable decisions. Scope each unit to the workspace or exact product. One unit should cover one retrievable concept.
• Context documents: source material that should remain available for retrieval and citation without being rewritten into a shorter rule.

The same source can support a context-unit proposal and remain preserved as a document. Do not turn every document into a ContextUnit, and do not put raw customer evidence, temporary notes, source inventories, or setup instructions in durable context.

MCP can retrieve context and related documents. To change a context unit, ask the agent for the exact content and scope, then review and apply the proposal in Zentrik.

The main Zentrik surfaces are views over these same product and evidence records:

• Product Details / Overview: canonical product description, mission, type, KPIs, tech stack, feature map, and personas.
• Product Ideas: the ideas already scoped to that product. Use this to check backlog overlap before creating another Idea.
• Product Projects: initiatives connected to the product, their delivery context, and the questions, documents, and user stories generated around them.
• Product Questions: unresolved product knowledge that needs investigation or an answer; do not turn an unanswered question into a fabricated fact.
• Workspace Context: reusable ContextUnits plus retrievable source documents, scoped to the workspace or a product.
• Discovery: Signals and their derived Insights, Opportunities, and Ideas, with evidence and traceability.
• OKRs: the strategic outcome frame used to interpret decisions. MCP can read OKRs but does not change them.

When importing material, route it to the surface that matches its future job. A product requirement may update the product model and remain a retrievable document; a customer transcript may create a Signal and later change the feature map; a backlog request becomes an Idea only after checking the evidence and existing product Ideas.

Use the Discovery graph for evidence and the decisions derived from it:

• Signals: source-shaped evidence from a coherent transcript, support ticket, review, feedback record, or discovery report. Preserve the original wording, source date, stable source key and external ID, product, and Account when known. Include a source URL or reference when available. One Signal should not be a blended summary of unrelated sources.
• People: identified customers or participants who should accumulate context across Signals, Studies, and portal activity. Match by exact email or use an explicit participant policy when creating a Signal. Keep missing Account creation as a separate choice; do not infer a Person or Account from prose.
• Insights: one source-backed learning that could change a product decision.
• Opportunities: an unmet need, product problem, or decision area; not a solution.
• Ideas: a feasible solution path for the existing product, linked to the supporting Opportunity and Insights, with the underlying Signal IDs retained in the evidence chain.

Product documentation normally belongs in the product model, context, or document retrieval. A customer transcript or support record belongs in Signals even when it also teaches us how the product works. Classify by the source and intended retrieval job, not by whether the text is interesting.

Signal processing is asynchronous. Wait for the workflow to finish, then read the extracted result and traceability before creating downstream entities.

Use the initiative surface only after a product decision has been reviewed:

• Idea: a discovery-backed backlog candidate, not a generic todo or implementation task.
• Initiative: a scoped product work item with a problem, users, outcomes, MVP, non-goals, requirements, dependencies, risks, and success measures.
• Initiative documents, questions, and user stories: the delivery context that follows from the approved initiative.
• Teams: use teams.list to resolve accessible team IDs before creation. Use initiatives.set_teams only as an explicit, reviewed complete replacement of an existing Initiative’s team set.

Keep the chain visible: Signal -> Insight -> Opportunity -> Idea -> Initiative. If the requested link is unavailable through MCP, preserve the relevant public IDs in the proposal and complete the link in Zentrik. Do not create an initiative merely because a source contains a feature request.

Lead with the actual product question, not the tool name.

Better:

What recurring customer themes appear around transcript accuracy right now?

Worse:

Use the MCP to inspect everything about our product.

The agent will decide which tools to call. Your question tells it what outcome matters.

When possible, specify one or more of:

• timeframe
• topic
• product area
• signal type
• output length

Example:

Summarize insights from the past 30 days about onboarding friction.
Keep it to five bullets and include one quote per bullet.

If the answer will influence prioritization, ask for supporting evidence explicitly.

Good additions:

• "include verbatim quotes"
• "show provenance"
• "note which signal each quote came from"
• "flag where evidence is weak"
• "say what data is missing"

This keeps the answer reviewable.

Import one clearly scoped source directly. For a batch or unclear metadata, preview the proposed records, resolve ambiguities, and approve the batch before writing. Check processing only when the next request depends on it.

See Load product evidence for a complete starter.

The best prompts say what the result should look like.

Examples:

• "Give me a three-theme summary with one quote each."
• "Rank the opportunities in a table."
• "Draft a planning update I can paste into Slack."
• "List the weak-evidence bets separately from the strong ones."
• "Add a recommended next action and note missing data."

Output shape matters because it turns a generic answer into something you can use immediately.

The MCP supports natural-language search across Discovery signals, insights, opportunities, and ideas, plus focused signal and initiative searches. Retrieval is still bounded and relevance-based rather than a complete workspace index. For important work, specify the entity type, product, topic, account, or timeframe when you can, then open the strongest matches with their evidence and relationships.

When you create a signal from text, extraction does not complete instantly. If you immediately ask for downstream insights, the data may not be ready yet.

An agent can only work with the graph it sees. If accounts are missing, signals are unlabeled, or opportunity links are sparse, answers may still be useful but incomplete. Ask the agent to state what is missing before treating an answer as decision-grade.