Skip to main content
The Kowalah Claude Connector exposes twelve tools, grouped into four jobs: keeping up with your programme, checking your own training, reading your AI Operating Model, and maintaining it. Every tool is scoped to organizations you belong to and filtered by your role in each one, so you never see anything Kowalah hasn’t given you access to in the platform.

Your programme

Get an update, find an accelerator, raise an opportunity

Your training

What you’re booked on, your agenda, how you’re getting on

Reading the operating model

Your unit tree, one unit’s portfolio, one process in full

Changing the operating model

Edit what you own, propose changes to what you don’t

​
Your programme

​
kowalah_get_update

A single tool for any “how are things”, “what’s the status of X”, “what’s waiting for me” question. Pass an optional natural-language query; the server figures out whether you want a portfolio rollup, a focused view of a specific thing, or just your identity and organizations.

​
Pending discoveries in the home view

If Kowalah is running a Discovery and you’re on the audience, the home view includes a pending_discoveries section with:
  • The discovery number (e.g. DISC-0003) and name
  • The goal, what Kowalah is researching
  • The business value context, why it matters
  • The close date, when the discovery stops collecting responses
  • The project the discovery sits against (if any)
You only see your own invite. You don’t see other people’s responses or Kowalah’s internal triage. Pending discoveries are independent of your role: members, core team, and admins all see whatever they’ve personally been invited to.

​
What a focused view returns

​
kowalah_find_accelerator

Searches Kowalah’s global accelerator library plus your organization’s private accelerators for a reusable prompt, GPT, training, or workflow. Use this whenever you’re about to raise a request for help. There may already be something on the shelf you can take and run with.
Results often include a try-it-now prompt that Claude can act on directly inside the same chat.

​
kowalah_create_opportunity

The single inbound entry point for everything a customer wants to raise with Kowalah: a question, an idea, a piece of work to scope, a new project to consider. Anyone in your organization can submit, regardless of role. You don’t have to decide whether the work is an Expert Request, a Deliverable, or a Project. Kowalah’s team triages from there. Before submitting, Claude is expected to:
  1. Check the accelerator library for something that already solves the problem
  2. Make sure the description is at least a paragraph (~80+ characters of real context: goal, what good looks like, anything Kowalah should know)
  3. Ask which organization the opportunity is for (if you belong to more than one)

​
Linking an opportunity to a discovery

If you’re responding to a Kowalah discovery you’ve been invited to, Claude passes the discovery_id through when it submits. The server then:
  • Validates that you’re actually on the discovery’s audience
  • Stamps the opportunity with the discovery and its project
  • Marks your audience invite as responded so reminders stop
You’ll see this happen automatically when you ask Claude to respond to a pending discovery. There’s nothing extra you need to type.

​
Your training

​
kowalah_get_my_training

Your own Kowalah training record: what you’re booked on, your agenda for the day, and how you’re getting on.
Pass a kind to choose the view:
This tool only ever shows your own training, matched to you by Kowalah account or email address. It never exposes other participants, their results, the cohort roster, trainer notes, or anyone else’s feedback. org_overview is counts and averages with no named individuals and no free-text comments; everyone else asking for it gets a not-permitted note.If you’re enrolled but the tool says you aren’t, the training may be registered against a different email address. Contact your Kowalah team.

​
Reading your operating model

These three tools give Claude your AI Operating Model: the map of how your organization actually works, and how much of it AI could support. Everyone in your organization can read the whole map, whatever their role.

​
kowalah_get_operating_model

The world view. Returns your unit tree with coverage rollups on every node (coverage %, process count, redesign-gap count, constraint count, rolled up across each unit’s whole subtree), plus org-wide totals and a narratable summary.
Pass organization_id only if you belong to more than one organization. If nothing has been mapped yet, the tool says so rather than returning an empty tree.

​
kowalah_get_operating_model_unit

One unit in focus: its subtree coverage rollup, the processes it owns directly (each with its own rollup), its child units, and the top redesign-backlog steps across its processes, ranked by constraint and coordination burden.

​
kowalah_get_process

One process in full, and the richest thing the connector returns. Includes:
  • Process metadata: purpose, cadence, criticality, owners, owning unit
  • Ordered steps with current to target dispositions, and gap and constraint markers
  • The DEFINE contract on each step: acceptance criteria, input artifact, output artifact
  • Per-step implementation links and per-step quality evals, with target versus current scores
  • A process-level rollup and the ranked redesign backlog
  • Inter-process connections, the handoffs and feeds touching this process
  • Initiatives already aimed at it, the opportunities, deliverables, and projects linked to the process or to one of its steps
The response also carries an access block telling Claude what you may do to this process, so it can offer the right next step rather than attempting an edit that gets refused. See who can change what.
Initiatives are filtered to what you personally may see, so this list can legitimately differ between two colleagues looking at the same process.

