@kadoa/mcp 0.7.2 → 0.7.4

package/README.md

@@ -89,7 +89,7 @@ Point your client to `https://mcp.kadoa.com/mcp` with OAuth authentication.
 
 | Tool | Description |
 |------|-------------|
-| `create_realtime_monitor` | Create an asynchronous realtime monitoring workflow after persisting notification channels |
+| `create_realtime_monitor` | Create an asynchronous realtime monitoring workflow, optionally from a template, after persisting notification channels |
 | `list_changes` | List detected data changes across one or more realtime monitoring workflows |
 | `get_change` | Get detailed information about one detected change, including the data snapshot (cut to whole rows past ~80 KB) and diff |
 
@@ -157,12 +157,20 @@ Point your client to `https://mcp.kadoa.com/mcp` with OAuth authentication.
 |------|-------------|
 | `create_support_ticket` | File a support ticket for one workflow so the Kadoa team investigates it |
 
+### Documentation
+
+| Tool | Description |
+|------|-------------|
+| `list_docs_pages` | List Kadoa documentation pages, for "how does Kadoa work / where do I find X" questions (API keys, billing, settings) |
+| `read_docs_page` | Read one docs.kadoa.com page as markdown |
+
 ### Account & team
 
 | Tool | Description |
 |------|-------------|
 | `whoami` | Show current user details, auth method, and team memberships |
 | `team_list` | List all teams you belong to and see which is active |
+| `list_compliance_rules` | Read the compliance rules applied to your team (robots.txt, terms of service, blocked sources, PII, and similar), with each rule's enabled status and configuration. Read-only |
 
 Team switching (a team_switch tool) exists in the code but is currently
 disabled and hidden from every client's tool list — a credential is fixed to
@@ -294,6 +302,13 @@ Claude uses get_workflow_assistant and the other workflow Assistant tools for fo
 
 Realtime monitors cannot be converted in place to or from scheduled workflows; create them with `create_realtime_monitor` from the start.
 
+Like `create_workflow`, `create_realtime_monitor` accepts `templateId`, optional
+`templateVersion` (defaults to the latest published version), and optional `prompt`
+for source-specific instructions. The monitor stays linked to the template and
+inherits its shared configuration; omit inline entity and schema when using a
+template. Notification channels are still required. Templates that control a batch
+frequency must use `create_workflow` instead.
+
 ### Update an Assistant-built workflow without replacing it
 
 ```
@@ -544,15 +559,13 @@ A typical feature touches three repos — **`kadoa-backend` → `kadoa-sdks` →
 | Backend endpoint | `kadoa-backend/` | The HTTP API. Source of truth; the OpenAPI spec is generated from here. |
 | SDK low-level | `kadoa-sdks/sdks/node/src/generated/api/*` | Auto-generated axios client. Raw HTTP, typed from the OpenAPI spec. **Do not hand-edit.** |
 | SDK domain (high-level) | `kadoa-sdks/sdks/node/src/domains/<thing>/<thing>.service.ts` | Thin domain wrapper over the generated client. `client.<thing>.<action>(...)`. This is what callers use. |
-| CLI | `kadoa-cli/src/commands/<thing>.ts` | Commander action: flag parsing, spinner, table/json output. Calls SDK domain. |
 | MCP (this repo) | `kadoa-mcp/src/tools/<domain>.ts` | Zod input schema + tool description tuned for LLMs. Calls SDK domain. |
 
 Mental model:
 - **SDK** = pure function over HTTP.
-- **CLI** = SDK + human UX (flags, table output).
 - **MCP** = SDK + LLM UX (zod schema, prose description).
 
-CLI and MCP both call **identical** SDK domain methods. A new feature added to the SDK is picked up by both clients for free — as long as we keep the layering honest.
+MCP calls SDK domain methods, never raw HTTP. Any other SDK consumer gets new features for free — as long as we keep the layering honest.
 
 ### Adding a new feature
 
@@ -560,7 +573,7 @@ CLI and MCP both call **identical** SDK domain methods. A new feature added to t
    - Add or modify the HTTP endpoint.
    - Make sure the OpenAPI spec reflects the change (paths, request/response schemas).
 
-2. **SDK** (`kadoa-sdks`) — always do this **before** MCP/CLI work (the SDK-first rule). No bandaid `axios` calls in MCP.
+2. **SDK** (`kadoa-sdks`) — always do this **before** MCP work (the SDK-first rule). No bandaid `axios` calls in MCP.
    - Regenerate the low-level client:
      ```bash
      bun kadoa-codegen fetch-spec -e https://api.kadoa.com/openapi -f
@@ -581,8 +594,6 @@ CLI and MCP both call **identical** SDK domain methods. A new feature added to t
    - If the change intentionally alters a tool's name, title, description, schema, outputSchema or annotations, regenerate the snapshot: `UPDATE_TOOLS_SNAPSHOT=1 BUN_TEST=1 bun test tests/unit/tools-list-snapshot.test.ts`, then `./node_modules/.bin/biome format --write tests/unit/fixtures/tools-list.snapshot.json`. Advertised input and output schemas are normalised by `src/tools/shared/portable-schema.ts` (no `$ref`/`$defs`, `const`, `oneOf`, `additionalProperties`, `$schema`, etc.), so strict clients such as Gemini accept them; zod validation is unchanged.
    - Use a Conventional Commit message (`feat(mcp): ...`, `fix(mcp): ...`). Release Please will cut the next version on merge to `main`.
 
-4. **CLI** (`kadoa-cli`), if the feature is user-facing on the command line: mirror the MCP step in `src/commands/<thing>.ts`. Same SDK call, different UX.
-
 ### Anti-patterns
 
 - ❌ Raw `axios` calls or hand-rolled HTTP in `src/tools/`. Always go through `ctx.client.<thing>`.