> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Overview > The four programmatic surfaces — REST API, Python SDK, Go SDK, and MCP server — and which one to reach for. Everything the console does is reachable programmatically, through four surfaces that exist for different jobs. This page tells you which one you want, so you do not build against the wrong one and discover it later. Each has its own page with the detail. ## Which surface | You want to… | Use | Why | | ------------------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Script or automate the platform itself — create an agent, invoke it, read a run | [The REST API](/developer-tools/apis) | Everything the console does, under one versioned HTTP surface | | Build an agent in Python | [The Python SDK](/developer-tools/python-sdk) | The worker runtime, agent definition, evidence, and credential delivery | | Build an agent in Go | [The Go SDK](/developer-tools/go-sdk) | The same worker contract with no Python in the container | | Let a model or an assistant operate the platform | [The MCP server](/developer-tools/mcp-server) | The platform's own capabilities as MCP tools, governed by the same permissions | | Work from your editor or terminal assistant | [Connect coding agents](/developer-tools/connect-coding-agents) | Wire Claude Code, Codex CLI, or Cursor to your workspace | ## The distinction that matters most **Two of these are for operating the platform, and two are for building the agents that run on it.** * The REST API and the MCP server are *client* surfaces. They call the platform. A script, a CI job, or a coding assistant uses them to create, invoke, and inspect things. * The SDKs are *worker* surfaces. Code written against them **is** the agent: it registers, receives runs, and reports evidence. A worker dials out and serves nothing, so there is no endpoint of yours for anyone to call. Getting this backwards is the common mistake. If you are asking "how do I make the platform do something", you want the API or the MCP server. If you are asking "how do I make my code available as an agent", you want an SDK. ## What they share All four surfaces resolve to one identity in one workspace, and every action is checked against that identity's [permissions](/security-and-governance/identity-and-access/roles-permissions) — including each MCP tool, which is authorized against the same capability as its HTTP equivalent. There is no surface that bypasses the permission model. Governed mutations and selected sensitive reads are audited, and a run's evidence records its instrumented execution — ordinary reads are not audit entries. | Surface | Authenticates with | | ------------------ | ------------------------------------------------------------------------------------------------ | | REST API | An [API key](/security-and-governance/identity-and-access/api-keys) as a bearer token | | MCP server | An API key, or OAuth where the deployment offers it | | Python and Go SDKs | A [worker token](/security-and-governance/identity-and-access/agent-identity) bound to one agent | ## Next steps Base URL, authentication, errors, and the interactive reference. Build a worker, emit evidence, test it locally. The platform's own tools, and how to scope a connection. Claude Code, Codex CLI, and Cursor against your workspace. ## Related topics - [Overview](/get-started/overview.md) - [Integrations overview](/manage-your-agents/build/integrations-overview.md) - [Evaluations](/manage-your-agents/optimize/evaluations.md) - [Onboarding](/get-started/onboarding.md) - [Modules & workflows](/modules-and-workflows/overview.md)