Bring your systems into one workflow.

Native modulesProvider capabilitiesMCP serversDiscovered tools

YAADMINRegistry · Access · Execution

Custom modulesYour environmentPermissions & approvalsControl the execution

One registry, several connection paths#

1. External system
2. Module / MCP
3. Tool registry
4. RBAC / approval
5. YAADMIN
6. User / AI workflow

Native modules wrap provider behavior. External MCP servers expose independently implemented tools. Custom Python packages can register tools for your own APIs/services within the supported SDK contracts.

Native provider integrations#

Action1 connects inventory, deployment and script operations. AD supplies directory reads. 1C uses a custom published read-only HTTP service. These are different capabilities with distinct permissions and failure behavior.

MCP connections#

STDIO process and HTTP POST tool operations support initialization, discovery and invocation. Remote names/descriptions/input schemas become registry descriptors and dynamic permissions. Read the MCP connection guide.

Scripts and custom modules#

Action1 library/inline PowerShell and generic batches are verified. A custom module can expose another operation through the registry, with its actual schema and permission model. Native n8n/surveillance/Terminal Server tools should not be assumed.

Connect with control#

Authentication establishes identity; permissions govern capability access; approval authorizes a particular execution. Personal HTTP MCP credentials remain owner-scoped and fail closed when missing.

Connect a server · Build a module · Configure permissions