docs: drop tools excluded from public MCP — visualization, search_users, execute_query, all objective_*

Strip references to tools removed from the public MCP per the Claude
connector review: generate_process_diagram (visualization page deleted),
search_users (workspace row + common chain), execute_query (Raw SQL
section in the skill), and the full objective_* surface (already removed
from concept/tool reference earlier; remaining bundled-skill mentions
cleaned up here). Skill tools.md section letters renumbered A–G to stay
contiguous.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Aditya Thiruvengadam

docs/docs.json

@@ -88,7 +88,6 @@
               "tools/entry-points",
               "tools/process-index",
               "tools/observations-and-changes",
-              "tools/visualization",
               "tools/artifacts",
               "tools/context-graph",
               "tools/workspace"

docs/guides/code-and-agents.mdx

@@ -22,7 +22,7 @@ In Claude Code, Cursor, or Codex, the assistant can chain process intelligence w
 |---|---|
 | **Claude Skill: weekly process health report** | One-time investigation becomes a repeatable organizational capability that runs on demand |
 | **Custom GPT: ops onboarding assistant** | Answers questions for new hires, grounded in your real process library |
-| **Claude Skill: audit package generator** | Given a process name, produces a full audit package — diagram, dependencies, changes, artifacts |
+| **Claude Skill: audit package generator** | Given a process name, produces a full audit package — dependencies, changes, artifacts |
 | **Skill: conformance monitor** | Compares new observations against the documented standard and flags deviations |
 
 ## Recipe for grounded code-gen

docs/guides/state-of-team.mdx

@@ -35,9 +35,6 @@ A team manager is checking in on the processes they own. The assistant should pr
   <Step title="Spot-check emerging deviations">
     Call [`get_observation_activity_timeline`](/tools/observations-and-changes) on the top two or three observations for primary-source detail.
   </Step>
-  <Step title="Generate diagrams (optional)">
-    Call [`generate_process_diagram`](/tools/visualization) on processes the manager will share in a 1:1 or team meeting.
-  </Step>
   <Step title="Synthesize">
     "Your team owns N processes. M changed in the last 30 days. K are showing deviation patterns worth your attention. Here are the top 3 with evidence."
   </Step>

docs/guides/transformation-thesis.mdx

@@ -43,9 +43,6 @@ The user has zeroed in on a target process or value stream and wants the assista
     - [`explore_graph_neighbors`](/tools/context-graph) — map the network.
     - [`summarize_community_subgraph`](/tools/context-graph) — orient if the process sits in a meaningful community.
   </Step>
-  <Step title="Produce the visual (optional)">
-    Call [`generate_process_diagram`](/tools/visualization) to produce a current-state diagram for the thesis document.
-  </Step>
   <Step title="Synthesize the thesis">
     Structure the answer as:
 

docs/tools/overview.mdx

@@ -15,7 +15,6 @@ Every workflow reduces to: **find the right process(es) → fetch detail → gat
 | [Standard entry points](/tools/entry-points) | `search`, `fetch` | The default starting path for any process question |
 | [Process Index](/tools/process-index) | Hierarchy navigation, process details, workspace lookup | `search` results feel sparse, or you need richer metadata than `fetch` returns |
 | [Process observations](/tools/observations-and-changes) | Recent changes, observations, activity timelines | "What changed?", "what happened?", "why does this run this way?" |
-| [Visualization](/tools/visualization) | Diagram generation | The user wants to see the flow |
 | [Artifacts](/tools/artifacts) | Document search, content retrieval, video frames | The user names a document or recording |
 | [Context Graph](/tools/context-graph) | Entities, communities, relationships, lineage | The question is relational |
 | [Workspace](/tools/workspace) | List workspaces, switch active workspace, attribute configs | Orienting before drilling in, or switching context |

docs/tools/visualization.mdx

@@ -10,7 +10,6 @@ icon: "building"
 | `switch_mcp_workspace` | **Only write tool exposed in production.** Switch the active workspace. Only call when the customer explicitly asks. |
 | `get_attribute_configurations` | Workspace-level attribute configs (custom fields, compliance attributes). Use when the customer asks about controls, compliance attributes, or process metadata schema. |
 | `search_workspace_activity_or_sessions` | Recent workspace sessions as supporting evidence. |
-| `search_users` | Find users in the workspace by name or other criteria. |
 
 ## Workspace switching
 
