Skip to main content
Kapso’s MCP gates expose optional knowledge, research, experiment-history, and repository-memory tools to coding agents. Each gate declares its dependencies in the central registry, so a missing API key or executable is handled before Claude Code starts instead of surfacing as a failed tool call during an experiment.

Gate registry

GateDefinition.required_env checks for a non-empty value. required_commands uses the system command lookup. These checks establish that a dependency is configured; they do not make a network request or prove that a credential is valid.

Failure policies

resolve_gates accepts three policies: Unknown gate names and unknown policy names are always configuration errors; they are never skipped.
The request order is preserved and duplicate names are removed. Diagnostics contain dependency names only—never credential values.

Building agent configuration

get_mcp_config resolves capabilities first and returns servers and allowed tools only for enabled gates:
Explicit path arguments satisfy the corresponding environment requirement and are forwarded only to the bundled MCP subprocess. Kapso uses the running Python interpreter for that subprocess, which avoids relying on a separate python executable on PATH. If all internal gates are omitted, no empty bundled server is created. External gates retain their own MCP server and tool-name prefix. The generic strategy defaults to warn, because its knowledge integrations are optional enrichment:
Use error for a reproducible campaign where every configured knowledge source is mandatory. Use skip when optional capabilities are expected to vary across machines and warnings would be noisy.

Adding a gate

Dependencies belong beside the tool definition, not in a search strategy:
For a bundled gate, also register its ToolGate class in GATE_CLASSES. For an external gate, set both command and server_name. Add hermetic resolution tests for missing and available dependencies; live credential tests should remain opt-in.