--- kind: action-skill id: curabis-bc-mcp version: 1 title: CURABIS Business Central MCP usage description: How to use the CURABIS Business Central MCP server to read project-management work from BC and write GitHub dev status back. Company-default workflow for syncing Claude Code / GitHub work with BC tasks. inputs: [project-no, task-no, branch, dev-status, comment] outputs: [task-list, updated-task, posted-comment] bc-version: [all] technologies: [al, mcp] countries: [w1] application-area: [all] domain: integration keywords: [mcp, business-central, project, subtask, github, branch, dev-status, comment, triage, sync] --- # CURABIS Business Central MCP usage CURABIS runs its development work out of the **Project Management 365 App** in Business Central. This MCP server lets an agent read the active projects and sub-tasks assigned in BC, and write the GitHub side (repo, branch, dev status, status comments) back onto them - so BC always reflects what is actually happening in the code. This is the **company-default** way to connect dev work to BC. It is invoked on demand: when the user references a BC task/project, asks "what am I working on", or wants to record branch / status / a note back to BC. ## Connection - Server: `businesscentral` - a local stdio bridge (`Scripts/bc-mcp-bridge.js`) that talks to the BC MCP endpoint `https://mcp.businesscentral.dynamics.com`. - Auth is **service-to-service**: every call runs as the app identity `BC_DevelopmentMCP`, **not** as the individual developer. The BC audit trail shows the app, not the person - so attribute work to a developer yourself (see "Developer identity" below). - If the server is not connected, say so and stop. Do not invent task data. ## Tools (BC MCP, Dynamic Tool Mode OFF) Tool names follow `List_PAG` (read), `ListUpdate_PAG` (modify), `Create_PAG` (create). Confirm exact names from the server's tool list. | Entity (page) | Read | Write you MAY do | Never | | --- | --- | --- | --- | | projects (6102901) | active projects, `Status = Started` | **read-only for the agent** | any field — humans manage projects | | projectRepositories (6102904) | project + gitHubRepository | `gitHubRepository` | all other fields | | activeTasks (6102900) | active sub-tasks, `Accepted` / `In progress` | `gitHubDevStatus`, `gitHubBranch` | other fields, create, delete | | newTasks (6102905) | pending sub-tasks, `Created` (awaiting customer approval) | create new task | `status` — always Created on insert, never change it | | taskComments (6102902) | comment lines for a task | create a comment, edit `comment`/`date`/`lineType` | delete | | users (6102903) | project-mgmt users: `userId` (login email), `name`, `employeeCode` | **read-only** | any write | `gitHubDevStatus` uses enum **CUR GitHub Dev Status**: `Backlog`, `In Progress`, `Done`, `On Hold` (developer/Claude-managed, independent of the BC sub-task `status`). Sub-task `status` values (BC-managed, never written by agent): `Created → Accepted → In progress → Finished → Invoiced`. Moving to `Accepted` requires `Starting date`, `Estimated time` and `Expected Delivery date` — only a BC user can do this. ## Standard workflow 1. **Find the work.** Read `activeTasks` (filter by `projectNo` or `gitHubRepository`). Use `gitHubRepository` on the project to confirm you are in the right repo. 2. **Claim it.** When you start, set `gitHubBranch` to the working branch and `gitHubDevStatus = In Progress` on the task (`ListUpdate activeTasks`). 3. **Record progress.** Post a status note with `Create taskComments` (`projectNo` + `subTaskNo` scope it to one task). Keep notes short and factual. 4. **Finish.** Set `gitHubDevStatus = Done` automatically when branch is merged to main. Set `On Hold` if the branch is parked. ## Create task workflow (PAG6102905) Use `Create_NewTask_PAG6102905` when a developer wants to register a new task from VS Code. Follow ALL steps — do not skip any: 1. **Duplicate check.** Search `activeTasks` and `newTasks` for similar descriptions on the same project. If a match is found, show it and ask the developer to confirm it is truly a new task. 2. **Ask clarifying questions.** Before estimating, ask: What is the expected outcome? What is the scope? Are there dependencies or unknowns? Summarise the answers as line-level comments. 3. **Propose an estimate.** Based on the summary, suggest estimated hours with reasoning. The developer has the final say — their number wins, no argument. 4. **Link to repo.** Set `gitHubRepository` from `git remote get-url origin`. Verify it matches the project's `gitHubRepository` via `projectRepositories`. 5. **Set responsible.** Resolve the developer's `employeeCode` from `users` via `git config user.email`. 6. **Create.** POST to `newTasks` with: `projectNo`, `description`, `taskType`, `taskResponsible`, `estimatedTime`, `startingDate`, `expectedDelivery`, `customerPriority`. Status is always `Created` — the page enforces this. 7. **Inform.** Tell the developer the task is created and awaiting customer approval in BC before work can begin. The `gitHubRepository` on a project is set via `projectRepositories` (PAG6102904) — the agent may write it. Never write it on the projects page (PAG6102901). ## Developer identity (under S2S) Because the MCP runs as `BC_DevelopmentMCP`, BC cannot see which developer is working. Resolve it client-side and map to a BC user: 1. Read the developer's email locally - `git config user.email` (matches their MS Passport / BC login email). 2. Look it up via the `users` tool: match `userId` (login email) -> `employeeCode` + `name`. 3. Use that to scope "my tasks" (filter `activeTasks` by `taskResponsible` = the employee) and to sign status comments (e.g. end with "- ") so attribution survives the shared app identity. If no matching user is found, say so - do not guess whose tasks these are. ## Safety rules CURABIS-BCMCP-001 Write only `gitHubBranch` / `gitHubDevStatus` on active tasks, and task comments. Never write BC sub-task `status` — it controls time registration and invoicing. Never modify any other field, never create/delete projects, never delete tasks or comments. CURABIS-BCMCP-006 Never start a task that is not `Accepted`. Before setting `gitHubDevStatus = In Progress`, verify the task appears in `activeTasks` (Status = Accepted or In progress). A task in `newTasks` (Status = Created) has not been approved — do not begin work on it. CURABIS-BCMCP-007 Follow the full create-task workflow (duplicate check → clarify → estimate → create). Never create a task without completing all steps. The developer's estimate always wins. CURABIS-BCMCP-002 Confirm scope before writing. A write needs an explicit `projectNo` + `taskNo` (and `subTaskNo` for comments). Never bulk-update. CURABIS-BCMCP-003 Match the repo. Before writing dev status/branch, verify the task's `gitHubRepository` matches the repo you are working in. If it does not, stop and ask. CURABIS-BCMCP-004 Read is safe, write is deliberate. Reading tasks/projects/comments is fine unprompted; any write-back must be something the user asked for or clearly intends. CURABIS-BCMCP-005 Don't guess data. If the server is unavailable or a task isn't found, report it - never fabricate task numbers, branches, or statuses.