Reference for governed MCP surfaces in AI Fabrix — Enterprise Knowledge capability tools, Role Assistant MCP packaging, enterprise capability keys, and multi-datasource selection after publish.
Architecture strength: one MCP pattern
AI Fabrix does not invent a private protocol for Role Assistants and a different one for Enterprise Knowledge. When you upload / promote a Role Assistant package, the platform compiles an MCP server for that Role Assistant system with the same publish machinery that produces Enterprise MCP for certified Connected Systems and Enterprise Knowledge: capability keys, Operational Trust, and the capability gateway.
That is the architecture signal: Role Assistants are not a side stack with a custom tool protocol. They are first-class systems on the same MCP / REST / CIP path.
Connected Systems / Business Entities / Role Assistant packages
→ certify + expose + upload (or Role Assistant promote)
→ COM / publish compile
→ Layer A Enterprise MCP + Layer B runtime-orchestration MCP + Role Assistant system MCP
→ same gateway + fail-closed trust
| Surface | What it is | Who connects |
|---|---|---|
| Enterprise MCP (Layer A) | Compiled business-capability and context tools from certified Enterprise Knowledge / Connected Systems | Role Assistants (usually in-process Python), external MCP clients |
| Runtime Orchestration MCP (Layer B) | Portal MCP on system key runtime-orchestration — universal Work tools (work.*, human.respond, …) |
ChatGPT and other external agents, channels, Work Portal — see Runtime Orchestration MCP |
| Role Assistant MCP | MCP compiled for the Role Assistant’s own systemKey when the package deploys — same generation and governance model |
External MCP clients, contract/E2E tests, tools that attach to that role system |
Inside the dataplane, Role Assistants often call the same Python implementation without an HTTP loopback; MCP and REST remain adapters over that surface. External AI still uses the governed Enterprise MCP Work tools for conversation-state work — see External AI and Enterprise MCP. Runtime admission: Role Assistant Runtime.
Source of truth
| Source | Path / command |
|---|---|
| Published Enterprise MCP surface | Dataplane after aifabrix upload <systemKey> |
| Role Assistant package / MCP | role-assistant/<roleKey>/ upload/promote (--env) — compiles MCP for that Role Assistant systemKey |
| Datasource exposure | exposed block in the external-datasource schema |
| Live Connected System tool list | aifabrix show <systemKey> --online |
| Concept narrative | Enterprise MCP (pillar) |
| Builder certification | Certification |
Dataplane knowledgebase articles describe datasource selector behavior and capability metadata — verify against your deployed version when debugging tool lists.
Concepts
| Concept | Meaning |
|---|---|
| Enterprise capability key | Deduplicated business action id (e.g. customer.list, deal.reviewPipeline) |
| MCP tool | One tool per enterprise capability key (or governed work tool) on a published MCP surface |
| Enterprise MCP | Knowledge/capability catalog compiled from certified integrations (Layer A) |
| Runtime Orchestration MCP | Portal MCP on runtime-orchestration — universal Work tools for external AI (Layer B) |
| Role Assistant MCP | MCP for a Role Assistant systemKey after package upload — same compile path as Enterprise MCP |
| Datasource selector | When multiple child datasources share a resourceType, callers pass datasource to choose execution target |
| Exposure | Controlled by datasource exposed config and upload/compile pipeline |
| Business metadata | Tool inputs/outputs use field mappings — not raw vendor field names |
MCP never exposes raw vendor URLs, API keys, or unconstrained REST paths to AI clients. Capability admission remains fail-closed under Operational Trust and the capability gateway — for Enterprise MCP and Role Assistant MCP alike.
Publish and verify (Connected Systems → Enterprise MCP)
aifabrix repair <systemKey> --expose
aifabrix validate <systemKey>
aifabrix upload <systemKey> --probe
aifabrix upload <systemKey>
aifabrix show <systemKey> --online
Then test execution:
aifabrix test-e2e <systemKey>
aifabrix datasource test-e2e <datasourceKey> --app <systemKey>
Role Assistant packages use the Role Assistant validate/upload path for their environment — confirm live tools after promote; do not assume local package JSON equals the online MCP server.
Multi-datasource selector
When Enterprise MCP combines two or more child datasources for the same resourceType and capability, request schemas include a first-level datasource input so callers explicitly choose the child to execute.
Integrators document which datasource keys apply for each resource type in field mappings and capability design — see Governed capabilities.
OpenAPI REST parity
REST routes published alongside MCP use the same compiled enterprise capability keys. Application clients, Role Assistants, and MCP clients share governance and certification scope. MCP and REST are adapters over one implementation — not parallel product stacks.
Limits
Published MCP tool names and selector behavior depend on your uploaded integration set, Role Assistant package, and dataplane version. Always verify with show --online (Connected Systems) or the live Role Assistant MCP endpoint after deploy — do not assume local JSON matches published tools.