> ## 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.

# MCP server

> The platform's own capabilities as MCP tools — grouped into toolsets, scopable per connection, and authorized exactly like the API.

The platform exposes its own capabilities as MCP tools, so a model or an assistant can operate it
directly rather than through generated HTTP calls. This page covers what is on that surface, how to
narrow a connection to the part you want, and how a tool call is authorized. It is the mirror image
of the [MCP Gateway](/manage-your-agents/build/mcp-gateway), which is the path for exposing *your*
tools to agents.

## The two MCP surfaces

Getting these the right way round matters:

| Surface                          | Direction               | What it is                                                                        |
| -------------------------------- | ----------------------- | --------------------------------------------------------------------------------- |
| **MCP server** (`/internal/mcp`) | Inbound to the platform | The platform's own capabilities as tools, for a model or assistant to call        |
| **MCP Gateway** (`/gateway/mcp`) | Outbound from an agent  | Your own MCP servers and OpenAPI surfaces, exposed to agents under gateway policy |

## What is on it

Entries are tools, resources, and prompts, grouped into **toolsets** by the job they do:

| Toolset      | What it covers                                                                                                       |
| ------------ | -------------------------------------------------------------------------------------------------------------------- |
| `core`       | Overview, search, get, listing available agents, metrics                                                             |
| `agents`     | Managing agents, schedules, credentials, integrations, hosted agents, notification sinks                             |
| `runs`       | Invoking an agent synchronously or asynchronously, waiting on runs, cancelling one, loading an artifact              |
| `knowledge`  | Searching knowledge, searching and saving memory                                                                     |
| `slack_bot`  | The tools that act through the Slack bot — sending, reacting, reading threads and channels, user lookups, permalinks |
| `incidents`  | Managing an incident and its investigation                                                                           |
| `workflows`  | Managing workflows, triggers, and channels                                                                           |
| `gateway`    | Managing the gateway and adding a server to it                                                                       |
| `goldens`    | Managing golden scenarios, versions, and suites, running them, and reading results                                   |
| `ui`         | Listing and calling console tools                                                                                    |
| `onboarding` | Listing and loading platform skills, and onboarding tasks                                                            |

## Scoping a connection

By default a connection serves everything. Two query parameters subtract from that:

```
/internal/mcp?toolset=slack_bot,knowledge
/internal/mcp?tools=manage_agent,search_knowledge
```

| Parameter | Value                                            |
| --------- | ------------------------------------------------ |
| `toolset` | A comma-separated list of toolsets               |
| `tools`   | A comma-separated list of individual entry names |

<Tip>
  Scope deliberately. A model given the whole surface spends context on tool descriptions it will
  never call, and a narrow connection is both cheaper and easier to reason about. Point an assistant at
  the toolsets its job needs.
</Tip>

## Knowing which workspace you are in

One tool is always served regardless of scoping: **`whoami`**. A connection is bound to exactly one
workspace, nothing else on the surface reports which, and an assistant asked "which workspace am I
operating in?" would otherwise have no way to answer. It returns the active workspace, the acting
identity, and — for a person — every workspace they belong to, with the current one marked.

## Authorization

Every tool call is checked against the same capability as its HTTP equivalent. There is no shortcut
here: an assistant connected as you can do what you can do, and nothing more.

<Note>
  Authorization depends on the **arguments**, not only on the tool. A general-purpose tool resolves to
  different capabilities depending on what it is asked to act on, so being able to call a tool is not
  the same as being able to do everything it can express.
</Note>

Guardrails apply to this surface as well as to the gateway: a rule at the tool-call gate covers both
your own connected servers and the platform's own tools. See
[Standards & Guardrails](/security-and-governance/controls/standards-guardrails).

## Next steps

<CardGroup cols={2}>
  <Card title="Connect coding agents" href="/developer-tools/connect-coding-agents">
    Wiring Claude Code, Codex CLI, or Cursor to this surface.
  </Card>

  <Card title="MCP Gateway" href="/manage-your-agents/build/mcp-gateway">
    The other direction — your tools, for your agents.
  </Card>

  <Card title="Roles & permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    The capabilities a tool call is checked against.
  </Card>

  <Card title="APIs" href="/developer-tools/apis">
    The same capabilities over HTTP.
  </Card>
</CardGroup>


## Related topics

- [MCP Gateway](/manage-your-agents/build/mcp-gateway.md)
- [Interfaces](/get-started/interfaces.md)
- [Control plane](/get-started/architecture/control-plane.md)
- [Klaudia Investigator](/manage-your-agents/build/catalog/klaudia-investigator.md)
- [Built-in integrations](/manage-your-agents/build/built-in-integrations.md)