For the complete documentation index, see llms.txt. This page is also available as Markdown.

Overview

The technical shape of Kula Intelligence — a remote MCP server over per-studio Postgres, with OAuth and a curated tool surface.

Kula Intelligence is a remote MCP server. AI clients connect to it, authenticate, and call a curated set of tools that read and (where permitted) write a single studio's operational data.

This section is for developers and integrators — agencies building on the Claude API, technical staff wiring up Claude Code, or anyone who wants the detail under the owner-facing guides.

The shape

  • No anonymous access. Every connection carries a role-scoped credential created in app.kula.digital — a connect link (/connect/{…}/mcp, OAuth) for Claude, or an access token (bearer) for other clients. Served over streamable HTTP.

  • One studio per connect link. Every request is authenticated, and the credential identifies exactly one studio. Tenancy is enforced by a database boundary — each studio's data lives in its own Postgres database, and there is no cross-studio read path. The studio is derived from the credential, never from a tool argument.

  • A curated tool surface, not raw database access. Clients don't run arbitrary SQL against the engine. They call purpose-built tools (list_tables, execute_query for read-only SELECTs, entity_lookup, get_member_plan_status, and so on). Reads are scope-gated; writes go only through guarded, audited tools. See the tool reference.

  • Skills as prompts. The skill library is surfaced as MCP prompts, so curated playbooks work in any compliant client.

Authentication, in one line

There is no open, anonymous access — every client connects with a role-scoped credential created in app.kula.digital, and which kind depends on the client:

  • Connect link (OAuth) for clients with a custom-connector flow (Claude): https://mcp.kula.digital/connect/{…}/mcp; using it runs the OAuth handshake (discovery, registration, PKCE, sign-in, consent — see OAuth).

  • Access token (bearer) for other clients: minted in app.kula.digital and presented as Authorization: Bearer <token> against https://mcp.kula.digital/mcp. See Connect.

Either way the credential carries its permission level; the runtime verifies it, derives the studio and level, and routes to that studio's database.

What it deliberately doesn't do

  • No money movement, refunds, or transfers.

  • No AI media generation.

  • No cross-studio reads — not even for analytics.

  • No arbitrary DML/DDL. execute_query is SELECT/WITH-only; mutations go through specific, audited tools.

Where to go next

Last updated

Was this helpful?