@integrity-labs/agt-cli 0.28.778 → 0.28.780

package/dist/mcp/index.js

@@ -40371,6 +40371,459 @@ var ASSET_TYPES = {
 var DEFAULT_CHUNK_BUDGET_BYTES = 180 * 1024;
 var textEncoder = new TextEncoder();
 
+// ../core/dist/integrations/oauth-providers.js
+var OAUTH_PROVIDERS = {
+  "google-workspace": {
+    definitionId: "google-workspace",
+    authorizeUrl: "https://accounts.google.com/o/oauth2/v2/auth",
+    tokenUrl: "https://oauth2.googleapis.com/token",
+    revokeUrl: "https://oauth2.googleapis.com/revoke",
+    defaultScopes: [
+      "https://www.googleapis.com/auth/gmail.modify",
+      "https://www.googleapis.com/auth/calendar",
+      "https://www.googleapis.com/auth/drive",
+      "https://www.googleapis.com/auth/spreadsheets",
+      "https://www.googleapis.com/auth/documents",
+      "https://www.googleapis.com/auth/chat.messages",
+      "https://www.googleapis.com/auth/chat.spaces.readonly"
+    ],
+    supportsRefresh: true,
+    extraAuthorizeParams: {
+      access_type: "offline",
+      prompt: "consent"
+    },
+    clientAuthMethod: "body",
+    userInfoUrl: "https://www.googleapis.com/oauth2/v2/userinfo"
+  },
+  "github": {
+    definitionId: "github",
+    authorizeUrl: "https://github.com/login/oauth/authorize",
+    tokenUrl: "https://github.com/login/oauth/access_token",
+    // ENG-6187: revoke the existing grant on reconnect so GitHub re-prompts and
+    // the four scopes below are actually granted. Without this, a stale narrow
+    // grant (e.g. an old read:user-only authorization) is silently re-issued and
+    // the missing-scopes banner loops forever.
+    grantRevokeUrl: "https://api.github.com/applications/{client_id}/grant",
+    defaultScopes: ["repo", "read:org", "gist", "workflow"],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "body",
+    userInfoUrl: "https://api.github.com/user"
+  },
+  "granola": {
+    // Granola MCP — remote streamable-HTTP at https://mcp.granola.ai/mcp.
+    // The AS is at mcp-auth.granola.ai and exposes RFC 8414 metadata at
+    // /.well-known/oauth-authorization-server. Auth is OAuth 2.0 with
+    // mandatory PKCE (S256) and a public client (no client_secret) issued
+    // via Dynamic Client Registration (RFC 7591). The bootstrap script
+    // (`packages/api/scripts/dcr-register.ts`) registers a client once at
+    // deploy time; OAUTH_GRANOLA_CLIENT_ID is set from its output.
+    definitionId: "granola",
+    authorizeUrl: "https://mcp-auth.granola.ai/oauth2/authorize",
+    tokenUrl: "https://mcp-auth.granola.ai/oauth2/token",
+    // Minimal scope set: `offline_access` earns the refresh_token so the
+    // refresh cron can rotate the bearer without operator action; `openid`
+    // is required for the OIDC code flow even when we don't request an
+    // id_token. Profile/email are intentionally omitted — we have no
+    // userInfoUrl wired up here, so requesting them would over-ask consent
+    // for fields the callback can't read.
+    defaultScopes: ["openid", "offline_access"],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "body",
+    pkce: "S256",
+    publicClient: true,
+    mcpUrl: "https://mcp.granola.ai/mcp",
+    // Curated surface (matches the catalog seed's defined_scopes[].tools).
+    toolAllowlist: ["search-meetings", "read-transcript", "read-summary", "list-folders"]
+  },
+  "brand-ninja": {
+    // ENG-6820: Brand Ninja External-Content MCP, remote streamable-HTTP at
+    // https://ext-api.app.brandninja.ai/v1/mcp. Same shape as Granola: the
+    // server exposes RFC 8414 authorization-server metadata at
+    // /.well-known/oauth-authorization-server (values below are taken verbatim
+    // from that document, not inferred). Auth is OAuth 2.0 authorization-code
+    // with mandatory PKCE (S256) and a public client (token_endpoint_auth_method
+    // 'none') issued via Dynamic Client Registration (RFC 7591). The bootstrap
+    // script (packages/api/scripts/dcr-register.ts) registers a client once at
+    // deploy time against the registration_endpoint
+    // (https://ext-api.app.brandninja.ai/v1/oauth/register); OAUTH_BRAND_NINJA_CLIENT_ID
+    // is set from its output. The AS advertises the refresh_token grant, so the
+    // shared oauth-refresh cron rotates the bearer without operator action.
+    definitionId: "brand-ninja",
+    authorizeUrl: "https://prod-brandninja.auth.ap-southeast-2.amazoncognito.com/oauth2/authorize",
+    tokenUrl: "https://prod-brandninja.auth.ap-southeast-2.amazoncognito.com/oauth2/token",
+    // The resource server (ext-api.app.brandninja.ai) advertises exactly two
+    // scopes: external-api/content.write (the default content surface) and
+    // external-api/admin (read-only credential metadata, granted per account
+    // admin). Default install is least-privilege: content.write only; an
+    // operator can widen to admin out of band. No openid/offline_access in the
+    // advertised scope set, so Cognito issues the refresh_token for the code grant
+    // regardless, so requesting only the resource scope keeps consent minimal.
+    defaultScopes: ["external-api/content.write"],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "body",
+    pkce: "S256",
+    publicClient: true,
+    mcpUrl: "https://ext-api.app.brandninja.ai/v1/mcp",
+    // Curated surface (matches the catalog seed's defined_scopes[].tools).
+    toolAllowlist: [
+      "submit_content_request",
+      "get_content_status",
+      "list_content_requests",
+      "list_channels",
+      "list_brands",
+      "list_topics",
+      "list_timeline_templates",
+      "list_content_types",
+      "list_source_skills",
+      "list_output_skills",
+      "list_conversion_skills",
+      "list_credentials",
+      "search_transcripts",
+      "create_source_clips",
+      "create_timeline_ranking",
+      "create_topic",
+      "create_timeline_template",
+      "create_knowledge",
+      "link_knowledge"
+    ]
+  },
+  "kajabi": {
+    // Kajabi MCP — remote streamable-HTTP at https://mcp.kajabi.com/mcp.
+    // Same Granola/Brand-Ninja shape: OAuth 2.0 authorization-code with
+    // mandatory PKCE (S256) and a public client (token_endpoint_auth_method
+    // 'none') issued via Dynamic Client Registration (RFC 7591). Values below
+    // are taken verbatim from Kajabi's RFC 8414 metadata at
+    // https://mcp.kajabi.com/.well-known/oauth-authorization-server (a Rails
+    // Doorkeeper AS), not inferred. NOTE the authorize host differs from the
+    // token host: authorize is on app.kajabi.com (the login surface), while
+    // token/register/revoke are on mcp.kajabi.com — do NOT "normalise" them to
+    // one host. The bootstrap script (packages/api/scripts/dcr-register.ts)
+    // registers a client once at deploy time against
+    // https://mcp.kajabi.com/mcp/oauth/register; OAUTH_KAJABI_CLIENT_ID is set
+    // from its output. Doorkeeper RESTRICTS a dynamic client to the scopes it
+    // registered with, so register with at least the union of defaultScopes
+    // below (--scope 'read write:contacts write:emails write:content
+    // write:commerce'). Widening defaultScopes forces a client re-register
+    // (new client_id) AND a per-connection re-consent: existing tokens keep
+    // the old scope set and their refreshes fail under the new client_id, so
+    // each connection flips to needs_reauth until the user re-runs Connect
+    // (ENG-7483). The AS advertises the refresh_token grant (no
+    // openid/offline_access scope needed), so the shared oauth-refresh cron
+    // rotates the bearer without operator action.
+    definitionId: "kajabi",
+    authorizeUrl: "https://app.kajabi.com/mcp/oauth/authorize",
+    tokenUrl: "https://mcp.kajabi.com/mcp/oauth/token",
+    revokeUrl: "https://mcp.kajabi.com/mcp/oauth/revoke",
+    // Coarse Doorkeeper scopes (NOT openid-style). Cross-domain reads (`read`)
+    // plus the write surfaces this integration ships: contact tags/segments,
+    // email broadcasts/sequences, and course updates (write:content gates
+    // update_course, the course-thumbnail path, ENG-7483). write:commerce is
+    // requested now (Brad's call on ENG-7483) so a later offer/pricing-write
+    // enablement needs no extra re-consent round; the tool allowlist below
+    // still exposes no commerce write, so the callable surface stays minimal.
+    defaultScopes: ["read", "write:contacts", "write:emails", "write:content", "write:commerce"],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "body",
+    pkce: "S256",
+    publicClient: true,
+    mcpUrl: "https://mcp.kajabi.com/mcp",
+    // Curated surface (matches the catalog seed's defined_scopes[].tools). Kajabi's
+    // live MCP advertises ~111 tools; the agent only needs these 28.
+    // CS-1427: `enable_toolset` is included so an agent can activate its own
+    // products/commerce + analytics toolsets on the connection (Kajabi gates those
+    // tool groups behind a runtime toolset that returns "not active" until enabled).
+    // Low-risk: this proxy still caps every tools/call to the allowlist, so a broad
+    // activation can't widen what's actually callable.
+    // ENG-7483: `get_course`/`update_course` enable the course-thumbnail refresh
+    // (update_course covers title/description/thumbnail per Kajabi's MCP docs).
+    // Fail-safe on naming drift: an allowlisted tool the server doesn't advertise
+    // is logged and skipped by the proxy, never a break.
+    toolAllowlist: [
+      "list_sites",
+      "get_site_summary",
+      "select_site",
+      "search_contacts",
+      "get_contact",
+      "search_products",
+      "get_product",
+      "list_offers",
+      "get_offer",
+      "list_offer_purchases",
+      "get_revenue_analytics",
+      "get_contacts_analytics",
+      "list_tags",
+      "create_tag",
+      "tag_contact",
+      "untag_contact",
+      "list_segments",
+      "create_segment",
+      "update_segment",
+      "list_broadcasts",
+      "get_broadcast",
+      "create_broadcast",
+      "list_sequences",
+      "get_sequence",
+      "create_sequence",
+      "enable_toolset",
+      "get_course",
+      "update_course",
+      // ENG-7629 follow-up: pages (Dee's landing-page edit) + themes (CS-1448
+      // theme-builder broadcast content). Callable via the proxy union manifest
+      // + per-call enable; matches the new kajabi:pages catalog scope.
+      "list_landing_pages",
+      "get_landing_page",
+      "update_landing_page",
+      "get_theme_content"
+    ],
+    // CS-1446: Kajabi gates several tool groups behind a runtime `enable_toolset`
+    // and does not advertise their tools in `tools/list` until the group is
+    // active. The harness freezes its callable-tool manifest from the
+    // connect-time `tools/list`, so a group the agent activates later never
+    // becomes callable (repro: enable_toolset('courses') → get_course/
+    // update_course still "No such tool available"). Pre-activate the gated
+    // groups whose tools we allowlist so they are advertised in that first
+    // manifest. Names are Kajabi's toolset ids (courses per CS-1446;
+    // products/commerce/analytics per CS-1427). Best-effort + idempotent: an
+    // unknown/unscoped name is logged and skipped by the proxy, and the
+    // toolAllowlist above still caps what is actually callable.
+    //
+    // ENG-8392: `contacts` + `emails` were missing, so thirteen allowlisted
+    // tools were unreachable by construction — list_tags, create_tag,
+    // tag_contact, untag_contact, list_segments, create_segment,
+    // update_segment (contacts) and list_broadcasts, get_broadcast,
+    // create_broadcast, list_sequences, get_sequence, create_sequence
+    // (emails). A customer agent was blocked on exactly those.
+    //
+    // These two ids are Kajabi's OWN spelling, not ours: the server names the
+    // toolset in its rejection, e.g. `list_tags` returns
+    //   "The 'contacts' toolset is not active. Call enable_toolset with
+    //    name: 'contacts' to activate it first."
+    // and `list_sequences` returns the same with 'emails'. Sourced that way
+    // deliberately — a wrong id here is logged and SKIPPED by the proxy, so a
+    // guess would look applied and change nothing.
+    //
+    // Why this went unnoticed for four rounds: `get_contacts_analytics` lives
+    // in the `analytics` group, which we already pre-enable. So the contacts
+    // family read as partly alive (you could see a site's contact count and
+    // growth curve) while every tag and segment call failed.
+    preEnableToolsets: [
+      "courses",
+      "products",
+      "commerce",
+      "analytics",
+      "pages",
+      "themes",
+      "contacts",
+      "emails"
+    ],
+    // ENG-8512: `update_course.thumbnail` stores a RELATIVE path into Kajabi's
+    // own storage — it is rendered as
+    //   https://kajabi-storefronts-production.kajabi-cdn.com/kajabi-storefronts-production/<value>
+    // so an absolute http(s) URL is structurally not a valid value for it.
+    // Kajabi accepts one anyway, returns 200, echoes it back, ingests nothing,
+    // and the course shows a broken image. Reported from a live client site
+    // (DTI) via CS-1548 after it produced a false "done" report and three
+    // failed cards.
+    //
+    // Anchored at the start so only an ABSOLUTE URL is refused; every relative
+    // path — the valid shape — passes untouched. This does not enable setting a
+    // thumbnail from a URL (that needs an upload path, CS-1548 item 4). It stops
+    // us reporting success for a write that did not happen.
+    argRejects: [
+      {
+        tool: "update_course",
+        field: "thumbnail",
+        pattern: "^\\s*https?://",
+        message: "thumbnail takes a relative path inside Kajabi storage, not an external URL. Kajabi accepts a URL here, returns 200 and never ingests it, so the image would silently stay broken. Upload the asset to Kajabi first and pass the storage path it returns."
+      },
+      // CS-1554: `search_contacts` accepts `tag_id`, does not apply it, and
+      // returns the FULL unfiltered contact list with `filters_applied: null`.
+      // Reported first-hand from a live client site (DTI) while auditing which
+      // contacts carried an opt-in tag. Corroborating evidence: Kajabi's own
+      // REST reference filters contacts with `filter[has_tag_id]`, not a bare
+      // `tag_id` — so the argument is dropped as unrecognised and the response
+      // says so, if you read `filters_applied`.
+      //
+      // Worse than the thumbnail case it sits next to. A broken image is
+      // visible; an unfiltered list that reads as filtered produces a confident
+      // wrong ANSWER, which a human then acts on. That is the same shape as the
+      // incident in CS-1554 where the agent told the customer content did not
+      // exist when it did.
+      //
+      // Any value at all is refused: the field is not partially supported, it
+      // is inert. `[\s\S]` matches every stringified scalar including 0 and
+      // false, which a `.`-style pattern anchored on truthiness would miss.
+      //
+      // NOT REPRODUCED BY ME — I have no Kajabi connection. This rests on the
+      // CS-1554 first-hand report plus the REST reference. The file's own bar is
+      // "provably wrong, never a guess", so a reviewer with a live Kajabi
+      // connection should confirm before this merges. If `tag_id` DOES filter
+      // for some tenant, drop this rule and keep the scalar fix.
+      {
+        tool: "search_contacts",
+        field: "tag_id",
+        pattern: "[\\s\\S]",
+        message: "tag_id is accepted by Kajabi and never applied \u2014 the call returns the FULL contact list with filters_applied: null, which reads as a filtered result and is not one. There is no working tag filter on this tool today. Use list_tags plus the per-contact tag data to determine membership, and treat any tag audit built on search_contacts(tag_id) as unfiltered."
+      }
+    ]
+  },
+  "notion-cli": {
+    // Notion's public OAuth app. Tokens are workspace-scoped and long-lived —
+    // Notion does not issue refresh_tokens, so `supportsRefresh: false` and
+    // the refresh cron skips this provider entirely. Scopes are not part of
+    // Notion's authorize URL contract; consent is governed by what the user
+    // grants in the OAuth screen, so `defaultScopes` stays empty.
+    // `owner=user` forces the user-OAuth variant (vs internal integration).
+    // Requires OAUTH_NOTION_CLI_CLIENT_ID and OAUTH_NOTION_CLI_CLIENT_SECRET.
+    definitionId: "notion-cli",
+    authorizeUrl: "https://api.notion.com/v1/oauth/authorize",
+    tokenUrl: "https://api.notion.com/v1/oauth/token",
+    defaultScopes: [],
+    supportsRefresh: false,
+    extraAuthorizeParams: {
+      owner: "user"
+    },
+    clientAuthMethod: "basic"
+  },
+  "xero": {
+    definitionId: "xero",
+    authorizeUrl: "https://login.xero.com/identity/connect/authorize",
+    tokenUrl: "https://identity.xero.com/connect/token",
+    revokeUrl: "https://identity.xero.com/connect/revocation",
+    defaultScopes: [
+      "openid",
+      "profile",
+      "email",
+      "offline_access",
+      // Granular scopes (required for apps created after March 2, 2026 —
+      // do NOT revert to the broad `accounting.transactions` /
+      // `accounting.contacts` scopes, Xero rejects the manifest).
+      // The variant *without* `.read` is the read+write granular scope.
+      "accounting.settings.read",
+      // contacts: write enables agent-driven supplier/customer creation
+      // (required for bill creation since a bill must reference a contact).
+      "accounting.contacts",
+      // invoices: write enables bill creation (Type=ACCPAY invoices) and
+      // updates to sales invoices alongside the existing read access.
+      "accounting.invoices",
+      // attachments: write enables agents to attach the source PDF to a
+      // bill at creation time. Read-only would force a follow-up manual
+      // upload in Xero; write closes the loop.
+      "accounting.attachments",
+      // accounting.transactions.read → granular read-only replacements
+      // for the surfaces we don't yet need write access on.
+      "accounting.payments.read",
+      "accounting.banktransactions.read",
+      // manualjournals: write (CS-1439) enables the xero-broker to post
+      // manual journals (reclasses, accruals, corrections) on approval. The
+      // variant without `.read` is the read+write granular scope. Note: an
+      // existing Xero install must RECONNECT for its token to carry this — the
+      // broker posts journals with the agent's own OAuth access_token.
+      "accounting.manualjournals",
+      // accounting.reports.read → granular read-only replacements
+      "accounting.reports.balancesheet.read",
+      "accounting.reports.profitandloss.read",
+      "accounting.reports.trialbalance.read",
+      "accounting.reports.budgetsummary.read",
+      "accounting.reports.banksummary.read",
+      "accounting.reports.executivesummary.read",
+      "accounting.reports.aged.read"
+    ],
+    // Read-only variant (ENG-6170): the `.read` granular scope for every
+    // surface, so a token granted under it cannot create bills/invoices or
+    // mutate contacts/attachments. Used when an install is (re)connected with
+    // `read_only: true` — e.g. to lock a production-books integration to reads
+    // until per-vendor broker mediation (ENG-4922) gates its writes.
+    readOnlyScopes: [
+      "openid",
+      "profile",
+      "email",
+      "offline_access",
+      "accounting.settings.read",
+      "accounting.contacts.read",
+      "accounting.invoices.read",
+      "accounting.attachments.read",
+      "accounting.payments.read",
+      "accounting.banktransactions.read",
+      "accounting.manualjournals.read",
+      "accounting.reports.balancesheet.read",
+      "accounting.reports.profitandloss.read",
+      "accounting.reports.trialbalance.read",
+      "accounting.reports.budgetsummary.read",
+      "accounting.reports.banksummary.read",
+      "accounting.reports.executivesummary.read",
+      "accounting.reports.aged.read"
+    ],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "basic",
+    userInfoUrl: "https://api.xero.com/connections"
+  },
+  // LinkedIn Ads (Marketing API). Confidential client with a static secret and
+  // refresh tokens (~60-day access token, ~1-year rotating refresh token), so it
+  // mirrors the Xero shape: clientAuthMethod 'body', supportsRefresh true, no
+  // PKCE. The shared authorize/callback/refresh machinery handles the rest.
+  //
+  // The single shared app is Augmented Team's own LinkedIn developer app
+  // (client id/secret in OAUTH_LINKEDIN_ADS_CLIENT_ID / _SECRET) - every org
+  // connects its own ad accounts against it; only the per-connection tokens
+  // differ. Register `${API_PUBLIC_URL}/integrations/oauth/callback` as an
+  // Authorized redirect URL on the LinkedIn app.
+  //
+  // NOTE (linkedin-verify): the grantable scope set depends on which LinkedIn
+  // API products the app is approved for (Advertising API, Lead Sync API,
+  // Community Management API). Keep this list to scopes the app actually holds -
+  // requesting an ungranted scope makes LinkedIn reject the authorize request.
+  "linkedin-ads": {
+    definitionId: "linkedin-ads",
+    authorizeUrl: "https://www.linkedin.com/oauth/v2/authorization",
+    tokenUrl: "https://www.linkedin.com/oauth/v2/accessToken",
+    // ENG-7897: this list is EXACTLY the Advertising API scope set, because
+    // Advertising API is the only product added to the Brand Ninja app. Every
+    // other scope we used to request here belonged to a product the app does
+    // not hold, and LinkedIn rejects the ENTIRE authorize request with
+    // `unauthorized_scope_error` if ANY single requested scope is ungranted -
+    // so five unapproved scopes bricked the connect for every customer, on
+    // every environment, rather than merely disabling five features.
+    //
+    // Scopes deliberately NOT requested, and the product each needs first:
+    //   openid / profile / email        -> Sign In with LinkedIn (OpenID Connect)
+    //   r_organization_social           -> Community Management API
+    //   r_marketing_leadgen_automation  -> Lead Sync API
+    //
+    // Dropping the OIDC trio costs only the `Connected as <name>` label: the
+    // userInfoUrl fetch in the callback is already best-effort and falls back
+    // to a plain 'Connected'. Do NOT re-add any of these until the matching
+    // product shows under "Added products" on the app - use the
+    // OAUTH_LINKEDIN_ADS_SCOPES override below to widen without a deploy once
+    // an approval lands, and only then promote it into this constant.
+    defaultScopes: [
+      // Advertising API: read + manage campaigns/creatives, and reporting.
+      "r_ads",
+      "rw_ads",
+      "r_ads_reporting"
+    ],
+    // Read-only variant: reporting only, no campaign/creative mutation. Used
+    // when an install is (re)connected with read_only: true. Same product
+    // constraint as above - `r_organization_social` was removed with it.
+    readOnlyScopes: [
+      "r_ads",
+      "r_ads_reporting"
+    ],
+    supportsRefresh: true,
+    extraAuthorizeParams: {},
+    clientAuthMethod: "body",
+    userInfoUrl: "https://api.linkedin.com/v2/userinfo"
+  }
+};
+OAUTH_PROVIDERS["xero-control-plane"] = {
+  ...OAUTH_PROVIDERS["xero"]
+};
+
 // ../core/dist/integrations/composio-account-probe.js
 var BODY_MAX_BYTES = 1024 * 1024;