Context
The built-in agent (#626) consumes the unified MCP tool registry (#615) RBAC-filtered — but the Operations profile (#617) only. From agent/registryTools.ts (#1545, in the #1549 stack):
The Application profile (#618) is intentionally out of scope here; it can fold in the same way once per-Resource tool generation is wired for the agent.
The fold-in is promised in that comment but tracked nowhere. This issue tracks it.
Why
Components deployed on an instance can already contribute tools in-process via the registry: auto-generated per-Resource verbs (#618) and curated static mcpTools (#622). Folding the Application profile into the agent's toolset makes those tools available to the built-in agent automatically — no extra transport, and the same per-call enforcement the operations profile already gets (hdb_user set to the configured agent user, verifyPerms at dispatch; listing stays a convenience filter, not the boundary).
Concretely, this makes the agent's tool surface pluggable by deployment: a memory/recall component's store/search tools would let the agent persist and recall findings across sessions with zero agent-specific wiring; the same goes for a docs-search component or org-internal tooling. Combined with agent.systemPromptAppend (#1560), an operator can both mount the tools and tell the agent when to reach for them — entirely with existing machinery.
It also generalizes the pattern behind the hardcoded harper_best_practice tool (#1560), which is extraTools-injected today because no component-contributed path exists.
Design questions
Out of scope (future)
Mounting external MCP servers as agent tool sources (an agent.mcpServers config) — the remote variant of the same idea. In-process components cover the same-instance case without a transport, so that can be weighed separately.
Refs: HarperFast/harper-pro#676, #615, #617, #618, #622, #1545, #1560, #1579.
🤖 Posted by Claude on behalf of @heskew
Context
The built-in agent (#626) consumes the unified MCP tool registry (#615) RBAC-filtered — but the Operations profile (#617) only. From
agent/registryTools.ts(#1545, in the #1549 stack):The fold-in is promised in that comment but tracked nowhere. This issue tracks it.
Why
Components deployed on an instance can already contribute tools in-process via the registry: auto-generated per-Resource verbs (#618) and curated
static mcpTools(#622). Folding the Application profile into the agent's toolset makes those tools available to the built-in agent automatically — no extra transport, and the same per-call enforcement the operations profile already gets (hdb_userset to the configured agent user,verifyPermsat dispatch; listing stays a convenience filter, not the boundary).Concretely, this makes the agent's tool surface pluggable by deployment: a memory/recall component's
store/searchtools would let the agent persist and recall findings across sessions with zero agent-specific wiring; the same goes for a docs-search component or org-internal tooling. Combined withagent.systemPromptAppend(#1560), an operator can both mount the tools and tell the agent when to reach for them — entirely with existing machinery.It also generalizes the pattern behind the hardcoded
harper_best_practicetool (#1560), which isextraTools-injected today because no component-contributed path exists.Design questions
static mcpTools) sufficient control over what the agent sees, or do tools need an agent-visible vs external-MCP-only annotation? [MCP] Application profile: tool generation over Resources registry #618 auto-generates verbs for every@exported Resource — the agent seeing all of them by default may be noisy or undesirable.agent/toolset.ts); confirm the same precedence holds for application tools.Out of scope (future)
Mounting external MCP servers as agent tool sources (an
agent.mcpServersconfig) — the remote variant of the same idea. In-process components cover the same-instance case without a transport, so that can be weighed separately.Refs: HarperFast/harper-pro#676, #615, #617, #618, #622, #1545, #1560, #1579.
🤖 Posted by Claude on behalf of @heskew