Skip to main content

​
Connect a service

A connection is an outside service the outpost joins as a client so the agent can use it. Something the outpost does itself, such as Overwatch or Watchdog, is a capability and lives under Settings → Capabilities. Open Settings → Connections to manage connections. Everyone can see their status and tools; administrators add, test, change and remove them. Add connection offers the built-in kinds: a TAK server, Palantir Foundry, a Compass video platform and a MediaMTX media server, each with its own form; weather comes configured by the deployment. A deployment can limit which kinds its outposts run; a kind it leaves out is not offered and has no tools. The dialog has three steps: Authentication, Connection test and Tools. When a local service answers on its usual port, its row shows Found locally; nothing is joined or imported until you choose it.

​
How tools reach the agent

Every connection’s tools land in one catalog on the outpost, with the names, descriptions and input schemas you can read on the dialog’s Tools step. The agent is not handed them wholesale: it discovers them by listing, searching and reading a schema, then calls one. A connection that is down costs its tools, not the turn. While a connection is joined, the agent’s prompt carries a paragraph about it, so it knows the service is there without being asked.

​
Use tools from Python

Inside the agent’s sandbox, configured connections expose generated, typed Python bindings under drkm.tools. Discover the modules and their function signatures from the running environment instead of assuming an integration’s API. Binding names drop the connector prefix: the catalog tool compass_feed is compass.feed.
Inside an agent sandbox
Calls run on the outpost with the current turn’s authority; the program never sees a credential or an address. The bindings are staged only inside a sandbox, so they are not available over the external SDK connection.

​
Scope and lifecycle

A connection belongs to the outpost, not to a person. Every agent turn on that outpost can use it, including turns a peer in the mesh delegates there; it is not replicated to other outposts, and per-operator sign-in is not offered. Give a service account the least access the agent needs. Built-in connections are edited from their row’s menu; a connection saved from the console can also be removed there, after which the install-configured join, if the deployment has one, is used again. Saved secrets, including connector keys and MCP sign-ins, are listed by holder and last four characters under Settings → Keys: deleting a key a connection requires removes that connection, an optional key is cleared on its own, and an MCP sign-in is signed out while its link stays. Keys set by the deployment are read-only there. Continue to MCP for third-party servers.