@@ -24,4 +23,3 @@ Customers configure custom attributes on processes (automation status, system of
 
 - **Confirm workspace at start**: `list_accessible_workspaces` → only call `switch_mcp_workspace` if the user explicitly asks
 - **Compliance audit**: `get_attribute_configurations` (read the schema) → walk the relevant hierarchy and filter by the attribute the user cares about
-- **Find a process owner**: `search` for the process → `search_users` for the owner named on it → hand off to a [Calendar or Slack connector](/guides/chain-with-connectors) for action

docs/tools/workspace.mdx

@@ -46,7 +46,6 @@ The Klarity MCP is the surface where a customer's AI agents pull organization-sp
 
 - **Outcome: find the highest-leverage automation / transformation opportunities across our org.** A platform lead, AI architect, or transformation owner asks "where in our [P2P / O2C / close cycle / value stream] can we automate?" Walk the hierarchy under the value stream (often in parallel across many leaves), look for high-volume manual steps, exception patterns, and cross-process duplication. Surface a ranked candidate set with citable evidence.
 - **Outcome: form a transformation thesis on a specific process or value stream.** The customer has zeroed in on a target. Build current-state, blast-radius, and dependency understanding; identify intervention points; ground the thesis in observations and graph relationships.
-- **Outcome: continue in-flight transformation work without restarting.** The customer has an existing Advisor objective ("shorten close from 7 to 3 days", "find duplicate invoice processing across geographies"). Pull `get_objective_context_bundle` to load prior findings, actions, activity, and agent state — then build on it instead of starting cold.
 
 See `tools.md` for end-to-end worked scenarios that compose many tools together for each of these outcomes.
 
@@ -76,10 +75,10 @@ Klarity runs the **Discover -> Structure -> Improve** loop continuously (replaci
 
 - **Discover**: Companion (ambient capture from sessions) and Interviewer (AI-guided structured capture) generate the raw process knowledge. Agents read this via process / observation / artifact tools.
 - **Structure**: The Process Index and Context Graph are the living, queryable map of the customer's organization. Agents navigate this via `search` / `fetch` / hierarchy / graph tools.
-- **Improve**: Advisor analyzes thousands of processes simultaneously to surface improvement opportunities; Signals give individual-level feedback. Agents read in-flight transformation work via objective tools.
+- **Improve**: Advisor analyzes thousands of processes simultaneously to surface improvement opportunities; Signals give individual-level feedback. Agents can scan the index in their own AI tools to surface candidates and form transformation theses, grounded in the same evidence.
 
 The customer's question almost always maps to one of these stages. Use the catalog in `tools.md` to pick the right tool for the goal.
 
 ## Tool Catalog
 
-The full PROD-allowed tool list, organized by use case with selection guidance, lives in `tools.md` (alongside this file). Read it when you need to pick a specific tool — it covers all 51 tools the Klarity MCP exposes in production and gives explicit "if the user asks X, call Y" patterns.
+The full PROD-allowed tool list, organized by use case with selection guidance, lives in `tools.md` (alongside this file). Read it when you need to pick a specific tool — it covers every tool the Klarity MCP exposes in production and gives explicit "if the user asks X, call Y" patterns.

skills/klarity-process-context-graph/SKILL.md

@@ -79,15 +79,7 @@ Use these to pull the evidence trail behind a process.
 
 ---
 
-## D. Process visualization
-
-| Tool | When to use |
-|---|---|
-| `generate_process_diagram` | When the user asks to **see** a process — diagrams, BPMN, flows. Choose `BPMNDiagram` when roles/teams/ownership matter; `ProcessFlowDiagram` for plain step flow. |
-
----
-
-## E. Artifacts — the source evidence
+## D. Artifacts — the source evidence
 
 Artifacts are the underlying documents, recordings, and source files behind
 processes (BRDs, SOPs, video recordings, screenshots).
@@ -106,7 +98,7 @@ processes (BRDs, SOPs, video recordings, screenshots).
 
 ---
 
-## F. Context Graph — relational map
+## E. Context Graph — relational map
 
 The Context Graph is the relational layer above the Process Index — entities
 (systems, teams, controls), communities (clusters of related work),
@@ -127,34 +119,7 @@ relationships (handoffs, dependencies). Use when the question is **relational**:
 
 ---
 
-## G. Objectives — Advisor & transformation tracking
-
-Objectives represent **transformation work** the customer is driving with
-Klarity Advisor (e.g., "shorten close from 7 to 3 days", "find duplicate
-invoice processing across geographies"). Each objective accumulates findings,
-actions, activity, and notes over time.
-
-Use these when the customer asks about ongoing transformation work or wants to
-build on prior analysis instead of starting from scratch.
-
-| Tool | When to use |
-|---|---|
-| `get_objective` | Full objective by resource key. |
-| `get_objective_action` | One specific action. |
-| `get_objective_finding` | One specific finding. |
-| `get_objective_note` | One specific note (agent notebook, user context, or run summary). |
-| `list_objective_actions` | All actions for an objective. |
-| `list_objective_findings` | All findings for an objective. |
-| `list_objective_notes` | All notes for an objective. |
-| `list_objective_activity` | Append-only activity log for an objective. |
-| `get_objective_context_bundle` | The stitched bundle: objective + findings + actions + activity + notes + agent state. **Best one-call for orientation.** |
-| `get_objective_analysis_input` | Top-of-run context bundle plus recent workspace evidence — what the Advisor agent itself sees at start of a run. |
-| `get_objective_agent_state` | The persisted agent checkpoint. Use when resuming or debugging an Advisor run. |
-| `list_objective_items_with_active_steering` | Findings/actions where the user has provided active steering feedback. |
-
----
-
-## H. Workspace navigation
+## F. Workspace navigation
 
 | Tool | When to use |
 |---|---|
@@ -163,15 +128,7 @@ build on prior analysis instead of starting from scratch.
 
 ---
 
-## I. Raw SQL (advanced fallback)
-
-| Tool | When to use |
-|---|---|
-| `execute_query` | Raw SQL against the workspace DB. **Last resort** — prefer the typed tools above. Useful when the customer asks an analytics question no typed tool covers. |
-
----
-
-## J. Workspace attributes & sessions
+## G. Workspace attributes & sessions
 
 | Tool | When to use |
 |---|---|
@@ -190,9 +147,7 @@ build on prior analysis instead of starting from scratch.
 
 **"What depends on Z?" / "What is the impact?"** → `search_knowledge_graph` to find Z's entity → `get_downstream_dependencies` (impact) or `get_upstream_sources` (root cause / inputs).
 
-**"Find improvement opportunities in our P2P value stream"** → `get_process_hierarchy_tree` (root: P2P node) → for each leaf: `get_process_details` → look for duplication, exception handling, missing controls. Surface as findings; offer to seed an objective.
-
-**"Continue the transformation work we started"** → `list_accessible_workspaces` (right workspace?) → if there is an existing objective, `get_objective_context_bundle` to load full prior state, then build on it.
+**"Find improvement opportunities in our P2P value stream"** → `get_process_hierarchy_tree` (root: P2P node) → for each leaf: `get_process_details` → look for duplication, exception handling, missing controls. Surface as a ranked candidate set with evidence.
 
 ---
 
@@ -276,9 +231,7 @@ should produce a concise, evidence-backed brief that the manager can act on.
 6. Spot-check the top 2–3 emerging deviations:
    `get_observation_activity_timeline` — drill into the actual session
    for primary-source detail.
-7. Optional: `generate_process_diagram` for processes the manager
-   wants to share with their team in a 1:1 or team meeting.
-8. Synthesize: "Your team owns N processes. M changed in the last 30
+7. Synthesize: "Your team owns N processes. M changed in the last 30
    days. K are showing deviation patterns worth your attention. Here are
    the top 3 with evidence."
 
@@ -307,16 +260,12 @@ hierarchy.
 6. `get_attribute_configurations` — workspace attribute schema (look for
    "automation status", "system of record", "control level" or similar
    metadata that helps rank candidates).
-7. `list_objective_findings` — has Advisor already analyzed this area?
-   Don't duplicate prior work.
-8. If yes: `get_objective_context_bundle` — load prior thinking and
-   build on it. If no: surface the candidate set fresh.
-9. For each top candidate:
+7. For each top candidate:
    - `get_process_observations` — confirm the deviation/manual pattern
      with concrete evidence.
    - `get_downstream_dependencies` — first cut at blast radius.
-10. Synthesize a ranked candidate set: process IDs, observation counts,
-    dependency depth, similarity to known patterns, evidence trail.
+8. Synthesize a ranked candidate set: process IDs, observation counts,
+   dependency depth, similarity to known patterns, evidence trail.
 
 ### Scenario 4 — Form a transformation thesis on a chosen process or value stream
 
@@ -355,13 +304,7 @@ evidence-grounded understanding before recommending changes.
 11. `explore_graph_neighbors` to map the surrounding network.
 12. `summarize_community_subgraph` if the process sits in a meaningful
     community — gives a one-call overview of the surrounding work.
-13. `list_objective_findings` — any prior Advisor thinking on this
-    process or value stream.
-14. If yes: `get_objective_context_bundle` — load prior findings,
-    actions, steering. Build on them, don't start from scratch.
-15. Optional: `generate_process_diagram` — produce a visual of current
-    state for the thesis document.
-16. Synthesize a transformation thesis:
+13. Synthesize a transformation thesis:
     - **Current state:** how the process actually runs (cite
       observations).
     - **Blast radius:** upstream feeders + downstream dependents.
@@ -382,9 +325,6 @@ evidence-grounded understanding before recommending changes.
   confidence.
 - **Always ground synthesis.** Cite process IDs, observation timestamps, and
   graph entity IDs. Never invent.
-- **Build on prior work when possible.** `list_objective_findings` +
-  `get_objective_context_bundle` save dozens of tool calls when the customer
-  has existing Advisor work in flight.
 - **Parallelize on transformation scans.** Scenario 3 explicitly benefits
   from multiple agents fanning out across the hierarchy. The MCP is
   stateless per call — there's no penalty for parallel reads.