Protocols and platforms
REST and MCP share the runtime. Distribution profiles reuse canonical business semantics.
REST boundary
The REST adapter is an HTTP-framework-neutral execution projection:
POST /v0alpha1/capabilities/{capability}/execute
{
"input": {},
"preconditions": {}
}Protocol metadata uses X-Brivya-Capability-Version, X-Request-Id, X-Correlation-Id, X-Causation-Id and Idempotency-Key headers. The body cannot assert trusted identity or approval state.
The hosting HTTP layer verifies authentication or session state and supplies a trusted RestSecurityContext. The adapter constructs an ActionRequest and calls BusinessRuntime.
MCP projection
The capability order.create@0.1.0 becomes the tool brivya.order.create.v0.1.0. Input and output JSON Schemas pass through to the MCP SDK.
The hosting transport/auth layer supplies a trusted McpContextResolver for verified identity, delegation, approvals and correlation metadata. Tool arguments are business input only. MCP annotations are hints, not authorization.
WorkBuddy and WeChat AI
| Reference projection | Output |
|---|---|
| WorkBuddy | connector-meta.json, mcp.json, skills/business/SKILL.md |
| WeChat AI | SKILL.md, mcp.json, runtime-bridge.json, components and registration patch |
These are reference generators and conformance baselines. Production publication still requires current official platform requirements, qualification and review. Third-party fields and APIs are not guaranteed stable.
Before integration
- Preserve schemas, risk and permission requirements.
- Keep canonical approval requirements for high-risk actions.
- Preserve idempotency and audit across protocols.
- Never elevate client identity or UI confirmation into trusted authorization evidence.
SemanticExperience describes shared interactions; platform renderers provide native presentation while actions remain bound to canonical Capability IDs.
Based on the public Alpha implementation · View source ↗