Reviewer guide
For Anthropic connector reviewers — test-account access, every tool with an example prompt, the OAuth round-trip, and the isolation model.
For connector-directory reviewers. Pair this with the internal submission packet at
docs/CONNECTOR_SUBMISSION_PACKET.mdin the repo.
Thanks for reviewing Kula Intelligence. This page gets you from zero to exercising every tool against a fully-populated demo studio.
What this connector is
A remote MCP server that gives an AI client a scoped, audited, read-mostly window onto one boutique fitness studio's operational data (members, attendance, sales, accounting, marketing). One connect link = one studio at one permission level; tenancy is a hard database boundary. It moves no money, generates no media, and never reads across studios. There is no open endpoint — all access is through a role-scoped connect link.
Connect link form:
https://mcp.kula.digital/connect/{…}/mcp(streamable HTTP)OAuth metadata (per link):
https://mcp.kula.digital/.well-known/oauth-protected-resource/connect/{…}/mcpPublic docs:
https://docs.kula.digital
Test account
The Kula team fills in the live values below before submission.
We provide a seeded demo studio ("Anthropic Connector Review") with realistic members, classes, attendance, sales, and accounting so every tool returns real results.
Reviewer connect link: provided with the submission — a role-scoped link of the form
https://mcp.kula.digital/connect/{…}/mcp.Permission level: the demo connect link is scoped to operations (member names, emails, and phone numbers visible; card fragments and payment-provider transaction ids redacted) — enough to exercise the full surface. A full-level link can be provided on request to review redaction behaviour.
Connecting
In Claude (recommended): add the provided connect link (https://mcp.kula.digital/connect/{…}/mcp) as a custom connector (Settings → Connectors → Add custom connector; leave Advanced settings blank). On connect, the client discovers the authorization server, you sign in to the demo account, and consent — then the connector is live. Discovery, dynamic client registration, and PKCE are all implemented — see OAuth. The callback https://claude.ai/api/mcp/auth_callback is registered, and Claude Code loopback redirects are accepted.
Opening the connect link without the trailing /mcp renders the human-facing connect page, which offers an Open in Claude button that pre-fills Claude's Add-custom-connector dialog with the connector name and the same URL. It is a convenience only: it fills in the two fields above and changes nothing about discovery, registration, consent, or scope. The page also shows the URL in full for manual entry.
Other clients: we can instead provide a role-scoped access token for the demo studio, used as Authorization: Bearer <token> against https://mcp.kula.digital/mcp. Either way, access is via a role-scoped credential created in console.kula.digital — there is no anonymous access.
Verify with: "List the tools you can use from Kula Intelligence."
Exercising the tools
These prompts return real data against the demo studio at its operations permission level.
"List the tables you can see and their columns for commerce.sale."
list_tables, get_table_schema
"How many recurring members do we have and how has attendance trended over 12 months?"
execute_query, get_semantic_catalogue
"Which recurring members have open attention signals right now, and what's their plan status?"
get_open_signals, get_member_plan_status
"Who are my top 5 current members?"
execute_query
"Show the relationship context for one of those members."
get_member_context, get_entity_edges
"Who are this member's main coaches, and how concentrated is the studio on its top staff?"
get_member_affinity, get_staff_concentration
"How is our recurring members' connection strength distributed, and which members have the strongest connections?"
get_location_context, list_quadrant_members
"Which coach do the most members rely on, and if they left, which members would lose their strongest connection?"
get_staff_concentration, simulate_departure, get_staff_context
"Look up one of those members by name."
entity_lookup
"Show this studio's business context."
get_business_context
"What skills are available, and what does the at-risk-members skill do?"
list_skills, get_skill
"Save a view of monthly revenue called monthly_revenue."
create_view (write — needs operations)
"Add a note to studio memory: 'reviewer test'."
memory_create (write — needs operations)
"How do I connect Stripe?"
search_docs, get_doc (product docs, no studio data)
These relationship-context tools describe who a member or staff member is connected to and how healthy those connections are — they are not churn predictors. Spotting members who have started dropping off is the job of the attention signals (get_open_signals, the sense layer future Whispers will surface) and the separate at-risk-members skill, both of which read from, but are distinct from, the relationship graph.
The relationship-context tools each take a required purpose that scopes the response — analysis purposes anonymise members, service-delivery purposes withhold the connection-strength analytics, and a denied purpose returns an empty result rather than an error.
The full surface with read-only/destructive flags is in the tool reference. Tools called above your token's permission level return a clear 403 and reveal nothing — try an analytics token against a names tool to see redaction in action.
What you won't be able to do (by design)
Move money, refund, or transfer — there are no such tools.
Generate images/audio/video — no such tools.
Reach another studio's data — tenancy is a physical database boundary, derived from the token, never a parameter.
Run arbitrary writes —
execute_queryisSELECT/WITH-only; mutations go through specific, scope-gated, audited tools.
See Security & data handling for the full posture.
Documentation you may want
Questions during review: support@kula.digital.
Last updated
Was this helpful?