Modes and Profiles
The runtime distinguishes between a broad discover view and curated, profile-specific views.
discover
discover exposes every normalized tool in the catalog, subject to execution-time policy such as managed deny rules and approval checks.
Use this when you want:
- maximum visibility into the API surface
- exploratory development
- schema inspection before curation is finalized
curated
curated narrows the visible tool set to the tool set selected by an agent profile.
A common pattern is:
{
"mode": { "default": "curated" },
"curation": {
"toolSets": {
"support": {
"allow": [
"tickets:listTickets",
"tickets:getTicket",
"tickets:createTicket"
],
"deny": ["**"]
}
}
},
"agents": {
"profiles": {
"support": {
"mode": "curated",
"toolSet": "support"
}
},
"defaultProfile": "support"
}
}
In the current implementation, allow + deny: ["**"] is the easiest way to express an allowlist.
How the runtime chooses a view
The selection rules are slightly different for catalog viewing and policy checks, but they lead to the same practical guidance.
Effective catalog selection
When building the view returned by GET /v1/catalog/effective:
- if
agentProfileis explicitly provided and exists, use that profile's effective view - otherwise, if no explicit mode was provided, start from
mode.default - if the resulting mode is
curatedandagents.defaultProfileexists, use that profile's view - otherwise, use the
discoverview
Policy selection
When deciding whether execution is allowed:
- start with the explicit
mode, or fall back tomode.default - if an explicit
agentProfileexists and that profile has its ownmode, the profile mode wins - the explicit profile's tool set is used when present
- otherwise, if the resulting mode is
curated, the default profile's tool set is used
Important nuance: explicit profile beats explicit mode
If you supply --agent-profile support, the support profile effectively decides the view even if you also pass --mode discover.
That is current implementation behavior, not just documentation guidance.
Pattern matching rules
Tool set patterns use Go's path.Match behavior plus one implementation-specific shortcut:
*and?behave likepath.Match**is treated as "match everything"- if
denycontains**andallowis non-empty, the**deny is skipped so the allowlist can still work
Discoverability vs enforcement
Remember the separation:
- the selected view controls which dynamic commands
oclirenders - execution-time policy still runs inside the runtime
So a tool can be hidden from the CLI tree, inspected by ID, or rejected at execution time depending on the combination of view and policy.