Interoperability

Kopilot is built to be driven by other tools and agents: an MCP server, portable skill manifests, and a discoverable agent manifest.

MCP server

Kopilot exposes its task and skill surfaces over the Model Context Protocol:

kopilot mcp --transport stdio

Transports: stdio (default), sse, and streamable-http (the latter two take --host and --port). A typical stdio client configuration:

{
  "mcpServers": {
    "kopilot": {
      "command": "kopilot",
      "args": ["mcp", "--transport", "stdio"]
    }
  }
}

Tools

Tool	Description
`agent_manifest`	Kopilot's interoperability manifest.
`list_portable_skills`	All enabled skills as portable manifests.
`get_portable_skill`	One skill's full manifest, including its system prompt and documentation.
`run_kopilot_task`	Run a natural-language task (`prompt`, optional `reflect` and `user`). Returns the full task result.

Resources

kopilot://agent/manifest
kopilot://skills
kopilot://skills/{name}

A task started over MCP goes through exactly the same executor as any other input: destructive commands still land in the approval queue, which is decided over the REST API by a human.

Portable skills

Every enabled skill is also published as a portable manifest over REST — GET /skills/portable for the catalog, GET /skills/portable/{name} for one skill including its prompts. Each manifest describes the skill's distribution format, its execution mode (delegated sub-agent with the four generic tools), and its safety posture (approval gating, protected namespaces). Skills load from built-in and external YAML today; the AISkill CRD is listed in manifests as a planned source.

Agent discovery manifest

GET /interop and GET /.well-known/agent-manifest.json return the same manifest: product identity, the async task API (POST /tasks, GET /tasks/history), MCP transports and tool names, the portable-skills endpoints, enabled skills, and the safety posture. These endpoints are unauthenticated by design so that other systems can discover Kopilot; task submission itself stays behind bearer auth.

Agent-to-agent protocols

Fuller agent-to-agent protocol support is planned, not shipped. What exists today is the practical bridge: a discovery manifest at a well-known path plus an authenticated async task API. The manifest says exactly this in its protocols.agent_to_agent section, so a client can detect the current state programmatically.