core

Layerline Core

This is the base context for the Layerline MCP server (layerline-mcp-server). Every other layerline-* skill assumes you've internalised the rules here.

The tool namespace

Every Layerline MCP tool is exposed as mcp__layerline__<tool_name>. There are about 150 of them, grouped by domain:

• Orgs/projects/members — covered here
• Assets — see layerline:assets
• Tasks/milestones/time — see layerline:tasks
• Reviews — see layerline:reviews
• Storage (files/versions/locks/shares/file boxes) — see layerline:storage
• GenStudio (AI generation/styles/moodboards/GDDs) — see layerline:genstudio

Don't memorise the full list — when you need a tool, scan the relevant domain skill, then call. Tool names use snake_case (list_projects), not camelCase.

How auth and org resolution work

The MCP server accepts two auth methods, and they affect every call:

1. Org-scoped API key — the org id is baked into the token. Tools accept organizationId (or orgId) as optional; if you pass nothing, the server resolves it from the token.
2. Personal JWT — no org binding. You must pass organizationId / orgId explicitly on tools that need it.

The server uses a helper called resolveOrgId that prefers the token's org and falls back to the param. It throws if neither is set.

What this means for you:

• If a user's previous calls in this session worked without an organizationId, they're on an API key — stop asking for it.
• If a tool errors with "organizationId is required — either use an org-scoped API key or pass organizationId as a parameter", call list_organizations and pick the right one.

Resolving IDs without bothering the user

The user almost never knows a UUID. Resolve IDs from names yourself using the read tools, then call the action tool. The standard pattern:

Need	Resolve via
orgId	list_organizations → match by name
projectId	list_projects(orgId) → match by name
userId for an assignee	get_org_members(orgId) or get_project_members(projectId) → match by email/name
statusId for a task	get_project_statuses(projectId) → match by status name
statusId for an asset	get_asset_statuses(projectId) → match by name
assetId from name	list_assets(projectId) → match
taskId from title	list_tasks(projectId, search: "...")
milestoneId from name	list_milestones(projectId)
reviewId	list_reviews(projectId, ...)
File fileId from path	ls_find_file_by_path(projectId, path)

When multiple matches exist, prefer the most recently updated one and tell the user what you picked. Don't show UUIDs to the user — refer to entities by name.

Org and project tools

list_organizations()
get_organization(orgId?)
update_organization(orgId?, name?, description?, logo_url?)

get_org_members(orgId?)
invite_org_member(orgId?, email, role)        // role: admin | producer | member | external
update_org_member_role(orgId?, targetUserId, role)
remove_org_member(orgId?, targetUserId)
get_pending_join_requests(orgId?)
review_join_request(orgId?, requestId, status)  // approved | rejected

list_projects(orgId?)
get_project(projectId)
create_project(orgId?, name, code?, description?, base_path?, project_type?, software?)
update_project(projectId, name?, description?, ...)
archive_project(projectId)

get_project_members(projectId)
add_project_member(projectId, userId, role)        // viewer | member | editor | admin
update_project_member_role(projectId, targetUserId, role)
remove_project_member(projectId, targetUserId)

get_project_statuses(projectId)                    // task statuses (Backlog, To Do, …)
create_project_status(projectId, name, color?, sort_order?, is_default?, is_done?)
update_project_status(statusId, ...)
delete_project_status(statusId)

get_dashboard_stats(orgId?)                        // per-project task/member/milestone/asset counts
get_project_stats(projectId)
get_project_activity_feed(projectId, limit?)

get_online_members(orgId?)

Project types

gamedev | animation | archviz | film_vfx | marketing | other. Pick from the user's description; default to gamedev for game-asset workflows.

Project codes

Codes are 2–10 uppercase chars (e.g. MGP). If the user doesn't supply one, omit it — the API auto-generates one from the name.

Roles, briefly

• Org roles: admin, producer, member, external. Owner is an implicit role on the org creator.
• Project roles: viewer, member, editor, admin. Org owners/admins automatically have access to every project.
• External users see only assets linked to tasks they're assigned to. Don't be surprised by short asset lists.

Notifications and presence

list_notifications(organizationId?, unreadOnly?, limit?, offset?)
get_notification_count(organizationId?)
mark_notification_read(notificationIds[])
mark_all_notifications_read(organizationId?)
delete_notification(notificationId)

get_online_members(orgId?)

Useful when the user asks "who's online?" or "what did I miss?".

Hard-won rules

• Don't paste UUIDs back to the user. Refer to things by name. UUIDs in chat are visual noise.
• Don't pass nil/zero/empty UUIDs as defaults. When a field is optional, OMIT it. The API rejects malformed UUIDs.
• Date formats: ISO 8601 (2026-03-15 for dates, full timestamp like 2026-03-04T09:00:00Z for times).
• Permission errors are real. If you get 403, the user genuinely lacks the permission — don't retry, surface the role gap clearly ("you're a viewer on this project; ask an admin to make you an editor").
• Default org for testing in this repo: Bitvoke (d429ba94-1b02-4507-a232-8f82d121aaa3) — if the user has multiple orgs and is testing locally, this is the one.