​
Changing your operating model

Reading the map is open to everyone. Changing it depends on where the thing you’re changing sits relative to you, which the connector resolves on every call. If you can’t edit something directly, the answer is never a dead end: it routes to a proposal.

​
kowalah_save_process

Creates or updates a process. On create, the process number is allocated automatically and the owner defaults to the owning unit’s leader. On update, only the fields you provide change. You can re-parent a process to a different unit within the same organization.

​
kowalah_save_process_step

Creates or updates a step within a process. On create, position defaults to append and the current disposition defaults to human.
The Jidoka rule. If a step’s target disposition is ai_autonomous, it must carry an escalation trigger: the stop-condition that hands control back to a human. A partial update that would leave a step autonomous without a trigger is rejected. This is enforced by the server, not just the UI.

​
kowalah_save_process_step_eval

Creates or updates an eval on a step: the quality check that its output meets its acceptance criteria. This is how a business owner sets and tracks the bar, for example “what counts as a good forecast category call” or “what a compliant response looks like”.
  • A gate blocks the step until it passes. It’s all-or-nothing and cannot carry a sampling percentage.
  • A monitor observes a sample, and may set a sampling percentage from 0 to 100.
  • target_score is the bar; current_score and measured_at record the latest reading.
Creating an eval needs edit rights on the parent process. Once it exists, the eval’s owner can keep editing it even if the process itself sits above their altitude, so a function lead can own the quality bar on a process they don’t otherwise control.

​
kowalah_save_org_unit

Creates or updates a node of your org-unit tree. For a child unit, pass a parent; the organization is inherited. Creating a root unit reshapes the top of the org chart and is restricted to admins and core team.

​
kowalah_propose_process_change

The route when you can’t edit directly. Instead of changing the process, it files an Opportunity linked to that process, and optionally pinned to one step, so the owner can pick it up.
Use it for “this step should be automated”, “the acceptance criteria here are wrong”, “we should add a quality gate”, anything you would change if it were yours. Anyone in the organization can propose against any process they can see, and nothing about the process itself is modified.

​
Who can change what

Your ability to edit the operating model is governed by your altitude: where the target sits relative to your home unit in the org tree. This is a different axis from your role, which governs what you can see.
Admins and core team are cross-cutting editors within their own organization: they can edit and create anywhere in it. Being an admin in one organization confers nothing in another.If no home unit has been set for you, everything resolves to the safe default of read and propose. Ask your organization admin to set your home unit if you should be able to edit.
Because kowalah_get_process returns your resolved access up front, Claude can offer “shall I change that, or propose it to the owner?” rather than trying an edit and reporting a refusal.
No connector tool deletes anything. Projects, deliverables, Expert Requests, and contracts are read-only through the connector, whatever your altitude or role.

​
Prompts

The connector also registers a few prompts you can pick from Claude’s prompt menu (the ”+” attachment or slash menu, depending on which Claude client you’re using). Some are role-gated. Members don’t see Programme update or Expert Request credits and quota in the prompt menu. They’re only registered for privileged roles.

​
Resources

Alongside tools, the connector exposes your accelerators, opportunities, projects, deliverables, and Expert Requests as MCP resources, so Claude clients that support resource browsing can attach them to a conversation directly. Resources are filtered by exactly the same rules as the tools, and the filter is re-checked on read, so a hand-typed identifier can’t bypass it.

​
What your role changes

Role governs visibility. Altitude, above, governs editing. A no_match response for a known reference number usually means the item exists but you’re not permitted to see it, not that it doesn’t exist. This is most common for members who aren’t on the stakeholder list for a given project, deliverable, or Expert Request. Two things are different:
  • Discovery invites are personal to you, so you always see your own pending discoveries regardless of role.
  • Training is personal to you: everyone sees their own record only, and only admins and core team can pull the anonymised org rollup.

​
Data filtering

The connector enforces visibility on the server side:
  • Organization scoping, only data from organizations you belong to is ever returned
  • Role-based filtering, members only see what they raised or are a stakeholder on
  • Altitude gating, operating-model writes are checked against your position in the org tree, after org scoping
  • Client visibility flags, tasks, risks, and decisions are filtered to client-visible items
  • Discovery audience gate, opportunity submissions tagged with a discovery_id are rejected if you’re not on the audience
  • Identity scoping, training data is matched to you personally by account or email
  • Field filtering, internal fields (Kowalah team assignments, contract values, payment details) are not exposed, and Kowalah-side ownership can’t be set by a client even on records you create

Set up in Claude

Add the connector to your Claude workspace

Work your operating model in Claude

Map, review, and improve processes in conversation

Roles and permissions

Full role reference

Security and data access

How the connector is scoped and gated