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 withsearch_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
Withagent: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 internaldeployment 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 abranchId. 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.
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.
- 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