mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
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 <noreply@anthropic.com>
This commit is contained in:
Michael Dieringer
parent
cda922b690
commit
169a25f379
1 changed files with 55 additions and 6 deletions
|
|
@ -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_<Entity>_PAG<id>` (read),
|
||||
|
|
@ -97,8 +97,10 @@ the tool by name directly, matching the convention `List_<Entity>_PAG<id>` (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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue