MCP and Skills
Use this page when you need to understand how Helpifyr exposes agent-visible access without turning MCP or skills into a second source of product, runtime, or contract truth.
When to use this page
- You need to know what MCP may expose and what must stay outside the MCP catalog.
- You are deciding whether a lane is a read-only tool, a guarded action, or only a guidance surface.
- You need to separate capability admission from operator or agent instructions.
Prerequisites
- You have read Agent Capability Plane.
- You want the public-safe boundary between access surfaces and source truth.
Architecture / Flow
Step-by-step procedure
1. Treat MCP as an access layer, not a system of record
In Helpifyr, MCP is how agent-visible surfaces are exposed after review, contract alignment, and promotion gates.
That means:
- MCP does not replace owner repo truth
- merged PR text alone is not enough for MCP admission
- only explicitly promoted surfaces become agent-visible MCP truth
2. Separate surface classes before you expose anything to agents
Fabric classifies new surfaces before they enter the catalog.
Important distinctions are:
- agent-visible MCP surfaces
- owner readback surfaces
- customer runtime surfaces
- identity and security surfaces
- deployment materialization surfaces
- quality or learning surfaces
Only the first class is eligible to become a real agent-visible MCP catalog entry.
3. Treat skills as guided behavior, not as authority
Skills explain how operators or agents should work through a lane. They help with sequencing, scope, and guardrails.
They do not replace:
- owner contracts
- capability admission
- runtime authority
- live verify evidence
4. Keep admission and execution tightly coupled to verify truth
An MCP lane becomes trustworthy only when issue, PR, contract, docs, feature truth, CI, and live verify stay aligned.
If that chain is incomplete:
- the lane must stay blocked, hidden, guarded, or planned-only
- missing truth must not be silently treated as admissible behavior
Verification
This page is being applied correctly when a reader can:
- explain why MCP is an access layer and not the source of record
- distinguish an admitted MCP surface from a non-catalog or blocked surface
- explain why skills guide behavior but do not override contracts, ownership, or live verify requirements
Common failure modes
Treating a merged owner PR as automatic MCP admission
Problem:
- agents or operators assume that once a change is merged it is automatically safe and visible in MCP.
Better path:
- require explicit classification, promotion gates, and catalog truth before calling a lane agent-visible
Treating skills as execution authority
Problem:
- guidance text is read as if it granted permission to mutate systems or bypass owner truth.
Better path:
- use skills for sequencing and guardrails, then follow the admitted runtime or review lane for actual execution