From 169a25f379e53a406e0c8c85fa53a853c54e413a Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Mon, 17 Aug 2026 08:16:53 +0200 Subject: [PATCH] bc-mcp.agent.md v4: document customers + QA test-iteration tools Live tool audit found the businesscentral MCP server exposes 19 tools, 4 undocumented: List_Customers_PAG50045 and the List/Create/Modify_TestIteration_PAG6102911 trio. Michael confirmed both are wanted: - customers (PAG50045): read-only, restricted in practice to `no` + `microsoftTenantId` even though the schema also exposes `name`/ `tenantCompanyName` (CURABIS-BCMCP-010). - testIterations (PAG6102911): activates the QA test-iteration flow designed 2026-08-09 (Ready for Test trigger, Robert/Linh manual testing on top of automated tests, defect dedup by shared root cause). Dedup grouping must come from a separate fresh-context agent, never the implementing agent grading its own defect count (CURABIS-BCMCP-009). Also resolves the open question from the 2026-08-09 design: the older CUR Sub Task informal bug-tracking fields (Error type / Error related to task) are a dead pattern at CURABIS and are not being unified with the new table. Corrected a stale tool-count claim (14 -> 19) along the way. Co-Authored-By: Claude Sonnet 5 --- custom/setup/templates/bc-mcp.agent.md | 61 +++++++++++++++++++++++--- 1 file changed, 55 insertions(+), 6 deletions(-) diff --git a/custom/setup/templates/bc-mcp.agent.md b/custom/setup/templates/bc-mcp.agent.md index a6482d2..b449759 100644 --- a/custom/setup/templates/bc-mcp.agent.md +++ b/custom/setup/templates/bc-mcp.agent.md @@ -1,17 +1,17 @@ --- kind: action-skill id: curabis-bc-mcp -version: 3 +version: 4 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. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 14 directly-named tools replace the old search/describe/invoke indirection. v3 (2026-08-03) - task-comment state checkpoints for resumability across machine/operator changes. -inputs: [project-no, task-no, branch, dev-status, comment] -outputs: [task-list, updated-task, posted-comment] +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. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 15 directly-named tools replace the old search/describe/invoke indirection. v3 (2026-08-03) - task-comment state checkpoints for resumability across machine/operator changes. v4 (2026-08-17) - customers (PAG50045) and QA test-iteration tracking (PAG6102911) added; server now exposes 19 tools. +inputs: [project-no, task-no, branch, dev-status, comment, test-iteration] +outputs: [task-list, updated-task, posted-comment, posted-test-iteration] 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] +keywords: [mcp, business-central, project, subtask, github, branch, dev-status, comment, triage, sync, qa, test-iteration, customers] --- # CURABIS Business Central MCP usage @@ -82,7 +82,7 @@ not setup. Load only what the task needs — see the table below for the full se ## Tools (BC MCP, Static Tool Mode) -The `businesscentral` MCP server exposes **14 directly-named tools**, one per +The `businesscentral` MCP server exposes **19 directly-named tools**, one per BC action, each with its own typed schema reflecting exactly which fields that page allows you to write. No discovery step, no per-call reverification — call the tool by name directly, matching the convention `List__PAG` (read), @@ -97,8 +97,10 @@ the tool by name directly, matching the convention `List__PAG` (read | newTasks (6102905) | `List_NewTasks_PAG6102905`, `Create_NewTask_PAG6102905` | create new task | `status` — always Created on insert, never change it | | taskComments (6102902) | `List_TaskComments_PAG6102902`, `Create_TaskComment_PAG6102902`, `Modify_TaskComment_PAG6102902` | create a comment, edit `comment`/`date`/`lineType` | delete | | consultants (PAG50009) | `List_Consultants_PAG50009` | **read-only** | any write; no Modify/Create tool exists | +| customers (PAG50045) | `List_Customers_PAG50045` | **read-only** | any write; no Modify/Create tool exists. Schema also exposes `name`/`tenantCompanyName`, but company policy is to surface only `no` + `microsoftTenantId` — don't select or print the other two | | projectAIScores (6102906) | `List_ProjectAIScores_PAG6102906`, `Create_ProjectAIScore_PAG6102906` | **Edison only** — insert one score entry per eval iteration | modify, delete (immutable posting table — no such tool exists); any other agent inserting here | | projectWeberScores (6102908) | `List_ProjectWeberScores_PAG6102908`, `Create_ProjectWeberScore_PAG6102908` | **Weber only** — insert one classification per sub-task coached | modify, delete (immutable posting table — no such tool exists); any other agent inserting here | +| testIterations (6102911) | `List_TestIterations_PAG6102911`, `Create_TestIteration_PAG6102911`, `Modify_TestIteration_PAG6102911` | insert one row per QA iteration (see "QA test-iteration workflow" below) | grade/dedupe your own defect count if you were the implementing agent; edit `entryNo`/`iterationNo` | `consultants` was previously documented here as `users (6102903)` — that entity does not exist in the BC MCP action catalog under any name. The real page is `List_Consultants_PAG50009` @@ -161,6 +163,46 @@ Follow ALL steps — do not skip any: The `gitHubRepository` on a project is set via `projectRepositories` (PAG6102904) — the agent may write it. Never write it on the projects page (PAG6102901). +## QA test-iteration workflow (PAG6102911) + +Built 2026-08-09 in ProjectMgmt365app to give the dev↔QA test loop the same kind of +signal-ratio measurement Edison already gives BCQuality rules. Robert and Linh +(Support+Test) test manually on top of the automated suite; this is where their +findings get recorded so the loop is measured, not vibes. + +1. **Trigger.** The one hard trigger a QA iteration hangs off is `gitHubDevStatus` + moving to `Ready for Test` on `activeTasks` — chosen specifically so developer-side + testing (inherent to coding) and tester-side testing (the measured checkpoint) never + need a case-by-case judgment call. +2. **Testing happens.** Robert/Linh execute manual scenarios against the task. Any bug + found becomes a new Claude-authored **failing test** (TDD red) — the implementing + session does not auto-fix it in the same breath; that stays a deliberate separate step. +3. **Dedup the defects — never by the implementer.** Group found defects by shared root + cause (three failing tests from one changed function = one defect), not raw + failing-test count — raw count punishes testers for writing more scenarios. The + grouping proposal must come from a **separate agent with fresh context**, working from + the diff/call-graph (code-causality), and Robert/Linh confirm scenario-equivalence + (do the fixes still feel like one user-facing problem). The agent that implemented the + fix must never grade its own defect count — same self-scoring conflict Edison's + read-only design avoids elsewhere. See CURABIS-BCMCP-009. +4. **Post the iteration.** Call `Create_TestIteration_PAG6102911` with `projectNo`, + `taskNo`, `readyForTestDateTime`, `testedBy`, `testCompletedDateTime`, + `defectsFoundRaw`, `defectsFoundDeduped`, `dependencyEvidence` (the causality + reasoning from step 3), `result` (`Passed`/`Failed`). `iterationNo`/`entryNo` are + server-computed (`GetNextLineNo` pattern, mirrors `Create_TaskComment_PAG6102902`) — + never set them yourself. +5. **Don't conflate iteration sequences.** `testIterations.iterationNo` counts QA + round-trips. `projectAIScores.iterationNo` (PAG6102906) counts AI hill-climbing + attempts. They are deliberately separate counters on separate tables — a task can be + on AI-score iteration 4 and QA iteration 1 at the same time. + +**Dead pattern — do not resurrect:** `CUR Sub Task` (307) also has an older, informal +bug-tracking pattern (`Error type` = QA-Environment/Customer test/Live Database, `Error +related to task`, FlowField counts). It covers **post-delivery** bugs, a different scope +from this pre-klarmelding dev↔QA loop, and per Michael (2026-08-17) CURABIS never +actually uses it. Don't propose unifying the two — there's nothing live on the other side +to unify with. + ## Developer identity (under S2S) Because the MCP runs as `BC_DevelopmentMCP`, BC cannot see which developer is working. @@ -199,3 +241,10 @@ CURABIS-BCMCP-004 Read is safe, write is deliberate. Reading tasks/projects/comm 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. +CURABIS-BCMCP-009 The agent/session that implemented a fix must never grade or dedupe its + own defect count when posting to `testIterations` (PAG6102911). The code-causality + grouping must come from a separate, fresh-context agent; testers confirm + scenario-equivalence before `Create_TestIteration_PAG6102911` is called. +CURABIS-BCMCP-010 `customers` (PAG50045) is read-only and even though the schema exposes + `name`/`tenantCompanyName`, only ever select/surface `no` + `microsoftTenantId` — never + print or log the other two fields.