Permission boundary
Decide which tools are read-only, which tools can change external state, and which actions require a human review before they run.
Tool access
Use this page when an assistant needs to reach files, browser state, APIs, or services without turning every request into blind automation.
Decide which tools are read-only, which tools can change external state, and which actions require a human review before they run.
Expose names, inputs, outputs, limits, and failure states clearly enough that the assistant can choose a tool without inventing capabilities.
Keep tool calls visible with the source context, selected parameters, observed result, and next decision so a user can inspect the run.
A useful private assistant should know what it may read, what it may change, what evidence is enough, and when it must pause. MCP gives the assistant a structured tool boundary; Coachix keeps that boundary close to private knowledge, reusable skills, model routing, and the visible console.
Start with read-only tools when the risk is uncertain. Add write or deploy actions only after the task has a named owner, expected input, expected output, rollback path, and a review point for sensitive changes.