@layers/amba-mcp 4.0.4 → 4.0.6

package/dist/lib/annotations.d.ts

@@ -80,13 +80,6 @@ export type ToolVerbClass = 'read' | 'destructive' | 'write';
  * `amba_` prefix. Exported for the test suite.
  */
 export declare function toolNameTokens(name: string): string[];
-/**
- * Classify a tool name into its behavioural class by PRECEDENCE
- * (destructive > read > write). Returns `null` if no token matches any
- * known verb — that should never happen for a real Amba tool and the
- * test suite asserts it doesn't, so a `null` at runtime means a new tool
- * used an unrecognised verb and needs a verb-set entry here.
- */
 export declare function classifyToolVerb(name: string): ToolVerbClass | null;
 /**
  * Derive a human-readable Title-Case title from the tool name. The

package/dist/tools/event-catalog.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Event catalog + control-plane webhook tools — discover what a project can
+ * emit, and subscribe webhooks to PLATFORM lifecycle events.
+ *
+ *   amba_events_catalog            GET    /webhooks/catalog
+ *   amba_control_webhooks_create   POST   /control-webhooks
+ *   amba_control_webhooks_list     GET    /control-webhooks
+ *   amba_control_webhooks_delete   DELETE /control-webhooks/:id
+ *
+ * Tenant/app-event subscription tools live in `webhooks.ts` (those subscribe to
+ * APP events like `economy.currency.spent`). These cover CONTROL-plane events
+ * about the project itself — provisioning, deploys, domains, billing — which is
+ * what an autonomous provisioning agent wants to react to.
+ *
+ * Descriptions stay provider-neutral and nudge toward the production pattern
+ * (discover the catalog → wire the lifecycle events) without overclaiming.
+ */
+import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+import type { ApiClient } from '../api-client.js';
+export declare function registerTools(server: McpServer, apiClient: ApiClient): void;

package/dist/tools/functions.d.ts

@@ -5,7 +5,7 @@
  * deploy a bundled script, list deployments, describe one, delete a
  * function (cascade), and full schedule lifecycle (create, pause,
  * resume, trigger now). Logs read is the last operation in the set —
- * Workers Logpush events for a single function over a bounded time
+ * Function logs for a single function over a bounded time
  * range.
  *
  * Wire details:

package/dist/tools/leagues.d.ts

@@ -6,7 +6,7 @@ import type { ApiClient } from '../api-client.js';
  * cohorts that the rollover workflow reshuffles. These tools provision and
  * inspect leagues; the admin routes are mounted at
  * `/v1/admin/projects/:projectId/leagues`. Members are assigned by the weekly
- * rollover (the registered Temporal schedule) and score live off `xp_awarded`
+ * rollover (the scheduled weekly rollover) and score live off `xp_awarded`
  * engagement events.
  */
 export declare function registerTools(server: McpServer, apiClient: ApiClient): void;

package/dist/tools/monetization.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Monetization control-plane tools (Phase 1 — read-only against RevenueCat).
+ *
+ * These let an agent reason about a project's subscription monetization as
+ * Infrastructure-as-Code: preview the gap between the declared config and
+ * what's live (plan), see what changed out-of-band (drift), snapshot the live
+ * config into a declarative bundle (export), adopt the live config as the
+ * managed baseline (adopt), and inspect the current declared definitions.
+ *
+ * Phase 1 is READ-ONLY against the upstream subscription provider: plan / drift
+ * / export only read; adopt writes Amba's own state (definitions + statefile),
+ * never the provider. Provisioning ("apply" — pushing declared changes back to
+ * the provider) is a later phase; these tools deliberately don't claim it.
+ *
+ * RevenueCat may be named here — it's a developer-chosen integration the
+ * developer configured themselves, not an Amba implementation detail.
+ */
+import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+import type { ApiClient } from '../api-client.js';
+export declare function registerTools(server: McpServer, apiClient: ApiClient): void;

package/dist/tools/operations.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Operation-handle MCP tools — poll an async operation to done | failed.
+ *
+ * Several Amba actions kick off work that may take a moment (e.g. buying a
+ * domain). Those endpoints return an `operation_id`; pass it to
+ * `amba_operations_get` to read the current status without re-triggering the
+ * action. Poll until `status` is `succeeded` or `failed` — on `failed`,
+ * `failed_reason` explains why.
+ *
+ * Tools:
+ *   - `amba_operations_get`  — read one operation's status (poll to done).
+ *   - `amba_operations_list` — list operations, optionally filtered by kind
+ *                              and/or status.
+ *
+ * Both are READ-ONLY — they never start or change an operation, only report
+ * it. The producing tool (e.g. `amba_domains_purchase`) is what creates the
+ * operation and returns its id.
+ *
+ * Authentication: every tool accepts an optional inline `pat` via the
+ * `registerTool` helper (see `../lib/with-pat.ts`).
+ */
+import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+import type { ApiClient } from '../api-client.js';
+export declare function registerTools(server: McpServer, apiClient: ApiClient): void;

package/dist/tools/payments.d.ts

@@ -0,0 +1,30 @@
+/**
+ * Amba Payments — Stripe Connect platform tools (tracker #10).
+ *
+ * Amba is the payments rail for the developer's app: the app is the seller,
+ * Amba takes a platform fee, Stripe carries money-transmission. These are
+ * the DEVELOPER-facing onboarding + configuration + reporting tools — the
+ * developer knowingly connects a Stripe account, so "Stripe" is named here
+ * (same posture as the existing developer-billing surface). The end-customer
+ * (app-user) payment surface lives in the SDK and stays neutral.
+ *
+ * Tools:
+ *   - amba_payments_account_create  — create the project's connected account
+ *   - amba_payments_create_onboarding_link — hosted onboarding URL (copy box)
+ *   - amba_payments_account_status  — onboarding + capability flags
+ *   - amba_payments_set_fee         — set the default platform fee (basis points)
+ *   - amba_payments_charge          — destination charge with application fee
+ *   - amba_payments_balance         — connected-account balance
+ *   - amba_payments_payouts         — connected-account payouts
+ *
+ * Backend routes: POST/GET/PUT /v1/admin/projects/:id/payments/*. All live
+ * Stripe calls are gated by the platform's PAYMENTS_CONNECT_LIVE
+ * kill-switch — when off, the tools surface a clear PAYMENTS_NOT_ENABLED
+ * error via the standard AmbaApiError path (the platform owner enables it).
+ *
+ * No vendor leakage on the END-CUSTOMER surface; here, naming Stripe is by
+ * intent in the developer onboarding context.
+ */
+import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+import type { ApiClient } from '../api-client.js';
+export declare function registerTools(server: McpServer, apiClient: ApiClient): void;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@layers/amba-mcp",
-  "version": "4.0.4",
+  "version": "4.0.6",
   "license": "Apache-2.0",
   "engines": {
     "node": ">=22"
@@ -26,7 +26,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.12.1",
     "zod": "^3.25.0",
-    "@layers/amba-shared": "4.0.3"
+    "@layers/amba-shared": "4.0.4"
   },
   "devDependencies": {
     "@types/node": "^22.10.2",