Skip to main content
When you connect Claude Code, you authorize the connection in your browser and pick two things: an organization role for it to act as, and Read only or Read & write access. Which tools Claude gets follows that role and access level, not your own role on the app or any agent-profile default. You can only pick roles you’re allowed to assign yourself, and you can change the role or access level later from Settings → AI Integrations without re-authorizing. See Members & Roles. The connection covers every app in the organization. Tools that act on an app take its slug or id on each call, so name the app you mean and Claude passes it along. This page covers the tools you’ll use while developing an app locally. AI Integrations → Tools & Permissions has the full reference, including tool groups outside app development.

What the role unlocks

Both gates must pass. Read & write doesn’t add write tools if the role lacks the matching permission, and a role with write permissions stays read-only on a Read only connection.

How tools appear

A few common tools, such as data-store reads, app discovery, cross-app calls, and skills, appear directly in Claude’s tool list. Every other tool the role allows is in Stardeck’s tool catalog: Claude finds it with search_stardeck_tools and runs it with execute_stardeck_read_tool or execute_stardeck_write_tool. Claude Code does this on its own; if a tool seems missing, ask Claude to search the Stardeck catalog for it. See How tools are disclosed.

The tool groups

Project tasks

Read and manage an app’s task list, the same persistent work items you see on the project dashboard. Claude can list tasks (list_project_tasks), and on a Read & write connection create, update, and remove them.

Project memory

Read and write an app’s persistent memory: notes and context that survive across sessions, scoped to that app (list_project_memory, read_project_memory, write_project_memory).

Data store

List the data stores the role can access, inspect their schema, run queries, and generate TypeScript types from a store’s live schema (generateDataStoreTypes) so the types in your checkout match the real database. With agent:data-store:write and Read & write access, Claude also gets write tools: schema changes, data mutations, and creating a data-store branch (an independent copy of the store’s tables and rows; see Branches and environment routing) to experiment without touching another branch’s data. Each store also has its own access settings, so a role can only reach stores it has a grant for.

Cross-app

Call endpoints on your other apps through the platform’s cross-app communication. A Read only connection can make GET calls; non-GET calls need Read & write.

Blueprint updates

With agent:repos:write on a Read & write connection, Claude can check whether a Blueprint-derived app has a newer published version (get_blueprint_update) and record a completed merge (complete_blueprint_update). The tools prepare an exact fetch ref, walk through a local git merge, and verify the result on the server before updating the baseline. The app must have agent development enabled, which it is by default. See Update from a Blueprint for the end-to-end workflow.

Modules

With the same access, Claude can turn an app’s Modules on or off (set_module_enabled) and install or update a published Module from another app in your org (install_module). The install is pushed to main; pull it, then apply the integration steps the tool returns. A connection bound to the Admin role can also detach a Module from its Blueprint (detach_module), or detach the whole app from its Blueprint in one step (detach_app, which shows a dry run first). Both are permanent.

Skills

Discover Stardeck skills, focused guides for building on the platform (listStardeckSkills, loadStardeckSkill). Claude can load design skills (UI, dashboards, i18n, and more) as content directly, and for SDK skills (auth, email, payments, data store, …) it gets a pointer to read that package’s SKILL.md from your checkout’s node_modules. Available with agent:skills:execute.

App roles & permissions

Read and configure an app’s roles and permissions model: app permissions, app roles, role-permission assignments, default sign-up role, team member access policy, and which app permissions each organization role holds for the app. In the tool schema, app role and team member map to the internal deployment role and organization member names. Reads need agent:deployment-auth:read; writes also need agent:deployment-auth:write and Read & write access.
SDK skill pointers only resolve once the @stardeck-customer-apps/* packages are installed in node_modules. Those packages come from GitHub Packages, which requires a token to install — see Installing dependencies.

Branches and production data

Data store tools act on the store’s default database unless you pass a branchId. That is usually the database production runs on, and it is not necessarily the branch your local app reads: get_project_dev_env gives your app the sandbox environment. To change the data your local app sees, find its branch (listDataStoreBranches, or the branch note get_project_dev_env returns when a store is pointed at a branch) and pass that branchId to the schema, row, and type-generation tools.
Treat write access carefully. A write without a branchId goes to the store’s default database, which is usually production. Prefer a least-privilege role and Read only access, and only authorize Read & write when you need to change data.

Security model

The connection has two independent gates:
  • Who can connect — the person authorizing must be a member of the organization and pick it during authorization. A token issued for one organization can’t reach another organization’s apps.
  • What Claude can do — the role and access level picked at authorization. The token decides who connects; the role decides what they can do once connected. The role is checked on every request, so if it’s removed or you leave the organization, access stops.
On top of that:
  • Nothing connects until you authorize — no tool reaches your organization until a member completes the browser authorization.
  • No stored secret — authorization happens in your browser; your MCP config holds only the public server URL.
  • Revocable — revoke a connection from Settings → AI Integrations; it stops working on its next request.
  • Audited — every tool call is logged and tagged so it’s distinguishable from in-product agent activity.
  • Client-side prompts — Claude Code’s own permission prompts add a final confirmation before tools run on your machine.

Next steps

Connect Claude Code

Authorize the org connection and connect your local Claude Code

Members & Roles

Create and configure the roles a connection can act as

Data Stores

How your app’s data stores work

Cross-App Communication

How your apps call each other’s endpoints